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
