Research + questions on brcmfmac and support for monitor mode

Research + questions on brcmfmac and support for monitor mode

[Rafał Miłecki]

I'm interested in adding support for monitor mode to the brcmfmac. I did
some early research on firmware capabilities & behavior using various
firmwares I could find for my devices: 43602a1, 4366b1, 4366c0 (BCM4366
and BCM4366E).

I was doing my tests by starting monitor mode with SET_MONITOR ioctl +
value 3 and dumping msgbuf RX header + skb data.

The good news is that almost every firmware has some minimal support for
monitor mode. Unfortunately implementing it may be (a big?) problem.

The basic concept is simple. Once we set SET_MONITOR to 3, firmware
starts passing up monitor mode frames to the driver.



The first problem I see is identifying monitor mode frames in order to
make brcmfmac pass them to the monitor interface. Monitor frames have
msg.ifidx set to 0 which makes them indistinguishable from main
interface frames by simply looking at that index field. There is nothing
in the msg.rsvd0, compl_hdr.status, rx_status_0 or rx_status_1 fields.

Now, some new firmwares have flags set to 0x0002 (instead of 0x0001) for
monitor frames. This is very helpful but it only applies to the really
recent images.

My first question is: is there any reliable way of filtering monitor
frames for older firmwares? We could try to reserve ifidx 0 for monitor
mode purposes, but I'm afraid I'd require hacking quite some code. Is
there any better & simpler solution?



The second problem is monitor frame format. Older firmwares were simply
passing 802.11 frames to the driver. It means passing frame control
field, duration, AP MAC, src MAC, dst MAC, sequence + data. There was no
info about signal, noise, etc. passed. New firmwares seem to be
including radiotap header which makes things much nicer.

The second question: is there a reliable way of telling what format uses
monitor packet passed by a firmware? Is it maybe strictly related to the
flags set to 0x0002 (instead of 0x0001)?



I was hoping that maybe looking at fw-reported capabilities will give me
any hint regarding that but I'm afraid I'm out of luck. Below is a list
of firmwares I tested and summary of each of them.

Note: as every firmware reports following capabilities:
802.11d 802.11h ampdu ampdu_rx ampdu_tx amsdurx amsdutx anqpo ap bcm_dcs
bsstrans cac cqa dfrts dwds led mfp p2po probresp_mac_filter pspretend
psr psta radio_pwrsave rm rxchain_pwrsave sta stbc-rx-1ss stbc-tx
traffic-mgmt traffic-mgmt-dwm vht-prop-rates wds wet wet_tunnel wme wnm
I omitted them below.

*****

1) brcmfmac43602-pcie.ap.bin from linux-firmware.git
Firmware version = wl0: Sep 18 2015 03:30:01 version 7.35.177.56 (r587209) FWID 01-6cb8e269

Monitor frames without raiotap

flags: 0x0001

Extra caps: mbss4 ndoe proptxstatus

*****

2) brcmfmac4366b-pcie.bin from linux-firmware.git
Firmware version = wl0: Jan  8 2016 12:54:07 version 10.10.69.3309 (r610991) FWID 01-c47a91a4

Monitor frames without raiotap

flags: 0x0001

Extra caps: ccx mbss8 multi-user-beamformer proptxstatus
single-user-beamformee single-user-beamformer toe txpwrcache

*****

3) 4366b1 development branch (from Arend)
Firmware version = wl0: Oct  6 2016 10:17:32 version 10.10 (TOB) (r663589) FWID 01-6c5a1687

Monitor frames without raiotap

flags: 0x0001

Extra caps: bgdfs ccx mbss8 multi-user-beamformer proptxstatus
single-user-beamformee single-user-beamformer toe txpwrcache

*****

4) brcmfmac4366c-pcie.bin.k3
Firmware version = wl0: Aug 19 2016 15:22:35 version 10.10.69.74 (r629731 WLTEST) FWID 01-5c0166fa

Monitor frames without raiotap

flags: 0x0001

Extra caps: bgdfs ccx cptlv-4 mbss8 multi-user-beamformee
multi-user-beamformer single-user-beamformee single-user-beamformer toe
txpwrcache

*****

5) brcmfmac4366c-pcie.bin.ea9500
Firmware version = wl0: Aug 23 2016 17:19:51 version 10.10.69.69 (r625687) FWID 01-8438621f

Monitor frames without raiotap

flags: 0x0001

Extra caps: bgdfs ccx mbss8 multi-user-beamformee multi-user-beamformer
proptxstatus single-user-beamformee single-user-beamformer toe
txpwrcache

*****

6) brcmfmac4366c-pcie.bin.ac88u
Firmware version = wl0: Sep 12 2016 13:26:44 version 10.10.69.6908 (r658761) FWID 01-fed440e1

Monitor frames without raiotap

flags: 0x0001

Extra caps: bgdfs ccx cptlv-4 mbss8 multi-user-beamformee
multi-user-beamformer proptxstatus single-user-beamformee
single-user-beamformer toe txpwrcache

*****

7) brcmfmac4366c-pcie.bin.asus-dhd24
Firmware version = wl0: Nov  7 2017 12:23:08 version 10.10.69.69017 (r730013) FWID 01-e258597c

Monitor frames include radiotap header

flags: 0x0002

Extra caps: bgdfs ccx cptlv-4 mbss8 multi-user-beamformee
multi-user-beamformer proptxstatus single-user-beamformee
single-user-beamformer toe txpwrcache

*****

8) 4366c0 fw from FW_EA9500v2_EA9500S_2.1.1.183171_prod.img
Firmware version = wl0: Aug  2 2017 18:45:13 version 10.10.122.20 (r683106) FWID 01-91326ac8

Monitor frames include radiotap header

flags: 0x0002

Extra caps: 160 bgdfs ccx dyn160 mbss8 multi-user-beamformee
multi-user-beamformer proptxstatus single-user-beamformee
single-user-beamformer toe txpwrcache

*****

9) 4366c0 fw from GT-AC5300_3.0.0.4_382_15984-gf481f58_cferom_ubi_0824.w
Firmware version = wl0: Aug 17 2017 08:13:19 version 10.10.122.20 (r683106) FWID 01-bbb1a4c

Monitor frames include radiotap header

flags: 0x0002

Extra caps: 160 bgdfs ccx cptlv-4 dyn160 mbss8 multi-user-beamformee
multi-user-beamformer proptxstatus single-user-beamformee
single-user-beamformer toe txpwrcache

*****

10) 4366c0 fw from ArcherC5400X(US)_171023.bin
Firmware version = wl0: Sep 14 2017 14:10:23 version 10.10.122.20 (r683106) FWID 01-9f0e64f9

Monitor frames include radiotap header

flags: 0x0002

Extra caps: 160 bgdfs ccx dyn160 mbss8 multi-user-beamformee
multi-user-beamformer proptxstatus single-user-beamformee
single-user-beamformer toe txpwrcache

Re: Research + questions on brcmfmac and support for monitor mode

[Arend van Spriel]

On 5/15/2018 2:29 PM, Rafał Miłecki wrote:
> I'm interested in adding support for monitor mode to the brcmfmac. I did
> some early research on firmware capabilities & behavior using various
> firmwares I could find for my devices: 43602a1, 4366b1, 4366c0 (BCM4366
> and BCM4366E).

I am interested too and already did some work in this respect.

> I was doing my tests by starting monitor mode with SET_MONITOR ioctl +
> value 3 and dumping msgbuf RX header + skb data.
>
> The good news is that almost every firmware has some minimal support for
> monitor mode. Unfortunately implementing it may be (a big?) problem.
>
> The basic concept is simple. Once we set SET_MONITOR to 3, firmware
> starts passing up monitor mode frames to the driver.

