Search Linux Wireless

Re: [PATCH] brcmfmac: detect & reject faked packet generated by a firmware

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2/1/2018 12:48 PM, Rafał Miłecki wrote:
On 2018-01-31 17:14, Hante Meuleman wrote:
It is an 802.2 frame, more specifically a LLC XID frames. So why it
exists?
And more over, why would we crash as an result? Decoding info can be
found
here:

https://www.cisco.com/c/en/us/support/docs/ibm-technologies/logical-link-control-llc/12247-45.html#con3


The frame was likely sent by the stack from remote site PC, should be
possible to capture with tcpdump.

I've seen these frames before, but don’t know what they are for. The
frame
appears to be correctly encoded. The ethertype, is not a type, but a len
field. The only protocol with such a short len allowed is llc, see also

https://www.savvius.com/networking-glossary/ethernet/frame_formats/

So it is 802.2 (also known as LLC)

This was actually quite helpful, thanks! Googling for "802.11 LLC XID
association" pointed me to some Google-indexed books:
1) Internet Protocols: Advances, Technologies and Applications
2) Broadband Wireless Access and Local Networks: Mobile WiMax and WiFi

Both of them describe IAPP standard which appears as IEEE 802.11f on
Wikipedia. It seems to be some old & obsolete roaming standard that was
replaced by 802.11r.

There is ADD operation defined by the 802.11f which is triggered "when a
station is newly associated". It also says "The frame is sent using a
MAC source address equal to the MAC address of the station".

So far it seems to match what I'm seeing. My guess is that Broadcom's
firmware includes some kind of support for the 802.11f. I'm still not
sure if that is really firmware's responsibility to handle that though.

I was just writing up a reply. It is indeed an IAPP packet. So it is a 802.11f packet and our firmware implements the 802.11 stack. What makes you think it is not firmware responsibility. It goes along with MLME states. The firmware change has been made centuries ago as far as I can tell.

Anyway, the packet should not have been sent back to us as it will result in intended disassociate. So what kernel are you running on. I am not seeing it on 4.4 kernel, but I am in the middle of another debugging session. However, I was able to associate just fine.

Regards,
Arend



[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Wireless Regulations]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux