bcm43xx-d80211 broadcast reception with WPA

bcm43xx-d80211 broadcast reception with WPA

[Paul Hampson]

Hi,

Long time lurker, first time poster. ^_^

I've been backporting the bcm43xx-d80211 driver to whatever the released
2.6 kernel was using the rt2x00 project's d80211 stack (equivalent to
current wireless-dev but with a workaround for not having a ieee80211_dev
pointer and still using the _tfm interface instead of the _cypher interface.)

As of last night's wireless-dev tree bcm43xx, everything seems to be
operating fine except incoming broadcast traffic is coming in 14 bytes too
long and scrambled. I presume this means it's not decrypting properly...

Anyway, I just thought I'd mention it. It might have gone unnoticed by the
bcm43xx-d80211 developers, since it doesn't interfere with normal operation
(A DHCP client's only broadcasts are outgoing) and only showed up for me
because radvd's RAs were not arriving and my IPv6 address was not being set.

I couldn't find any mention of such a thing on the list, and I'm happy to
provide whatever debugging output is useful, but the laptop with the device
isn't with me at the moment.

Relevant facts:

Platform: Debian/unstable (PPC) w/linux-image-2.6.18-1-powerpc (2.6.18-3)
Drivers:  bcm43xx-d80211 from wireless-dev 774f233b7915a2c36480eb4d98e6f57938f04b7b
Firmware: 4.80.46.0 (BE, from AppleAirPortBrcm4311)
Stack:    ieee80211 from http://rt2x00.serialmonkey.com/rt2x00-cvs-daily.tar.gz
 2006110303 is the date on the output, I believe. Hasn't been updated since 20061028
 Plus a backport of the following commits:
[PATCH] d80211: extend extra_hdr_room to be a bytecount 522e078b9f1f8309770dd161d90ddac1573a7877
[PATCH] d80211: remove unused variable in ieee80211_rx_irqsafe 10bfc9cdf9621385a3b69aa35f9fa86cc6a46bc6
[PATCH] d80211: Add wireless statistics 448bf25bc9e3d70a211fdf235426472089371c43
(as well as anything else that showed up in a diff of the d80211 dir against the rt2x00
iee80211 dir and wasn't a 2.6.19ism or wireless-devism)

I'm basically using the instructions I posted at [1] except also patching rt2x00's
ieee80211 stack.

I acknowledge that any of the firmware version, the backporting, the forward porting
or the current lunar cycle may be causing this problem. If no one pipes up with an
insight, I'll try tonight with a v3 firmware, although the reason I moved to a v3
firmware was my previous build of bcm43xx-d80211 also wasn't getting an IPv6 address,
although I don't believe the RAs were scrambled in that case.

[1] http://openfacts.berlios.de/index-en.phtml?title=Broadcom_43xx_Linux_Driver/Debian_Unstable_with_Devicescape_802.11_stack

-- 
Paul "TBBle" Hampson
Opinions expressed here do not reflect the views of my employer
Hell, we don't even agree on my pay cheque

Re: bcm43xx-d80211 broadcast reception with WPA

[Ivo Van Doorn]

Hi,

> I've been backporting the bcm43xx-d80211 driver to whatever the released
> 2.6 kernel was using the rt2x00 project's d80211 stack (equivalent to
> current wireless-dev but with a workaround for not having a ieee80211_dev
> pointer and still using the _tfm interface instead of the _cypher interface.)

Just a note about that stack, it should only be used on kernel 2.6.17
and higher.
Previous kernels had a bug that caused the stack to crash.
The _tfm cipher interface will soon change, since I haven't had time to update
the stack to the latest version yet, I'll do that this weekend.

 Ivo

Re: bcm43xx-d80211 broadcast reception with WPA

[Paul Hampson]

Ivo Van Doorn <ivdoorn <at> gmail.com> writes:
> > I've been backporting the bcm43xx-d80211 driver to whatever the released
> > using the rt2x00 project's d80211 stack

> Just a note about that stack, it should only be used on kernel 2.6.17
> and higher.

Thanks, I've noted that at the berlios wiki.

--
Paul "TBBle" Hampson
Paul.Hampson@Pobox.com

Re: bcm43xx-d80211 broadcast reception with WPA

[Michael Buesch]

On Thursday 09 November 2006 23:23, Paul Hampson wrote:
> Hi,
> 
> Long time lurker, first time poster. ^_^
> 
> I've been backporting the bcm43xx-d80211 driver to whatever the released
> 2.6 kernel was using the rt2x00 project's d80211 stack (equivalent to
> current wireless-dev but with a workaround for not having a ieee80211_dev
> pointer and still using the _tfm interface instead of the _cypher interface.)
> 
> As of last night's wireless-dev tree bcm43xx, everything seems to be
> operating fine except incoming broadcast traffic is coming in 14 bytes too
> long and scrambled. I presume this means it's not decrypting properly...

It sounds like a bug in the hardware decryption setup.
Are you using TKIP or not?

Incoming mcast frames are handled in a special way in hardware.
The keyidx field of the packet is used to lookup the key, as
far as I know. (Otherwise the MAC address is used).
Can I see a full dmesg log and a capture log on the broken machine, please?

-- 
Greetings Michael.

Re: bcm43xx-d80211 broadcast reception with WPA

[Paul Hampson]

Michael Buesch <mb <at> bu3sch.de> writes:

> On Thursday 09 November 2006 23:23, Paul Hampson wrote:
> > I've been backporting the bcm43xx-d80211 driver to whatever the released
> > 2.6 kernel was using the rt2x00 project's d80211 stack (equivalent to
> > current wireless-dev but with a workaround for not having a ieee80211_dev
> > pointer and still using the _tfm interface instead of the _cypher interface.)

> > As of last night's wireless-dev tree bcm43xx, everything seems to be
> > operating fine except incoming broadcast traffic is coming in 14 bytes too
> > long and scrambled. I presume this means it's not decrypting properly...

> It sounds like a bug in the hardware decryption setup.
> Are you using TKIP or not?

Yes, it's using TKIP. The router docs and the loading of the tkip module
when I use the softmac driver agree on this.

> Incoming mcast frames are handled in a special way in hardware.
> The keyidx field of the packet is used to lookup the key, as
> far as I know. (Otherwise the MAC address is used).
> Can I see a full dmesg log and a capture log on the broken machine, please?

Sending first some ipv6 broadcast pings and then some ipv4 broadcast pings:
(Commands "ping -b 192.168.192.255 -c 1" and "ping6 -I intel0 -c 1 ip6-allnodes")

17:04:08.794400 00:02:a5:40:8d:61 (oui Unknown) Unknown SSAP 0x26 >
33:33:00:00:00:01 (oui Unknown) Unknown DSAP 0x9c Unnumbered, eb, Flags [Poll],
length 116
        0x0000:  9d26 fbda 7284 bd60 6cdf 58c4 d064 71c6
        0x0010:  2a09 adab 4a19 a691 5640 9216 eae8 df70
        0x0020:  b94e 9ee9 fd75 6c25 ab16 36fb cdac c231
        0x0030:  0f17 f965 4d20 4a11 ab50 c77f 66ca 54e4
        0x0040:  e469 e458 5d6c c13d cc78 48fd da5c 7f71
        0x0050:  2f06 0728 c8da 689b b790 ec22 4d62 5a92
        0x0060:  221b b3cb 65e5 dc8a 8e57 3486 2a1e a2c2
        0x0070:  faf6 ae71
17:04:10.104111 00:02:a5:40:8d:61 (oui Unknown) Unknown SSAP 0xa8 >
33:33:00:00:00:01 (oui Unknown) Unknown DSAP 0xb8 Supervisory, Reject, rcv seq
78, Flags [Final], length 116
        0x0000:  b8a9 099d 0afb f9f3 8ef6 1c31 81c0 f1eb
        0x0010:  3869 1952 9762 f4f0 c743 7613 fd9c 99cd
        0x0020:  1644 a454 df14 5481 a35a 8c96 59b3 9391
        0x0030:  8579 a165 3da2 58ad a6a8 d499 e40c 4c4c
        0x0040:  3b33 a4ce 2b2e 439b 77f6 da5d 1d18 1685
        0x0050:  1e64 39cb 3565 5596 30eb fa1c 1cbd cec8
        0x0060:  395b a38c f7a4 a754 7c19 d694 a94b a4f9
        0x0070:  5785 64aa
17:04:10.938418 00:02:a5:40:8d:61 (oui Unknown) Unknown SSAP 0x1c >
33:33:00:00:00:01 (oui Unknown) Unknown DSAP 0x64 Unnumbered, 23, Flags [Poll],
length 116
        0x0000:  641c 338d 7f62 2bcd 4fff c7dd 4a6e efa1
        0x0010:  07ed f39b 5b88 c68e 27dd f35b 70cf df3c
        0x0020:  0cb8 f3ba 0b97 9069 43f9 e74f 1cb2 e4d7
        0x0030:  bf97 fbd8 94d8 efc5 284d 5393 604b 13ef
        0x0040:  1cd7 46e1 7b35 008b 8247 89bb 0a6a 4dac
        0x0050:  45e3 49af 853d 13fa e263 dea8 26ca 7076
        0x0060:  bec6 938f bd75 19bd a3ea 9f79 ea65 2c2d
        0x0070:  a45c b3d1
17:04:14.491735 00:02:a5:40:8d:61 (oui Unknown) Unknown SSAP 0x8a > Broadcast
Unknown DSAP 0xe4 Information, send seq 49, rcv seq 14, Flags [Final], length 96
        0x0000:  e58b 621d 383b 5114 c37d 54de da9e dd8b
        0x0010:  7d28 87d2 7d53 cd57 f0b4 c079 54a5 0bbe
        0x0020:  3eb2 f0b9 e1e6 e82b e52b ffaf f833 217c
        0x0030:  dbe7 c9f1 db0f 592e b432 5f7d 8041 f73f
        0x0040:  7267 662b d64e 170d c619 a447 b2c0 bd17
        0x0050:  b97b b032 dd1b d8f5 c007 eae9 0aee ea9f