The main issue is that monitor mode was historically made for what we 
call NIC drivers, ie. driver running on the host so without an active 
cpu on the device. Also monitor functionality is used within the 
firmware itself by other features, which is why most firmwares you have 
include monitor functionality.

I implemented monitor mode for SDIO devices, but that required firmware 
changes so an explicit firmware target. Unfortunately, for PCIe things 
are quite different. On SDIO the entire packet is passed to the host, 
but for PCIe the 802.11 part is split from the 802.3 payload.

> The first problem I see is identifying monitor mode frames in order to
> make brcmfmac pass them to the monitor interface. Monitor frames have
> msg.ifidx set to 0 which makes them indistinguishable from main
> interface frames by simply looking at that index field. There is nothing
> in the msg.rsvd0, compl_hdr.status, rx_status_0 or rx_status_1 fields.
>
> Now, some new firmwares have flags set to 0x0002 (instead of 0x0001) for
> monitor frames. This is very helpful but it only applies to the really
> recent images.
>
> My first question is: is there any reliable way of filtering monitor
> frames for older firmwares? We could try to reserve ifidx 0 for monitor
> mode purposes, but I'm afraid I'd require hacking quite some code. Is
> there any better & simpler solution?

Depends what you want. I wanted mainly a dedicated sniffer so only 
allowing changing the main interface to monitor mode. Not allowing 
adding a monitor mode interface.

> The second problem is monitor frame format. Older firmwares were simply
> passing 802.11 frames to the driver. It means passing frame control
> field, duration, AP MAC, src MAC, dst MAC, sequence + data. There was no
> info about signal, noise, etc. passed. New firmwares seem to be
> including radiotap header which makes things much nicer.

For the SDIO implementation mentioned I generated radiotap header in 
brcmfmac. I recall that was the intention for the PCIe implementation as 
well, but maybe things changed since then as you managed to get radiotap 
headers on recent firmwares.

> The second question: is there a reliable way of telling what format uses
> monitor packet passed by a firmware? Is it maybe strictly related to the
> flags set to 0x0002 (instead of 0x0001)?

This is the flags in the msgbuf RXHEADER? That is

> I was hoping that maybe looking at fw-reported capabilities will give me
> any hint regarding that but I'm afraid I'm out of luck. Below is a list
> of firmwares I tested and summary of each of them.
>
> Note: as every firmware reports following capabilities:
> 802.11d 802.11h ampdu ampdu_rx ampdu_tx amsdurx amsdutx anqpo ap bcm_dcs
> bsstrans cac cqa dfrts dwds led mfp p2po probresp_mac_filter pspretend
> psr psta radio_pwrsave rm rxchain_pwrsave sta stbc-rx-1ss stbc-tx
> traffic-mgmt traffic-mgmt-dwm vht-prop-rates wds wet wet_tunnel wme wnm
> I omitted them below.

Actually the capability iovar is tricky/broken. It can potentially 
truncate the string so you don't get all the information on the host.

So a question about monitor mode. In hostapd an attempt is made to 
create a monitor interface. Is that no longer done because of you recent 
patch regarding the wiphy flag HAVE_AP_SME?

Regards,
Arend

Re: Research + questions on brcmfmac and support for monitor mode

[Rafał Miłecki]

On 16 May 2018 at 10:37, Arend van Spriel <arend.vanspriel@broadcom.com> wr=
ote:
> On 5/15/2018 2:29 PM, Rafa=C5=82 Mi=C5=82ecki wrote:
>>
>> I'm interested in adding support for monitor mode to the brcmfmac. I did
>> some early research on firmware capabilities & behavior using various
>> firmwares I could find for my devices: 43602a1, 4366b1, 4366c0 (BCM4366
>> and BCM4366E).
>
>
> I am interested too and already did some work in this respect.
>
>> I was doing my tests by starting monitor mode with SET_MONITOR ioctl +
>> value 3 and dumping msgbuf RX header + skb data.
>>
>> The good news is that almost every firmware has some minimal support for
>> monitor mode. Unfortunately implementing it may be (a big?) problem.
>>
>> The basic concept is simple. Once we set SET_MONITOR to 3, firmware
>> starts passing up monitor mode frames to the driver.
>
>
> The main issue is that monitor mode was historically made for what we cal=
l
> NIC drivers, ie. driver running on the host so without an active cpu on t=
he
> device. Also monitor functionality is used within the firmware itself by
> other features, which is why most firmwares you have include monitor
> functionality.

Nice to know.

Regarding NIC drivers: that's how I found out about WLC_SET_MONITOR
(by looking at wl_linux.c) and values 1/2/3 (by looking at
wl_monitor()).


> I implemented monitor mode for SDIO devices, but that required firmware
> changes so an explicit firmware target. Unfortunately, for PCIe things ar=
e
> quite different. On SDIO the entire packet is passed to the host, but for
> PCIe the 802.11 part is split from the 802.3 payload.
>
>> The first problem I see is identifying monitor mode frames in order to
>> make brcmfmac pass them to the monitor interface. Monitor frames have
>> msg.ifidx set to 0 which makes them indistinguishable from main
>> interface frames by simply looking at that index field. There is nothing
>> in the msg.rsvd0, compl_hdr.status, rx_status_0 or rx_status_1 fields.
>>
>> Now, some new firmwares have flags set to 0x0002 (instead of 0x0001) for
>> monitor frames. This is very helpful but it only applies to the really
>> recent images.
>>
>> My first question is: is there any reliable way of filtering monitor
>> frames for older firmwares? We could try to reserve ifidx 0 for monitor
>> mode purposes, but I'm afraid I'd require hacking quite some code. Is
>> there any better & simpler solution?
>
>
> Depends what you want. I wanted mainly a dedicated sniffer so only allowi=
ng
> changing the main interface to monitor mode. Not allowing adding a monito=
r
> mode interface.

Oh, then we have a pretty different use cases. I wanted to run AP
interfaces for all the time and periodically add monitor interface to
listen to the air traffic. That's why I need to distinguish monitor
packets from other ones.


>> The second problem is monitor frame format. Older firmwares were simply
>> passing 802.11 frames to the driver. It means passing frame control
>> field, duration, AP MAC, src MAC, dst MAC, sequence + data. There was no
>> info about signal, noise, etc. passed. New firmwares seem to be
>> including radiotap header which makes things much nicer.
>
>
> For the SDIO implementation mentioned I generated radiotap header in
> brcmfmac. I recall that was the intention for the PCIe implementation as
> well, but maybe things changed since then as you managed to get radiotap
> headers on recent firmwares.

The real problem introduced by that PCIe firmware change (adding
radiotap header) is inconsistency. It seems like a format change
introduced without adding a way of discovering which format is being
used.


>> The second question: is there a reliable way of telling what format uses
>> monitor packet passed by a firmware? Is it maybe strictly related to the
>> flags set to 0x0002 (instead of 0x0001)?
>
>
> This is the flags in the msgbuf RXHEADER? That is

struct brcmf_msgbuf *msgbuf;
rx_complete->flags


>> I was hoping that maybe looking at fw-reported capabilities will give me
>> any hint regarding that but I'm afraid I'm out of luck. Below is a list
>> of firmwares I tested and summary of each of them.
>>
>> Note: as every firmware reports following capabilities:
>> 802.11d 802.11h ampdu ampdu_rx ampdu_tx amsdurx amsdutx anqpo ap bcm_dcs
>> bsstrans cac cqa dfrts dwds led mfp p2po probresp_mac_filter pspretend
>> psr psta radio_pwrsave rm rxchain_pwrsave sta stbc-rx-1ss stbc-tx
>> traffic-mgmt traffic-mgmt-dwm vht-prop-rates wds wet wet_tunnel wme wnm
>> I omitted them below.
>
>
> Actually the capability iovar is tricky/broken. It can potentially trunca=
te
> the string so you don't get all the information on the host.
>
> So a question about monitor mode. In hostapd an attempt is made to create=
 a
> monitor interface. Is that no longer done because of you recent patch
> regarding the wiphy flag HAVE_AP_SME?

I didn't test that but that's what I'd expect. Now that hostapd sees
HAVE_AP_SME it shouldn't run into any fallback paths including monitor
mode hacks.

--=20
Rafa=C5=82

Re: Research + questions on brcmfmac and support for monitor mode

[Rafał Miłecki]

I'm providing extra version info of tested firmware images as requested
by Arend in another e-mail thread.

On 15.05.2018 14:29, Rafał Miłecki wrote:
> 1) brcmfmac43602-pcie.ap.bin from linux-firmware.git
> Firmware version = wl0: Sep 18 2015 03:30:01 version 7.35.177.56 (r587209) FWID 01-6cb8e269
> 
> Monitor frames without raiotap
> 
> flags: 0x0001
> 
> Extra caps: mbss4 ndoe proptxstatus

43602a1-roml/pcie-ag-splitrx-fdap-mbss-mfp-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop Version: 7.35.177.56 CRC: 548eccd4 Date: Fri 2015-09-18 03:31:06 PDT Ucode Ver: 986.122 FWID: 01-6cb8e269


> 2) brcmfmac4366b-pcie.bin from linux-firmware.git
> Firmware version = wl0: Jan  8 2016 12:54:07 version 10.10.69.3309 (r610991) FWID 01-c47a91a4
> 
> Monitor frames without raiotap
> 
> flags: 0x0001
> 
> Extra caps: ccx mbss8 multi-user-beamformer proptxstatus
> single-user-beamformee single-user-beamformer toe txpwrcache

4366b1-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs Version: 10.10.69.237 CRC: 4bc48c7b Date: Fri 2016-01-08 12:55:25 PST Ucode Ver: 1073.531 FWID: 01-c47a91a4


> 3) 4366b1 development branch (from Arend)
> Firmware version = wl0: Oct  6 2016 10:17:32 version 10.10 (TOB) (r663589) FWID 01-6c5a1687
> 
> Monitor frames without raiotap
> 
> flags: 0x0001
> 
> Extra caps: bgdfs ccx mbss8 multi-user-beamformer proptxstatus
> single-user-beamformee single-user-beamformer toe txpwrcache

4366b1-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs Version: 10.10 (TOB) (r663589) CRC: 50d4be62 Date: Thu 2016-10-06 10:46:42 BST Ucode Ver: 1128.155 FWID: 01-6c5a1687

> 4) brcmfmac4366c-pcie.bin.k3
> Firmware version = wl0: Aug 19 2016 15:22:35 version 10.10.69.74 (r629731 WLTEST) FWID 01-5c0166fa
> 
> Monitor frames without raiotap
> 
> flags: 0x0001
> 
> Extra caps: bgdfs ccx cptlv-4 mbss8 multi-user-beamformee
> multi-user-beamformer single-user-beamformee single-user-beamformer toe
> txpwrcache

4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfgtest-seqcmds-phydbg-phydump-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-11nprop-dbgam-dbgams-ringer-dmaindex16-bgdfs-hostpmac Version: 10.10.69.74 CRC: a6268b76 Date: Mon 2016-09-12 16:39:23 CST FWID 01-5c0166fa


> 5) brcmfmac4366c-pcie.bin.ea9500
> Firmware version = wl0: Aug 23 2016 17:19:51 version 10.10.69.69 (r625687) FWID 01-8438621f
> 
> Monitor frames without raiotap
> 
> flags: 0x0001
> 
> Extra caps: bgdfs ccx mbss8 multi-user-beamformee multi-user-beamformer
> proptxstatus single-user-beamformee single-user-beamformer toe
> txpwrcache

4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-hostpmac Version: 10.10.69.69 CRC: 34d30c8c Date: Tue 2016-08-23 17:31:24 PDT FWID 01-8438621f


> 6) brcmfmac4366c-pcie.bin.ac88u
> Firmware version = wl0: Sep 12 2016 13:26:44 version 10.10.69.6908 (r658761) FWID 01-fed440e1
> 
> Monitor frames without raiotap
> 
> flags: 0x0001
> 
> Extra caps: bgdfs ccx cptlv-4 mbss8 multi-user-beamformee
> multi-user-beamformer proptxstatus single-user-beamformee
> single-user-beamformer toe txpwrcache

4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-hostpmac-txpwr Version: 10.10.69.252 CRC: 9fa88ab1 Date: Mon 2016-09-12 13:28:49 CST Ucode Ver: 1073.579 FWID: 01-fed440e1


> 7) brcmfmac4366c-pcie.bin.asus-dhd24
> Firmware version = wl0: Nov  7 2017 12:23:08 version 10.10.69.69017 (r730013) FWID 01-e258597c
> 
> Monitor frames include radiotap header
> 
> flags: 0x0002
> 
> Extra caps: bgdfs ccx cptlv-4 mbss8 multi-user-beamformee
> multi-user-beamformer proptxstatus single-user-beamformee
> single-user-beamformer toe txpwrcache

4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-hostpmac-txpwr-stamon Version: 10.10.69.69017 (r730013) CRC: cf0b5621 Date: Tue 2017-11-07 12:34:00 CST Ucode Ver: 1073.579 FWID: 01-e258597c


> 8) 4366c0 fw from FW_EA9500v2_EA9500S_2.1.1.183171_prod.img
> Firmware version = wl0: Aug  2 2017 18:45:13 version 10.10.122.20 (r683106) FWID 01-91326ac8
> 
> Monitor frames include radiotap header
> 
> flags: 0x0002
> 
> Extra caps: 160 bgdfs ccx dyn160 mbss8 multi-user-beamformee
> multi-user-beamformer proptxstatus single-user-beamformee
> single-user-beamformer toe txpwrcache

4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-stamon-hostpmac-murx-splitassoc-hostmemucode-dyn160-dhdhdr Version: 10.10.122.20 CRC: c3ff28b5 Date: Wed 2017-08-02 18:58:48 PDT FWID 01-91326ac8


> 9) 4366c0 fw from GT-AC5300_3.0.0.4_382_15984-gf481f58_cferom_ubi_0824.w
> Firmware version = wl0: Aug 17 2017 08:13:19 version 10.10.122.20 (r683106) FWID 01-bbb1a4c
> 
> Monitor frames include radiotap header
> 
> flags: 0x0002
> 
> Extra caps: 160 bgdfs ccx cptlv-4 dyn160 mbss8 multi-user-beamformee
> multi-user-beamformer proptxstatus single-user-beamformee
> single-user-beamformer toe txpwrcache

4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-stamon-hostpmac-murx-splitassoc-hostmemucode-dyn160-dhdhdr Version: 10.10.122.20 CRC: af9bda7b Date: Thu 2017-08-17 08:21:56 CST FWID 01-bbb1a4c


> 10) 4366c0 fw from ArcherC5400X(US)_171023.bin
> Firmware version = wl0: Sep 14 2017 14:10:23 version 10.10.122.20 (r683106) FWID 01-9f0e64f9
> 
> Monitor frames include radiotap header
> 
> flags: 0x0002
> 
> Extra caps: 160 bgdfs ccx dyn160 mbss8 multi-user-beamformee
> multi-user-beamformer proptxstatus single-user-beamformee
> single-user-beamformer toe txpwrcache

4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-stamon-hostpmac-murx-splitassoc-hostmemucode-dyn160-dhdhdr Version: 10.10.122.20 CRC: fe843f10 Date: Mon 2017-10-23 17:10:00 CST FWID 01-9f0e64f9

