You are not logged in.
I have 40/40Mbit internet connection but the lookup for pages is so slow on eth0. Pages are loaded sometimes in 5 or 10 or 15 seconds and more, so eg. in firefox there's 15 seconds 'Waiting for bbs.archlinux.org...' etc. When I'm on wlan0 it works good. The problem occurs only on eth0. I think it has something to do wit my network settings. There's LAMP on my laptop with wildcards virtual hosts working together with dnsmasq. Please help me to check what's wrong on my install of Arch.
/etc/hosts
#
# /etc/hosts: static lookup table for host names
#
#<ip-address> <hostname.domain.org> <hostname>
127.0.0.1 localhost.localdomain localhost arch mysql devel dev
::1 localhost.localdomain localhost arch
# End of file
/etc/resolv.conf
nameserver 127.0.0.1
nameserver 8.8.8.8
nameserver 8.8.4.4
# Generated by NetworkManager
nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 193.110.186.2
# NOTE: the libc resolver may not support more than 3 nameservers.
# The nameservers listed below may not be recognized.
nameserver 127.0.0.1
nameserver 193.110.186.240
ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.4 netmask 255.255.255.0 broadcast 192.168.1.255
ether 10:1f:74:e9:76:5b txqueuelen 1000 (Ethernet)
RX packets 37780 bytes 38433892 (36.6 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 50321 bytes 11979344 (11.4 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
loop txqueuelen 0 (Local Loopback)
RX packets 2066 bytes 179277 (175.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 2066 bytes 179277 (175.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.3 netmask 255.255.255.0 broadcast 192.168.1.255
ether d0:df:9a:ec:18:cd txqueuelen 1000 (Ethernet)
RX packets 17052 bytes 5592525 (5.3 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 3730 bytes 787978 (769.5 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
/etc/dnsmasq.conf
port=53
domain-needed
bogus-priv
strict-order
address=/localhost/devel/dev/mysql/127.0.0.1
listen-address=127.0.0.1
bind-interfaces
Last edited by 5ulo (2013-04-29 16:21:27)
Offline
Two things I notice... though I have no idea whether either is potentially causing you issues.
First, there is an nss module in systemd that makes it so editing the /etc/hosts file is no longer necessary. I don't know that is is harmful to have it the way you do, but it would probably be wise to change it to the vanilla form.
Second, your /etc/resolv.conf is totally f*cked up. I am not sure how you got it like that, or how you managed to have NetworkManager append its crap to the end of the file. But even if you had not been reading the copy/paste while you were doing it, I would have somewhat expected that you would have noticed that you have 500 namesevers which include duplicates. But really, if you are copying and pasting things here for others to read and debug, I would certainly hope that you yourself would have taken at least a moment to read through these files as well.
Offline
I always recommend to run e.g. bind (or unbound) locally, then /etc/resolv.conf will just contain:
nameserver 127.0.0.1
Offline
I followed Arch Wiki > Dnsmasq tutorial. There was some resolv.conf.head which puts 127.0.0.1 at the top of the resolv.conf in order to use dnsmasq for localhost. Now my resolv.conf looks like this
nameserver 127.0.0.1
# Generated by NetworkManager
nameserver 8.8.8.8
nameserver 8.8.4.4
The problem on eth0 still occurs. wlan0 is safe
Offline
Are you calling it specifically a *DNS* problem, as opposed to some other kind of network problem?
E.g., a common fix for eth0 going through an Internet router is:
ip link set dev eth0 up mtu 1492
Google that
Offline
You can "dig domain" (dig is in the dnsutils package) to see the query time. dnsmasq should cache the queries, so asking about the same domain for a second time should be quicker. See if queries on eth0 are indeed slower than on wlan0.
Offline
dig youtube.com
eth0
; <<>> DiG 9.9.2-P2 <<>> youtube.com
;; global options: +cmd
;; connection timed out; no servers could be reached
wlan0
; <<>> DiG 9.9.2-P2 <<>> youtube.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36861
;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;youtube.com. IN A
;; ANSWER SECTION:
youtube.com. 300 IN A 173.194.39.130
youtube.com. 300 IN A 173.194.39.137
youtube.com. 300 IN A 173.194.39.134
youtube.com. 300 IN A 173.194.39.142
youtube.com. 300 IN A 173.194.39.136
youtube.com. 300 IN A 173.194.39.129
youtube.com. 300 IN A 173.194.39.132
youtube.com. 300 IN A 173.194.39.131
youtube.com. 300 IN A 173.194.39.135
youtube.com. 300 IN A 173.194.39.128
youtube.com. 300 IN A 173.194.39.133
;; Query time: 28 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Apr 28 20:02:58 2013
;; MSG SIZE rcvd: 216
@brebs will google for that
Offline
What does "dig @8.8.8.8 youtube.com" on eth0 show?
Offline
dig @8.8.8.8 youtube.com
; <<>> DiG 9.9.2-P2 <<>> @8.8.8.8 youtube.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27376
;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;youtube.com. IN A
;; ANSWER SECTION:
youtube.com. 163 IN A 173.194.39.137
youtube.com. 163 IN A 173.194.39.136
youtube.com. 163 IN A 173.194.39.134
youtube.com. 163 IN A 173.194.39.131
youtube.com. 163 IN A 173.194.39.142
youtube.com. 163 IN A 173.194.39.135
youtube.com. 163 IN A 173.194.39.133
youtube.com. 163 IN A 173.194.39.129
youtube.com. 163 IN A 173.194.39.130
youtube.com. 163 IN A 173.194.39.128
youtube.com. 163 IN A 173.194.39.132
;; Query time: 20 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Apr 28 20:21:48 2013
;; MSG SIZE rcvd: 216
but sometimes it timed out
Offline
So is this a problem that has recently started to occur, or has it always been like this?
Offline
eth0 wasn't that slow as I remember. Last two months I was only on wlan0. Tried eth0 yesterday and it was so sloow. I will try eth0 in my office tomorrow. Maybe it has something to do with my DD-WRT router.
Offline
See how often you get timeouts with "dig youtube.com", "dig @8.8.8.8 youtube.com" and "dig @8.8.4.4 youtube.com". Does "dig youtube.com" ever get through? If it does, what server is listed?
The way you probably have it set up, dig/Firefox/whatever first tries asking 127.0.0.1, when it fails it tries asking 8.8.8.8, then 8.8.4.4. Asking 127.0.0.1 makes dnsmasq ask 8.8.8.8 and 8.8.4.4. And it seems you have problems connecting to 8.8.8.8 and 8.8.4.4 on eth0, for whatever reason. You could try with your ISPs DNS servers instead. Or OpenDNS (208.67.222.222 and 208.67.220.220, I believe).
To make things clearer, you could leave "nameserver 127.0.0.1" in resolv.conf, set dnsmasq to use resolv.conf.dnsmasq and put those non-127.0.0.1 addresses there.
Offline
What happens if you log into your DD-WRT router through ssh (or *yuck* telnet, if that is what your version runs) and try the dig commands from there?
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way
Offline
To make things clearer, you could leave "nameserver 127.0.0.1" in resolv.conf, set dnsmasq to use resolv.conf.dnsmasq and put those non-127.0.0.1 addresses there.
I can't believe... THAT'S IT! What I did:
- since resolv.conf is generated by each reboot I switched to manual DNS in network configuration and added (for eth and wlan) 127.0.0.1
- created /etc/resolv.conf.dnsmasq containing
nameserver 8.8.8.8
nameserver 8.8.4.4
- edit /etc/dnsmasq.conf and added
resolv-file=/etc/resolv.conf.dnsmasq
it works!!! I hope it will work forever
Thanks all you people!
Last edited by 5ulo (2013-04-28 19:19:41)
Offline
What happens if you log into your DD-WRT router through ssh (or *yuck* telnet, if that is what your version runs) and try the dig commands from there?
there's no dig on my router
Offline
ewaller wrote:What happens if you log into your DD-WRT router through ssh (or *yuck* telnet, if that is what your version runs) and try the dig commands from there?
there's no dig on my router
It is DD-WRT, you can fix that
(There is dig on my router)
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way
Offline
It is DD-WRT, you can fix that
(There is dig on my router)
found it.. an addon thanks
Offline
tried it in my office.. eth0 sloooooooow lookup.. wlan0 like a rocket.. so the problem still here. I was happy only for a moment
Offline
Do you get packet loss when pinging from eth0?
Offline
no packet loss but the progress of ping is like this:
$ ping archlinux.org
delay few seconds
PING archlinux.org (66.211.214.131) 56(84) bytes of data.
delay 5-15 seconds and then the output looks like normal
64 bytes from gudrun.archlinux.org (66.211.214.131): icmp_seq=1 ttl=45 time=127 ms
64 bytes from gudrun.archlinux.org (66.211.214.131): icmp_seq=32 ttl=45 time=126 ms
64 bytes from gudrun.archlinux.org (66.211.214.131): icmp_seq=33 ttl=45 time=126 ms
64 bytes from gudrun.archlinux.org (66.211.214.131): icmp_seq=34 ttl=45 time=126 ms
...
Offline
Have you tried other DNS servers, as mentioned earlier by me? You can use "dig @server domain" to ask different servers.
Offline
yes.. openDNS and also my ISP DNS.. the problem persists only on eth.. wlan ist OK
Offline
What happens if you ping those DNS servers? Any packet loss? How often do you _not_ get timeouts when using dig? What is the output of "ip -s link show eth0"? I understand it now works at home, but not in your office?
Offline
After you ^C'd on your ping, did ping report packet loss?
Offline
you should check with tcpdump what's going on.
run on a shell:
sudo tcpdump -i eth0 port 53
and then in another one query a bunch of dns servers and see what happen on the net.
Offline