On 2/1/2018 11:42 AM, 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)
Please, try to accept for a moment that it may be really a *firmware*
doing something unexpected. I feel you don't really want to trust my
research and conclusions ;)
We do. What Hante is saying is that it is a valid packet and we should
not discard it.
Maybe you can spend a moment and try to reproduce this problem? It
should be rather simple, I see this packet every time.
I tried on my OpenWrt box, which is a bridged config, but did not see it.
Why I'm blaming a firmware:
1) I see that packet being sent no matter what device tries to connect
(Linux, Android, Windows).
2) I can't see that packet when connecting the same devices to a
non-Broadcom AP.
3) Running Wireshark on my Linux notebook never shows that packet
leaving my notebook
4) Running independent device in monitor mode never catches that packet
in the air
I really tried to do my homework well before sending this patch. I see
no other explanation for this packet's existence.
Ok.
Could you try grepping your firmware source looking some LLC references?
Maybe there is really something you can find there to confirm this
issue?
Will do.
P.S.
Arend's right, firmware isn't crashing, I never said that :)
Regards,
Arend
