On 1/25/2019 10:11 AM, Rafał Miłecki wrote:
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@xxxxxxxxxx>
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@xxxxxxxxxxxx> 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?
and for customer for whom we compile firmwares based on their feature
requirements. Anyway, I could build a new firmware for 4366b1/4366c0
including radiotap. However, end-users may get to use firmware that is
not supporting it.
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
I did read that before, but apparently did miss some details.
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.
Right. Thanks for explaining (again).
Regards,
Arend
