Problems using Netgear WN111v2 with the driver built into the kernel

[Charlie Foxtrot]

Hello,

I'm having problems with my wireless connection going down using the driver that's built into the knoppix 6.4.4 kernel. It generally will stay up for a few hours then it no longer works, and I have to remove and reinsert the connector, or even reboot the machine. Lately, it seem that a full reboot is typically what is required. I had similar, but somewhat worse, problems with Mint 10 as well. On the other hand with Lucid Puppy 5.2, it would stay up for a couple days.

When the connection goes down, I don't get the prompt to use the credentials stored in the keyring, instead I get the Wireless Network Authentication Required dialog.

I'm using older, two part firmware, as is describe here:
http://wireless.kernel.org/en/users/Drivers/ar9170

With Mint 10, I tried both the old and new firmware, it was pretty much the same either way. Puppy used the 2 part firmware, so that's what I've tried with knoppix.

I thought that maybe the reason that Puppy was working was that it used an older version of the kernel (2.6.33.2), but I've tried to use knoppix 6.2, which is has a slightly older kernel than Puppy and it was pretty much the same.

Here's where it loses the connection:



Apr 21 16:28:06 Microknoppix -- MARK --
Apr 21 16:44:58 Microknoppix kernel: [29816.893738] ieee80211 phy0: wlan0: No probe response from AP 94:44:52:43:16:f4 after 500ms, disconnecting.
Apr 21 16:44:58 Microknoppix wpa_supplicant[2886]: CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
Apr 21 16:44:58 Microknoppix kernel: [29817.069489] cfg80211: Calling CRDA to update world regulatory domain
Apr 21 16:44:58 Microknoppix NetworkManager[2855]: <info> (wlan0): supplicant connection state: completed -> disconnected
Apr 21 16:44:58 Microknoppix NetworkManager[2855]: <info> (wlan0): supplicant connection state: disconnected -> scanning
Apr 21 16:45:01 Microknoppix wpa_supplicant[2886]: Trying to associate with 94:44:52:43:16:f4 (SSID='Charlies' freq=2432 MHz)
Apr 21 16:45:01 Microknoppix NetworkManager[2855]: <info> (wlan0): supplicant connection state: scanning -> associating
Apr 21 16:45:01 Microknoppix kernel: [29820.106860] wlan0: authenticate with 94:44:52:43:16:f4 (try 1)
Apr 21 16:45:01 Microknoppix kernel: [29820.303730] wlan0: authenticate with 94:44:52:43:16:f4 (try 2)
Apr 21 16:45:02 Microknoppix kernel: [29820.503745] wlan0: authenticate with 94:44:52:43:16:f4 (try 3)
Apr 21 16:45:02 Microknoppix kernel: [29820.703734] wlan0: authentication with 94:44:52:43:16:f4 timed out
Apr 21 16:45:06 Microknoppix NetworkManager[2855]: <info> (wlan0): roamed from BSSID 94:44:52:43:16:F4 (Charlies) to (none) ((none))
Apr 21 16:45:11 Microknoppix wpa_supplicant[2886]: Authentication with 94:44:52:43:16:f4 timed out.
Apr 21 16:45:11 Microknoppix NetworkManager[2855]: <info> (wlan0): supplicant connection state: associating -> disconnected
Apr 21 16:45:11 Microknoppix NetworkManager[2855]: <info> (wlan0): supplicant connection state: disconnected -> scanning
Apr 21 16:45:14 Microknoppix NetworkManager[2855]: <info> (wlan0): device state change: 8 -> 3 (reason 11)
Apr 21 16:45:14 Microknoppix NetworkManager[2855]: <info> (wlan0): deactivating device (reason: 11).
Apr 21 16:45:14 Microknoppix NetworkManager[2855]: <info> (wlan0): canceled DHCP transaction, DHCP client pid 3204
Apr 21 16:45:14 Microknoppix NetworkManager[2855]: <error> [1303404314.202975] [nm-system.c:1229] check_one_route(): (wlan0): error -34 returned from rtnl_route_del(): Netlink Error (errno = Numerical result out of range)
Apr 21 16:45:14 Microknoppix NetworkManager[2855]: <info> Activation (wlan0) starting connection 'Auto Charlies'
Apr 21 16:45:14 Microknoppix NetworkManager[2855]: <info> (wlan0): device state change: 3 -> 4 (reason 0)
Apr 21 16:45:14 Microknoppix NetworkManager[2855]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled...
Apr 21 16:45:14 Microknoppix NetworkManager[2855]: <info> (wlan0): supplicant connection state: scanning -> disconnected
Apr 21 16:45:14 Microknoppix NetworkManager[2855]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) started...
Apr 21 16:45:14 Microknoppix NetworkManager[2855]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled...
Apr 21 16:45:14 Microknoppix NetworkManager[2855]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) complete.
Apr 21 16:45:14 Microknoppix NetworkManager[2855]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) starting...
Apr 21 16:45:14 Microknoppix NetworkManager[2855]: <info> (wlan0): device state change: 4 -> 5 (reason 0)
Apr 21 16:45:14 Microknoppix NetworkManager[2855]: <info> Activation (wlan0/wireless): access point 'Auto Charlies' has security, but secrets are required.
Apr 21 16:45:14 Microknoppix NetworkManager[2855]: <info> (wlan0): device state change: 5 -> 6 (reason 0)
Apr 21 16:45:14 Microknoppix NetworkManager[2855]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) complete.
Apr 21 16:45:14 Microknoppix NetworkManager[2855]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled...
Apr 21 16:45:14 Microknoppix NetworkManager[2855]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) started...
Apr 21 16:45:14 Microknoppix NetworkManager[2855]: <info> (wlan0): device state change: 6 -> 4 (reason 0)
Apr 21 16:45:14 Microknoppix NetworkManager[2855]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled...
Apr 21 16:45:14 Microknoppix NetworkManager[2855]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) complete.
Apr 21 16:45:14 Microknoppix NetworkManager[2855]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) starting...
Apr 21 16:45:14 Microknoppix NetworkManager[2855]: <info> (wlan0): device state change: 4 -> 5 (reason 0)
Apr 21 16:45:14 Microknoppix NetworkManager[2855]: <info> Activation (wlan0/wireless): connection 'Auto Charlies' has security, and secrets exist. No new secrets needed.
Apr 21 16:45:14 Microknoppix NetworkManager[2855]: <info> Config: added 'ssid' value 'Charlies'
Apr 21 16:45:14 Microknoppix NetworkManager[2855]: <info> Config: added 'scan_ssid' value '1'
Apr 21 16:45:14 Microknoppix NetworkManager[2855]: <info> Config: added 'key_mgmt' value 'WPA-PSK'
Apr 21 16:45:14 Microknoppix NetworkManager[2855]: <info> Config: added 'psk' value '<omitted>'
Apr 21 16:45:14 Microknoppix NetworkManager[2855]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) complete.
Apr 21 16:45:14 Microknoppix NetworkManager[2855]: <info> Config: set interface ap_scan to 1
Apr 21 16:45:14 Microknoppix NetworkManager[2855]: <info> (wlan0): supplicant connection state: disconnected -> scanning
Apr 21 16:45:40 Microknoppix NetworkManager[2855]: <warn> Activation (wlan0/wireless): association took too long.
Apr 21 16:45:40 Microknoppix NetworkManager[2855]: <info> (wlan0): device state change: 5 -> 6 (reason 0)
Apr 21 16:45:40 Microknoppix NetworkManager[2855]: <warn> Activation (wlan0/wireless): asking for new secrets
Apr 21 16:45:40 Microknoppix NetworkManager[2855]: <info> (wlan0): supplicant connection state: scanning -> disconnected
Apr 21 16:45:55 Microknoppix NetworkManager[2855]: <warn> (wlan0): link timed out.
Apr 21 17:08:06 Microknoppix -- MARK --


