On Friday 10 August 2007 17:35:03 Larry Finger wrote: > Michael Buesch wrote: > > 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. > >> > >> 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: > >> > >> --- 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) > >> > >> > >> 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. > >> > >> Larry > >> > >> > > > > 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; > > } > > > > This part of set_multicast_list also was not touched by the patch > > if (wl->promisc != !!(netflags & IFF_PROMISC)) { > wl->promisc = !!(netflags & IFF_PROMISC); > if (bcm43xx_status(dev) == BCM43xx_STAT_INITIALIZED) > bcm43xx_adjust_opmode(dev); > } > > Is that correct? My thinking is that it should be >= BCM43xx_STAT_INITIALIZED.
Yeah, you are right. I will submit patches for this. -- Greetings Michael. _______________________________________________ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev