Return-path: Received: from 10.mo4.mail-out.ovh.net ([188.165.33.109]:47303 "EHLO 10.mo4.mail-out.ovh.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751761AbeBALZC (ORCPT ); Thu, 1 Feb 2018 06:25:02 -0500 Received: from player746.ha.ovh.net (b6.ovh.net [213.186.33.56]) by mo4.mail-out.ovh.net (Postfix) with ESMTP id 1D938146D6A for ; Thu, 1 Feb 2018 12:16:27 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Date: Thu, 01 Feb 2018 12:16:10 +0100 From: =?UTF-8?Q?Rafa=C5=82_Mi=C5=82ecki?= To: Arend van Spriel Cc: Hante Meuleman , =?UTF-8?Q?Rafa=C5=82_Mi?= =?UTF-8?Q?=C5=82ecki?= , Kalle Valo , Franky Lin , Chi-Hsien Lin , Wright Feng , Pieter-Paul Giesberts , linux-wireless@vger.kernel.org, "BRCM80211-DEV-LIST,PDL" , brcm80211-dev-list@cypress.com Subject: Re: [PATCH] brcmfmac: detect & reject faked packet generated by a firmware In-Reply-To: <5A72F42A.5090700@broadcom.com> References: <20180130090922.30346-1-zajec5@gmail.com> <5A705B5E.5070906@broadcom.com> <5A71D08B.7090905@broadcom.com> <4f6223b8083ed69432493a37d4f45b69@mail.gmail.com> <5A72F42A.5090700@broadcom.com> Message-ID: <02d88813e98362b59f7be59abf41b519@milecki.pl> (sfid-20180201_122506_200305_0921E96B) Sender: linux-wireless-owner@vger.kernel.org List-ID: On 2018-02-01 12:04, Arend van Spriel wrote: > 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. I think Hante believed it's a packet "sent by the stack from remote site PC" which would make it completely valid. If that packet was never sent by a STA and firmware is just making it up, including putting STA's MAC as source address (in the Ethernet header) it smells fishy. Do we still find it a valid packet? >> 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. Can you try my debugging diff I sent yesterday? >> 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.