I got home my connection was down. I tried to log in using the saved credentials (it wasn't asking me to use the keyring). It failed, I tried removing and reinserting the wireless adapter several times, but it didn't work:


Running iwevent last night to see if I had anything interesting, my wireless connection stayed up all night for the first time. I tried it again this eventing with the following results. Any idea what's up with the segmentation fault? It appears to coincide with it losing the connection.



knoppix@Microknoppix:~$ iwevent
Waiting for Wireless Events from interfaces...
19:41:18.210480 wlan0 Scan request completed
19:41:57.796882 wlan0 Scan request completed
19:42:57.793745 wlan0 Scan request completed
19:44:17.800202 wlan0 Scan request completed
19:45:57.800193 wlan0 Scan request completed
19:47:57.836848 wlan0 Scan request completed
19:49:57.823711 wlan0 Scan request completed
19:51:57.790160 wlan0 Scan request completed
19:53:57.826810 wlan0 Scan request completed
19:55:58.170337 wlan0 Scan request completed
19:57:57.800120 wlan0 Scan request completed
19:58:00.472203 wlan0 New Access Point/Cell address:Not-Associated
19:58:02.253448 wlan0 Scan request completed
19:58:02.329379 wlan0 Set Mode:Managed
19:58:02.329445 wlan0 Set ESSID:off/any
19:58:02.329463 wlan0 Set Frequency:2.432 GHz (Channel 5)
19:58:02.330301 wlan0 Set ESSID:"Charlies"
19:58:02.502064 wlan0 Association Response IEs:010882848B961224486C32040C183060DD180050F20201 01000003A4000027A4000042435E0062322F002D1AEE1113FF FF00000100000000000000000000000
handle_netlink_events: error reading netlink: Bad file descriptor.
Segmentation fault


I guess I'll try the newer firmware, but any ideas as to anything else I should look for? I have a system log of Mint 10 losing the connection too, it looks pretty similar.

I also have logs of it loading and connecting to my router after a reboot with knoppix, etc.

-Charlie

[Charlie Foxtrot]

For what it's worth; I've been using the newer, one part firmware overnight; but it hasn't helped.

-Charlie

[krishna.murphy]

Charlie, et. al. -

FWIW, I often see the prompt to supply the WPA2 passphrase for my wireless network when I boot my Knoppix box after shutting it down. I have found that by simply hitting escape or clicking the Cancel button on the dialog box, the system will then automatically "find" the credential store (which I have set to use a saved password to access the credentials without typing them more than once.) I don't know why it doesn't just get to it immediately, but it usually only happens once at the beginning of a new session.

Hope that helps!
Krishna :mrgreen:

[Charlie Foxtrot]

Krishna,

I tried hitting cancel, but it immediately went to disconnected status. I've roll back to the 2 part firmware, it seems like it might work slightly better.

-Charlie

[krishna.murphy]

Krishna,

I tried hitting cancel, but it immediately went to disconnected status. I've roll back to the 2 part firmware, it seems like it might work slightly better.

-CharlieYeah, mine does that, too. But it then immediately(?) starts connecting again, and this time it finds the credentials store. One possible difference is that I have set my router to NOT broadcast the SSID, so the process must proceed WITHOUT finding it broadcast; also, the driver in use in my case is the ath5k, which is where you suspect the trouble is arising, I think. It is possible that's it, but I thought enumerating the symptoms of my similar troubles might help clarify the situation for you.

Cheers!

Krishna :mrgreen:

[Charlie Foxtrot]

Are you using the WN111V2 and the ath5k drivers? How do you get it to do that, since the driver is in the kernel? Or do you mean the ath5k firmware? I'm not sure how you would do that either, since the kernel first looks for ar9170.fw and if it can't find that goes looking for ar9170-1.fw and ar9170-2.fw.

-Charlie

[Forester]

Hi Charlie,

Oh dear. :(

I don't think this is a Network Manager problem. Once you've supplied the keyring password the NM takes over and if the WLAN connection is dropped, the NM will reconnect automatically without bothering you for a password. Under Knoppix I never gave a keyring password so every now and then I get asked to enter my WPA pass phrase again, That's the NM reconnecting. The fact that you got asked for the pass phrase I think means the automatic reconnection failed.

The automatic reconnection failed, I believe because of ...

kernel: [29816.893738] ieee80211 phy0: wlan0: No probe response from AP 94:44:52:43:16:f4 after 500ms, disconnecting.What this means it the kernel thinks your wireless interface has gone away (been unplugged). More likely it has powered down (gone into suspend or hibernation mode).

You've tried unplugging and reinsertion to get out of this disconnect problem. I seem to remember you have a laptop. Does closing the lid make it suspend/hibernate ? Does the wireless reconnect when you resume ? Have you tried closing the lid as a way either of avoiding or of getting out of this disconnect problem ?

I did a google on:


ieee80211 phy0: wlan0: No probe responseand got a lot of recent (this year) hits. There were a couple for Broadcom (b43 / bcm4318, which I think utu has), one for a Linksys WUSB600N v1 (which I think has the same chip as you do Charlie) and loads for the athk5 (which Krishna has). That does not mean they are related. Many are on mailing lists and ramble on and on without conclusion.

There is one long conversion between some well meaning chap with a problem and an expert. Basically the expert was saying if the chap had a problem he should find out exactly which change in the kernel has introduced it and then maybe the expert would look into it. Ever build the kernel yourself ? Ever done a git bisection ? The chap's problem was a disconnect at start up that was intermittent (like Krishna's). Get one bisect wrong and you're wasting your time. :(

Have I seen this kind of problem ? May be and I might be able to suggest a work around. I've two old laptop I sometimes use for testing. One has a cheap USB wireless and the other an old PCMCIA card wireless. Last backend I tried testing Debian squeeze installation by using the netinstall from the smallest business card iso. Not recommended. It worked fine but was slow so I left it running overnight. In the morning the wireless connections were dead (both laptops). No way to revive them short of unplugging and reinserting the device and then rescanning to remake the network connection allowing the installation to be completed.

My hypothesis os that if the wireless adapter is idle for a long time it will shut down. It will appear to disconnect from Linux and you need, at least, to unplug and reinsert. No one sees this much because wireless connections are usually idle for long enough.

Open a console and ping your router. Leave the ping running for 48 hours and see if your wireless does not disconnect. If it does not, then install ntp and all ntp to the list of SERVICES in /etc/rc.local. That should keep your wireless up and your time correct. :)

