Re: [PATCH]: bcm43xx-d80211: fix hwcrypto issues (mcast)
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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bcm43xx-d80211 broadcast reception with WPA
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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bcm43xx-d80211 broadcast reception with WPA
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 0x: 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 0x: 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 0x: 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 0x: 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 0x: 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 0x: 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
bcm43xx-d80211 broadcast reception with WPA
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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
