Workaround for my Ubuntu wireless connectivity problems

About a month ago, I started having problems connecting my Ubuntu 11.10 laptop to MSU’s wireless network. In the morning, when I would connect, it would do so successfully for 10 minutes to an hour. Then it would stop working, and just try to repeatedly connect. I don’t know where to file this bug under, so for now, I’ll just store the info on my blog.

For example, here’s a section of /var/log/syslog from today:

Mar 21 11:36:20 friday wpa_supplicant[1441]: Trying to authenticate with 00:0c:e6:6d:9a:7f (SSID='MSUnet 2.0' freq=5180 MHz)
Mar 21 11:36:20 friday kernel: [231715.216575] wlan0: direct probe to 00:0c:e6:6d:9a:7f (try 1/3)
Mar 21 11:36:20 friday kernel: [231715.416174] wlan0: direct probe to 00:0c:e6:6d:9a:7f (try 2/3)
Mar 21 11:36:20 friday kernel: [231715.616246] wlan0: direct probe to 00:0c:e6:6d:9a:7f (try 3/3)
Mar 21 11:36:21 friday kernel: [231715.816115] wlan0: direct probe to 00:0c:e6:6d:9a:7f timed out
Mar 21 11:36:28 friday wpa_supplicant[1441]: Trying to authenticate with 00:0c:e6:6d:9a:7f (SSID='MSUnet 2.0' freq=5180 MHz)
Mar 21 11:36:28 friday kernel: [231723.286531] wlan0: direct probe to 00:0c:e6:6d:9a:7f (try 1/3)
Mar 21 11:36:28 friday kernel: [231723.484108] wlan0: direct probe to 00:0c:e6:6d:9a:7f (try 2/3)
Mar 21 11:36:28 friday kernel: [231723.684256] wlan0: direct probe to 00:0c:e6:6d:9a:7f (try 3/3)

Notice that the timeout seems to be about 200 milliseconds. Not very long. Watching the output of wpa_cli, I saw it add and remove APs from its list at an alarming rate. Indeed, it was adding and removing them as fast as it was timing out. At my university, there are multiple Access Points (APs) for every SSID, and I think it was getting hung up on it.

So, after scouring the net for help and not getting much, I did eventually find someone advising to run wpa_supplicant myself, without using network-manager, which is what Ubuntu currently uses to manage wpa_supplicant. Given that this is how I used to manage my network connections when I ran Gentoo, I decided to give it a try.

So, I stopped network-manager with a ‘sudo /etc/init.d/network-manager stop’ command, and killed the wpa_supplicant process that was still running. I created my own wpa_supplicant configuration file, in ~/sandbox/wpasup.conf:

network={ ssid="MSUnet 2.0" scan_ssid=1 key_mgmt=NONE }
network={ ssid="MSUnet Guest 2.0" scan_ssid=1 key_mgmt=NONE }

After saving this file, I just needed to run my own process of wpa_supplicant, then once it connected to the AP, run dhclient to have DHCP give me an IP and all that.

$ sudo wpa_supplicant -iwlan0 -s -d -c/home/user/sandbox/wpasup.conf /var/run/wpasupplicant
$ sudo dhclient wlan0

Update: 2012-07-10

I heard back from the IT people in my building and they said this:

There are a number of intel wireless complaints similar to yours on the intel wireless site. http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2338, for example.

Basically the problem seems to be that you are picking up signal from 2 or more access points at the same time, and rather than the driver locking on to one and holding it, it is fluttering back and forth between them.
You are probably out of luck until Intel fixes their linux drivers…

So, there it is. Fortunately, it looks like there is frequent activity on this bug, so I have high hopes that it will get resolved soon.

Let me know if you have any ideas or information!

Update 2013-06-19

I now use this workaround: Use Ubuntu’s standard network manager and connect to wifi via a USB wireless adapter that works with free drivers. I searched for a cheap adapter on Newegg and found one that I verified had a free software driver. I ended up going with the ENCORE ENUWI-G2 Wireless Adapter. It works great with no manual setup needed.

Another workaround

My colleague, Karl Smith, found another solution: manually turn the wireless device off and on again. For him, it continued to say it was disconnected in Network Manager, but he was able to connect to the Internet normally. He used the hardware wireless switch, but I think one could also use a software device-off command. I haven’t tried yet.

Leave a Reply

Your email address will not be published. Required fields are marked *

     

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>