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
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
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?