Score:0

debian wheezy has packet loss on ping

gb flag

There is an old debian wheezy server in my office. Any network operations involving this server are very slow, whether ssh, scp, or using its Apache web server. Pinging from inside this wheezy server to anything else on the local network has high packet loss (e.g. 50-80%), which explains why it is so slow.

Any ideas on what could be causing this? Not sure if this is correlation or causation but the slowdown happened around the same time they replaced the RAM in the computer. Normal commandline operations, when not typing them over a network ssh connection, seem to work fine in terms of speed.

Score:1
ru flag

Process of Elimination

There are many links in the chain from one location on the network to another. Try and rule out parts of the chain to help identify the issue.

From a client on the network to that wheezy server there would at least be

  • client os
  • client network card
  • client cable (or wifi signal and wifi access point)
  • at least 1 network switch, maybe more, each with at least 1 cable between
  • wheezy's network cable
  • wheezy's network card
  • wheezy's OS

Since you seem to already suspect the issue is on the wheezy server, try plugging in another device instead of the wheezy server to the same network cable and see if it has the same issue. Then you should have a good idea of what side of that cable (or the cable itself) has an issue.

You could also boot the wheezy server from a linux live cd (doesn't have to be wheezy) to see if there's something wrong with the software it's running, or if it's hardware related.

Duplicate IP?

Another completely separate issue may be occurring, in that there may be a duplicate IP address on the network, and a whole lot of the packets are going to the wrong device. An easy to explain way to check for this would be to,

  • try and ping the wheezy server IP address with the wheezy server powered off. If you get a response then you have a duplicate.
  • If you didn't get a response, it may just be firewall blocked by the other device, look at the arp table of the thing running ping and check the MAC address for the wheezy IP, and if it has changed you have a duplicate.

Duplicate MAC? In these days of virtualised servers it is also possible to have duplicate MAC addresses, which would also result in many dropped packets. This is harder to scan for, particularly if the device with the duplicate MAC address has a different IP address. If you have a managed switch you could look at its MAC table and see if the same MAC address is visible on multiple ports, or when unplugging the wheezy server, the MAC address changes port. Don't worry if multiple MACs are listed for a single port, as that is most likely just another switch connected to that port.

gb flag
With wheezy server powered off I get a "Destination Host Unreachable" message when pinging. The arp table (arp -a in terminal) brings up <incomplete> as the MAC address. The same network cable works fine when connected to other devices. Debian wheezy cannot ping 8.8.8.8, the DNS server as well, and thus cannot access the wider web, so it must be an OS or network card issue.
gb flag
There was a duplicate IP problem, but not in the troubleshooting way listed above. See my solution for an elaboration
Score:0
gb flag

In my router settings the address associated with my debian wheezy device, 192.168.1.97, was mapped to a different MAC address than my eth0 port. Changing the IP binding in the router to the correct MAC address fixed the issue, though removing that IP address from the IP binding settings would also probably have worked.

ru flag
For the benefit of others, what make and model is that router?
gb flag
TPLink TL-WR941HP
ru flag
For reference this setting looks to be https://www.tp-link.com/us/support/faq/1915/ and is designed to make the listed IP address only useable by the bound MAC address.
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.