On Tue, Mar 11, 2008 at 10:07:20PM -0500, Paul Johnson wrote: > On Tue, Mar 11, 2008 at 3:58 PM, John W. Linville <linville@xxxxxxxxxx> wrote: > > On Tue, Mar 11, 2008 at 02:08:58PM -0600, Paul Johnson wrote: > > > On Tue, Mar 11, 2008 at 1:50 PM, John W. Linville <linville@xxxxxxxxxx> wrote: > > > > If I knew when people were going to have problems, I'd only merge > > bug-free combinations. :-) In general these drivers are expected > > to function. Indeed for my boxes in my environments they have > > generally worked for a long time. There has been some churn upstream > > recently that probably destabilized them -- I assure you that it > > was unintentional. > > Can I make sure I understand. You do have a laptop using iwl3945 and > it does associate dependably to a router, using a WEP key, with > NetworkManager? You can go between environments and the system can > get an IP number with NM? Yes. > Can you point me at docs on debugging? Posting the logs you posted is probably a good step. If I suspected a driver problem there might be more to ask, but given what you have posted I don't think the problem is in the driver. > I saw, with my own eyes, that NM could join a nonsecured network when > I wrote you this morning. But I came home and failed. When > NetworkManager tries to join my WEP network, I see the same old > blubber (pasted in a load of crap below). I let NM try several times > (I was clicking on nm-applet to make it try again). Then I restarted > without NM and system-config-network was able to join the network. This points to a userland issue. If the driver didn't work, then s-c-n wouldn't work either. > I do not have any WPA networks and have never configured the WPA > framework on this laptop. Could that be causing my trouble? Not if you are trying to use WEP. :-) > ACPI: PCI Interrupt 0000:0c:00.0[A] -> GSI 17 (level, low) -> IRQ 17 > wlan0: Initial auth_alg=0 > wlan0: authenticate with AP 00:19:5b:48:2f:8d > wlan0: RX authentication from 00:19:5b:48:2f:8d (alg=0 transaction=2 status=0) > wlan0: authenticated > wlan0: associate with AP 00:19:5b:48:2f:8d > wlan0: RX AssocResp from 00:19:5b:48:2f:8d (capab=0x31 status=0 aid=6) > wlan0: associated > wlan0: switched to long barker preamble (BSSID=00:19:5b:48:2f:8d) Up to here looks fine. > WEP decrypt failed (ICV) > WEP decrypt failed (ICV) > WEP decrypt failed (ICV) > WEP decrypt failed (ICV) > WEP decrypt failed (ICV) > WEP decrypt failed (ICV) > WEP decrypt failed (ICV) > WEP decrypt failed (ICV) > WEP decrypt failed (ICV) > WEP decrypt failed (ICV) > printk: 3 messages suppressed. > WEP decrypt failed (ICV) > WEP decrypt failed (ICV) > WEP decrypt failed (ICV) > printk: 8 messages suppressed. > WEP decrypt failed (ICV) > wlan0: disassociate(reason=3) > wlan0: disassociate(reason=3) > wlan0: RX deauthentication from 00:19:5b:48:2f:8d (reason=7) > wlan0: deauthenticated > wlan0: RX deauthentication from 00:19:5b:48:2f:8d (reason=7) > wlan0: RX deauthentication from 00:19:5b:48:2f:8d (reason=7) > wlan0: RX deauthentication from 00:19:5b:48:2f:8d (reason=7) > wlan0: RX deauthentication from 00:19:5b:48:2f:8d (reason=7) > wlan0: RX deauthentication from 00:19:5b:48:2f:8d (reason=7) . . . After here things look bad. "WEP decrypt failed" suggests that maybe somehow your WEP key got changed post-association. The "reason=3" lines indicate "Deauthenticated because sending STA is leaving (has left) IBSS or ESS". Since the reason originates with your router, this suggests that we have sent a disassocation request and the router is complying with our request. The "reason=7" lines indicate "Class 3 frame received from nonassociated STA". Class 3 frames are general data frames, and they are not allowed when in an unassociated state. So, basically it looks like something is confusing the mac80211 component. One could argue that this shouldn't happen, but one might counter that with the meme that we should "give the user enough rope to shoot himself in the foot" (or something like that). Anyway, that is a digression... Generally when this happens it is because more than one userland entitiy is trying to drive things. So for example you might have a copy of wpa_supplicant running in competition with the wpa_supplicant that is spawned by NetworkManager, or s-c-n might be doing something to drive the device while NM is trying to be in control. Etc, etc, ad infinitum... :-) These are in the "don't do that" category. So, you probably want to run system-config-network and disable the device there. You probably also want to do this: service wpa_supplicant stop chkconfig wpa_supplicant off And for my personal tastes: chkconfig NetworkManager on Then for a healthy cleansing, reboot the box. Resist any temptation to run "ifconfig" or "iwconfig". It is best to limit any "iwlist" invocations as well. In other words, stay out of NetworkManager's way. :-) Does this result in a more pleasant NM-driven experience? :-) If not, that is about all I know to do ATM. I'll refer you to Dan Williams <dcbw@xxxxxxxxxx> for further NM assistance. Good luck! John -- John W. Linville linville@xxxxxxxxxx