[Charlie Foxtrot]

Hi Charlie,

You've tried unplugging and reinsertion to get out of this disconnect problem. I seem to remember you have a laptop. Does closing the lid make it suspend/hibernate ? Does the wireless reconnect when you resume ? Have you tried closing the lid as a way either of avoiding or of getting out of this disconnect problem ?


There is one long conversion between some well meaning chap with a problem and an expert. Basically the expert was saying if the chap had a problem he should find out exactly which change in the kernel has introduced it and then maybe the expert would look into it. Ever build the kernel yourself ? Ever done a git bisection ? The chap's problem was a disconnect at start up that was intermittent (like Krishna's). Get one bisect wrong and you're wasting your time. :(

Have I seen this kind of problem ? May be and I might be able to suggest a work around. I've two old laptop I sometimes use for testing. One has a cheap USB wireless and the other an old PCMCIA card wireless. Last backend I tried testing Debian squeeze installation by using the netinstall from the smallest business card iso. Not recommended. It worked fine but was slow so I left it running overnight. In the morning the wireless connections were dead (both laptops). No way to revive them short of unplugging and reinserting the device and then rescanning to remake the network connection allowing the installation to be completed.

My hypothesis os that if the wireless adapter is idle for a long time it will shut down. It will appear to disconnect from Linux and you need, at least, to unplug and reinsert. No one sees this much because wireless connections are usually idle for long enough.

Open a console and ping your router. Leave the ping running for 48 hours and see if your wireless does not disconnect. If it does not, then install ntp and all ntp to the list of SERVICES in /etc/rc.local. That should keep your wireless up and your time correct. :)

Forester,

I tried out running knoppix briefly as a live cd on my wife's laptop, but I'm mainly running it installed on the HDD of my old Dell desktop, that's where I'm seeing this problem.

Generally, it does seem like my wireless connection dies when the machine is idle. The first time it ran successfully overnight was when I was running iwevent in a terminal window, which would probably act similar to doing a ping.

However, it has died several times when I was in the middle of surfing the web. Generally it will stay up for 3 or 4 hours at at time. For some reason it's been working for about 28 hours straight now, I'm not sure what's up.

It seems the best way to recover is hit cancel when it prompts for my credentials, which it shouldn't really have to do, since I've saved them in the keyring. This puts the adapter in disconnected mode. I generally have

tail -F /var/log/syslog

running in a terminal window. After all the activity has stopped, I remove and reinsert my adapter and then pick my wireless router from the list. If I remove adapter while linux is trying to use it, it seems to put things in a weird state and I sometimes have to do a reboot to get it to work again.

Thanks,
-Charlie

[Forester]

However, it has died several times when I was in the middle of surfing the web.


Oh dear. I'm sorry to read that. Must be a bit of nuisance. However, you seem to have a work around.

The thread I read said there is bug somewhere in the encryption. Perhaps that is what you are seeing. It wasn't clear but what was clear was that they don't know where the problem lies so little chance of a fix any time soon.

I looked at the ar9170 driver page you referenced and it says the driver is deprecated and you should be using the carl9170 driver instead. The driver is present in Knoppix but you'd need to download appropriate firmware. Both drivers a loadable modules (they aren't actually built into the kernel). If you want to try this driver, we'd need to find and change a udev rule somewhere. Let me know if you want to give it a go and I'll dig a little deeper.

[Charlie Foxtrot]

I might try playing around with the firmware later. For now, I've noticed that I'm seeing the following in dmesg:

[ 3.812719] usb 5-2: not running at top speed; connect to a high speed hub

So I've ordered an el-cheapo USB 2.0 adapter card, and will try that out. I'm wondering if it might make my connection more stable, in addition to making it faster.

-Charlie

[Forester]

So I've ordered an el-cheapo USB 2.0 adapter card, and will try that out. I'm wondering if it might make my connection more stable, in addition to making it faster.


I hope so. I did wonder when you said you had an old laptop whether you were stuck with USB 1.1.

USB 1.1 through put is about the same as 802.11 b (12 Mbps). If this forces your adapter into that mode, it will slow your WLAN down for anyone else using it. With a USB 2.0 hub you should get 802.11 g (54 Mbps) so yes it will be faster. Fast enough to watch streamed video (if your laptop can keep up).

I would hope it is more stable. Although your adapter claims to be USB 1.1 compatible, that won't have been tested as much. I've had wireless disconnects while transferring large files to another machine. I guess something couldn't take the load. Overload might be why you loose the connection while you're busy. That should get better with a USB 2 hub. You don't want the wireless going down and taking your VPN connection with it.

Interference is another possibility. Does the Network Manager report other wireless networks in your neighbourhood ? Are they on the same channel ? If so, try using a different one. It is said that things like cordless mice and cheap electrical equipment can cause interference too.

Anyway, best of luck. Let us know how you get on.