Bug 154599 - Extremely slow name resolution, throughput is fine
Extremely slow name resolution, throughput is fine
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-04-12 18:34 EDT by Greg Martyn
Modified: 2015-01-04 17:18 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-05-08 00:24:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
tethereal capture of an outage (5.97 KB, text/plain)
2005-04-15 21:48 EDT, Greg Martyn
no flags Details

  None (edit)
Description Greg Martyn 2005-04-12 18:34:52 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Firefox/1.0.2 Fedora/1.0.1-1.3.1 StumbleUpon/1.9992

Description of problem:
I am getting lots of timeouts when trying to browse the web. Once I get a website loaded, it is generally fast, but loading the first page sometimes takes several tries.

I dual-boot with Windows XP and although there are some blips in service, they are nowhere near as noticeable as those under Linux.

This problem also appeared while running Mandrake 10.2

There are no problems with connecting to other computers on our LAN

Version-Release number of selected component (if applicable):


How reproducible:
Sometimes

Steps to Reproduce:
-bash-3.00# nslookup arstechnica.com
;; connection timed out; no servers could be reached

-bash-3.00# nslookup arstechnica.com
Server:         151.203.0.85
Address:        151.203.0.85#53


Additional info:

My DNS servers are provided by Verizon:
151.202.0.85
151.203.0.85
Comment 1 Greg Martyn 2005-04-12 18:41:40 EDT
Network card:
3Com Corporation 3c905C-TX/TX-M [Tornado]

DNS settings (From network configuration)
Hostname: localhost.localdomain
Primary DNS: 151.202.0.85
Secondary DNS: 151.203.0.85
Tertiary DNS:
DNS search path: localdomain

Automatically obraining IP address settings from dhcp
Automatically obtaining DNS information from provider
IPv6 configuration is off
Comment 2 Dave Jones 2005-04-12 20:50:41 EDT
what does /etc/resolv.conf look like ?

can you capture with tcpdump/tethereal a packet dump showing what happens when
you do a lookup ?
Comment 3 Greg Martyn 2005-04-15 04:06:21 EDT
[greg@localhost ~]$ cat /etc/resolv.conf
; generated by /sbin/dhclient-script
nameserver 151.202.0.85
nameserver 151.203.0.85
search localdomain

A little more on what happens:
Browsing works fine, everything is fast. Then at random times, it breaks.
The other Windows and FC machines all can't get out to the internet. Maybe
it's just DNS, maybe it's everything. Not sure yet. Anyway, after a little
while, the Windows machines are back to browsing the internet at normal
speeds, but the FC machines are still getting timeouts when browsing to new
sites. If I am able to connect to a download site with one of the FC machines
though, the download will happen at full speed.

Tomorrow I will try out using different DNS servers; see what that does.
When the problem happens again, I'll post the tethereal dump as requested.

Thank you for taking the time to work with me on this one. I know this is one
of those problems that are near impossible to pin down, and it seems like
one of those times where the user just doesn't know what they're doing,
so I just wanted to commend you for helping me. Truely great support!
Comment 4 Dave Jones 2005-04-15 15:22:43 EDT
Actually, I've seen something similar with my dsl at home, which is also
provided by Verizon.  From time to time the modem seems to 'forget' the MAC
address of the remote end of the connection.
If you run tcpdump, you'll see lots of outgoing ARP who-has traffic, followed by
a flood of responses a while later.

The modem they provided me with is a Westell (dont have the model # handy).
Do you have the same one by any chance ?

My suspicion is that this isn't a Linux problem (I see the same thing with my
Wife's Apple Powerbook), but some problem either with Verizons end of the DSL,
or the modem firmware.
Comment 5 Greg Martyn 2005-04-15 21:48:49 EDT
Created attachment 113267 [details]
tethereal capture of an outage

Here's the tethereal output when I tried to visit
http://www.KDE-Apps.org/content/show.php?content=15163

At first it fails, but I kept refreshing until it went through.

I tried to cut out background noise like kmail checking for mail; let me know
if I cut too much.
Comment 6 Dave Jones 2005-04-16 00:07:44 EDT
I guess 192.168.0.113 is your desktop machine, what is 192.168.0.1 ?
If this is your modem, I'm stuck.

If its a Linux firewall/gateway, can you run the tethereal there instead ?
Comment 7 Dave Jones 2005-04-16 00:13:44 EDT
you can make things slightly faster by disabling ipv6 if you don't use it..

add...

alias net-pf-10 off

to your /etc/modprobe.conf, and next time you boot your interfaces won't be IPV6
aware.
Comment 8 Greg Martyn 2005-04-16 00:31:17 EDT
192.168.0.113 -> my computer (now on FC3)
192.168.0.120 -> another FC3 computer
192.168.0.1 -> D-Link DI-704P router (http://www.dlink.com/products/?pid=63)
Comment 9 David Kuestler 2005-04-16 04:01:29 EDT
I have had problems with small SOHO routers. To save costs they are often
designed and tested with only windows in mind where windows uses shorter, non
standard timeouts and other network idosyncracies. They are also designed for
only 4 NATed internal hosts so if you have more than 4 internal hosts you get
intermittent responces.
Are you using it as a firewall ?
Are you using NAT ?
Do you have more than 4 internal hosts ?
Comment 10 Greg Martyn 2005-05-08 00:26:11 EDT
If I ever come up with some clear test case, I'll reopen. Otherwise, this is
just silly.
Comment 11 Greg Martyn 2005-05-08 00:26:43 EDT
Thanks for all your help though :)

Note You need to log in before you can comment on or make changes to this bug.