17:04:16.489911 00:02:a5:40:8d:61 (oui Unknown) Unknown SSAP 0xa4 > Broadcast
ProWay NM Information, send seq 122, rcv seq 28, Flags [Final], length 96
        0x0000:  0fa5 f439 af38 57a6 564c 0c25 e2c0 7a09
        0x0010:  61fb a1f1 adb0 3718 cb39 3a03 6ecf ad42
        0x0020:  6e9c 75d7 cd06 0566 30c9 0238 4cf8 61a9
        0x0030:  0928 9414 f48b 2a07 3eca 05de a8a9 9787
        0x0040:  1ed5 2643 f82a b9a8 8e5a 5410 6858 b5c0
        0x0050:  ecb2 72a3 2dfb 66ac 0ce8 c4f8 ea87 ab14
17:04:18.449142 00:02:a5:40:8d:61 (oui Unknown) Unknown SSAP 0xb4 > Broadcast
Unknown DSAP 0x6a Supervisory, Receiver not Ready, rcv seq 23, Flags [Command],
length 96
        0x0000:  6bb4 252e 2888 d3b1 68bc 6129 9087 4170
        0x0010:  f4e2 4a47 adc9 9bce 7bf2 51b3 ac20 bd10
        0x0020:  7d67 3e00 6b6f 41ff 3e0c 2940 d31c 6143
        0x0030:  f7e4 caa6 879f 4663 e04b 0f6d 37eb 1db5
        0x0040:  fffd 0dfa 9b78 80e1 a30a 799e 9b1a 9d4a
        0x0050:  61c8 f041 e564 d566 b697 aaf6 8336 a6f3

And the dmesg output:

bcm43xx_d80211: no version for "ssb_init" found: kernel tainted.
PCI: Enabling device 0001:10:12.0 (0004 -> 0006)
ssb: Core 0 found: cc 0800, rev 04, vendor 4243
ssb: Core 1 found: cc 0812, rev 05, vendor 4243
ssb: Core 2 found: cc 080D, rev 02, vendor 4243
ssb: Core 3 found: cc 0807, rev 02, vendor 4243
ssb: Core 4 found: cc 0804, rev 09, vendor 4243
bcm43xx_d80211: Broadcom 4306 WLAN found
ssb: Switching to core 4
ssb: Switching to core 1
bcm43xx_d80211: PHY connected
bcm43xx_d80211: Detected PHY: Version: 2, Type 2, Revision 2
bcm43xx_d80211: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2)
bcm43xx_d80211: Radio turned off
bcm43xx_d80211: Radio turned off
wmaster0: Selected rate control algorithm 'simple'
bcm43xx_d80211: Virtual interface added (type: 0x00000002, ID: 6, MAC:
00:0d:93:ef:57:2d)
ssb: Switching to core 0
ssb: Switching to core 1
bcm43xx_d80211: PHY connected
bcm43xx_d80211: firmware revision 15F, patchlevel 7E, date 2006-07-29 05:54:02
ssb: Switching to core 0
ssb: Switching to core 1
bcm43xx_d80211: Radio turned on
ssb: Switching to core 0
ssb: Switching to core 1
bcm43xx_d80211: Chip initialized
bcm43xx_d80211: 30-bit DMA initialized
bcm43xx_d80211: Keys cleared
bcm43xx_d80211: Selected 802.11 core (phytype 2)
wlan0.11: Does not support passive scan, disabled
wlan0: starting scan
wlan0: scan completed
wlan0: Initial auth_alg=0
wlan0: authenticate with AP 00:14:6c:ed:c1:76
wlan0: RX authentication from 00:14:6c:ed:c1:76 (alg=0 transaction=2 status=0)
wlan0: authenticated
wlan0: associate with AP 00:14:6c:ed:c1:76
wlan0: RX AssocResp from 00:14:6c:ed:c1:76 (capab=0x471 status=0 aid=1)
wlan0: associated
bcm43xx_d80211: Using software based encryption for keyidx: 0, mac:
00:14:6c:ed:c1:76
bcm43xx_d80211: Using software based encryption for keyidx: 1, mac:
ff:ff:ff:ff:ff:ff
agpgart: Putting AGP V2 device at 0000:00:0b.0 into 4x mode
agpgart: Putting AGP V2 device at 0000:00:10.0 into 4x mode
[drm] Loading R300 Microcode
wlan0: no IPv6 routers present
device wlan0 entered promiscuous mode
audit(1163225045.337:6): dev=wlan0 prom=256 old_prom=0 auid=4294967295
wlan0: TKIP decrypt failed for RX frame from 00:14:6c:ed:c1:76 (res=-3)
wlan0: TKIP decrypt failed for RX frame from 00:14:6c:ed:c1:76 (res=-3)
device wlan0 left promiscuous mode
audit(1163225061.805:7): dev=wlan0 prom=0 old_prom=256 auid=4294967295

I can't reliably reproduce those "TKIP decrypt failed", I suspect that might be
annoyingly co-incidental failures from SSH, NMB, DHCP or IPv6 RA traffic.

Unloading the driver dmesg:
bcm43xx_d80211: Radio turned off
ssb: Switching to core 0
bcm43xx_d80211: DMA-32 0x0200 (RX) max used slots: 2/64
ssb: Switching to core 1
bcm43xx_d80211: DMA-32 0x02A0 (TX) max used slots: 0/128
bcm43xx_d80211: DMA-32 0x0280 (TX) max used slots: 0/128
bcm43xx_d80211: DMA-32 0x0260 (TX) max used slots: 0/128
bcm43xx_d80211: DMA-32 0x0240 (TX) max used slots: 0/128
bcm43xx_d80211: DMA-32 0x0220 (TX) max used slots: 20/128
bcm43xx_d80211: DMA-32 0x0200 (TX) max used slots: 0/128
bcm43xx_d80211: Virtual interface removed (type: 0x00000002, ID: 6, MAC:
00:0d:93:ef:57:2d)
wlan0: deauthenticate(reason=3)
wlan0: set_encrypt - low-level disable failed
wlan0: set_encrypt - low-level disable failed
wlan0: Initial auth_alg=0
wlan0: authenticate with AP 00:00:00:00:00:00

And loading up with v3 firmware:
ssb: Core 0 found: cc 0800, rev 04, vendor 4243
ssb: Core 1 found: cc 0812, rev 05, vendor 4243
ssb: Core 2 found: cc 080D, rev 02, vendor 4243
ssb: Core 3 found: cc 0807, rev 02, vendor 4243
ssb: Core 4 found: cc 0804, rev 09, vendor 4243
bcm43xx_d80211: Broadcom 4306 WLAN found
ssb: Switching to core 4
ssb: Switching to core 1
bcm43xx_d80211: PHY connected
bcm43xx_d80211: Detected PHY: Version: 2, Type 2, Revision 2
bcm43xx_d80211: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2)
bcm43xx_d80211: Radio turned off
bcm43xx_d80211: Radio turned off
wmaster0: Selected rate control algorithm 'simple'
bcm43xx_d80211: Virtual interface added (type: 0x00000002, ID: 8, MAC:
00:0d:93:ef:57:2d)
ssb: Switching to core 0
ssb: Switching to core 1
bcm43xx_d80211: PHY connected
bcm43xx_d80211: firmware revision 122, patchlevel 9A, date 2005-08-15 18:44:03
ssb: Switching to core 0
ssb: Switching to core 1
bcm43xx_d80211: Radio turned on
ssb: Switching to core 0
ssb: Switching to core 1
bcm43xx_d80211: Chip initialized
bcm43xx_d80211: 30-bit DMA initialized
bcm43xx_d80211: Keys cleared
bcm43xx_d80211: Selected 802.11 core (phytype 2)
wlan0.11: Does not support passive scan, disabled
wlan0: starting scan
wlan0: scan completed
wlan0: Initial auth_alg=0
wlan0: authenticate with AP 00:14:6c:ed:c1:76
wlan0: RX authentication from 00:14:6c:ed:c1:76 (alg=0 transaction=2 status=0)
wlan0: authenticated
wlan0: associate with AP 00:14:6c:ed:c1:76
wlan0: RX AssocResp from 00:14:6c:ed:c1:76 (capab=0x471 status=0 aid=1)
wlan0: associated
bcm43xx_d80211: Using software based encryption for keyidx: 0, mac:
00:14:6c:ed:c1:76
bcm43xx_d80211: Using software based encryption for keyidx: 2, mac:
ff:ff:ff:ff:ff:ff

One each of the ip4 and ip6 pings under v3 firmware
17:18:29.454625 00:02:a5:40:8d:61 (oui Unknown) Unknown SSAP 0xdc > Broadcast
Unknown DSAP 0xa6 Unnumbered, 07, Flags [Poll], length 96
        0x0000:  a6dc 1759 5095 ed4f 92f6 17dc d10c 9538
        0x0010:  e3e5 e302 e8f0 bfd8 0970 3dc7 315a c5eb
        0x0020:  ab6c 0c17 76a8 69ff c316 4955 1762 7ca0
        0x0030:  ba7f e65f e490 57e4 ad6c 53d5 fd4e d6de
        0x0040:  41b2 5ab9 4749 52e4 1a9d bad9 e2a7 8544
        0x0050:  91a6 eeef 5cc4 958c bc83 d7af 31f6 09a3
17:18:44.738765 00:02:a5:40:8d:61 (oui Unknown) Unknown SSAP 0xd2 >
33:33:00:00:00:01 (oui Unknown) Unknown DSAP 0x0a Information, send seq 103, rcv
seq 95, Flags [Command], length 116
        0x0000:  0ad2 cebe 311a edd5 4e6c 3c2f 2e53 5120
        0x0010:  d4da 94b6 a481 0d02 d802 cc6d 9f85 5106
        0x0020:  8c41 d771 4e8f 79cf bf2f 39c9 1dbd ad05
        0x0030:  544d 060d 154c 61d2 87d9 e6a2 b17c c353
        0x0040:  506c 2b3b e9d5 227f c849 aace 6b8f 3dbc
        0x0050:  55fa d232 65dd 51eb 4da5 84fe 95dc bb14
        0x0060:  7ba1 4e21 3215 816d c3e9 c7bf 05d9 812b
        0x0070:  ea8a f5af

