Where I'm living now, the internet connection (wired) shows the following weird symptoms. They seem to be independent of whether I use host names or IP addresses.
- Pinging works
- Skype works
- Wget connects, but never receives a response. (Keeps waiting at "HTTP Request sent, awaiting response" until timeout.)
- Except for a small subset of domains, for which it works.
- ssh commands (
ssh host ls
) works. - Interactive ssh works for a short while, but hangs quickly, e.g. during the first
ls
— at the same point every time. - Under Windows, everything works fine.
What can I do to diagnose this further? So far, I've just been looking at the application layer. Since there is an apparent internet connection, there must be some way to tunnel Firefox, but I'd like to pin down the problem first.
It is very likely related to large packets not making their way through. I've found out that there is an MTU, but setting it for eth0 does not solve my problem. I think that I'm behind PPPOE and a router. The external IPs are the same on Windows and Linux.
Output of some commands:
ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1024 qdisc mq state UP qlen 1000
link/ether 00:26:aa:aa:aa:61 brd ff:ff:ff:ff:ff:ff
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000
link/ether c4:17:aa:aa:aa:ff brd ff:ff:ff:ff:ff:ff
4: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
link/ether 5e:49:aa:aa:aa:27 brd ff:ff:ff:ff:ff:ff
ip route show
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.4 metric 1
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1
169.254.0.0/16 dev eth0 scope link metric 1000
default via 192.168.1.1 dev eth0 proto static
ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1024 qdisc mq state UP qlen 1000
link/ether 00:26:2d:78:ac:61 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.4/24 brd 192.168.1.255 scope global eth0
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000
link/ether c4:17:fe:3b:56:ff brd ff:ff:ff:ff:ff:ff
4: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
link/ether 5e:49:01:03:55:27 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
inet6 fe80::5c49:1ff:fe03:5527/64 scope link
valid_lft forever preferred_lft forever
I can send pings up to size 1468.
tim@milagros:/$ ping -M do -c 1 -s 1470 stackexchange.com
PING stackexchange.com (64.34.119.12) 1470(1498) bytes of data.
--- stackexchange.com ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
tim@milagros:/$ ping -M do -c 1 -s 1468 stackexchange.com
PING stackexchange.com (64.34.119.12) 1468(1496) bytes of data.
1476 bytes from stackoverflow.com (64.34.119.12): icmp_seq=1 ttl=52 time=176 ms
--- stackexchange.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 176.539/176.539/176.539/0.000 ms
tim@milagros:~/projekt/perl$ ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:26:2d:78:ac:61
inet addr:192.168.1.4 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:161 errors:0 dropped:0 overruns:0 frame:0
TX packets:194 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:143947 (143.9 KB) TX bytes:67727 (67.7 KB)
Interrupt:16
Best Answer
Tim, I respectfully urge you to ignore your doubts about changing MTU. Your issue has MTU problem written all over it and I have been a professional network engineer for over 15 years.
To prove whether MTU helps, conduct tests from your linux machine using ping with the
DF
bit set in the IP header...I calculated the
-s
parameter assuming your PPPoE IP MTU is 1300 bytes. If that ping succeeds, then use-s 1472
and watch what happens... if the ping it now fails, you have conclusive proof that there is an MTU issue (assuming you have not set your Ethernet link MTU lower). FYI,-s 1472
will send a 1500-byte ethernet-payload echo-request;-M do -s 1472
sends that same 1500-byte payload with the DF-bit set in the IP header.Also remember that MTU must be set on both sides of the link... so you would need to do this on your modem as well.
EDIT
Tim, you still have not run the commands I asked you to. Let me give you an example of what is wrong with what you did (I need to modify the destination host to stackexchange.com, due to firewalling for IP fragmentation in my path to 8.8.8.8)
Negative example (using your ping flags)
Rhetorical question: how did a 64KB ping packet get through a 1500-byte ethernet segment? (see End note A) I can't help unless you post the information I am asking for. This is the same example, with
ping -M do
Positive example
ping -M do
provides information about the maximum MTU along the path (in this case, we know the first-hop ethernet segment has anIP MTU
of 1500-bytes).End Notes:
A. Your pings can be completed as a series of IP fragments, because by-default
ping
allows IP fragmentation. If you are trying to find the maximum packet size that will pass through a link, you must modify the IP header (which I illustrated with-M do
) to ensure you don't get a bunch of fragmented responses stitched together at the end. Usingping -c 1 -s 65507 64.34.119.12
: