MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Date: Thu, 01 Feb 2018 11:42:53 +0100
From: =?UTF-8?Q?Rafa=C5=82_Mi=C5=82ecki?= <rafal@milecki.pl>
To: Hante Meuleman <hante.meuleman@broadcom.com>
Cc: Arend Van Spriel <arend.vanspriel@broadcom.com>,
        =?UTF-8?Q?Rafa=C5=82?= =?UTF-8?Q?_Mi=C5=82ecki?=
        <zajec5@gmail.com>, Kalle Valo <kvalo@codeaurora.org>,
        Franky Lin <franky.lin@broadcom.com>,
        Chi-Hsien Lin <chi-hsien.lin@cypress.com>,
        Wright Feng <wright.feng@cypress.com>,
        Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>,
        linux-wireless@vger.kernel.org,
        "BRCM80211-DEV-LIST,PDL" <brcm80211-dev-list.pdl@broadcom.com>,
        brcm80211-dev-list@cypress.com
Subject: Re: [PATCH] brcmfmac: detect & reject faked packet generated by a
 firmware
In-Reply-To: <4f6223b8083ed69432493a37d4f45b69@mail.gmail.com>
References: <20180130090922.30346-1-zajec5@gmail.com>
 <5A705B5E.5070906@broadcom.com>
 <e6719fcc4080afc43d62d370ad9cfd34@milecki.pl>
 <5A71D08B.7090905@broadcom.com>
 <4f6223b8083ed69432493a37d4f45b69@mail.gmail.com>
Message-ID: <f64b5ee40e534046c47a5675a078706f@milecki.pl> (sfid-20180201_120137_254213_26E5D395)
Sender: linux-wireless-owner@vger.kernel.org

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 ;)

Maybe you can spend a moment and try to reproduce this problem? It
should be rather simple, I see this packet every time.

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.

Could you try grepping your firmware source looking some LLC references?
Maybe there is really something you can find there to confirm this
issue?

P.S.
Arend's right, firmware isn't crashing, I never said that :)