I've had this issue ever since I got the motherboard I currently sport if I recall correctly, which means its been around since about the beginning of 2014. No amount of updating or reinstalling has fixed this issue. I even went as far as replacing my router which did nothing.
From all of my research, I have come to the conclusion that it fails to get a DHCP lease. The odd thing is that I did notice that sometimes, it would get a DHCP lease but it seemed to vary a lot. I never realized why it sometimes got a DHCP lease and sometimes not, but I think I got it figured out now. I don't know why it behaves like this, but at least it does. There was a period where I used Linux during all of my time in front of the computer and it got a lease every single time. No problems. Then I booted Windows to do something, and when I tried to go back to Linux, the lease didn't work anymore. I figured I'd reboot a few times to see if it would work, nope. Ever since, I haven't been able to get networking to work again since I've booted into Windows more frequently since I need internet. I've tried deleting the lease on the router after booting into Linux to see if that worked, but apparently not.
journalctl grepping NetworkManager and dhclient
The lease that is acquired here is from me using the phone to tether.
I would think the router would see the DHCPDISCOVER request, but it doesn't. There's not a single entry in the router log that acknowledges that this computer exists as soon as Linux is booted when Windows was booted the last 24 hours I'd assume. I've tried manually setting a route but that doesn't work either. I've tried different DHCP clients, nope.
I'd love to fix this issue but I have no idea where to start. I've been working on this for soon two years and I have barely made any progress in resolving this.
Router is a ASUS RT-N66U running Tomato Shibby. Keep in mind that it didn't work on my previous router, stock firmware of this one or on Tomato.
So the link is up and dhclient claims to be sending DHCPDISCOVER's on eno1 but the router claims to not be receiving any DHCPDISCOVER's, and the hardware is verified by working networking in windows installation. So where are the packets going?
I would check the activity lights on each end of the link to see if they blink when your client sends DHCPDISCOVER's. If they do, check interface rx packet counters and error counters on the router. If they don't, check interface tx counters and error counters on the client with "ethtool -S eno1". If packets are not being transmitted use tcpdump or wireshark to see if DHCPDISCOVER's are coming out of the network stack. If they are not then check your firewall rules. There are lots of places the packets could be getting lost, it would be good to determine how far they get.
Alternately, have you tried a static network configuration?
I checked the activity lights and I assume blinking means activity? The router does recognize that it is connected to an ethernet port at least, but I wasn't able to see any blinking either on my router or on the back of my desktop when trying to connect.
I used ethtool on eno1 and there are some values that increases when trying to connect. tx_packets, tx_bytes, tx_broadcast and tx_multicast. Something is happening.
I have no idea how to use Wireshark, but I did something with it.
This doesn't tell me anything, am I doing this right? This just tells me what I already knew. I assume I want to capture traffic on the router on the interface my desktop is connected to but I'm not sure how I would do that. Is there an easy way to install the CLI version of Wireshark onto a router or is that not needed?
-- read the Forum Etiquette and only post thumbnails http://wiki.archlinux.org/index.php/For … s_and_code [jwr] --
The cli equivalent of wireshark is tcpdump. See "man tcpdump" for basic options and "man pcap-filter" for the filtering language. I am not familiar with tomato, but it is linux based so hopefully it has basic tools like tcpdump and ethtool.
That said, if the link lights do not show any activity I would not expect to see anything. It seems like packets go into the MAC but don't come out the wire. Almost as if windows has left the MAC or Phy in a wierd state and Linux does not completely re-initialise it. Have you tried shutting down the computer and unplugging it for a minute or two to make sure all standby power is blead down, then booting directly into Linux? Have you tried one of the other network interfaces that Windows does not use?
You are definitely onto something! I just shut the computer off, flipped the PSU switch, let it sit until all of the LED's turned off, flipped PSU back on and booted straight into Linux. No hassle, the DHCP lease was acquired! By another network interface, do you mean physically plugging the cable into a different ethernet slot on the router? If you meant that, I tried that before I did the other thing with no luck.
I'm so happy that there exists a quick and dirty solution to fixing this when switching between Windows and Linux, but how to fix it permanently is still a mystery to me. I think you're pretty correct when you say that Windows leaves the network stuff in some sort of weird state that Linux isn't able to fully understand.
Forgot to add, tcpdump and ethtool weren't installed on my system so I have some doubts that they're on the router by default, but it's easy to find out if we were to need the tools later.
Last edited by raghap (2016-01-15 03:08:19)
Nevermind about the other interface thing, I saw "Wired Connection 2" in your logs and assumed your board had two ethernet ports, but I now realise it has only one. As for diagnostic tools on the router, I think we can be reasonably confident at this point that the packets are not getting that far.
If what we suspect is actually what is happening then it would seem like a driver bug. Probably not much else to do besides report it, but I am curious if poking around at anything in /sys/class/net/eno1/device has any effect, ex.
sudo echo 1 > /sys/class/net/eno1/device/reset
I am not sure on the semantics here, you may or may not need to set it back to 0 to reactivate it, and NetworkManager may or may not get angry if you don't stop it before doing such things.
This happens when you dual boot between Linux and Windows. Check out http://superuser.com/a/621218
Either set Windows to use UTC (which is buggy)...
https://wiki.archlinux.org/index.php/Ti … in_Windows
or set Linux not to.
timedatectl set-local-rtc 1
Last edited by doggone (2016-01-15 16:58:13)
or set Linux not to.
timedatectl set-local-rtc 1
FWIW, That is strongly discouraged.
Last edited by ewaller (2016-01-15 17:39:23)
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
You assume people are rational and influenced by evidence. You must not work with the public much. -- Trilby
How to Ask Questions the Smart Way