DHCP only works after suspend from sleep

ads103 · 2016-11-11 20:00:05

I just installed Hydrogen on a Dell Latitude E6440 connected via Ethernet to my local network. I've found that when I boot to my desktop, my DHCP just won't give me an IP address. However, once I suspend the system and wake it back up, I get an address just fine.

Naturally, I'd like DHCP to work the first time, at boot. I'm a bit at a loss on how to troubleshoot this, though. Google searches mostly turn up problems with connecting to Wi-Fi after resuming from sleep; I haven't found anything on Ethernet starting to work after resuming.

Any suggestions?

Head_on_a_Stick · 2016-11-11 20:21:09

ads103 wrote:

my DHCP just won't give me an IP address

What exactly do you mean by "my DHCP"?

BunsenLabs runs NetworkManager (which relies on isc-dhcp-client to assign the addresses), are you using this to connect?

Before you suspend, what is the output of:

systemctl --failed
sudo /sbin/dhclient eth0

For general troubleshooting you can interrogate the systemd journal with the `journalctl` command.

See https://www.digitalocean.com/community/ … stemd-logs for more on this.

ads103 · 2016-11-11 20:34:51

By "my DHCP," I mean the DHCP server on my LAN. When I hover my mouse cursor over the network manager icon in tint2, it creates a text bubble that reads, "Requesting an Ethernet network address for 'Ethernet connection 1'..."

I just tried turning my networking off and back on by right-clicking this icon and un- and re-checking, "Enable Networking." This didn't cause any changes.

Your first command generated this output:

0 loaded units listed. Pass --all to see loaded but inactive units, too.

Your second command generated no output at all (other than the prompt for my sudo password, of course.)

I suppose some of my noobishness is showing, as I've never used journalctl before. I'll check it out and see what i can see.

Head_on_a_Stick · 2016-11-11 20:59:51

ads103 wrote:

By "my DHCP," I mean the DHCP server on my LAN. When I hover my mouse cursor over the network manager icon in tint2, it creates a text bubble that reads, "Requesting an Ethernet network address for 'Ethernet connection 1'..."

Does this still happen if you define a static IP address with NetworkManager?

There are some graphical instructions buried in this thread:

http://superuser.com/questions/645487/s … orkmanager

ads103 · 2016-11-11 21:07:58

I just suspended, resumed, and statically assigned the address I got. I then rebooted, and my Internet connection came up just fine with the static assignment. But I'm hesitant to mark things as "solved" since the issue is with the DHCP.

ads103 · 2016-11-11 22:12:12

If you'll pardon the double post, I've dug up a little more info I feel I should share. I found an article where someone was in a similar situation to me, available here: http://www.debianhelp.org/node/1915. Their setup and mine aren't exactly the same, but they're similar. My Ethernet controller is an Intel I217-LM, and I'm also dual-booting Windows. I'm also using the same driver, e1000e. The solution in that thread was to disable Wake on Lan in both the bios and in Windows.

I did so. It did not change anything. I'm still unable to get an IP from my DHCP server. Does anyone know of, perhaps, an alternate driver I could try? Or something of that nature? I've made sure all packages on my system are up to date using apt-get dist-upgrade, so I'm certain I'm not using an old version of the driver.

Additionally, I turned off my wi-fi using the network manager icon in tint2, and I ran dhclient -v in a terminal. It produced a message that said, "No broadcast interfaces available." I looked in the man page and found the -w flag, which forces dhclient to try even if it doesn't find a broadcast interface. That seems to apply to my situation, since my Ethernet interface is on the backside of a laptop dock. I ran it again like so, forcing it to use my eth0 interface:

sudo dhclient -v -w eth0

It produced this output:

Internet Systems Consortium DHCP Client 4.3.1
Copyright 2004-2014 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth0/84:7b:eb:35:e4:50
Sending on   LPF/eth0/84:7b:eb:35:e4:50
Sending on   Socket/fallback
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 10
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 18
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 15
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 10
No DHCPOFFERS received.
Trying recorded lease 192.168.255.75
PING 192.168.254.1 (192.168.254.1) 56(84) bytes of data.

--- 192.168.254.1 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

bound: renewal in 32452 seconds.

What on earth? Does this mean that I'm broadcasting DHCP requests and just never getting replies?

Last edited by ads103 (2016-11-11 22:27:22)

Horizon_Brave · 2016-11-12 06:10:48

Do you have another DHCP server doling out addresses on your network?

Also post the output of:

grep dhcp-server-identifier /var/lib/dhcp3/dhclient.leases

Last edited by Horizon_Brave (2016-11-12 06:37:41)

ads103 · 2016-11-12 13:27:34

Horizon_Brave wrote:

Also post the output of:

grep dhcp-server-identifier /var/lib/dhcp3/dhclient.leases

Before I do that, I'd like to add some more info. The issues are present at a corporate network. I just took my laptop home for the weekend ( ), plugged it up to my home LAN, booted up, and everything worked fine. So... I guess this complicates things a bit, because I'm not intimately familiar with the corporate network, nor do I have access to much on it besides an Ethernet jack in a cubicle.

With that being said, here's the output you asked for:

$ grep dhcp-server-identifier /var/lib/dhcp/dhclient.leases 
  option dhcp-server-identifier 192.168.254.1;
  option dhcp-server-identifier 1.1.1.1;

