[Solved-ish]Linux invisible to dhcp server

Grant · 2019-08-06 20:21:59

It's been almost more than a month that my Arch won't consider establishing a connection to my LAN. Along with Arch I've got a W10 which (regretfully) I have to point out it manages to surf the Internet through DHCP just fine, just like the other few devices in my network (although wireless ones).

My nic is correctly picked up by the kernel and the driver loaded by udev (as seen through dmesg). ip link show confirms that. Pinging localhost also does the job.

I use netctl to establish a connection. I tried both a static profile and a dynamic one. Let me go through what happens with the dynamic one: as dhcpcd runs, it just hangs. It gets no reply at all: through Wireshark I do see the broadcast DHCP discovery packet but it gets no answer at all. And thus it then just exits after a few seconds.

I tried a static profile by setting a fictious IP (surely not used by others) with the very same parameters W10 gets (submask and gateway). Yet I cannot even ping my local gateway (at 192.168.1.1). Running 'ip neigh' shows failed regarding the latter and similarly arp says incomplete under hwaddress. Might there be something wrong there?

I'm totally lost and I don't know that else to try. I had thought the fast-boot/hybrid thing of W10 was causing the issue (perhaps the kernel was sort of "freezing" the card and linux couldn't use it ) but after disabling the fast boot and hybernation, perfoming a full shutdown neither sorted it out. Any ideas? Thank you so much.

Last edited by Grant (2019-08-10 07:25:10)

Lone_Wolf · 2019-08-07 13:45:18

Does it make a difference if you disable netctl and run dhcpcd manually ?
Same question for dhclient .

as root run

# ethtool your-interface

and post output.

also post lspci -k so we can see what hardware you have.

seth · 2019-08-07 14:19:00

https://wiki.archlinux.org/index.php/Du … t_Start-Up *is* indeed the usual suspect (so usual that I linked it before reading the end of your post…)
Ensure the router has no MAC filter and check "sudo journalctl -b", esp. for kernel errors related to the NIC.

There's also https://bbs.archlinux.org/viewtopic.php?id=248257 so let's see whether some tutorial or installer spreads dumb FW rules:

sudo iptables -L

Grant · 2019-08-07 19:23:49

seth wrote:

https://wiki.archlinux.org/index.php/Du … t_Start-Up *is* indeed the usual suspect (so usual that I linked it before reading the end of your post…)
Ensure the router has no MAC filter and check "sudo journalctl -b", esp. for kernel errors related to the NIC.
There's also https://bbs.archlinux.org/viewtopic.php?id=248257 so let's see whether some tutorial or installer spreads dumb FW rules:
sudo iptables -L

Fast start up used indeed to raise issues back then and performing a full shutdown solved the issue. Anyways, I've turned it off along with hybernation but no more luck (I've checked it's actually of in the Win register - I can also mount the partition without any warnings). The issue isn't definitely that one anymore, sigh.
iptables has no rules in it, everything's accepted.

I found something quite stunning. I tried to pop in a good ol' live Arch (dating back to 2013) and even an Ubuntu 10.04 (which used NM) but neither managed to connect! How on earth? I can't believe the very same machine connects just fine with Windows. I though some cable could be broken but that cannot be because of that. Where else could the issue lie in? I'm sorry if that could be leading to OT.

I'm posting the other outputs for completeness' sake,

# ethtool eno1
Settings for eno1:
	Supported ports: [ TP ]
	Supported link modes:   10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Supported pause frame use: No
	Supports auto-negotiation: Yes
	Supported FEC modes: Not reported
	Advertised link modes:  10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Advertised pause frame use: No
	Advertised auto-negotiation: Yes
	Advertised FEC modes: Not reported
	Speed: 1000Mb/s
	Duplex: Full
	Port: Twisted Pair
	PHYAD: 1
	Transceiver: internal
	Auto-negotiation: on
	MDI-X: off (auto)
	Supports Wake-on: pumbg
	Wake-on: g
	Current message level: 0x00000007 (7)
			       drv probe link
	Link detected: yes
# lspci -k
00:00.0 Host bridge: Intel Corporation 4th Gen Core Processor DRAM Controller (rev 06)
	Subsystem: ASUSTeK Computer Inc. 4th Gen Core Processor DRAM Controller
	Kernel driver in use: hsw_uncore
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor PCI Express x16 Controller (rev 06)
	Kernel driver in use: pcieport
	Kernel modules: shpchp
00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 05)
	Subsystem: ASUSTeK Computer Inc. 8 Series/C220 Series Chipset Family USB xHCI
	Kernel driver in use: xhci_hcd
	Kernel modules: xhci_pci