Re: Research + questions on brcmfmac and support for monitor mode

[Arend van Spriel]

On 5/30/2018 1:52 PM, Rafał Miłecki wrote:
> I'm providing extra version info of tested firmware images as requested
> by Arend in another e-mail thread.

Hi Rafał,

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.

Regards,
Arend

> On 15.05.2018 14:29, Rafał Miłecki wrote:
>> 1) brcmfmac43602-pcie.ap.bin from linux-firmware.git
>> Firmware version = wl0: Sep 18 2015 03:30:01 version 7.35.177.56
>> (r587209) FWID 01-6cb8e269
>>
>> Monitor frames without raiotap
>>
>> flags: 0x0001
>>
>> Extra caps: mbss4 ndoe proptxstatus
>
> 43602a1-roml/pcie-ag-splitrx-fdap-mbss-mfp-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop
> Version: 7.35.177.56 CRC: 548eccd4 Date: Fri 2015-09-18 03:31:06 PDT
> Ucode Ver: 986.122 FWID: 01-6cb8e269
>
>
>> 2) brcmfmac4366b-pcie.bin from linux-firmware.git
>> Firmware version = wl0: Jan  8 2016 12:54:07 version 10.10.69.3309
>> (r610991) FWID 01-c47a91a4
>>
>> Monitor frames without raiotap
>>
>> flags: 0x0001
>>
>> Extra caps: ccx mbss8 multi-user-beamformer proptxstatus
>> single-user-beamformee single-user-beamformer toe txpwrcache
>
> 4366b1-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs
> Version: 10.10.69.237 CRC: 4bc48c7b Date: Fri 2016-01-08 12:55:25 PST
> Ucode Ver: 1073.531 FWID: 01-c47a91a4
>
>
>> 3) 4366b1 development branch (from Arend)
>> Firmware version = wl0: Oct  6 2016 10:17:32 version 10.10 (TOB)
>> (r663589) FWID 01-6c5a1687
>>
>> Monitor frames without raiotap
>>
>> flags: 0x0001
>>
>> Extra caps: bgdfs ccx mbss8 multi-user-beamformer proptxstatus
>> single-user-beamformee single-user-beamformer toe txpwrcache
>
> 4366b1-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs
> Version: 10.10 (TOB) (r663589) CRC: 50d4be62 Date: Thu 2016-10-06
> 10:46:42 BST Ucode Ver: 1128.155 FWID: 01-6c5a1687
>
>> 4) brcmfmac4366c-pcie.bin.k3
>> Firmware version = wl0: Aug 19 2016 15:22:35 version 10.10.69.74
>> (r629731 WLTEST) FWID 01-5c0166fa
>>
>> Monitor frames without raiotap
>>
>> flags: 0x0001
>>
>> Extra caps: bgdfs ccx cptlv-4 mbss8 multi-user-beamformee
>> multi-user-beamformer single-user-beamformee single-user-beamformer toe
>> txpwrcache
>
> 4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfgtest-seqcmds-phydbg-phydump-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-11nprop-dbgam-dbgams-ringer-dmaindex16-bgdfs-hostpmac
> Version: 10.10.69.74 CRC: a6268b76 Date: Mon 2016-09-12 16:39:23 CST
> FWID 01-5c0166fa
>
>
>> 5) brcmfmac4366c-pcie.bin.ea9500
>> Firmware version = wl0: Aug 23 2016 17:19:51 version 10.10.69.69
>> (r625687) FWID 01-8438621f
>>
>> Monitor frames without raiotap
>>
>> flags: 0x0001
>>
>> Extra caps: bgdfs ccx mbss8 multi-user-beamformee multi-user-beamformer
>> proptxstatus single-user-beamformee single-user-beamformer toe
>> txpwrcache
>
> 4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-hostpmac
> Version: 10.10.69.69 CRC: 34d30c8c Date: Tue 2016-08-23 17:31:24 PDT
> FWID 01-8438621f
>
>
>> 6) brcmfmac4366c-pcie.bin.ac88u
>> Firmware version = wl0: Sep 12 2016 13:26:44 version 10.10.69.6908
>> (r658761) FWID 01-fed440e1
>>
>> Monitor frames without raiotap
>>
>> flags: 0x0001
>>
>> Extra caps: bgdfs ccx cptlv-4 mbss8 multi-user-beamformee
>> multi-user-beamformer proptxstatus single-user-beamformee
>> single-user-beamformer toe txpwrcache
>
> 4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-hostpmac-txpwr
> Version: 10.10.69.252 CRC: 9fa88ab1 Date: Mon 2016-09-12 13:28:49 CST
> Ucode Ver: 1073.579 FWID: 01-fed440e1
>
>
>> 7) brcmfmac4366c-pcie.bin.asus-dhd24
>> Firmware version = wl0: Nov  7 2017 12:23:08 version 10.10.69.69017
>> (r730013) FWID 01-e258597c
>>
>> Monitor frames include radiotap header
>>
>> flags: 0x0002
>>
>> Extra caps: bgdfs ccx cptlv-4 mbss8 multi-user-beamformee
>> multi-user-beamformer proptxstatus single-user-beamformee
>> single-user-beamformer toe txpwrcache
>
> 4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-hostpmac-txpwr-stamon
> Version: 10.10.69.69017 (r730013) CRC: cf0b5621 Date: Tue 2017-11-07
> 12:34:00 CST Ucode Ver: 1073.579 FWID: 01-e258597c
>
>
>> 8) 4366c0 fw from FW_EA9500v2_EA9500S_2.1.1.183171_prod.img
>> Firmware version = wl0: Aug  2 2017 18:45:13 version 10.10.122.20
>> (r683106) FWID 01-91326ac8
>>
>> Monitor frames include radiotap header
>>
>> flags: 0x0002
>>
>> Extra caps: 160 bgdfs ccx dyn160 mbss8 multi-user-beamformee
>> multi-user-beamformer proptxstatus single-user-beamformee
>> single-user-beamformer toe txpwrcache
>
> 4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-stamon-hostpmac-murx-splitassoc-hostmemucode-dyn160-dhdhdr
> Version: 10.10.122.20 CRC: c3ff28b5 Date: Wed 2017-08-02 18:58:48 PDT
> FWID 01-91326ac8
>
>
>> 9) 4366c0 fw from GT-AC5300_3.0.0.4_382_15984-gf481f58_cferom_ubi_0824.w
>> Firmware version = wl0: Aug 17 2017 08:13:19 version 10.10.122.20
>> (r683106) FWID 01-bbb1a4c
>>
>> Monitor frames include radiotap header
>>
>> flags: 0x0002
>>
>> Extra caps: 160 bgdfs ccx cptlv-4 dyn160 mbss8 multi-user-beamformee
>> multi-user-beamformer proptxstatus single-user-beamformee
>> single-user-beamformer toe txpwrcache
>
> 4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-stamon-hostpmac-murx-splitassoc-hostmemucode-dyn160-dhdhdr
> Version: 10.10.122.20 CRC: af9bda7b Date: Thu 2017-08-17 08:21:56 CST
> FWID 01-bbb1a4c
>
>
>> 10) 4366c0 fw from ArcherC5400X(US)_171023.bin
>> Firmware version = wl0: Sep 14 2017 14:10:23 version 10.10.122.20
>> (r683106) FWID 01-9f0e64f9
>>
>> Monitor frames include radiotap header
>>
>> flags: 0x0002
>>
>> Extra caps: 160 bgdfs ccx dyn160 mbss8 multi-user-beamformee
>> multi-user-beamformer proptxstatus single-user-beamformee
>> single-user-beamformer toe txpwrcache
>
> 4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-stamon-hostpmac-murx-splitassoc-hostmemucode-dyn160-dhdhdr
> Version: 10.10.122.20 CRC: fe843f10 Date: Mon 2017-10-23 17:10:00 CST
> FWID 01-9f0e64f9

