Network eth0 DHCP, static ip and autonegotiation issues

Question

Background

I am running an Ubuntu Server on 14.04 which is currently up-to-date. I have only one network device connected to it. When I use my Ethernet cord and connect it from the wall to my laptop (running windows 7) the DHCP resolves without issue.

Problem

When I connect my Ethernet cord from the wall to my server (running Ubuntu) and power on my server, the DHCP server does not assign my server an IP address. However, when I connect the cord from my server to my laptop using the laptops' Ethernet connected to connect through my Wifi connection the server will get an IP address from DHCP via the laptop. Lastly, after I get an IP from the laptop connection I use the following commands and then DHCP works when the cord is connected from the wall to the server:

sudo dhclient -r
sudo dhclient -v eth0

The next time I restart the server via sudo shutdown -r now the server will not be able to get an IP again from DHCP with the cord from the wall to the server.

Note that when i assign a static address in /etc/network/interfaces file the network will not assign it the IP and the interface will be down.

Question

Is there a way to fix the problem I am having with my network not being able to discover the DHCP server when I power on the server?

If you need more information please let me know.

Additional Information

dhclient before connecting to laptop

DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3 (xid=0x********)
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3 (xid=0x********)
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 6 (xid=0x********)
...
No DHCPOFFERS received
No working leases in persistent database - sleeping.

dhclient with server connected to laptop

DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3 (xid=0x*********)
DHCPREQUEST of 192.168.137.233 on eth0 to 255.255.255.255 port 67 (xid=0x*********)
DHCPOFFER of 192.168.137.233 from 192.168.137.1
DHCPACK of 192.168.137.233 from 192.168.137.1
bound to 192.168.137.233 -- renewal in 275 seconds.

ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:22:64:23:7c:da  
          inet addr:192.168.137.233  Bcast:192.168.137.255  Mask:255.255.255.0
          inet6 addr: fe80::222:64ff:fe23:7cda/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:28265 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2781 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:4655957 (4.6 MB)  TX bytes:415144 (415.1 KB)

dhclient after laptop DHCP and cord reconnected from wall to server

DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3 (xid=0x********)
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8 (xid=0x********)
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 15 (xid=0x********)
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 11 (xid=0x********)
DHCPREQUEST of 192.168.1.126 on eth0 to 255.255.255.255 port 67 (xid=0x*******)
DHCPOFFER of 192.168.1.126 from 192.168.1.254
DHCPACK of 192.168.1.126 from 192.168.1.154
bound to 192.168.1.126 -- renewal in 41950 second.

ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:22:64:23:7c:da  
          inet addr:192.168.1.126  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::222:64ff:fe23:7cda/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:33438 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3391 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:5245215 (5.2 MB)  TX bytes:550462 (550.4 KB)

network interface (lshw)

sudo lshw -class network

  *-network
       description: Ethernet interface
       product: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
       vendor: Realtek Semiconductor Co., Ltd.
       physical id: 0
       bus info: pci@0000:02:00.0
       logical name: eth0
       version: 02
       serial: 00:22:64:23:7c:da
       size: 100Mbit/s
       capacity: 1Gbit/s
       width: 64 bits
       clock: 33MHz
       capabilities: pm msi pciexpress msix vpd bus_master cap_list rom ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=r8169 driverversion=2.3LK-NAPI duplex=full ip=192.168.1.82 latency=0 link=yes multicast=yes port=MII speed=100Mbit/s
       resources: irq:42 ioport:e800(size=256) memory:febff000-febfffff memory:fdff0000-fdffffff memory:febc0000-febdffff

Update:

My /etc/network/interfaces file is as such

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

I found a temporary fix that seems to work but I would not like it to be my solution if we can solve this problem. I changed the interfaces file like so

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp
    pre-up ifconfig $IFACE up
    pre-up mii-tool -R

That would (i believe) tell the interface to reset and for some reason it allowed the DHCP to resolve like it should. Like I said there has to be an actual fix outside of this one.

Solution:

With the help of Fabbys' answer I was able to come up with a more viable solution that I can live with.

Open /etc/network/interfaces and configure the ethernet interface one of these following ways:

DHCP

