On one of my linux computers the network is acting weird. It's really slow when connecting to any computer outside of my local network (~1.5 Kb/s no matter what server). At the same time it has good speed within the local network (>4 Mb/s).
Dmesg does not report any errors related to the loaded module, dns is working, the mtu-size is fine. I'm using a wired connection, not wlan. I have tried with different cables and different ports on the router, the problem persists.
ip -s -s link eth0 <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped overrun mcast 161453 227 49 0 0 0 RX errors: length crc frame fifo missed 0 0 0 49 109
Tx has no errors.
ethtool eth0 Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Supported pause frame use: No Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Advertised pause frame use: No Advertised auto-negotiation: Yes Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Link partner advertised pause frame use: Symmetric Link partner advertised auto-negotiation: Yes Speed: 100Mb/s Duplex: Full Port: MII PHYAD: 32 Transceiver: internal Auto-negotiation: on Supports Wake-on: pumbg Wake-on: d Current message level: 0x00000007 (7) drv probe link Link detected: yes ethtool -S eth0 NIC statistics: tx_ok: 17330 rx_ok: 24344 tx_err: 0 rx_err: 0 rx_fifo: 1034 frame_align: 0 tx_ok_1col: 0 tx_ok_mcol: 0 rx_ok_phys: 24295 rx_ok_bcast: 49 rx_ok_mcast: 0 tx_abort: 0 tx_underrun: 0 rx_frags: 0
Ok, so I just proxied the traffic through another local machine and managed to get xorg, firefox etc down and I just realized that:
So it seems that it's related to having FEW active connections (I also get a higher degree of fifo errors when having one single connection). Could this be a driver issue?
1.5Kb/s is the right size for one packet a second. I've seen cases where the TCP Delayed Ack wasn't working and packets were getting sent with 200ms delays, but 1000ms is something else entirely. This is the point where I'd break out the packet sniffer and see what's happening on the wire.
Since you are seeing different behavior from on-network and off-network traffic, I'd grab captures in three areas:
2 and 3 are very important, since it can help you figure out if your border device is somehow filtering things it shouldn't be or if the remote side is doing things it shouldn't. You're looking for anomalies, and as there are a large number of ways things can fail this way I can't give you specific guidance on how to identify things that are there. Wireshark has some very good error-highlighting, which may tell you what's going on just by loading the captures.
User contributions licensed under CC BY-SA 3.0