Re: Research + questions on brcmfmac and support for monitor mode

[Rafał Miłecki]

On Mon, 11 Jun 2018 at 12:48, Arend van Spriel
<arend.vanspriel@broadcom.com> wrote:
> On 5/30/2018 1:52 PM, Rafa=C5=82 Mi=C5=82ecki wrote:
> > I'm providing extra version info of tested firmware images as requested
> > by Arend in another e-mail thread.
>
> 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.

The problem is that there isn't a direct mapping between what's
visible with the "tail" command and what firmware returns for the
"cap" iovar. Just to be sure I bumped #define MAX_CAPS_BUFFER_SIZE to
1024. Firmware that has "stamon" when checked with "tail" command
doesn't report "stamon" over "cap" iovar. So I can't detect if
firmware was compiled with WL_MONITOR and WL_RADIOTAP using "cap"
iovar.

Re: Research + questions on brcmfmac and support for monitor mode

[Arend van Spriel]

On 6/18/2018 1:54 PM, Rafał Miłecki wrote:
> On Mon, 11 Jun 2018 at 12:48, Arend van Spriel
> <arend.vanspriel@broadcom.com> wrote:
>> On 5/30/2018 1:52 PM, Rafał Miłecki wrote:
>>> I'm providing extra version info of tested firmware images as requested
>>> by Arend in another e-mail thread.
>>
>> 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.
>
> The problem is that there isn't a direct mapping between what's
> visible with the "tail" command and what firmware returns for the
> "cap" iovar. Just to be sure I bumped #define MAX_CAPS_BUFFER_SIZE to
> 1024. Firmware that has "stamon" when checked with "tail" command
> doesn't report "stamon" over "cap" iovar. So I can't detect if
> firmware was compiled with WL_MONITOR and WL_RADIOTAP using "cap"
> iovar.

All true. My suggestion is to look for "monitor" and "rtap" in the "cap" 
iovar response to detect if firmware is compiled with WL_MONITOR and 
WL_RADIOTAP respectively. When one (or both) of these is not detected, 
we could fallback to try a stamon iovar and if it is supported enable 
both WL_MONITOR and WL_RADIOTAP. I am looking into a good candidate for 
the stamon iovar so I can prepare a patch.

Regards,
Arend

Re: Research + questions on brcmfmac and support for monitor mode

[Rafał Miłecki]

On Mon, 18 Jun 2018 at 21:36, Arend van Spriel
<arend.vanspriel@broadcom.com> wrote:
>
> On 6/18/2018 1:54 PM, Rafa=C5=82 Mi=C5=82ecki wrote:
> > On Mon, 11 Jun 2018 at 12:48, Arend van Spriel
> > <arend.vanspriel@broadcom.com> wrote:
> >> On 5/30/2018 1:52 PM, Rafa=C5=82 Mi=C5=82ecki wrote:
> >>> I'm providing extra version info of tested firmware images as request=
ed
> >>> by Arend in another e-mail thread.
> >>
> >> 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 b=
e
> >> used for older firmwares.
> >
> > The problem is that there isn't a direct mapping between what's
> > visible with the "tail" command and what firmware returns for the
> > "cap" iovar. Just to be sure I bumped #define MAX_CAPS_BUFFER_SIZE to
> > 1024. Firmware that has "stamon" when checked with "tail" command
> > doesn't report "stamon" over "cap" iovar. So I can't detect if
> > firmware was compiled with WL_MONITOR and WL_RADIOTAP using "cap"
> > iovar.
>
> All true. My suggestion is to look for "monitor" and "rtap" in the "cap"
> iovar response to detect if firmware is compiled with WL_MONITOR and
> WL_RADIOTAP respectively. When one (or both) of these is not detected,
> we could fallback to try a stamon iovar and if it is supported enable
> both WL_MONITOR and WL_RADIOTAP. I am looking into a good candidate for
> the stamon iovar so I can prepare a patch.

Oh, I wasn't aware of the "stamon" iovar (or missed that in your
e-mails). If that works, it'll be a very nice fallback way of
detecting WL_MONITOR and WL_RADIOTAP!

--=20
Rafa=C5=82

Re: Research + questions on brcmfmac and support for monitor mode

[Rafał Miłecki]

On Mon, 18 Jun 2018 at 23:46, Rafa=C5=82 Mi=C5=82ecki <zajec5@gmail.com> wr=
ote:
> On Mon, 18 Jun 2018 at 21:36, Arend van Spriel
> <arend.vanspriel@broadcom.com> wrote:
> >
> > On 6/18/2018 1:54 PM, Rafa=C5=82 Mi=C5=82ecki wrote:
> > > On Mon, 11 Jun 2018 at 12:48, Arend van Spriel
> > > <arend.vanspriel@broadcom.com> wrote:
> > >> On 5/30/2018 1:52 PM, Rafa=C5=82 Mi=C5=82ecki wrote:
> > >>> I'm providing extra version info of tested firmware images as reque=
sted
> > >>> by Arend in another e-mail thread.
> > >>
> > >> Looking into our firmware repo it there are two flags, ie. WL_MONITO=
R
> > >> and WL_RADIOTAP. It seems both are set for firmware containing -stam=
on-
> > >> feature. Your list below confirms that. I still plan to add indicati=
on
> > >> for WL_RADIOTAP in the "cap" iovar, but a stamon feature check could=
 be
> > >> used for older firmwares.
> > >
> > > The problem is that there isn't a direct mapping between what's
> > > visible with the "tail" command and what firmware returns for the
> > > "cap" iovar. Just to be sure I bumped #define MAX_CAPS_BUFFER_SIZE to
> > > 1024. Firmware that has "stamon" when checked with "tail" command
> > > doesn't report "stamon" over "cap" iovar. So I can't detect if
> > > firmware was compiled with WL_MONITOR and WL_RADIOTAP using "cap"
> > > iovar.
> >
> > All true. My suggestion is to look for "monitor" and "rtap" in the "cap=
"
> > iovar response to detect if firmware is compiled with WL_MONITOR and
> > WL_RADIOTAP respectively. When one (or both) of these is not detected,
> > we could fallback to try a stamon iovar and if it is supported enable
> > both WL_MONITOR and WL_RADIOTAP. I am looking into a good candidate for
> > the stamon iovar so I can prepare a patch.
>
> Oh, I wasn't aware of the "stamon" iovar (or missed that in your
> e-mails). If that works, it'll be a very nice fallback way of
> detecting WL_MONITOR and WL_RADIOTAP!

I just tried "stamon" iovar and it doesn't work. Following call:
u32 var;
brcmf_fil_iovar_int_get(ifp, "stamon", &var);
returns -52

Can you look at that "stamon" iovar again, please?

--=20
Rafa=C5=82

Re: Research + questions on brcmfmac and support for monitor mode

[Rafał Miłecki]