The only other thing that jumped out as relevant is that
/sys/class/ieee80211/phy0/device/net:wlan0/keys/default/key (also 2/key)
had a different value from
/sys/class/ieee80211/phy0/sta/00:14:6c:ed:c1:76/key
and the former matched iwconfig's key listing, which had a [3] following it.

-- 
Paul "TBBle" Hampson
Paul.Hampson@Pobox.com

Re: bcm43xx-d80211 broadcast reception with WPA

[Michael Buesch]

Please _don't_ remove CCs.

On Saturday 11 November 2006 07:32, Paul Hampson wrote:
> Michael Buesch <mb <at> bu3sch.de> writes:
> 
> > On Thursday 09 November 2006 23:23, Paul Hampson wrote:
> > > I've been backporting the bcm43xx-d80211 driver to whatever the released
> > > 2.6 kernel was using the rt2x00 project's d80211 stack (equivalent to
> > > current wireless-dev but with a workaround for not having a ieee80211_dev
> > > pointer and still using the _tfm interface instead of the _cypher interface.)
> 
> > > As of last night's wireless-dev tree bcm43xx, everything seems to be
> > > operating fine except incoming broadcast traffic is coming in 14 bytes too
> > > long and scrambled. I presume this means it's not decrypting properly...
> 
> > It sounds like a bug in the hardware decryption setup.
> > Are you using TKIP or not?
> 
> Yes, it's using TKIP. The router docs and the loading of the tkip module
> when I use the softmac driver agree on this.

TKIP is still software encryption. Did you try with WPA-AES, for example,
which is hardware encryption?

The problem might be that the card tries to decrypt mcast
frames in the crypto hardware, although we did not set a key.
So it uses a random key to decrypt. That obviously results in crap.

-- 
Greetings Michael.

Re: bcm43xx-d80211 broadcast reception with WPA

[Paul TBBle Hampson]

On Sat, Nov 11, 2006 at 04:07:05PM +0100, Michael Buesch wrote:
> Please _don't_ remove CCs.

Sorry, I was sending via the gmane web interface, I guess it doesn't
honour CCs.

This one's via muttng's NNTP support to gmane, so I _think_ it's going
to the right places.

> On Saturday 11 November 2006 07:32, Paul Hampson wrote:
>> Michael Buesch <mb <at> bu3sch.de> writes:

> >> On Thursday 09 November 2006 23:23, Paul Hampson wrote:
> > >> I've been backporting the bcm43xx-d80211 driver to whatever the released
> > >> 2.6 kernel was using the rt2x00 project's d80211 stack (equivalent to
> > >> current wireless-dev but with a workaround for not having a ieee80211_dev
> > >> pointer and still using the _tfm interface instead of the _cypher interface.)

> > >> As of last night's wireless-dev tree bcm43xx, everything seems to be
> > >> operating fine except incoming broadcast traffic is coming in 14 bytes too
> > >> long and scrambled. I presume this means it's not decrypting properly...

> >> It sounds like a bug in the hardware decryption setup.
> >> Are you using TKIP or not?

>> Yes, it's using TKIP. The router docs and the loading of the tkip module
>> when I use the softmac driver agree on this.

> TKIP is still software encryption. Did you try with WPA-AES, for example,
> which is hardware encryption?

The router here only supports TKIP that I can see. There's another
network I'll be on on Monday night which I might be able to throw into
WPA2 mode... In fact, I was there yesterday and couldn't even get a
DHCP IP address, but didn't have the time to diagnose it.

> The problem might be that the card tries to decrypt mcast
> frames in the crypto hardware, although we did not set a key.
> So it uses a random key to decrypt. That obviously results in crap.

Eww, yuck.

-- 
-----------------------------------------------------------
Paul "TBBle" Hampson, B.Sc, LPI, MCSE
On-hiatus Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
Paul.Hampson@Pobox.Com

Of course Pacman didn't influence us as kids. If it did,
we'd be running around in darkened rooms, popping pills and
listening to repetitive music.
 -- Kristian Wilson, Nintendo, Inc, 1989

License: http://creativecommons.org/licenses/by/2.1/au/
-----------------------------------------------------------

Re: bcm43xx-d80211 broadcast reception with WPA

[Michael Buesch]

On Sunday 12 November 2006 02:24, Paul TBBle Hampson wrote:
> On Sat, Nov 11, 2006 at 04:07:05PM +0100, Michael Buesch wrote:
> > Please _don't_ remove CCs.
> 
> Sorry, I was sending via the gmane web interface, I guess it doesn't
> honour CCs.
> 
> This one's via muttng's NNTP support to gmane, so I _think_ it's going
> to the right places.
> 
> > On Saturday 11 November 2006 07:32, Paul Hampson wrote:
> >> Michael Buesch <mb <at> bu3sch.de> writes:
> 
> > >> On Thursday 09 November 2006 23:23, Paul Hampson wrote:
> > > >> I've been backporting the bcm43xx-d80211 driver to whatever the released
> > > >> 2.6 kernel was using the rt2x00 project's d80211 stack (equivalent to
> > > >> current wireless-dev but with a workaround for not having a ieee80211_dev
> > > >> pointer and still using the _tfm interface instead of the _cypher interface.)
> 
> > > >> As of last night's wireless-dev tree bcm43xx, everything seems to be
> > > >> operating fine except incoming broadcast traffic is coming in 14 bytes too
> > > >> long and scrambled. I presume this means it's not decrypting properly...
> 
> > >> It sounds like a bug in the hardware decryption setup.
> > >> Are you using TKIP or not?
> 
> >> Yes, it's using TKIP. The router docs and the loading of the tkip module
> >> when I use the softmac driver agree on this.
> 
> > TKIP is still software encryption. Did you try with WPA-AES, for example,
> > which is hardware encryption?
> 
> The router here only supports TKIP that I can see. There's another
> network I'll be on on Monday night which I might be able to throw into
> WPA2 mode... In fact, I was there yesterday and couldn't even get a
> DHCP IP address, but didn't have the time to diagnose it.

TKIP hw encryption needs some modifications to the d80211 stack.
There are patches available, but I think they are not merged, yet.
John, do you know the state on these patches?

> > The problem might be that the card tries to decrypt mcast
> > frames in the crypto hardware, although we did not set a key.
> > So it uses a random key to decrypt. That obviously results in crap.
> 
> Eww, yuck.


Ah, and also note that you _need_ firmware from a v4 binary driver
to have hardware encryption with bcm43xx.

-- 
Greetings Michael.

Re: bcm43xx-d80211 broadcast reception with WPA

[Ismail Donmez]

Hi,
12 Kas 2006 Paz 10:34 tarihinde şunları yazmıştınız:
> Ah, and also note that you _need_ firmware from a v4 binary driver
> to have hardware encryption with bcm43xx.

Last time I heard only v3 firmware was supported. Is that changed?

Regards,
ismail

Re: bcm43xx-d80211 broadcast reception with WPA

[Michael Buesch]

On Sunday 12 November 2006 21:43, Ismail Donmez wrote:
> Hi,
> 12 Kas 2006 Paz 10:34 tarihinde şunları yazmıştınız:
> > Ah, and also note that you _need_ firmware from a v4 binary driver
> > to have hardware encryption with bcm43xx.
> 
> Last time I heard only v3 firmware was supported. Is that changed?

Yes, wireless-dev supports v4 firmware (and even requires it for
advanced features like hw encryption)

-- 
Greetings Michael.

Re: bcm43xx-d80211 broadcast reception with WPA

[Ismail Donmez]

12 Kas 2006 Paz 23:47 tarihinde, Michael Buesch şunları yazmıştı: 
> On Sunday 12 November 2006 21:43, Ismail Donmez wrote:
> > Hi,
> >
> > 12 Kas 2006 Paz 10:34 tarihinde şunları yazmıştınız:
> > > Ah, and also note that you _need_ firmware from a v4 binary driver
> > > to have hardware encryption with bcm43xx.
> >
> > Last time I heard only v3 firmware was supported. Is that changed?
>
> Yes, wireless-dev supports v4 firmware (and even requires it for
> advanced features like hw encryption)

Thanks for information, this firmware would also solve the recent roothole.

Regards,
ismail

Re: bcm43xx-d80211 broadcast reception with WPA

[Ismail Donmez]

13 Kas 2006 Pts 00:40 tarihinde şunları yazmıştınız:
> 12 Kas 2006 Paz 23:47 tarihinde, Michael Buesch şunları yazmıştı:
> > On Sunday 12 November 2006 21:43, Ismail Donmez wrote:
> > > Hi,
> > >
> > > 12 Kas 2006 Paz 10:34 tarihinde şunları yazmıştınız:
> > > > Ah, and also note that you _need_ firmware from a v4 binary driver
> > > > to have hardware encryption with bcm43xx.
> > >
> > > Last time I heard only v3 firmware was supported. Is that changed?
> >
> > Yes, wireless-dev supports v4 firmware (and even requires it for
> > advanced features like hw encryption)
>
> Thanks for information, this firmware would also solve the recent roothole.

s/roothole/security vulnerability would be better =)

/ismail

Re: bcm43xx-d80211 broadcast reception with WPA

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 331 bytes --]

On Mon, 2006-11-13 at 00:41 +0200, Ismail Donmez wrote:

> > Thanks for information, this firmware would also solve the recent roothole.
> 
> s/roothole/security vulnerability would be better =)

Ummm, the problem was in the driver, not the firmware. You can't have
security problems like that in the firmware.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: bcm43xx-d80211 broadcast reception with WPA

[Ismail Donmez]

13 Kas 2006 Pts 00:54 tarihinde şunları yazmıştınız:
> On Mon, 2006-11-13 at 00:41 +0200, Ismail Donmez wrote:
> > > Thanks for information, this firmware would also solve the recent
> > > roothole.
> >
> > s/roothole/security vulnerability would be better =)
>
> Ummm, the problem was in the driver, not the firmware. You can't have
> security problems like that in the firmware.

Ah then only ndiswrapper is problematic. Thanks for the insight.

/ismail