00:16.0 Communication controller: Intel Corporation 8 Series/C220 Series Chipset Family MEI Controller #1 (rev 04)
	Subsystem: ASUSTeK Computer Inc. 8 Series/C220 Series Chipset Family MEI Controller
	Kernel driver in use: mei_me
	Kernel modules: mei_me
00:19.0 Ethernet controller: Intel Corporation Ethernet Connection I217-V (rev 05)
	DeviceName:  Onboard LAN
	Subsystem: ASUSTeK Computer Inc. Ethernet Connection I217-V
	Kernel driver in use: e1000e
	Kernel modules: e1000e
00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 (rev 05)
	Subsystem: ASUSTeK Computer Inc. 8 Series/C220 Series Chipset Family USB EHCI
	Kernel driver in use: ehci-pci
	Kernel modules: ehci_pci
00:1b.0 Audio device: Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller (rev 05)
	Subsystem: ASUSTeK Computer Inc. 8 Series/C220 Series Chipset High Definition Audio Controller
	Kernel driver in use: snd_hda_intel
	Kernel modules: snd_hda_intel
00:1c.0 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #1 (rev d5)
	Kernel driver in use: pcieport
	Kernel modules: shpchp
00:1c.1 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #2 (rev d5)
	Kernel driver in use: pcieport
	Kernel modules: shpchp
00:1c.6 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d5)
00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 (rev 05)
	Subsystem: ASUSTeK Computer Inc. 8 Series/C220 Series Chipset Family USB EHCI
	Kernel driver in use: ehci-pci
	Kernel modules: ehci_pci
00:1f.0 ISA bridge: Intel Corporation Z87 Express LPC Controller (rev 05)
	Subsystem: ASUSTeK Computer Inc. Z87 Express LPC Controller
	Kernel driver in use: lpc_ich
	Kernel modules: lpc_ich
00:1f.2 SATA controller: Intel Corporation 8 Series/C220 Series Chipset Family 6-port SATA Controller 1 [AHCI mode] (rev 05)
	Subsystem: ASUSTeK Computer Inc. 8 Series/C220 Series Chipset Family 6-port SATA Controller 1 [AHCI mode]
	Kernel driver in use: ahci
	Kernel modules: ahci
00:1f.3 SMBus: Intel Corporation 8 Series/C220 Series Chipset Family SMBus Controller (rev 05)
	Subsystem: ASUSTeK Computer Inc. 8 Series/C220 Series Chipset Family SMBus Controller
	Kernel driver in use: i801_smbus
	Kernel modules: i2c_i801
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Pitcairn PRO [Radeon HD 7850 / R7 265 / R9 270 1024SP]
	Subsystem: PC Partner Limited / Sapphire Technology Radeon HD 7850 2GB GDDR5 DVI-I/DVI-D/HDMI/DP
	Kernel driver in use: radeon
	Kernel modules: radeon, amdgpu
01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Oland/Hainan/Cape Verde/Pitcairn HDMI Audio [Radeon HD 7000 Series]
	Subsystem: PC Partner Limited / Sapphire Technology Oland/Hainan/Cape Verde/Pitcairn HDMI Audio [Radeon HD 7000 Series]
	Kernel driver in use: snd_hda_intel
	Kernel modules: snd_hda_intel
03:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA Controller (rev 01)
	Subsystem: ASUSTeK Computer Inc. ASM1062 Serial ATA Controller
	Kernel driver in use: ahci
	Kernel modules: ahci
04:00.0 PCI bridge: ASMedia Technology Inc. ASM1083/1085 PCIe to PCI Bridge (rev 03)

seth · 2019-08-07 20:41:01

It would seems that either windows still has control over the device or that some mac spoofing at play resp. the router has a stale lease from the windows connection.
Is the device still shown in the router despite the not getting a dhcp lease? Or even though the system isn't connected at all?
Did you ensure that windows didn't re-enable fast boot (because it does that with some updates)?

Grant · 2019-08-08 08:33:00

seth wrote:

It would seems that either windows still has control over the device or that some mac spoofing at play resp. the router has a stale lease from the windows connection.
Is the device still shown in the router despite the not getting a dhcp lease? Or even though the system isn't connected at all?
Did you ensure that windows didn't re-enable fast boot (because it does that with some updates)?

I guess you're spot on. With the router turned off I booted windows and I made a hard reboot with the button on my case so that it should have no time to do its nasty things against my will. Then, I ran Arch, turned on my router, brought up the interface and ran dhcpcd: it worked like a charm! No hanging whatsoever, instant DHCP response. Same for dhclient. So I guess it'd be the case to blame Windows.. but for what? What could it be doing to keep "hold" of the card? How do I stop that (apart from killing Windows the hard way)?

Unfortunately I don't have access to the (buggy) router panel so I can't tell you about that. Sorry.

seth · 2019-08-08 14:16:29

Did you ensure that windows didn't re-enable fast boot (because it does that with some updates)?

Other than that, the cycle might have been enough to make the router forget the lease.
Did you try whether you can still reproduce the problem?

Grant · 2019-08-10 07:24:37

Sadly I still definitely can reproduce the issue. So far, it seems W10 is, let me say, locking up on my NIC and preventing Linux from using it. Reading up on that, I found that giving

ipconfig /release

before rebooting, which forces W to cease the the lease, could help in these very cases. It didn't for me. Only hitting the restart button seems to deal with that so far.

So there seems to be something beyond fast startup that messes up dual booting, at least for me and with the latest updated of W10 (some wrote W puts the nic in a state linux doesn't expect and thus it causes it not to work properly). I haven't found anything like that on the Wiki/forum, so perhaps I might be writing up on that if I get to find a solution (I've got a few candidates on my checklist).

I'm marking the topic as "solved" (shouldn't I(?) ), because I'm pretty certain we found the culprit even though without a full solution. I'm very thankful to everyone contributing!

Lone_Wolf · 2019-08-10 10:57:01

Sometimes power management settings on network cards can only be set from the windows driver.[1]
I haven't mentioned this earlier in the thread as recent cases of that issue were related to Wake on Lan, not normal use.

Use windows device manager to find your network card and access it's properties .
There should be a tabpage Power options" , on it look for "Allow the computer to turn off this device to save power"

Disable that option and check if it helps.

[1] realtek network cards suffered heavily from this in the windows xp period

Arch Linux

#1 2019-08-06 20:21:59

[Solved-ish]Linux invisible to dhcp server

#2 2019-08-07 13:45:18

Re: [Solved-ish]Linux invisible to dhcp server

#3 2019-08-07 14:19:00

Re: [Solved-ish]Linux invisible to dhcp server

#4 2019-08-07 19:23:49

Re: [Solved-ish]Linux invisible to dhcp server

#5 2019-08-07 20:41:01

Re: [Solved-ish]Linux invisible to dhcp server

#6 2019-08-08 08:33:00

Re: [Solved-ish]Linux invisible to dhcp server

#7 2019-08-08 14:16:29

Re: [Solved-ish]Linux invisible to dhcp server

#8 2019-08-10 07:24:37

Re: [Solved-ish]Linux invisible to dhcp server

#9 2019-08-10 10:57:01

Re: [Solved-ish]Linux invisible to dhcp server

Board footer