On Tue, 19 Jun 2018 at 07:36, Rafa=C5=82 Mi=C5=82ecki <zajec5@gmail.com> wr=
ote:
> On Mon, 18 Jun 2018 at 23:46, Rafa=C5=82 Mi=C5=82ecki <zajec5@gmail.com> =
wrote:
> > On Mon, 18 Jun 2018 at 21:36, Arend van Spriel
> > <arend.vanspriel@broadcom.com> wrote:
> > >
> > > On 6/18/2018 1:54 PM, Rafa=C5=82 Mi=C5=82ecki wrote:
> > > > On Mon, 11 Jun 2018 at 12:48, Arend van Spriel
> > > > <arend.vanspriel@broadcom.com> wrote:
> > > >> On 5/30/2018 1:52 PM, Rafa=C5=82 Mi=C5=82ecki wrote:
> > > >>> I'm providing extra version info of tested firmware images as req=
uested
> > > >>> by Arend in another e-mail thread.
> > > >>
> > > >> Looking into our firmware repo it there are two flags, ie. WL_MONI=
TOR
> > > >> and WL_RADIOTAP. It seems both are set for firmware containing -st=
amon-
> > > >> feature. Your list below confirms that. I still plan to add indica=
tion
> > > >> for WL_RADIOTAP in the "cap" iovar, but a stamon feature check cou=
ld be
> > > >> used for older firmwares.
> > > >
> > > > The problem is that there isn't a direct mapping between what's
> > > > visible with the "tail" command and what firmware returns for the
> > > > "cap" iovar. Just to be sure I bumped #define MAX_CAPS_BUFFER_SIZE =
to
> > > > 1024. Firmware that has "stamon" when checked with "tail" command
> > > > doesn't report "stamon" over "cap" iovar. So I can't detect if
> > > > firmware was compiled with WL_MONITOR and WL_RADIOTAP using "cap"
> > > > iovar.
> > >
> > > All true. My suggestion is to look for "monitor" and "rtap" in the "c=
ap"
> > > iovar response to detect if firmware is compiled with WL_MONITOR and
> > > WL_RADIOTAP respectively. When one (or both) of these is not detected=
,
> > > we could fallback to try a stamon iovar and if it is supported enable
> > > both WL_MONITOR and WL_RADIOTAP. I am looking into a good candidate f=
or
> > > the stamon iovar so I can prepare a patch.
> >
> > Oh, I wasn't aware of the "stamon" iovar (or missed that in your
> > e-mails). If that works, it'll be a very nice fallback way of
> > detecting WL_MONITOR and WL_RADIOTAP!
>
> I just tried "stamon" iovar and it doesn't work. Following call:
> u32 var;
> brcmf_fil_iovar_int_get(ifp, "stamon", &var);
> returns -52
>
> Can you look at that "stamon" iovar again, please?

I kept looking around and noticed that "wl" user space tool supports
"sta_monitor" command. I tried "sta_monitor" iovar and it worked! I
guess that's the iovar you meant...

--=20
Rafa=C5=82

Re: Research + questions on brcmfmac and support for monitor mode

[Rafał Miłecki]

