Re: bcm43xx-d80211 broadcast reception with WPA
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 - 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
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 - 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
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) [EMAIL PROTECTED] 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/ --- - 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
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) [EMAIL PROTECTED] 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/ --- pgpjEPc1lK5rF.pgp Description: PGP signature
Re: bcm43xx-d80211 broadcast reception with WPA
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. - 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
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 - 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
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 - 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
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. - 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
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 - 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
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. - 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
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 - 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
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 - 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
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 signature.asc Description: This is a digitally signed message part
Re: bcm43xx-d80211 broadcast reception with WPA
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. - 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
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) [EMAIL PROTECTED] 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/ --- - 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
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 - 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
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. - 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
