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

[Arend van Spriel <arend.vanspriel@broadcom.com>]

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