Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken

[Ehud Gavron]

Jory, thank you for helping convince Michael I was not hallucinating!

Larry, thank you for finding the difference in the kernel output!



It works.



Have I thanked everyone yet?  Because it sure as heck feels like I want to.

Ehud

Michael Buesch wrote:

Michael, thank you for finding the part of the code affected by the underlying changes caused by the patch but not changed by the patch! I've got the latest wireless-dev tree (2.6.23-rc2, git checkout -f) with the change below IT WORKS!!!

On Friday 10 August 2007 17:02:15 Larry Finger wrote:

Jory A. Pratt wrote:

Larry Finger wrote:

What encryption method are you using?

Larry

I use wep encryption on a WRT54G V3 with dd-wrt. I will work on it later tonight and see what I can come up with.

Your answer confirms my latest result in which I have been able to reproduce 
the problem here.





--- dmesg.good  2007-08-10 09:40:23.000000000 -0500
+++ dmesg.bad   2007-08-10 09:41:23.000000000 -0500
..snip..
@@ -569,7 +569,6 @@
  bcm43xx_mac80211: 32-bit DMA initialized
  bcm43xx_mac80211: Wireless interface started
  NET: Registered protocol family 17
-bcm43xx_mac80211: Using hardware based encryption for keyidx: 0, mac: 
ff:ff:ff:ff:ff:ff
  eth1: Initial auth_alg=0
  eth1: authenticate with AP 00:1a:70:46:ba:b1
  eth1: RX authentication from 00:1a:70:46:ba:b1 (alg=0 transaction=2 status=0)




Larry

I bisected the wireless-dev kernel to an arbitrary point before the change in status handling (commit 85a83d26). That version could connect successfully using WEP and WPA encryption. I then added the status-handling patch and tried again. This kernel could still do WPA encryption and it could authenticate and associate with the WEP-using AP, but it could not get an IP number using DHCP. I then did a diff between the dmesg output for the driver that works (dmesg.good) and the one that does not (dmesg.bad). There are the usual number of differences due to slight timing difference, etc, but the following difference stands out: The good version is using hardware encryption, and the bad one is not. I have no idea why, but it seems to be the critical difference. I'm ready to test any trial patch.

Ok, I see the bug in set_key.

        if (bcm43xx_status(dev) != BCM43xx_STAT_INITIALIZED) {
                err = -ENODEV;
                goto out_unlock;
        }

We didn't have a chance to spot the bug in the patch that introduced
it, because it did not touch this function.
This should be changed to

        if (bcm43xx_status(dev) < BCM43xx_STAT_INITIALIZED) {
                err = -ENODEV;
                goto out_unlock;
        }

smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev