I’ve had a series of strange issues with my Dell XPS 13 9350 DE under Ubuntu 14.04, 16.04, and now 16.10. Bouncing around between versions has helped some things, but this strange wireless issue seems to have followed me around.
Everything works just fine for X amount of time and then the wireless will just drop. In my
/var/log/kern.log file (or via
dmesg), I’ll see something like this:
wlp58s0: disconnect from AP 58:6d:8f:99:8b:f4 for new auth to 58:6d:8f:99:8b:f5
Just in case I missed it, that message will generously repeat every 2 minutes or so. Sometimes nothing noticeable happens, other times my connection will break and I’ll have to restart the network manager service.
I spent some time today digging into the issue. I’m not sure that I actually fixed anything, but I at least learned a few commands and want to save links to a few helpful sites.
FWIW, my laptop has an Intel 8260 rev 3a wireless adapter, but these commands should help in general troubleshooting as well.
sudo lshw -C network
lshw is “a small tool to extract detailed information on the hardware configuration of the machine.”
This gave me some cool information like the product, vendor, and firmware version of the wireless adapter. The firmware version listed when I started was 21.302800.0, which didn’t make any sense when compared to the list of iwlwifi drivers maintained on kernel.org.
sudo iwlist scan
iwlist, combined with “scan”, provides a list of in range access points. I didn’t really use this much this time, but it does help show what wireless frequencies other nearby APs are using.
uname -r -m
uname prints system information. This isn’t entirely useful for troubleshooting wireless issues, but is an easy way to get your kernel information. I didn’t know this command until recently, so I’m putting it here. See also:
dmesg | grep iwl
dmesg displays “all messages from the kernel ring buffer”. There’s a term.
This is probably the most useful command. It showed me what firmware linux was trying to load for the wireless adapter, what failed, and what succeeded.
[ 8.687719] iwlwifi 0000:3a:00.0: Direct firmware load for iwlwifi-8000C-22.ucode failed with error -2
[ 8.690891] iwlwifi 0000:3a:00.0: loaded firmware version 21.302800.0 op_mode iwlmvm
There was a lot more than that, but I was able to see that it was attempting to load 3 wrong versions of the firmware and then successfully loading a very wrong version of the firmware.
modprobe -r iwlwifi; modprobe iwlwifi
I removed the “wrong” versions of the firmware from
/lib/firmware/ and ran the
modprobe commands to first remove the loaded module and then re-add it again. I confirmed through
dmesg that the “correct” firmware version was loaded.
The worst part about all of this is that it’s still happening. So I guess it may not be a firmware issue, but some kind of hardware thing. The list of “platform noise” issue on the kernel.org iwlwifi page is probably where I’m going to focus next. I changed the channel on my router once, but I may be able to dig deeper on that.
Update (an hour later): Things seem to be more stable after finding a more open 2.4Ghz channel. I also found what seems to be a maintained list of core releases for the iwlwifi drivers. That led me to what should be the latest mainline version of the 8260 driver that I need. After making
iwlwifi-8000C-22.code available and running
modprobe, the correct driver (22) was picked up and installed.
Update (Jan 8, 2017): The problem is definitely back, even with all of the fixes above. I’m starting to wonder if it’s partially the fault of my router as I’m always able to get to the router admin interface, just not over anything that requires DNS. Today I disabled IPv6 on the wireless adapter and set a static IP address with static DNS. We’ll see how that holds up!
Update (Jan 8, 2017): Disabling IPv6 didn’t matter at all. I did find a new piece of the puzzle though. Ubuntu’s Network Manager uses dnsmasq by default. I disabled the configuration for this and now when my wireless drops and reconnects, DNS will at least continue working. Some other network stuff is still having trouble, but I don’t have to completely restart the network services right now.
Here are some links that I found useful for learning how to troubleshoot this all: