Slow broadband connection on Linux machine behind hub, browser spends a long time "resolving host"

Are your DNS settings configured proper ? Ones you post after resolving download is going well , see if your server addresses are the same as Wins'  first .

Check /etc/resolv.conf on the SuSE box. I expect that you'll find more than one name server listed and that the first is invalid. That causes all DNS looks to have to time out on the first name server before trying the second. A common mistake is to have:

nameserver 127.0.0.1
nameserver 123.4.5.6

and if there not a copy of named running on the local machine (and correctly configured) you'll see this behaviour.

Here is more information that may help:

Settings in Yast

Network address setup: Automatic address setup via DHCP

Host name and server configuration

Host Name: linux
Domain Name: local
"Change host name via DHCP" is checked.
Nameservers: 192.168.0.1
Domain Search: [left blank]
"Update name servers and search list via DHCP" is checked.

-----
Contents of  /etc/resolv.conf file:

### BEGIN INFO
#
# Modified_by:  dhcpcd
# Backup:       /etc/resolv.conf.saved.by.dhcpcd
# Process:      dhcpcd
# Process_id:   3273
# Script:       /sbin/modify_resolvconf
# Saveto:
# Info:         This is a temporary resolv.conf created by service dhcpcd.
#               The previous file has been saved and will be restored later.
#
#               If you don't like your resolv.conf to be changed, you
#               can set MODIFY_{RESOLV,NAMED}_CONF_DYNAMICALLY=no. This
#               variables are placed in /etc/sysconfig/network/config.
#
#               You can also configure service dhcpcd not to modify it.
#
#               If you don't like dhcpcd to change your nameserver
#               settings
#               then either set DHCLIENT_MODIFY_RESOLV_CONF=no
#               in /etc/sysconfig/network/dhcp, or
#               set MODIFY_RESOLV_CONF_DYNAMICALLY=no in
#               /etc/sysconfig/network/config or (manually) use dhcpcd
#               with -R.  If you only want to keep your searchlist, set
#               DHCLIENT_KEEP_SEARCHLIST=yes in /etc/sysconfig/network/dhcp or
#               (manually) use the -K option.
#
### END INFO
nameserver 192.168.0.1

----

Contents of  /etc/host.conf file:

# /etc/host.conf - resolver configuration file
#
# Please read the manual page host.conf(5) for more information.
#
#
# The following option is only used by binaries linked against
# libc4 or libc5. This line should be in sync with the "hosts"
# option in /etc/nsswitch.conf.
#
order hosts, bind
#
# The following options are used by the resolver library:
#
multi on

--------

A Windows ME machine connected to the same router with normal broadband behavior has these settings:

Specified IP address: 192.168.0.50
Subnet Mask: 255.255.255.0
DNS: enable
Host: anything
Domain: [left blank]
Server search order: 192.168.0.1
Gateway: 192.168.0.1
Allow binding to ATM: NO

-------

Here are some setting from the router (Dlink DI-614+):

LAN
MAC Address
      00-40-05-5A-7F-7D
IP Address
      192.168.0.1
Subnet Mask
      255.255.255.0
DHCP Server
      Enabled
        
WAN
MAC Address
      00-40-05-5A-7F-7E
Connection
      DHCP Client Connected  
IP Address
      172.16.1.11
Subnet Mask
      255.255.0.0
Default Gateway
      172.16.0.254
DNS
      172.16.0.254

The set up of the SuSE box looks okay so maybe it is something related to the DNS proxy on the D-link. I'd suggest editing /etc/resolv.conf and setting the nameserver IP to be that used by the D-link (172.16.0.254).

I edited the /etc/resolv.conf to use the nameserver used by the D-link (172.16.0.254), but I had to uncheck the "Update name servers and search list via DHCP" in YAST to get it to stick. (Otherwise, it would automatically go back to the IP address of the router, 192.168.0.1.)

The /etc/resolv.conf at the bottom now reads :

domain local
nameserver 172.160.0.254

The behavior hasn't changed, however.

...but after shutting down computer and restarting, I had to go back to YAST and re-select the "Update name servers and search list via DHCP" in the Network Card settings, which then recreated the /etc/resolv.conf file with the "nameserver 192.168.0.1" setting, which had disappered on reboot. Otherwise, I would have no connection at all. It appears the DHCP on the router is dictating things.

The router is primarily being used to share a DSL connection. There is no file sharing between the computers on the LAN or at least none setup. Two of the computers, the Linux box and a Windows ME machine, I have control over. I could try to see if I could set up sharing between them and see what happens.

