Re: What do you think about compat-wireless, iwl3945, & how does kernel find "updates" modules?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux