0

After a server restart, the server is unable to obtain an IP address through a wired ethernet interface, neither automatically nor manually.

However the green light on the back of the machine where the ethernet cable is attached, indicating activity, continues to blink at a very fast and steady rate (eg. as if some large file transfer was being made).

Obtaining an IP address has never been an issue before, and I find this very strange. Whereas normally network manager would obtain an IP automatically, this time it did not, and dhclient -v eth0 fails to get a DHCP offer.

I would like to determine at a low level what kind of traffic is going through the ethernet port, since I'm now concerned about malicious code having been inserted into the server.

How can I determine what kind of traffic is going through the device, at a low level?

I have tried nethogs, but this evidently is not the appropriate tool.

Could tcpdump or wireshark show all the traffic going through the interface? Since the server is offline, haven't been able to test this since I would have to download the appropriate dependencies via another system.

Since I did disable some seemingly non-essential services (and I suspect this is most likely the culprit), are there any services necessary for obtaining an IP address from a wired ethernet?

I've produced a pastebin of a session at the machine in question, including the outputs of ifconfig, the running services, and the failed attempt to obtain an IP through dhclient.

Edit:

To rule out a possible router issue, I tried to verify that I could get an IP using the same ethernet cable into another machine, connected wirelessly to the same router, but in fact, the same problem occurs. So this seems to be an issue with the router's ethernet ports and not in the server configuration, and thus the question is possibly out of the scope of this forum.

I will try restarting the router through the wireless interface, but since I'm clueless about how to debug a router problem, are there any tools or expected behaviour I can use to break down this problem?

4
  • Can you send the results of the following: ifconfig, your network-scripts ifcfg-eth0 file, try doing a service network restart (if on CentOS and possibly RedHat), and any results that comes when doing that? Jul 9, 2014 at 6:00
  • I'm on Debian and I'm not able to find a ifcfg-eth. file, though I included the contents of /etc/network/interfaces. I'm still clueless as to what is going on, as well as concerned about the seeming constant activity shown by the blinking light.
    – user84207
    Jul 9, 2014 at 6:37
  • When you talk about "obtaining an IP address manually", I suspect what you really mean is that you run a DHCP client from the command line. That's not going to help, if the problem is that the DHCP server is not responding. A server shouldn't be relying on DHCP, a static configuration would be better. You can use tcpdump to debug this kind of problem, and running it on either the DHCP client or the DHCP server will provide some hints.
    – kasperd
    Jul 9, 2014 at 7:21
  • Thanks for the tip on not relying on dhcp, I will look it. Since on the LAN I can usually refer to the server by name, it hasn't seemed like a problem given my server's rather domestic usage.
    – user84207
    Jul 10, 2014 at 2:44

1 Answer 1

1

It's possible you have a faulty network port, I've seen the exact same thing happen on a server due to a power surge (same symptoms of steady link light, and no connectivity). I'd suggest confirming this by setting a static address on the interface, and then seeing if you can pass traffic once it's connected.

Something like (for example):

auto eth0 iface eth0 inet static address 10.0.0.20 netmask 255.255.255.0 gateway 10.0.0.1

And then: ifdown eth0 && ifup eth0 (as root)

Then try and ping the gateway or another machine on the network. Although this is not necessarily a definite way of determining whether it is a fauly port/card, it should help you narrow it down.

2
  • The actual problem was not faulty network port on the server's side, but on the router. It did occur after a power outage, which probably included a power surge. After a modem restart, the ethernet ports resumed working correctly, so everything in the LAN worked correctly, but the router could no longer connect to the internet. Ultimately the ISP offered to replace the router.
    – user84207
    Jul 10, 2014 at 2:37
  • Glad to hear you got to the bottom of it :)
    – Andrew
    Jul 10, 2014 at 7:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .