Re: NM and ipw3945 once again

["Andrea Dell'Amico" <adellam sevenseas org>]

On Sun, 2007-03-18 at 16:14 +0200, Sertaç Ö. Yıldız wrote:
> * [13.Mar.07 10:39 -0400] Dan Williams:
> > Well, if the driver is sending a disassociation event, then clearly the
> > driver cannot proceed with the options it's been given.  In the plain
> > wpa_supplicant case that was noted above, even wpa_supplicant tries once
> > and doesn't get it, then retries and does get it.  I'm very curious what
> > causes the driver to think it got disconnected, especially since it
> > apparently can connect with a second association request with the exact
> > same options.
> 
> NM can connect as soon as I login after a reboot, but after resuming
> from a suspend/hibernate it continuously fails while wpa_supplicant
> succeeds after a retry.
> 
> > If there's driver debugging that can be enabled, that would be quite
> > helpful.  Or frame capture between the AP and the STA.
> 
> Attached is what is logged when NM fails to associate. The ‘privacy
> mismatch’ part seems to be the cause.

I'm observing the same behaviour.
Not only after a resume, but also when other access points other than
mine appear or disappear, especially when I'm at home where I have a
Linksys WAG345G.
At work I have a 3com 7760 and the network never disconnects, and rarely
fails to connect after a resume.

A 'modprobe -r ipw3945' temporarily resolve the problem.

> This is with:
> - ieee80211 git-1.1.13 (from FC6 kernel 2.6.20-1.2925.fc6)
> - ipw3945 1.2.0dmpr
> - NetworkManager-0.6 svn2479
> - nm-applet svn64

fc6 for me, with ipw3945 from atrmps (I tried the new driver but I get
unresolved symbols)

> PS: I’m not subscribed to the list, please cc.

ciao
andrea
-- 
Do. Or do not. There is no try. (Yoda)