On Mon, 11 Jun 2018 at 12:48, Arend van Spriel
<arend.vanspriel@broadcom.com> wrote:
> On 5/30/2018 1:52 PM, Rafa=C5=82 Mi=C5=82ecki wrote:
> > I'm providing extra version info of tested firmware images as requested
> > by Arend in another e-mail thread.
>
> 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 just checked wl.mk (it's an open source file) and found following line:
WLFILES_SRC_HI +=3D src/wl/sys/wlc_stamon.c
not guarded by any ifeq.

It appears wlc_stamon.c is always being compiled in. Are you 100% sure
that wlc_stamon.c depends & uses radiotap? Are you sure it's
impossible to include stamon support without radiotap support?

I'm asking because we're going to check "sta_monitor" iovar to find
out if radiotap support is included. I'd like to be sure it's 100%
reliable.

Re: Research + questions on brcmfmac and support for monitor mode

[Arend van Spriel]

On 6/19/2018 9:27 AM, Rafał Miłecki wrote:
> On Mon, 11 Jun 2018 at 12:48, Arend van Spriel
> <arend.vanspriel@broadcom.com> wrote:
>> On 5/30/2018 1:52 PM, Rafał Miłecki wrote:
>>> I'm providing extra version info of tested firmware images as requested
>>> by Arend in another e-mail thread.
>>
>> 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 just checked wl.mk (it's an open source file) and found following line:
> WLFILES_SRC_HI += src/wl/sys/wlc_stamon.c
> not guarded by any ifeq.

wl.mk is used for NIC driver (softmac) so it is not used for fullmac 
firmware.

> It appears wlc_stamon.c is always being compiled in. Are you 100% sure
> that wlc_stamon.c depends & uses radiotap? Are you sure it's
> impossible to include stamon support without radiotap support?
>
> I'm asking because we're going to check "sta_monitor" iovar to find
> out if radiotap support is included. I'd like to be sure it's 100%
> reliable.

I have already created a patch for this (see below). I will submit it 
this week.

Regards,
Arend

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
index f70fec6..67d7fc7 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
@@ -207,6 +207,7 @@ void brcmf_feat_attach(struct brcmf_pub *drvr)
  	struct brcmf_if *ifp = brcmf_get_ifp(drvr, 0);
  	struct brcmf_pno_macaddr_le pfn_mac;
  	struct brcmf_gscan_config gscan_cfg;
+	struct brcmf_stamon_sta_config stamon_cfg;
  	u32 wowl_cap;
  	s32 err;

@@ -217,6 +218,20 @@ void brcmf_feat_attach(struct brcmf_pub *drvr)
  		brcmf_feat_iovar_data_set(ifp, BRCMF_FEAT_GSCAN,
  					  "pfn_gscan_cfg",
  					  &gscan_cfg, sizeof(gscan_cfg));
+
+	if (!brcmf_feat_is_enabled(ifp, BRCMF_FEAT_MONITOR) ||
+	    !brcmf_feat_is_enabled(ifp, BRCMF_FEAT_RADIOTAP)) {
+		ifp->fwil_fwerr = true;
+		memset(&stamon_cfg, 0, sizeof(stamon_cfg));
+		/* iovar requires IOVF_SET_UP so this fails either way */
+		err = brcmf_fil_iovar_data_set(ifp, "sta_monitor", &stamon_cfg,
+					       sizeof(stamon_cfg));
+		if (err != BRCMF_FW_UNSUPPORTED) {
+			ifp->drvr->feat_flags |= BRCMF_FEAT_MONITOR;
+			ifp->drvr->feat_flags |= BRCMF_FEAT_RADIOTAP;
+		}
+		ifp->fwil_fwerr = false;
+	}
  	brcmf_feat_iovar_int_get(ifp, BRCMF_FEAT_PNO, "pfn");
  	if (drvr->bus_if->wowl_supported)
  		brcmf_feat_iovar_int_get(ifp, BRCMF_FEAT_WOWL, "wowl");
diff --git 
a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
index 4b29070..e42d296 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
@@ -963,4 +963,36 @@ struct brcmf_gscan_config {
  	struct brcmf_gscan_bucket_config bucket[1];
  };

+enum brcmf_stamon_cfg_cmd {
+        STAMON_CFG_CMD_DEL = 0,
+        STAMON_CFG_CMD_ADD = 1,
+        STAMON_CFG_CMD_ENB = 2,
+        STAMON_CFG_CMD_DSB = 3,
+        STAMON_CFG_CMD_CNT = 4,
+        STAMON_CFG_CMD_RSTCNT = 5,
+        STAMON_CFG_CMD_GET_STATS = 6,
+        STAMON_CFG_CMD_SET_MONTIME = 7
+};
+
+/**
+ * struct brcmf_stamon_sta_config - configuration data for sta monitor.
+ *
+ * @cmd: subcommand for this configuration (see @enum 
brcmf_stamon_cfg_cmd).
+ * @mac: mac address of sta for which @cmd is intended.
+ * @version: version of this configuration structure.
+ * @length: number of bytes following this field.
+ * @chanspec: not used ?
+ * @mon_time: time for which STA's are monitored (ms).
+ * @offchan_time: timer for which off-channel STA's are monitored.
+ */
+struct brcmf_stamon_sta_config {
+        __le32 cmd;
+        u8 mac[ETH_ALEN];
+        __le16 version;
+        __le16 length;
+        __le16 chanspec;
+        __le32 monitor_time;
+        __le32 offchan_time;
+};
+
  #endif /* FWIL_TYPES_H_ */

Re: Research + questions on brcmfmac and support for monitor mode

[Rafał Miłecki]

On 19.06.2018 09:53, Arend van Spriel wrote:
> On 6/19/2018 9:27 AM, Rafał Miłecki wrote:
>> On Mon, 11 Jun 2018 at 12:48, Arend van Spriel
>> <arend.vanspriel@broadcom.com> wrote:
>>> On 5/30/2018 1:52 PM, Rafał Miłecki wrote:
>>>> I'm providing extra version info of tested firmware images as requested
>>>> by Arend in another e-mail thread.
>>>
>>> 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 just checked wl.mk (it's an open source file) and found following line:
>> WLFILES_SRC_HI += src/wl/sys/wlc_stamon.c
>> not guarded by any ifeq.
> 
> wl.mk is used for NIC driver (softmac) so it is not used for fullmac firmware.

Weird. I see a few rte references in wl.mk which suggests it's used for
both (softmac & fullmac firmware).


>> It appears wlc_stamon.c is always being compiled in. Are you 100% sure
>> that wlc_stamon.c depends & uses radiotap? Are you sure it's
>> impossible to include stamon support without radiotap support?
>>
>> I'm asking because we're going to check "sta_monitor" iovar to find
>> out if radiotap support is included. I'd like to be sure it's 100%
>> reliable.
> 
> I have already created a patch for this (see below). I will submit it this week.

Just to be clear could you also answer my above question, please?

Did you check if it's impossible to build firmware *with* stamon.c (and
sta_monitor iovar) and *without WL_RADIOTAP?


> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
> index f70fec6..67d7fc7 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
> @@ -207,6 +207,7 @@ void brcmf_feat_attach(struct brcmf_pub *drvr)
>       struct brcmf_if *ifp = brcmf_get_ifp(drvr, 0);
>       struct brcmf_pno_macaddr_le pfn_mac;
>       struct brcmf_gscan_config gscan_cfg;
> +    struct brcmf_stamon_sta_config stamon_cfg;
>       u32 wowl_cap;
>       s32 err;
> 
> @@ -217,6 +218,20 @@ void brcmf_feat_attach(struct brcmf_pub *drvr)
>           brcmf_feat_iovar_data_set(ifp, BRCMF_FEAT_GSCAN,
>                         "pfn_gscan_cfg",
>                         &gscan_cfg, sizeof(gscan_cfg));
> +
> +    if (!brcmf_feat_is_enabled(ifp, BRCMF_FEAT_MONITOR) ||
> +        !brcmf_feat_is_enabled(ifp, BRCMF_FEAT_RADIOTAP)) {
> +        ifp->fwil_fwerr = true;
> +        memset(&stamon_cfg, 0, sizeof(stamon_cfg));
> +        /* iovar requires IOVF_SET_UP so this fails either way */
> +        err = brcmf_fil_iovar_data_set(ifp, "sta_monitor", &stamon_cfg,
> +                           sizeof(stamon_cfg));

I think it may be simpler (and maybe less invasive) to use
brcmf_fil_iovar_data_get.


> +        if (err != BRCMF_FW_UNSUPPORTED) {
> +            ifp->drvr->feat_flags |= BRCMF_FEAT_MONITOR;
> +            ifp->drvr->feat_flags |= BRCMF_FEAT_RADIOTAP;
> +        }
> +        ifp->fwil_fwerr = false;
> +    }

Re: Research + questions on brcmfmac and support for monitor mode

[Arend van Spriel]

On 6/19/2018 10:32 AM, Rafał Miłecki wrote:
> On 19.06.2018 09:53, Arend van Spriel wrote:
>> On 6/19/2018 9:27 AM, Rafał Miłecki wrote:
>>> On Mon, 11 Jun 2018 at 12:48, Arend van Spriel
>>> <arend.vanspriel@broadcom.com> wrote:
>>>> On 5/30/2018 1:52 PM, Rafał Miłecki wrote:
>>>>> I'm providing extra version info of tested firmware images as
>>>>> requested
>>>>> by Arend in another e-mail thread.
>>>>
>>>> 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 just checked wl.mk (it's an open source file) and found following
>>> line:
>>> WLFILES_SRC_HI += src/wl/sys/wlc_stamon.c
>>> not guarded by any ifeq.
>>
>> wl.mk is used for NIC driver (softmac) so it is not used for fullmac
>> firmware.
>
> Weird. I see a few rte references in wl.mk which suggests it's used for
> both (softmac & fullmac firmware).

yeah. my mistake.

>>> It appears wlc_stamon.c is always being compiled in. Are you 100% sure
>>> that wlc_stamon.c depends & uses radiotap? Are you sure it's
>>> impossible to include stamon support without radiotap support?
>>>
>>> I'm asking because we're going to check "sta_monitor" iovar to find
>>> out if radiotap support is included. I'd like to be sure it's 100%
>>> reliable.
>>
>> I have already created a patch for this (see below). I will submit it
>> this week.
>
> Just to be clear could you also answer my above question, please?
>
> Did you check if it's impossible to build firmware *with* stamon.c (and
> sta_monitor iovar) and *without WL_RADIOTAP?

Yes. The functions in stamon.c, most importantly wlc_stamon_attach, are 
only invoked in firmware when WL_STA_MONITOR is defined.

>> diff --git
>> a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
>> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
>> index f70fec6..67d7fc7 100644
>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
>> @@ -207,6 +207,7 @@ void brcmf_feat_attach(struct brcmf_pub *drvr)
>>       struct brcmf_if *ifp = brcmf_get_ifp(drvr, 0);
>>       struct brcmf_pno_macaddr_le pfn_mac;
>>       struct brcmf_gscan_config gscan_cfg;
>> +    struct brcmf_stamon_sta_config stamon_cfg;
>>       u32 wowl_cap;
>>       s32 err;
>>
>> @@ -217,6 +218,20 @@ void brcmf_feat_attach(struct brcmf_pub *drvr)
>>           brcmf_feat_iovar_data_set(ifp, BRCMF_FEAT_GSCAN,
>>                         "pfn_gscan_cfg",
>>                         &gscan_cfg, sizeof(gscan_cfg));
>> +
>> +    if (!brcmf_feat_is_enabled(ifp, BRCMF_FEAT_MONITOR) ||
>> +        !brcmf_feat_is_enabled(ifp, BRCMF_FEAT_RADIOTAP)) {
>> +        ifp->fwil_fwerr = true;
>> +        memset(&stamon_cfg, 0, sizeof(stamon_cfg));
>> +        /* iovar requires IOVF_SET_UP so this fails either way */
>> +        err = brcmf_fil_iovar_data_set(ifp, "sta_monitor", &stamon_cfg,
>> +                           sizeof(stamon_cfg));
>
> I think it may be simpler (and maybe less invasive) to use
> brcmf_fil_iovar_data_get.

Thanks for the comment, but looking at the firmware I can not concur. In 
the get-path there is yet another compile flag that requires different 
query for different firmwares. For the set there is a prerequisite that 
the firmware stack is up and we know it is not upon executing 
brcmf_feat_attach() so it fails before entering the specific iovar 
handler in firmware.

Regards,
Arend

Re: Research + questions on brcmfmac and support for monitor mode

[Rafał Miłecki]

On 15.05.2018 14:29, Rafał Miłecki wrote:
> I was hoping that maybe looking at fw-reported capabilities will give me
> any hint regarding that but I'm afraid I'm out of luck. Below is a list
> of firmwares I tested and summary of each of them.
> 
> Note: as every firmware reports following capabilities:
> 802.11d 802.11h ampdu ampdu_rx ampdu_tx amsdurx amsdutx anqpo ap bcm_dcs
> bsstrans cac cqa dfrts dwds led mfp p2po probresp_mac_filter pspretend
> psr psta radio_pwrsave rm rxchain_pwrsave sta stbc-rx-1ss stbc-tx
> traffic-mgmt traffic-mgmt-dwm vht-prop-rates wds wet wet_tunnel wme wnm
> I omitted them below.

I'm sending an updated (with "cap" and "sta_monitor" info) summary of
firmwares I tested.

*****

1) brcmfmac43602-pcie.ap.bin from linux-firmware.git
43602a1-roml/pcie-ag-splitrx-fdap-mbss-mfp-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop Version: 7.35.177.56 CRC: 548eccd4 Date: Fri 2015-09-18 03:31:06 PDT Ucode Ver: 986.122 FWID: 01-6cb8e269
Firmware version = wl0: Sep 18 2015 03:30:01 version 7.35.177.56 (r587209) FWID 01-6cb8e269

Monitor frames: yes
Monitor frame flags: 0x0001
Radiotap: no

Flag "monitor" in the "cap" iovar: no
FW "sta_monitor" error (DOWN): -4 (BCME_NOTUP)
FW "sta_monitor" error (UP): -23 (BCME_UNSUPPORTED)

*****

2) brcmfmac4366b-pcie.bin from linux-firmware.git
4366b1-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs Version: 10.10.69.237 CRC: 4bc48c7b Date: Fri 2016-01-08 12:55:25 PST Ucode Ver: 1073.531 FWID: 01-c47a91a4
Firmware version = wl0: Jan  8 2016 12:54:07 version 10.10.69.3309 (r610991) FWID 01-c47a91a4

Monitor frames: yes
Monitor frame flags: 0x0001
Radiotap: no

Flag "monitor" in the "cap" iovar: no
FW "sta_monitor" error (DOWN): -4 (BCME_NOTUP)
FW "sta_monitor" error (UP): -23 (BCME_UNSUPPORTED)

*****

3) 4366b1 development branch (from Arend)
4366b1-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs Version: 10.10 (TOB) (r663589) CRC: 50d4be62 Date: Thu 2016-10-06 10:46:42 BST Ucode Ver: 1128.155 FWID: 01-6c5a1687
Firmware version = wl0: Oct  6 2016 10:17:32 version 10.10 (TOB) (r663589) FWID 01-6c5a1687