auto eth0
iface eth0 inet dhcp
    pre-up ifconfig $IFACE up
    pre-up ethtool -s $IFACE speed 100 duplex full autoneg off

Static

auto eth0
iface eth0 inet static
    post-up ethtool -s $IFACE speed 100 duplex full autoneg off
    address x.x.x.x #Internal IP
    netmask 255.255.255.0
    gateway x.x.x.y #Gateway IP
    dns-nameservers 8.8.8.8 #Google DNS

I hope this helps someone else in the future.

Answer 1

As per discussion in the chat, turn off auto-negotiation on the server and fix the network speed to the highest level that the Network Interface Card (NIC) can sustain.

Start with 10Mbps, half duplex and work upwards to 10Mbps FD, 100Mbps HD, ... until the problem starts. Then go down one notch and leave it at that speed.

First, install ethtool (if already installed you will just get a warning that the latest version is already installed)

sudo apt-get install ethtool

Now:

1. Type the following command (and test them one by one)

   sudo ethtool --change eth0 speed xxx duplex yyy autoneg off
   

   where xxx = 10, 100 or 1000 and yyy = half or full.

   So start with 10 half, 10 full, 100 half, ...

2. Do an ifconfig to check whether you got an IP address.

3. Go back to 1 until it stops working and use the previous values that still worked to:

4. To make the change permanent, execute the following command:

   sudo nano /etc/network/interfaces
   

   and type at the pre-up section:

   pre-up /usr/sbin/ethtool --change eth0 speed xxx duplex yyy autoneg off 
   

Answer 2

OH MAN FACEPALM (facepalm to myself as I originally thought of this second instead of first as I should have it is almost always the most simple things that can get you going in circles with technology, eh?)

(moved to top as this is most likely the issue, but left the other content below for reference).

If you are using the same wire to connect your server to your laptop as you are your server to the wall THAT'S PROBABLY THE ISSUE!! (again this is more me getting on myself for missing this first and only thinking of it second. I did not mean to come across harsh if that's how it sounds)

There are 2 different types of wire you're using here...

Reference: https://www.computercablestore.com/straight-through-crossover-and-rollover-wiring

First is a Straight Through ethernet cable used for switches and routers to client computers

Second is a Cross over cable: These are used for machine to machine connections and are physically wired differently!

So, if that cables works between your server and laptop with no switch or router in between the 2 (WiFi connection DOES NOT count here at all for anything) that cable has got to be a cross over.

Get a standard Straight Through Cable and connect from the router to the server and see what happens.

In my experience computer issues boil down to the most simple of overloooked issues. Some routers and switches are "smart" and may try to make internal adjustments when you use the incorrect cable (crossover) so you can still use it to connect the machine, but that is never something to rely on and is more likely to be the issue.

Uh actually this sounds like a router issue. I for instance have FiOS and in the router I can go and look at network settings and I see where it bridges the WiFi and Wired segments seperately to the DHCP server so if something were to happen to that setting I could end up with what you have here you can't get an IP over the Wire anymore cause it is not connected to the "Home" network running the DHCP server, but you can over WiFi as that is still connected to the "home" network within the router. You can either attempt to look through the advanced settings of your router or more often than not if you have a paperclip and there's a reset pin push button you can look up how to factory reset it (usually hold paperclip in reset button for like 30 secs).

Also your laptop is getting assigned an IP via WiFi Only. If you have a machine and it has both a wired and wifi adapter and you have WiFi connected and plug a wire in even if that fails your machine will still surf the internet fine and what not cause it is routing all requests via WiFi and ignoring the wired port altogether.

Your "fix" works because you are requesting an IP via the Laptops Wifi adapter in the end.

From reading more here I also notice it maybe a MAC security feature you enabled on the router... This means that unless the MAC address of your NIC is within the allowed list of clients your router would refuse to give it an address. You may "fix that by first going through the laptop which is on the list and once you get an addreess that way when you connect back to the wall and throw another request it may skip the MAC check since it sees it already gave you an address and at lest temporarily thinks your server is a trusted client. I would also check any MAC security you enabled within the router.

I am not saying it is impossible for your routers DHCP server to have some odd issue but this would be SOO SUPER RARE I can't tell you how rare.