This actually looks like info from the corporate network! My default gateway there was 192.168.254.1, and my subnet mask was 255.255.254.0. At home, I use 192.168.0.0/24.

Head_on_a_Stick · 2016-11-12 14:25:19

I think this is a router-side issue, have you checked with the IT support people?

ads103 · 2016-11-12 15:08:44

Not yet, I'll do so Monday.
Thank you all for your help so far.

Horizon_Brave · 2016-11-12 20:03:39

ads103 wrote:

Horizon_Brave wrote:
Also post the output of:
grep dhcp-server-identifier /var/lib/dhcp3/dhclient.leases
Before I do that, I'd like to add some more info. The issues are present at a corporate network. I just took my laptop home for the weekend ( ), plugged it up to my home LAN, booted up, and everything worked fine. So... I guess this complicates things a bit, because I'm not intimately familiar with the corporate network, nor do I have access to much on it besides an Ethernet jack in a cubicle.
With that being said, here's the output you asked for:
$ grep dhcp-server-identifier /var/lib/dhcp/dhclient.leases 
  option dhcp-server-identifier 192.168.254.1;
  option dhcp-server-identifier 1.1.1.1;
This actually looks like info from the corporate network! My default gateway there was 192.168.254.1, and my subnet mask was 255.255.254.0. At home, I use 192.168.0.0/24.

I'm thinking the issue is that your corporation has it's own DHCP server and you may be running something to get dhcp leases on your laptop. Perhaps you have your home dhcp server address set to get addresses from there. Two DHCP servers will interfere and you'll get some strange results, including no answers from either, or spotty dropped connections.

ads103 · 2016-11-17 16:19:37

Just wanted to keep y'all updated for documentation's sake, in case anyone has a similar issue in the future.
A technical support representative looked over the issue with me, here's what we tried:

We connected a different laptop running CentOS to my cube's Ethernet cable. It received an IP address immediately. This led us to believe the issue is unique to my system.
I loaded the CentOS installer from an install DVD on my laptop. It was unable to receive an IP address. This seems to support the theory that the issue is unique to my system.
We restarted the service NetworkManager using
```
sudo service NetworkManager stop
sudo service NetworkManager start
```
Moments later, I received an IP address without sleeping the system. We started a figurative victory dance, all looked well.
I restarted my laptop, and booted into Windows. I spent a few minutes there before rebooting into Linux. Once again, I wasn't able to get an IP address. It looks like our figurative victory dance was a bit premature.
We manually removed my lease from the DHCP server. This had no effect.
According to this thread at whirlpool.net, it was suggested that I uncomment the line "#send dhcp-client-identifier" and place my MAC address at the end of the line. I did so. This didn't have any effect, I still wasn't able to contact the DHCP server.

Here's my current train of thought, just thinking out-loud here for documentation's sake:

Perhaps there are differences in implementation in the DHCP protocol in Windows and Linux, and the Cisco devices my laptop connect to simply don't "like" the Linux implementation. Is the Linux implementation of DHCP somehow "incorrect" or incomplete?
Is the problem something in my system? I've run apt-get upgrade to verify that I have the latest versions of software, and I'm certainly not aware of any bugs. But I'm not familiar enough with Linux to single out which packages could contribute to this issue. dhclient is the first that comes to mind, but it clearly does its job on other networks.
Perhaps dual-booting has something to do with it! Perhaps my IP address is already reserved "for Windows," and the server doens't want to talk to me until that lease expires.
I know that this issue is reproducible in the installer for CentOS, but I'm not sure about the OS itself, once installed. I need to try it next... as much as I love the BunsenLabs look and feel, functionality is important.

Last edited by ads103 (2016-11-17 18:18:27)

Head_on_a_Stick · 2016-11-17 20:59:38

ads103 wrote:

I know that this issue is reproducible in the installer for CentOS

Is the issue reproducible in the BunsenLabs live session?

ads103 · 2016-11-17 21:01:19

Yes. It is also reproducible in a virtual machine running under Windows, with my network adapter bridged to my Ethernet port. NAT works fine.

#1 2016-11-11 20:00:05

DHCP only works after suspend from sleep

#2 2016-11-11 20:21:09

Re: DHCP only works after suspend from sleep

#3 2016-11-11 20:34:51

Re: DHCP only works after suspend from sleep

#4 2016-11-11 20:59:51

Re: DHCP only works after suspend from sleep

#5 2016-11-11 21:07:58

Re: DHCP only works after suspend from sleep

#6 2016-11-11 22:12:12

Re: DHCP only works after suspend from sleep

#7 2016-11-12 06:10:48

Re: DHCP only works after suspend from sleep

#8 2016-11-12 13:27:34

Re: DHCP only works after suspend from sleep

#9 2016-11-12 14:25:19

Re: DHCP only works after suspend from sleep

#10 2016-11-12 15:08:44

Re: DHCP only works after suspend from sleep

#11 2016-11-12 20:03:39

Re: DHCP only works after suspend from sleep

#12 2016-11-17 16:19:37

Re: DHCP only works after suspend from sleep

#13 2016-11-17 20:59:38

Re: DHCP only works after suspend from sleep

#14 2016-11-17 21:01:19

Re: DHCP only works after suspend from sleep

Board footer