Monitor frames: yes
Monitor frame flags: 0x0001
Radiotap: no

Flag "monitor" in the "cap" iovar: no
FW "sta_monitor" error (DOWN): -4 (BCME_NOTUP)
FW "sta_monitor" error (UP): -23 (BCME_UNSUPPORTED)

*****

4) brcmfmac4366c-pcie.bin.k3
4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfgtest-seqcmds-phydbg-phydump-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-11nprop-dbgam-dbgams-ringer-dmaindex16-bgdfs-hostpmac Version: 10.10.69.74 CRC: a6268b76 Date: Mon 2016-09-12 16:39:23 CST FWID 01-5c0166fa
Firmware version = wl0: Aug 19 2016 15:22:35 version 10.10.69.74 (r629731 WLTEST) FWID 01-5c0166fa

Monitor frames: yes
Monitor frame flags: 0x0001
Radiotap: no

Flag "monitor" in the "cap" iovar: no
FW "sta_monitor" error (DOWN): -4 (BCME_NOTUP)
FW "sta_monitor" error (UP): -23 (BCME_UNSUPPORTED)

*****

5) brcmfmac4366c-pcie.bin.ea9500
4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-hostpmac Version: 10.10.69.69 CRC: 34d30c8c Date: Tue 2016-08-23 17:31:24 PDT FWID 01-8438621f
Firmware version = wl0: Aug 23 2016 17:19:51 version 10.10.69.69 (r625687) FWID 01-8438621f

Monitor frames: yes
Monitor frame flags: 0x0001
Radiotap: no

Flag "monitor" in the "cap" iovar: no
FW "sta_monitor" error (DOWN): -4 (BCME_NOTUP)
FW "sta_monitor" error (UP): -23 (BCME_UNSUPPORTED)

*****

6) brcmfmac4366c-pcie.bin.ac88u
4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-hostpmac-txpwr Version: 10.10.69.252 CRC: 9fa88ab1 Date: Mon 2016-09-12 13:28:49 CST Ucode Ver: 1073.579 FWID: 01-fed440e1
Firmware version = wl0: Sep 12 2016 13:26:44 version 10.10.69.6908 (r658761) FWID 01-fed440e1

Monitor frames: yes
Monitor frame flags: 0x0001
Radiotap: no

Flag "monitor" in the "cap" iovar: no
FW "sta_monitor" error (DOWN): -4 (BCME_NOTUP)
FW "sta_monitor" error (UP): -23 (BCME_UNSUPPORTED)

*****

7) brcmfmac4366c-pcie.bin.asus-dhd24
4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-hostpmac-txpwr-stamon Version: 10.10.69.69017 (r730013) CRC: cf0b5621 Date: Tue 2017-11-07 12:34:00 CST Ucode Ver: 1073.579 FWID: 01-e258597c
Firmware version = wl0: Nov  7 2017 12:23:08 version 10.10.69.69017 (r730013) FWID 01-e258597c

Monitor frames: yes
Monitor frame flags: 0x0002
Radiotap: yes

Flag "monitor" in the "cap" iovar: no
FW "sta_monitor" error (DOWN): -4 (BCME_NOTUP)
FW "sta_monitor" error (UP): -1 (BCME_ERROR)

*****

8) 4366c0 fw from FW_EA9500v2_EA9500S_2.1.1.183171_prod.img
4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-stamon-hostpmac-murx-splitassoc-hostmemucode-dyn160-dhdhdr Version: 10.10.122.20 CRC: c3ff28b5 Date: Wed 2017-08-02 18:58:48 PDT FWID 01-91326ac8
Firmware version = wl0: Aug  2 2017 18:45:13 version 10.10.122.20 (r683106) FWID 01-91326ac8

Monitor frames: yes
Monitor frame flags: 0x0002
Radiotap: yes

Flag "monitor" in the "cap" iovar: no
FW "sta_monitor" error (DOWN): -4 (BCME_NOTUP)
FW "sta_monitor" error (UP): -1 (BCME_ERROR)

*****

9) 4366c0 fw from GT-AC5300_3.0.0.4_382_15984-gf481f58_cferom_ubi_0824.w
4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-stamon-hostpmac-murx-splitassoc-hostmemucode-dyn160-dhdhdr Version: 10.10.122.20 CRC: af9bda7b Date: Thu 2017-08-17 08:21:56 CST FWID 01-bbb1a4c
Firmware version = wl0: Aug 17 2017 08:13:19 version 10.10.122.20 (r683106) FWID 01-bbb1a4c

Monitor frames: yes
Monitor frame flags: 0x0002
Radiotap: yes

Flag "monitor" in the "cap" iovar: no
FW "sta_monitor" error (DOWN): -4 (BCME_NOTUP)
FW "sta_monitor" error (UP): -1 (BCME_ERROR)

*****

10) 4366c0 fw from ArcherC5400X(US)_171023.bin
4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-stamon-hostpmac-murx-splitassoc-hostmemucode-dyn160-dhdhdr Version: 10.10.122.20 CRC: fe843f10 Date: Mon 2017-10-23 17:10:00 CST FWID 01-9f0e64f9
Firmware version = wl0: Sep 14 2017 14:10:23 version 10.10.122.20 (r683106) FWID 01-9f0e64f9

Monitor frames: yes
Monitor frame flags: 0x0002
Radiotap: yes

Flag "monitor" in the "cap" iovar: no
FW "sta_monitor" error (DOWN): -4 (BCME_NOTUP)
FW "sta_monitor" error (UP): -1 (BCME_ERROR)