Re: [PATCH] brcmfmac: support monitor frames with hardware/ucode header

["Rafał Miłecki" <rafal@milecki.pl>]

On 2019-01-25 09:51, Arend Van Spriel wrote:
> On 1/22/2019 12:08 PM, Rafał Miłecki wrote:
>> From: Rafał Miłecki <rafal@milecki.pl>
>> 
>> The new FullMAC firmwares for 4366b1/4366c0 were supposed to provide
>> monitor frames with radiotap header but it doesn't seem to be the 
>> case.
> 
> I was not aware that this was supposed to. I did not build a radiotap
> variant to keep it feature-wise similar to 4366b0 firmware.

Well, then apparently I got confused :( When you wrote:

On Mon, 11 Jun 2018 at 12:48, Arend van Spriel 
<arend.vanspriel@broadcom.com> wrote:
> Looking into our firmware repo it there are two flags, ie. WL_MONITOR
> and WL_RADIOTAP. It seems both are set for firmware containing -stamon-
> feature. Your list below confirms that. I still plan to add indication
> for WL_RADIOTAP in the "cap" iovar, but a stamon feature check could be
> used for older firmwares.

I assumed you'll add "rtap" cap value (to the internal wl code 
repository?)
because you mean to release a firmware using it.

Maybe you just meant it to be for your customers compiling firmwares on
their own?


>> Testing the latest release resulted in discovering a new format being
>> used. It seems (almost?) identical to the one known from ucode used in
>> SoftMAC devices which is most likely the same codebase anyway.
> 
> I am a bit confused. How many formats are there? It is either ucode
> format or radiotap, right?

So far we got two formats:
1) 802.11 frames (with frame (sub)type & all addresses)
2) 802.11 frames with the radiotap header
and now we also have:
3) 802.11 frames with the ucode header

For more info please check my original post:
Research + questions on brcmfmac and support for monitor mode
https://www.spinics.net/lists/linux-wireless/msg173573.html


>> While radiotap support was meant to be announced with the "rtap" fw
>> capability string it seems no alternative was added for the hw/ucode
>> format. It means each firmware requires a feature mapping quirk.
> 
> I thought we only needed a quirk for the firmware that provide
> radiotap but do not announce it. For the others we can assume ucode
> format if monitor mode is supported. Probably missing something.

802.11 frames with ucode header is something entirely new, I didn't see 
any
Asus/Linksys/Netgear/TP-LINK firmware using it.

As the old firmwares were providing frames without any header (also 
making
it impossible to e.g. read signal strength) we need this new flag to
distinguish firmwares with ucode header from them.