Re: bcm43xx-d80211 broadcast reception with WPA

[Jiri Benc]

On Sun, 12 Nov 2006 09:34:27 +0100, Michael Buesch wrote:
> TKIP hw encryption needs some modifications to the d80211 stack.
> There are patches available, but I think they are not merged, yet.
> John, do you know the state on these patches?

Waiting for Hong Liu to respond to Johannes' comments.

Thanks,

 Jiri

-- 
Jiri Benc
SUSE Labs

Re: bcm43xx-d80211 broadcast reception with WPA

[Paul TBBle Hampson]

[-- Attachment #1: Type: text/plain, Size: 3077 bytes --]

On Sun, Nov 12, 2006 at 09:34:27AM +0100, Michael Buesch wrote:
> On Sunday 12 November 2006 02:24, Paul TBBle Hampson wrote:
>> On Sat, Nov 11, 2006 at 04:07:05PM +0100, Michael Buesch wrote:
> >> On Saturday 11 November 2006 07:32, Paul Hampson wrote:
> >>> Michael Buesch <mb <at> bu3sch.de> writes:
>> 
> > >>> On Thursday 09 November 2006 23:23, Paul Hampson wrote:
> > > >>> I've been backporting the bcm43xx-d80211 driver to whatever the released
> > > >>> 2.6 kernel was using the rt2x00 project's d80211 stack (equivalent to
> > > >>> current wireless-dev but with a workaround for not having a ieee80211_dev
> > > >>> pointer and still using the _tfm interface instead of the _cypher interface.)
>> 
> > > >>> As of last night's wireless-dev tree bcm43xx, everything seems to be
> > > >>> operating fine except incoming broadcast traffic is coming in 14 bytes too
> > > >>> long and scrambled. I presume this means it's not decrypting properly...
>> 
> > >>> It sounds like a bug in the hardware decryption setup.
> > >>> Are you using TKIP or not?
>> 
> >>> Yes, it's using TKIP. The router docs and the loading of the tkip module
> >>> when I use the softmac driver agree on this.
>> 
> >> TKIP is still software encryption. Did you try with WPA-AES, for example,
> >> which is hardware encryption?

I've just tried with WEP-104, which reports hardware encryption for all
four keys.

> Ah, and also note that you _need_ firmware from a v4 binary driver
> to have hardware encryption with bcm43xx.

Just to summarise results so far:

(Current version)
bcm43xx-d80211 w/v3 firmware and TKIP: Garbled broadcast RX
bcm43xx-d80211 w/v4 firmware and TKIP: Garbled broadcast RX
bcm43xx-d80211 w/v4 firmware and WEP-104: Correct broadcast RX

(version from wireless-dev before October 23rd, unsure of exact date)
bcm43xx (softmac) w/v3 firmware and TKIP: Correct broadcast RX

Still to test: bcm43xx-d80211 w/v3 firmware and WEP-104

I also tried looking at how the two drivers I've got here are clearing
their keys and comparing them to the bcm specs, and there's nothing
obviously wrong that I can see. Sadly I can't compare the drivers
directly since one is using the v3 specs and one the v4 specs... -_-