Let's see if we can pin down where the problem is. On the SuSE box execute 'host www.suse.com'. If there's no problem with DNS resolution you should get an answer within a second or two. Next we should try an FTP to some reasonably fast site. I don't know where you are located,  but ftp.uu.net () is usually quite responsive from most anywhere, so try:

ftp 192.48.96.9
Connected to 192.48.96.9 (192.48.96.9).
220 FTP server ready.
Name (192.48.96.9:jlevie): anonymous
331 Guest login ok, send your complete e-mail address as password.
Password: your-email-addr
ftp> get gzip.tar

If the connection is established quickly, but the download takes extraordinarily long that might indicate a link mode negotiation between SuSE and the hub/switch it connects to.

The response to the host command was almost instantaneous. I am located in Seattle. The ftp connection was a second or two. The download was completed in not much more. Transcript of the session below:

lxuser@linux:~/Documents/Linux> host www.suse.com
www.suse.com has address 195.135.220.3

lxuser@linux:~/Documents/Linux> ftp 192.48.96.9
Connected to ftp.UU.NET.
220 FTP server ready.
Name (192.48.96.9:lxuser): anonymous
331 Guest login ok, send your complete e-mail address as password.
Password:
....
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> get gzip.tar
local: gzip.tar remote: gzip.tar
500 'EPSV': command not understood.
227 Entering Passive Mode (192,48,96,9,240,196)
150 Opening BINARY mode data connection for gzip.tar (798720 bytes).
100% |*************************************|   780 KB  142.53 KB/s    00:00 ETA
226 Transfer complete.
798720 bytes received in 00:05 (140.05 KB/s)
ftp> close
221-You have transferred 798720 bytes in 1 files.
221-Total traffic for this session was 800305 bytes in 1 transfers.
221-Thank you for using the FTP service on neo-ftp.uu.net.
221 Goodbye.
ftp>

That is normal response and indicates that basic networking to Internet sites appears to be working properly. Lets try and FTP to the same site by name this time and see if the connection is as fast. Since we've proved that data transfers occur at DSL speeds it will suffice to simply open and then close the FTP session to ftp.uu.net.

If that also works normally, but  a browser is still slow check the browser's configuration and make sure that it isn't trying to use a proxy.

There are other tests we can do to pin down the problem, but lets see what happens here first.

The FTP connection to ftp.uu.net took much longer, about 15 seconds.

I finally got someone at SuSE to respond after weeks (the Novell takeover apparently disrupted their tech support system) and was given the simple fix below. It worked! I want to thank those who responded, especially jlevie, for their effort. What we discovered here helped me rule out what the problem wasn't. And that was a long way from where I started, again thanks. (I'm still puzzled why Konqueror was affected by something that is supposed to be specific to Mozilla.)

Suggested by SuSE:

Mozilla and IPv6

Applies to: SUSE LINUX 9.0
Symptom

When entering an URL in Mozilla, Mozilla freezes.
Cause

By default, Mozilla uses IPv6 for name resolution. However, if you use SuSEfirewall2, IPv6 is locked for security reasons, so the request will be ignored.
Solution

If you do not need IPv6 support, deactivate it by changing the file /etc/modules.conf as follows.

Change

alias net-pf-10 ipv6
#alias net-pf-10           off

to

#alias net-pf-10 ipv6
alias net-pf-10           off

This must be specific to SuSE 9.0 since I've never observed this on other Linuxen. I don't think we would have figured this one out very quickly, but I'm glad you found a solution.

Hey vmunoz, I've been struggling with the exact same issue with a D-Link 614+ as you, only I'm using Fedora Core 2 Test 1. I've been running with that same "alias net-pf-10 off" tweak as you have, and it seemed to do the trick. Someone pointed me to this site: http://www.numion.com/YourSpeed . That showed me that I was only getting one tenth of the speed from Linux that I was getting from the same box dual-booting into Windows XP.  Last night I finally tried what I should have tried a long time ago - I removed the D-Link and tried a direct connect. Boom! All of a sudden my Linux connection was faster than the Windows side. So that made me try something else D-Link related - upgrading the firmware. I hadn't done that for a while, so I figured what the heck. And it worked! My speeds are way high now; one test peaked at almost 500kbps. Now I need to remove that net-pf-10 change to see if that makes any difference now.

Bottom line - upgrade your D-Link firmware! (take note of any settings/passwords first, because the upgrade will wipe them out)

randy

i had almost the exact same problem where by mozilla would take ages to resolve hosts.  Im using a D-Link DSL-504.  I disabled the DNS proxy function on the router and set the DHCP server to issue the DNS addresses of my ISP and this fixxed the problem immediately.  Id say that if i could be bothered to update the firmware it would fix the problem too.