And to top it off, current wireless-dev's softmac bcm43xx driver doesn't
build against 2.6.18, and I'm not yet motivated into munging it into
doing so, unless it will have diagnostic advantage to this situation.
(It'll require also building a new ieee80211softmac at least)

-- 
-----------------------------------------------------------
Paul "TBBle" Hampson, B.Sc, LPI, MCSE
On-hiatus Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
Paul.Hampson@Pobox.Com

Of course Pacman didn't influence us as kids. If it did,
we'd be running around in darkened rooms, popping pills and
listening to repetitive music.
 -- Kristian Wilson, Nintendo, Inc, 1989

License: http://creativecommons.org/licenses/by/2.1/au/
-----------------------------------------------------------

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: bcm43xx-d80211 broadcast reception with WPA

[Johannes Berg]

On Wed, 2006-11-15 at 01:29 +1100, Paul TBBle Hampson wrote:

> Just to summarise results so far:
> 
> (Current version)
> bcm43xx-d80211 w/v3 firmware and TKIP: Garbled broadcast RX
> bcm43xx-d80211 w/v4 firmware and TKIP: Garbled broadcast RX
> bcm43xx-d80211 w/v4 firmware and WEP-104: Correct broadcast RX
> 
> (version from wireless-dev before October 23rd, unsure of exact date)
> bcm43xx (softmac) w/v3 firmware and TKIP: Correct broadcast RX

The last item is interesting. The softmac version doesn't include any hw
crypto so it never checks the 'decrypt attempted' bit in the RX header
afaik, leaving all crypto to hw.

I postulated before that the problem is that the firmware sets the
'decrypt attempted' bit even if the key is none, hence the driver tells
the d80211 stack that the frame was already decrypted (no decrypt error
occurs because in reality the algorithm is 'none'.)

You could test this theory by clearing the 'decrypt attempted' bit
unconditionally in the RX path before it is ever tested. Then, any
wep/aes should no longer work properly with v4 firmware and
bcm43xx-d80211, but tkip would. If my theory is correct.

johannes

Re: bcm43xx-d80211 broadcast reception with WPA

[Paul TBBle Hampson]

On Wed, Nov 15, 2006 at 01:29:59AM +1100, Paul TBBle Hampson wrote:
> Just to summarise results so far:

> (Current version)
> bcm43xx-d80211 w/v3 firmware and TKIP: Garbled broadcast RX
> bcm43xx-d80211 w/v4 firmware and TKIP: Garbled broadcast RX
> bcm43xx-d80211 w/v4 firmware and WEP-104: Correct broadcast RX

> (version from wireless-dev before October 23rd, unsure of exact date)
> bcm43xx (softmac) w/v3 firmware and TKIP: Correct broadcast RX

> Still to test: bcm43xx-d80211 w/v3 firmware and WEP-104

bcm43xx-d80211 w/v3 firmware and WEP-104: Garbled _everything_ RX
Of course, that's to be expected. WEP only uses broadcast keys, and
we knew they were failing in software mode.

-- 
-----------------------------------------------------------
Paul "TBBle" Hampson, B.Sc, LPI, MCSE
On-hiatus Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
Paul.Hampson@Pobox.Com

Of course Pacman didn't influence us as kids. If it did,
we'd be running around in darkened rooms, popping pills and
listening to repetitive music.
 -- Kristian Wilson, Nintendo, Inc, 1989

License: http://creativecommons.org/licenses/by/2.1/au/
-----------------------------------------------------------

Re: bcm43xx-d80211 broadcast reception with WPA

[Johannes Berg]

On Wed, 2006-11-15 at 01:40 +1100, Paul TBBle Hampson wrote:

> bcm43xx-d80211 w/v3 firmware and WEP-104: Garbled _everything_ RX
> Of course, that's to be expected. WEP only uses broadcast keys, and
> we knew they were failing in software mode.

Hmm, not sure about this, but it sort of confirms my theory -- with v3
firmware we never upload keys to the hw so the hw will successfully
decrypt frames with the 'none' algorithm, and the RX path will treat
them as though they were decrypted already.

johannes

Re: bcm43xx-d80211 broadcast reception with WPA

[Michael Buesch]

On Tuesday 14 November 2006 15:40, Johannes Berg wrote:
> On Wed, 2006-11-15 at 01:29 +1100, Paul TBBle Hampson wrote:
> 
> > Just to summarise results so far:
> > 
> > (Current version)
> > bcm43xx-d80211 w/v3 firmware and TKIP: Garbled broadcast RX
> > bcm43xx-d80211 w/v4 firmware and TKIP: Garbled broadcast RX
> > bcm43xx-d80211 w/v4 firmware and WEP-104: Correct broadcast RX
> > 
> > (version from wireless-dev before October 23rd, unsure of exact date)
> > bcm43xx (softmac) w/v3 firmware and TKIP: Correct broadcast RX
> 
> The last item is interesting. The softmac version doesn't include any hw
> crypto so it never checks the 'decrypt attempted' bit in the RX header
> afaik, leaving all crypto to hw.
> 
> I postulated before that the problem is that the firmware sets the
> 'decrypt attempted' bit even if the key is none, hence the driver tells
> the d80211 stack that the frame was already decrypted (no decrypt error
> occurs because in reality the algorithm is 'none'.)
> 
> You could test this theory by clearing the 'decrypt attempted' bit
> unconditionally in the RX path before it is ever tested. Then, any
> wep/aes should no longer work properly with v4 firmware and
> bcm43xx-d80211, but tkip would. If my theory is correct.

yes, Johannes. The problem is that the decrypt attempted bit is even
set for key_none. When I force-disable this codepath, TKIP works
perfectly well.
I will do a patch for this. There are a few other minor bugs in the
crypto stuff, which I will fix, too. Key clearing is not handled 100%
correct, etc...

-- 
Greetings Michael.

[PATCH, RFT]: Fix bcm43xx-d80211 hwcrypto (was Re: bcm43xx-d80211 broadcast reception with WPA)

[Michael Buesch]

Please test if this fixes hwcrypto.
Note that we will require v4 firmware with this patch.
I will remove v3 firmware support, because it's _really_
a huge pain to support both firmware versions.
If someone wants to have v3 support, please fork my tree.
Or alternatively simply install v4 firmware, which is a lot
easier. ;)

Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h
===================================================================
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h	2006-11-14 16:03:00.000000000 +0100
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h	2006-11-14 18:34:14.000000000 +0100
@@ -620,7 +620,6 @@ struct bcm43xx_stats {
 
 struct bcm43xx_key {
 	u8 enabled;
-	u8 used;
 	u8 algorithm;
 	u8 address[6];
 };
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
===================================================================
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c	2006-11-14 16:03:00.000000000 +0100
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c	2006-11-15 18:58:51.000000000 +0100
@@ -874,11 +874,12 @@ static void keymac_write(struct bcm43xx_
 {
 	u32 addrtmp[2];
 
+	assert(index >= 4 + 4);
+	memcpy(bcm->key[index].address, addr, 6);
 	/* We have two default TX keys and two default RX keys.
 	 * Physical mac 0 is mapped to physical key 8.
 	 * So we must adjust the index here.
 	 */
-	assert(index >= 4 + 4);
 	index -= 8;
 
 	addrtmp[0] = addr[0];
@@ -912,97 +913,88 @@ static void keymac_write(struct bcm43xx_
 	}
 }
 
-static int key_write_common(struct bcm43xx_private *bcm,
-			    u8 index, u8 algorithm,
-			    struct ieee80211_key_conf *keyconf,
-			    const u8 *mac_addr)
+static void do_key_write(struct bcm43xx_private *bcm,
+			 u8 index, u8 algorithm,
+			 const u8 *key, size_t key_len,
+			 const u8 *mac_addr)
 {
 	u8 buf[BCM43xx_SEC_KEYSIZE];
 
-	/* The "index" passed to this function is the
-	 * absolute key table index.
-	 */
-
-	if ((index >= bcm->max_nr_keys) ||
-	    (keyconf && (keyconf->keylen > BCM43xx_SEC_KEYSIZE)))
-		return -EINVAL;
+	assert(index < bcm->max_nr_keys);
+	assert(key_len <= BCM43xx_SEC_KEYSIZE);
 
 	memset(buf, 0, sizeof(buf));
-	if (mac_addr)
+	if (index >= 8)
 		keymac_write(bcm, index, buf); /* First zero out mac. */
-	if (keyconf)
-		memcpy(buf, keyconf->key, keyconf->keylen);
+	memcpy(buf, key, key_len);
 	key_write(bcm, index, algorithm, buf);
-	if (mac_addr)
+	if (index >= 8)
 		keymac_write(bcm, index, mac_addr);
-	bcm->key[index].algorithm = algorithm;
-	bcm->key[index].used = 1;
-	bcm->key[index].enabled = 1;
-	if (mac_addr)
-		memcpy(bcm->key[index].address, mac_addr, 6);
-	else
-		memset(bcm->key[index].address, 0, 6);
 
-	return 0;
+	bcm->key[index].algorithm = algorithm;
 }
 
-static int bcm43xx_default_key_write(struct bcm43xx_private *bcm,
-				     u8 index, u8 algorithm,
-				     struct ieee80211_key_conf *key)
+static int bcm43xx_key_write(struct bcm43xx_private *bcm,
+			     int index, u8 algorithm,
+			     const u8 *key, size_t key_len,
+			     const u8 *mac_addr,
+			     struct ieee80211_key_conf *keyconf)
 {
-	int err;
+	int i;
 
-	if (index > 3)
+	if (key_len > BCM43xx_SEC_KEYSIZE)
 		return -EINVAL;
+	if (index < 0) {
+		/* Per station key with associated MAC address.
+		 * Look if it already exists, if yes update, otherwise
+		 * allocate a new key.
+		 */
+		for (i = 8; i < bcm->max_nr_keys; i++) {
+			if (compare_ether_addr(bcm->key[i].address, mac_addr) == 0) {
+				/* found existing */
+				index = i;
+				break;
+			}
+		}
+		if (index < 0) {
+			for (i = 8; i < bcm->max_nr_keys; i++) {
+				if (!bcm->key[i].enabled) {
+					/* found empty */
+					index = i;
+					break;
+				}
+			}
+		}
+		if (index < 0) {
+			dprintk(KERN_ERR PFX "Out of hw key memory\n");
+			return -ENOBUFS;
+		}
+	} else
+		assert(index <= 3);
 
-	/* Write default TX key */
-	err = key_write_common(bcm, index, algorithm,
-			       key, NULL);
-	if (err)
-		return err;
-	/* Write default RX key */
-	err = key_write_common(bcm, index + 4, algorithm,
-			       key, NULL);
-	key->hw_key_idx = index;
-
-	return err;
-}
-
-static int bcm43xx_key_write(struct bcm43xx_private *bcm,
-			     u8 algorithm,
-			     struct ieee80211_key_conf *key,
-			     const u8 *mac_addr)
-{
-	int err;
-	u8 index;
-
-	for (index = 4 + 4; index < bcm->max_nr_keys; index++) {
-		if (!bcm->key[index].used)
-			break;
+	do_key_write(bcm, index, algorithm, key, key_len, mac_addr);
+	if (index <= 3) {
+		/* Default RX key */
+		assert(mac_addr == NULL);
+		do_key_write(bcm, index + 4, algorithm, key, key_len, NULL);
 	}
-	if (index >= bcm->max_nr_keys)
-		return -ENOBUFS;
+	keyconf->hw_key_idx = index;
 
-	err = key_write_common(bcm, index, algorithm,
-			       key, mac_addr);
-	key->hw_key_idx = index;
-
-	return err;
+	return 0;
 }
 
 static void bcm43xx_clear_keys(struct bcm43xx_private *bcm)
 {
-	static const u8 zero[6] = { 0 };
+	static const u8 zero[BCM43xx_SEC_KEYSIZE] = { 0 };
 	unsigned int i;
 
+	BUILD_BUG_ON(BCM43xx_SEC_KEYSIZE < ETH_ALEN);
 	for (i = 0; i < bcm->max_nr_keys; i++) {
-		key_write_common(bcm, i, 0, NULL,
-				 (i >= 4 + 4) ? zero : NULL);
-		bcm->key[i].used = 0;
+		do_key_write(bcm, i, BCM43xx_SEC_ALGO_NONE,
+			     zero, BCM43xx_SEC_KEYSIZE,
+			     zero);
 		bcm->key[i].enabled = 0;
-		bcm->key[i].algorithm = 0;
 	}
-	dprintk(KERN_INFO PFX "Keys cleared\n");
 }
 
 /* http://bcm-specs.sipsolutions.net/80211CoreReset */
@@ -1928,9 +1920,15 @@ static int bcm43xx_upload_microcode(stru
 	fwtime = bcm43xx_shm_read16(bcm, BCM43xx_SHM_SHARED,
 				    BCM43xx_SHM_SH_UCODETIME);
 
-	phy->fw = BCM43xx_FW_3;
-	if (fwrev > 0x128)
-		phy->fw = BCM43xx_FW_4;
+	phy->fw = BCM43xx_FW_4;
+	if (fwrev <= 0x128) {
+		printk(KERN_ERR PFX "YOUR FIRMWARE IS TOO OLD. Firmware from "
+		       "binary drivers older than version 4.x is unsupported. "
+		       "You must upgrade your firmware files.\n");
+		bcm43xx_write32(bcm->wlcore, BCM43xx_MMIO_STATUS_BITFIELD, 0);
+		err = -EOPNOTSUPP;
+		goto out;
+	}
 	printk(KERN_DEBUG PFX "firmware revision %X, patchlevel %X, "
 			      "date 20%.2i-%.2i-%.2i %.2i:%.2i:%.2i\n",
 	       fwrev, fwpatch,
@@ -3630,7 +3628,6 @@ static int bcm43xx_net_set_key(struct ne
 	u8 algorithm;
 	u8 index;
 	int err = -EINVAL;
-	int i;
 
 	switch (key->alg) {
 	case ALG_NONE:
@@ -3665,33 +3662,33 @@ static int bcm43xx_net_set_key(struct ne
 		err = -ENODEV;
 		goto out_unlock;
 	}
-	if (bcm43xx_current_phy(bcm)->fw == BCM43xx_FW_3) {
-		/* No support for HW-crypto with v3 firmware. */
-		key->force_sw_encrypt = 1;
-		err = 0;
-		goto out_unlock;
-	}
 
 	switch (cmd) {
 	case SET_KEY:
+		key->force_sw_encrypt = 0;
 
 		if (algorithm == BCM43xx_SEC_ALGO_TKIP) {
 			/* FIXME: No TKIP hardware encryption for now. */
-			err = 0;
 			key->force_sw_encrypt = 1;
-			goto out_unlock;
+			algorithm = BCM43xx_SEC_ALGO_NONE;
 		}
 
 		if (is_broadcast_ether_addr(addr)) {
 			/* addr is FF:FF:FF:FF:FF:FF for default keys */
-			err = bcm43xx_default_key_write(bcm, index,
-							algorithm, key);
+			err = bcm43xx_key_write(bcm, index, algorithm,
+						key->key, key->keylen,
+						NULL, key);
 		} else {
-			err = bcm43xx_key_write(bcm, algorithm, key,
-						addr);
+			err = bcm43xx_key_write(bcm, -1, algorithm,
+						key->key, key->keylen,
+						addr, key);
 		}
-		if (err)
+		if (err) {
+			key->force_sw_encrypt = 1;
 			goto out_unlock;
+		}
+		bcm->key[key->hw_key_idx].enabled = 1;
+
 		if (algorithm == BCM43xx_SEC_ALGO_WEP40 ||
 		    algorithm == BCM43xx_SEC_ALGO_WEP104) {
 			bcm43xx_hf_write(bcm,
@@ -3702,21 +3699,23 @@ static int bcm43xx_net_set_key(struct ne
 					 bcm43xx_hf_read(bcm) &
 					 ~BCM43xx_HF_USEDEFKEYS);
 		}
-		key->force_sw_encrypt = 0;
 		break;
-	case DISABLE_KEY:
+	case DISABLE_KEY: {
+		static const u8 zero[BCM43xx_SEC_KEYSIZE] = { 0 };
+
+		algorithm = BCM43xx_SEC_ALGO_NONE;
 		if (is_broadcast_ether_addr(addr)) {
-			err = key_write_common(bcm, index, 0, NULL, NULL);
+			err = bcm43xx_key_write(bcm, index, algorithm,
+						zero, BCM43xx_SEC_KEYSIZE,
+						NULL, key);
 		} else {
-			static const u8 zero[6] = { 0 };
-
-			for (i = 8; i < bcm->max_nr_keys; i++) {
-				if (compare_ether_addr(bcm->key[i].address, addr) != 0)
-					continue;
-				err = key_write_common(bcm, i, 0, NULL, zero);
-			}
+			err = bcm43xx_key_write(bcm, -1, algorithm,
+						zero, BCM43xx_SEC_KEYSIZE,
+						addr, key);
 		}
+		bcm->key[key->hw_key_idx].enabled = 0;
 		break;
+	}
 	case REMOVE_ALL_KEYS:
 		bcm43xx_clear_keys(bcm);
 		err = 0;
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_xmit.c
===================================================================
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_xmit.c	2006-11-14 16:03:00.000000000 +0100
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_xmit.c	2006-11-15 18:16:18.000000000 +0100
@@ -405,7 +405,6 @@ static void generate_txhdr_fw4(struct bc
 
 		assert(key_idx < bcm->max_nr_keys);
 		key = &(bcm->key[key_idx]);
-		assert(key->used);
 
 		if (key->enabled) {
 			/* Hardware appends ICV. */
@@ -648,34 +647,45 @@ void bcm43xx_rx(struct bcm43xx_private *
 
 	if ((macstat & BCM43xx_RX_MAC_DEC) &&
 	    !(macstat & BCM43xx_RX_MAC_DECERR)) {
+		unsigned int keyidx;
 		int wlhdr_len;
 		int iv_len;
 		int icv_len;
 
-		/* Remove PROTECTED flag to mark it as decrypted. */
-		assert(fctl & IEEE80211_FCTL_PROTECTED);
-		fctl &= ~IEEE80211_FCTL_PROTECTED;
-		wlhdr->frame_control = cpu_to_le16(fctl);
-
-		wlhdr_len = ieee80211_get_hdrlen(fctl);
-		if (skb->data[wlhdr_len + 3] & (1 << 5)) {
-			/* The Ext-IV Bit is set in the "KeyID"
-			 * octet of the IV.
-			 */
-			iv_len = 8;
-			icv_len = 8;
-		} else {
-			iv_len = 4;
-			icv_len = 4;
-		}
+		keyidx = ((macstat & BCM43xx_RX_MAC_KEYIDX)
+			  >> BCM43xx_RX_MAC_KEYIDX_SHIFT);
+		/* We must adjust the key index here. We want the "physical"
+		 * key index, but the ucode passed it slightly different.
+		 */
+		keyidx += 4;
+		assert((keyidx >= 4) && (keyidx < bcm->max_nr_keys));
+
+		if (bcm->key[keyidx].algorithm != BCM43xx_SEC_ALGO_NONE) {
+			/* Remove PROTECTED flag to mark it as decrypted. */
+			assert(fctl & IEEE80211_FCTL_PROTECTED);
+			fctl &= ~IEEE80211_FCTL_PROTECTED;
+			wlhdr->frame_control = cpu_to_le16(fctl);
+
+			wlhdr_len = ieee80211_get_hdrlen(fctl);
+			if (skb->data[wlhdr_len + 3] & (1 << 5)) {
+				/* The Ext-IV Bit is set in the "KeyID"
+				 * octet of the IV.
+				 */
+				iv_len = 8;
+				icv_len = 8;
+			} else {
+				iv_len = 4;
+				icv_len = 4;
+			}
 
-		/* Remove the IV */
-		memmove(skb->data + iv_len, skb->data, wlhdr_len);
-		skb_pull(skb, iv_len);
-		/* Remove the ICV */
-		skb_trim(skb, skb->len - icv_len);
+			/* Remove the IV */
+			memmove(skb->data + iv_len, skb->data, wlhdr_len);
+			skb_pull(skb, iv_len);
+			/* Remove the ICV */
+			skb_trim(skb, skb->len - icv_len);
 
-		status.flag |= RX_FLAG_DECRYPTED;
+			status.flag |= RX_FLAG_DECRYPTED;
+		}
 	}
 
 	status.signal = bcm43xx_rssi_postprocess(bcm, jssi,


-- 
Greetings Michael.

Re: [PATCH, RFT]: Fix bcm43xx-d80211 hwcrypto

[Paul TBBle Hampson]

On Wed, Nov 15, 2006 at 07:48:08PM +0100, Michael Buesch wrote:
> Please test if this fixes hwcrypto.
> Note that we will require v4 firmware with this patch.
> I will remove v3 firmware support, because it's _really_
> a huge pain to support both firmware versions.
> If someone wants to have v3 support, please fork my tree.
> Or alternatively simply install v4 firmware, which is a lot
> easier. ;)

Tested fine for me with both TKIP sw encryption and WEP-104 hw
encryption, on v4 firmware.

(Without applying today's new wireless-dev patches)

-- 
-----------------------------------------------------------
Paul "TBBle" Hampson, B.Sc, LPI, MCSE
On-hiatus Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
Paul.Hampson@Pobox.Com

Of course Pacman didn't influence us as kids. If it did,
we'd be running around in darkened rooms, popping pills and
listening to repetitive music.
 -- Kristian Wilson, Nintendo, Inc, 1989

License: http://creativecommons.org/licenses/by/2.1/au/
-----------------------------------------------------------

[PATCH]: bcm43xx-d80211: fix hwcrypto issues (mcast)

[Michael Buesch]

This fixes various bcm43xx-d80211 hwcrypto issues,
which mainly prevented mcast frames from being decrypted properly.

This is mostly a rewrite of the key managing code.
Note that after this patch v3 firmware is no longer supported.

Signed-off-by: Michael Buesch <mb-fseUSCV1ubazQB+pC5nmwQ@public.gmane.org>

Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h
===================================================================
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h	2006-11-14 16:03:00.000000000 +0100
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h	2006-11-14 18:34:14.000000000 +0100
@@ -620,7 +620,6 @@ struct bcm43xx_stats {
 
 struct bcm43xx_key {
 	u8 enabled;
-	u8 used;
 	u8 algorithm;
 	u8 address[6];
 };
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
===================================================================
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c	2006-11-14 16:03:00.000000000 +0100
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c	2006-11-15 18:58:51.000000000 +0100
@@ -874,11 +874,12 @@ static void keymac_write(struct bcm43xx_
 {
 	u32 addrtmp[2];
 
+	assert(index >= 4 + 4);
+	memcpy(bcm->key[index].address, addr, 6);
 	/* We have two default TX keys and two default RX keys.
 	 * Physical mac 0 is mapped to physical key 8.
 	 * So we must adjust the index here.
 	 */
-	assert(index >= 4 + 4);
 	index -= 8;
 
 	addrtmp[0] = addr[0];
@@ -912,97 +913,88 @@ static void keymac_write(struct bcm43xx_
 	}
 }
 
-static int key_write_common(struct bcm43xx_private *bcm,
-			    u8 index, u8 algorithm,
-			    struct ieee80211_key_conf *keyconf,
-			    const u8 *mac_addr)
+static void do_key_write(struct bcm43xx_private *bcm,
+			 u8 index, u8 algorithm,
+			 const u8 *key, size_t key_len,
+			 const u8 *mac_addr)
 {
 	u8 buf[BCM43xx_SEC_KEYSIZE];
 
-	/* The "index" passed to this function is the
-	 * absolute key table index.
-	 */
-
-	if ((index >= bcm->max_nr_keys) ||
-	    (keyconf && (keyconf->keylen > BCM43xx_SEC_KEYSIZE)))
-		return -EINVAL;
+	assert(index < bcm->max_nr_keys);
+	assert(key_len <= BCM43xx_SEC_KEYSIZE);
 
 	memset(buf, 0, sizeof(buf));
-	if (mac_addr)
+	if (index >= 8)
 		keymac_write(bcm, index, buf); /* First zero out mac. */
-	if (keyconf)
-		memcpy(buf, keyconf->key, keyconf->keylen);
+	memcpy(buf, key, key_len);
 	key_write(bcm, index, algorithm, buf);
-	if (mac_addr)
+	if (index >= 8)
 		keymac_write(bcm, index, mac_addr);
-	bcm->key[index].algorithm = algorithm;
-	bcm->key[index].used = 1;
-	bcm->key[index].enabled = 1;
-	if (mac_addr)
-		memcpy(bcm->key[index].address, mac_addr, 6);
-	else
-		memset(bcm->key[index].address, 0, 6);
 
-	return 0;
+	bcm->key[index].algorithm = algorithm;
 }
 
-static int bcm43xx_default_key_write(struct bcm43xx_private *bcm,
-				     u8 index, u8 algorithm,
-				     struct ieee80211_key_conf *key)
+static int bcm43xx_key_write(struct bcm43xx_private *bcm,
+			     int index, u8 algorithm,
+			     const u8 *key, size_t key_len,
+			     const u8 *mac_addr,
+			     struct ieee80211_key_conf *keyconf)
 {
-	int err;
+	int i;
 
-	if (index > 3)
+	if (key_len > BCM43xx_SEC_KEYSIZE)
 		return -EINVAL;
+	if (index < 0) {
+		/* Per station key with associated MAC address.
+		 * Look if it already exists, if yes update, otherwise
+		 * allocate a new key.
+		 */
+		for (i = 8; i < bcm->max_nr_keys; i++) {
+			if (compare_ether_addr(bcm->key[i].address, mac_addr) == 0) {
+				/* found existing */
+				index = i;
+				break;
+			}
+		}
+		if (index < 0) {
+			for (i = 8; i < bcm->max_nr_keys; i++) {
+				if (!bcm->key[i].enabled) {
+					/* found empty */
+					index = i;
+					break;
+				}
+			}
+		}
+		if (index < 0) {
+			dprintk(KERN_ERR PFX "Out of hw key memory\n");
+			return -ENOBUFS;
+		}
+	} else
+		assert(index <= 3);
 
-	/* Write default TX key */
-	err = key_write_common(bcm, index, algorithm,
-			       key, NULL);
-	if (err)
-		return err;
-	/* Write default RX key */
-	err = key_write_common(bcm, index + 4, algorithm,
-			       key, NULL);
-	key->hw_key_idx = index;
-
-	return err;
-}
-
-static int bcm43xx_key_write(struct bcm43xx_private *bcm,
-			     u8 algorithm,
-			     struct ieee80211_key_conf *key,
-			     const u8 *mac_addr)
-{
-	int err;
-	u8 index;
-
-	for (index = 4 + 4; index < bcm->max_nr_keys; index++) {
-		if (!bcm->key[index].used)
-			break;
+	do_key_write(bcm, index, algorithm, key, key_len, mac_addr);
+	if (index <= 3) {
+		/* Default RX key */
+		assert(mac_addr == NULL);
+		do_key_write(bcm, index + 4, algorithm, key, key_len, NULL);
 	}
-	if (index >= bcm->max_nr_keys)
-		return -ENOBUFS;
+	keyconf->hw_key_idx = index;
 
-	err = key_write_common(bcm, index, algorithm,
-			       key, mac_addr);
-	key->hw_key_idx = index;
-
-	return err;
+	return 0;
 }
 
 static void bcm43xx_clear_keys(struct bcm43xx_private *bcm)
 {
-	static const u8 zero[6] = { 0 };
+	static const u8 zero[BCM43xx_SEC_KEYSIZE] = { 0 };
 	unsigned int i;
 
+	BUILD_BUG_ON(BCM43xx_SEC_KEYSIZE < ETH_ALEN);
 	for (i = 0; i < bcm->max_nr_keys; i++) {
-		key_write_common(bcm, i, 0, NULL,
-				 (i >= 4 + 4) ? zero : NULL);
-		bcm->key[i].used = 0;
+		do_key_write(bcm, i, BCM43xx_SEC_ALGO_NONE,
+			     zero, BCM43xx_SEC_KEYSIZE,
+			     zero);
 		bcm->key[i].enabled = 0;
-		bcm->key[i].algorithm = 0;
 	}
-	dprintk(KERN_INFO PFX "Keys cleared\n");
 }
 
 /* http://bcm-specs.sipsolutions.net/80211CoreReset */
@@ -1928,9 +1920,15 @@ static int bcm43xx_upload_microcode(stru
 	fwtime = bcm43xx_shm_read16(bcm, BCM43xx_SHM_SHARED,
 				    BCM43xx_SHM_SH_UCODETIME);
 
-	phy->fw = BCM43xx_FW_3;
-	if (fwrev > 0x128)
-		phy->fw = BCM43xx_FW_4;
+	phy->fw = BCM43xx_FW_4;
+	if (fwrev <= 0x128) {
+		printk(KERN_ERR PFX "YOUR FIRMWARE IS TOO OLD. Firmware from "
+		       "binary drivers older than version 4.x is unsupported. "
+		       "You must upgrade your firmware files.\n");
+		bcm43xx_write32(bcm->wlcore, BCM43xx_MMIO_STATUS_BITFIELD, 0);
+		err = -EOPNOTSUPP;
+		goto out;
+	}
 	printk(KERN_DEBUG PFX "firmware revision %X, patchlevel %X, "
 			      "date 20%.2i-%.2i-%.2i %.2i:%.2i:%.2i\n",
 	       fwrev, fwpatch,
@@ -3630,7 +3628,6 @@ static int bcm43xx_net_set_key(struct ne
 	u8 algorithm;
 	u8 index;
 	int err = -EINVAL;
-	int i;
 
 	switch (key->alg) {
 	case ALG_NONE:
@@ -3665,33 +3662,33 @@ static int bcm43xx_net_set_key(struct ne
 		err = -ENODEV;
 		goto out_unlock;
 	}
-	if (bcm43xx_current_phy(bcm)->fw == BCM43xx_FW_3) {
-		/* No support for HW-crypto with v3 firmware. */
-		key->force_sw_encrypt = 1;
-		err = 0;
-		goto out_unlock;
-	}
 
 	switch (cmd) {
 	case SET_KEY:
+		key->force_sw_encrypt = 0;
 
 		if (algorithm == BCM43xx_SEC_ALGO_TKIP) {
 			/* FIXME: No TKIP hardware encryption for now. */
-			err = 0;
 			key->force_sw_encrypt = 1;
-			goto out_unlock;
+			algorithm = BCM43xx_SEC_ALGO_NONE;
 		}
 
 		if (is_broadcast_ether_addr(addr)) {
 			/* addr is FF:FF:FF:FF:FF:FF for default keys */
-			err = bcm43xx_default_key_write(bcm, index,
-							algorithm, key);
+			err = bcm43xx_key_write(bcm, index, algorithm,
+						key->key, key->keylen,
+						NULL, key);
 		} else {
-			err = bcm43xx_key_write(bcm, algorithm, key,
-						addr);
+			err = bcm43xx_key_write(bcm, -1, algorithm,
+						key->key, key->keylen,
+						addr, key);
 		}
-		if (err)
+		if (err) {
+			key->force_sw_encrypt = 1;
 			goto out_unlock;
+		}
+		bcm->key[key->hw_key_idx].enabled = 1;
+
 		if (algorithm == BCM43xx_SEC_ALGO_WEP40 ||
 		    algorithm == BCM43xx_SEC_ALGO_WEP104) {
 			bcm43xx_hf_write(bcm,
@@ -3702,21 +3699,23 @@ static int bcm43xx_net_set_key(struct ne
 					 bcm43xx_hf_read(bcm) &
 					 ~BCM43xx_HF_USEDEFKEYS);
 		}
-		key->force_sw_encrypt = 0;
 		break;
-	case DISABLE_KEY:
+	case DISABLE_KEY: {
+		static const u8 zero[BCM43xx_SEC_KEYSIZE] = { 0 };
+
+		algorithm = BCM43xx_SEC_ALGO_NONE;
 		if (is_broadcast_ether_addr(addr)) {
-			err = key_write_common(bcm, index, 0, NULL, NULL);
+			err = bcm43xx_key_write(bcm, index, algorithm,
+						zero, BCM43xx_SEC_KEYSIZE,
+						NULL, key);
 		} else {
-			static const u8 zero[6] = { 0 };
-
-			for (i = 8; i < bcm->max_nr_keys; i++) {
-				if (compare_ether_addr(bcm->key[i].address, addr) != 0)
-					continue;
-				err = key_write_common(bcm, i, 0, NULL, zero);
-			}
+			err = bcm43xx_key_write(bcm, -1, algorithm,
+						zero, BCM43xx_SEC_KEYSIZE,
+						addr, key);
 		}
+		bcm->key[key->hw_key_idx].enabled = 0;
 		break;
+	}
 	case REMOVE_ALL_KEYS:
 		bcm43xx_clear_keys(bcm);
 		err = 0;
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_xmit.c
===================================================================
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_xmit.c	2006-11-14 16:03:00.000000000 +0100
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_xmit.c	2006-11-15 18:16:18.000000000 +0100
@@ -405,7 +405,6 @@ static void generate_txhdr_fw4(struct bc
 
 		assert(key_idx < bcm->max_nr_keys);
 		key = &(bcm->key[key_idx]);
-		assert(key->used);
 
 		if (key->enabled) {
 			/* Hardware appends ICV. */
@@ -648,34 +647,45 @@ void bcm43xx_rx(struct bcm43xx_private *
 
 	if ((macstat & BCM43xx_RX_MAC_DEC) &&
 	    !(macstat & BCM43xx_RX_MAC_DECERR)) {
+		unsigned int keyidx;
 		int wlhdr_len;
 		int iv_len;
 		int icv_len;
 
-		/* Remove PROTECTED flag to mark it as decrypted. */
-		assert(fctl & IEEE80211_FCTL_PROTECTED);
-		fctl &= ~IEEE80211_FCTL_PROTECTED;
-		wlhdr->frame_control = cpu_to_le16(fctl);
-
-		wlhdr_len = ieee80211_get_hdrlen(fctl);
-		if (skb->data[wlhdr_len + 3] & (1 << 5)) {
-			/* The Ext-IV Bit is set in the "KeyID"
-			 * octet of the IV.
-			 */
-			iv_len = 8;
-			icv_len = 8;
-		} else {
-			iv_len = 4;
-			icv_len = 4;
-		}
+		keyidx = ((macstat & BCM43xx_RX_MAC_KEYIDX)
+			  >> BCM43xx_RX_MAC_KEYIDX_SHIFT);
+		/* We must adjust the key index here. We want the "physical"
+		 * key index, but the ucode passed it slightly different.
+		 */
+		keyidx += 4;
+		assert((keyidx >= 4) && (keyidx < bcm->max_nr_keys));
+
+		if (bcm->key[keyidx].algorithm != BCM43xx_SEC_ALGO_NONE) {
+			/* Remove PROTECTED flag to mark it as decrypted. */
+			assert(fctl & IEEE80211_FCTL_PROTECTED);
+			fctl &= ~IEEE80211_FCTL_PROTECTED;
+			wlhdr->frame_control = cpu_to_le16(fctl);
+
+			wlhdr_len = ieee80211_get_hdrlen(fctl);
+			if (skb->data[wlhdr_len + 3] & (1 << 5)) {
+				/* The Ext-IV Bit is set in the "KeyID"
+				 * octet of the IV.
+				 */
+				iv_len = 8;
+				icv_len = 8;
+			} else {
+				iv_len = 4;
+				icv_len = 4;
+			}
 
-		/* Remove the IV */
-		memmove(skb->data + iv_len, skb->data, wlhdr_len);
-		skb_pull(skb, iv_len);
-		/* Remove the ICV */
-		skb_trim(skb, skb->len - icv_len);
+			/* Remove the IV */
+			memmove(skb->data + iv_len, skb->data, wlhdr_len);
+			skb_pull(skb, iv_len);
+			/* Remove the ICV */
+			skb_trim(skb, skb->len - icv_len);
 
-		status.flag |= RX_FLAG_DECRYPTED;
+			status.flag |= RX_FLAG_DECRYPTED;
+		}
 	}
 
 	status.signal = bcm43xx_rssi_postprocess(bcm, jssi,


-- 
Greetings Michael.

Re: [PATCH]: bcm43xx-d80211: fix hwcrypto issues (mcast)

[Benjamin Herrenschmidt]

On Thu, 2006-11-16 at 15:07 +0100, Michael Buesch wrote:
> This fixes various bcm43xx-d80211 hwcrypto issues,
> which mainly prevented mcast frames from being decrypted properly.
> 
> This is mostly a rewrite of the key managing code.
> Note that after this patch v3 firmware is no longer supported.

So what is the solution for Apple machines owner who only get a v3
firmware from Apple ? I remember you telling me the answer on irc but I
wanted to make it public :-) Some web site we can d/l the windows
updates and extract the FW ?

Cheers,
Ben.

Re: [PATCH]: bcm43xx-d80211: fix hwcrypto issues (mcast)

[Johannes Berg]

On Fri, 2006-11-17 at 18:46 +1100, Benjamin Herrenschmidt wrote:

> So what is the solution for Apple machines owner who only get a v3
> firmware from Apple ? I remember you telling me the answer on irc but I
> wanted to make it public :-) Some web site we can d/l the windows
> updates and extract the FW ?

Yes, fwcutter comes with a huge list of URLs for both firmware versions
(I suppose they'll remove the v3 ones now...)

Also, very new Apple drivers (AppleAirportExpress4311 or something like
that) for the PCI-E stuff contains v4 firmware, but I doubt you'd get
those drivers with an update.

johannes

Re: [PATCH]: bcm43xx-d80211: fix hwcrypto issues (mcast)

[Benjamin Herrenschmidt]

On Fri, 2006-11-17 at 08:53 +0100, Johannes Berg wrote:
> On Fri, 2006-11-17 at 18:46 +1100, Benjamin Herrenschmidt wrote:
> 
> > So what is the solution for Apple machines owner who only get a v3
> > firmware from Apple ? I remember you telling me the answer on irc but I
> > wanted to make it public :-) Some web site we can d/l the windows
> > updates and extract the FW ?
> 
> Yes, fwcutter comes with a huge list of URLs for both firmware versions
> (I suppose they'll remove the v3 ones now...)

Well, the latest "released" version (fwcutter-005) contains a huge list
of ... v3 URLs :-) Only 2 v4 in there. I'll check SVN.

Cheers,
Ben.

Re: [PATCH]: bcm43xx-d80211: fix hwcrypto issues (mcast)

[Paul Hampson]

Benjamin Herrenschmidt wrote:
> On Fri, 2006-11-17 at 08:53 +0100, Johannes Berg wrote:
>> On Fri, 2006-11-17 at 18:46 +1100, Benjamin Herrenschmidt wrote:

>>> So what is the solution for Apple machines owner who only get a v3
>>> firmware from Apple ? I remember you telling me the answer on irc but I
>>> wanted to make it public :-) Some web site we can d/l the windows
>>> updates and extract the FW ?

>> Yes, fwcutter comes with a huge list of URLs for both firmware versions
>> (I suppose they'll remove the v3 ones now...)

v3 ones are still needed for the softmac version, unless I'm badly drunk...

> Well, the latest "released" version (fwcutter-005) contains a huge list
> of ... v3 URLs :-) Only 2 v4 in there. I'll check SVN.

There's actually a v4 big-endian firmware in the fwcutter list in SVN, but
no URL to fetch it from...

It comes from the AppleAirPortBrcm4311 driver. I've no idea where that update
comes from, I found a copy on the Internet somewhere. (I think someone posted
the file to a message board looking for help with it...)

I'm not sure, would it be be bad for me to just stick a copy of it up on a
website? If so, I can prolly dig up the place I got it from (I'm sure I
bookmarked it at the time) and people can choose their own level of comfort.

I have to say it's not clear from the documentation that BE machines like
PPC need to use a BE firmware... (If that's not the case, it's not clear
that it's not the case either, it just doesn't say either way. ^_^)

In fact, given that it's a BE firmware update for Intel-based Macs' bcm
cards, I presume the endianess of the firmware doesn't matter?

-- 
Paul Hampson
Paul.Hampson@Pobox.com

Re: [PATCH]: bcm43xx-d80211: fix hwcrypto issues (mcast)

[Andreas Schwab]

Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:

> Well, the latest "released" version (fwcutter-005) contains a huge list
> of ... v3 URLs :-) Only 2 v4 in there. I'll check SVN.

Still the same.  One of them does not exist, the other one requires
Javascript!

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [PATCH]: bcm43xx-d80211: fix hwcrypto issues (mcast)

[Johannes Berg]

On Fri, 2006-11-17 at 11:35 +0100, Andreas Schwab wrote:

> Still the same.  One of them does not exist, the other one requires
> Javascript!

Yeah, looks like Martin forgot to put the URLs in the the readme while
he put them into commit messages...

Try these:

Support for bcmwl5.sys v4.80.53.0 added.
ftp://downloads.netgear.com/files/wn511b_sw_3_28_3_8_setup.zip
(bcmwl5.sys is renamed to wn511b.sys)

Support for bcmwl5(64).sys v4.100.15.5 added.
from the latest Linksys WPC300N driver at
http://www.linksys.com/download/
It's ucode revision 0x0173, patchlevel 0x0425, 2006-10-04.

Martin, can you add these to the readme?

johannes

Re: [PATCH]: bcm43xx-d80211: fix hwcrypto issues (mcast)

[Andreas Schwab]

Johannes Berg <johannes@sipsolutions.net> writes:

> Try these:
>
> Support for bcmwl5.sys v4.80.53.0 added.
> ftp://downloads.netgear.com/files/wn511b_sw_3_28_3_8_setup.zip
> (bcmwl5.sys is renamed to wn511b.sys)

No supported files in there.

> Support for bcmwl5(64).sys v4.100.15.5 added.
> from the latest Linksys WPC300N driver at
> http://www.linksys.com/download/
> It's ucode revision 0x0173, patchlevel 0x0425, 2006-10-04.

Requires Javascript.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [PATCH]: bcm43xx-d80211: fix hwcrypto issues (mcast)

[Paul TBBle Hampson]

[-- Attachment #1: Type: text/plain, Size: 1245 bytes --]

On Fri, Nov 17, 2006 at 11:35:54AM +0100, Andreas Schwab wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:

>> Well, the latest "released" version (fwcutter-005) contains a huge list
>> of ... v3 URLs :-) Only 2 v4 in there. I'll check SVN.

> Still the same.  One of them does not exist, the other one requires
> Javascript!

MacOS X 10.4.8 Update for Intel [1] has
AppleAirportBrcm4311 E99AD02FDD7699FA52F0B9153C8411C8
 4.80.46.0 big-endian, supported in fwcutter-svn

It's a 200MB download for just the one file, but w3m seems to be able to
process it OK, so I assume it doesn't require Javascript.

[1] http://www.apple.com/support/downloads/macosx1048updateintel.html

-- 
-----------------------------------------------------------
Paul "TBBle" Hampson, B.Sc, LPI, MCSE
On-hiatus Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
Paul.Hampson@Pobox.Com

Of course Pacman didn't influence us as kids. If it did,
we'd be running around in darkened rooms, popping pills and
listening to repetitive music.
 -- Kristian Wilson, Nintendo, Inc, 1989

License: http://creativecommons.org/licenses/by/2.1/au/
-----------------------------------------------------------

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH]: bcm43xx-d80211: fix hwcrypto issues (mcast)

[Martin Langer]

On Fri, Nov 17, 2006 at 12:04:42PM +0100, Johannes Berg wrote:
> On Fri, 2006-11-17 at 11:35 +0100, Andreas Schwab wrote:
> 
> > Still the same.  One of them does not exist, the other one requires
> > Javascript!
> 
> Yeah, looks like Martin forgot to put the URLs in the the readme while
> he put them into commit messages...

The last update for README was quite some time ago. I think that file 
is a bad way to transport that kind of information. So I'm afraid a lot 
of links are really out of date now. A better way is probably an open 
wiki (berlios?). Volunteers and other ideas are always welcome.

The comments in the commit messages are more a kind of protocol and not 
the best link on earth. And if you wait some days the number of mirrors 
for the latest driver will explode. It would be bad to write the first 
available link into the README. A download link should be a direct 
link, a small package, easy to extract and so on. But I'm really not 
interested in doing that job of a hunter for the perfect download link 
and try to keep that link up to date. I think it's more important to 
write support for more driver files instead of doing that surrounding 
stuff for a few files in a perfect way. Google isn't that complicated 
these days and it's more up to date than our README.
 
> Support for bcmwl5.sys v4.80.53.0 added.
> ftp://downloads.netgear.com/files/wn511b_sw_3_28_3_8_setup.zip
> (bcmwl5.sys is renamed to wn511b.sys)
> 
> Support for bcmwl5(64).sys v4.100.15.5 added.
> >from the latest Linksys WPC300N driver at
> http://www.linksys.com/download/
> It's ucode revision 0x0173, patchlevel 0x0425, 2006-10-04.
> 
> Martin, can you add these to the readme?

These are bad examples for adding to README. People aren't prepared 
well enough to look for renamed bcmwl5.sys files which are packaged 
twice and they expect direct links, too. ...

Martin

Re: [PATCH]: bcm43xx-d80211: fix hwcrypto issues (mcast)

[Paul TBBle Hampson]

[-- Attachment #1: Type: text/plain, Size: 1386 bytes --]

On Fri, Nov 17, 2006 at 06:46:29PM +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2006-11-16 at 15:07 +0100, Michael Buesch wrote:
>> This fixes various bcm43xx-d80211 hwcrypto issues,
>> which mainly prevented mcast frames from being decrypted properly.
>> 
>> This is mostly a rewrite of the key managing code.
>> Note that after this patch v3 firmware is no longer supported.

> So what is the solution for Apple machines owner who only get a v3
> firmware from Apple ? I remember you telling me the answer on irc but I
> wanted to make it public :-) Some web site we can d/l the windows
> updates and extract the FW ?

http://bcm43xx.spugna.org/index.php?topic=141.msg517 provides the
following links to 4.80.46.0:

http://www.i-nz.net/files/perm/AppleAirPortBrcm4311.tar.gz
http://www.i-nz.net/files/perm/bcmwl5-win32.tar.gz

-- 
-----------------------------------------------------------
Paul "TBBle" Hampson, B.Sc, LPI, MCSE
On-hiatus Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
Paul.Hampson@Pobox.Com

Of course Pacman didn't influence us as kids. If it did,
we'd be running around in darkened rooms, popping pills and
listening to repetitive music.
 -- Kristian Wilson, Nintendo, Inc, 1989

License: http://creativecommons.org/licenses/by/2.1/au/
-----------------------------------------------------------

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]