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
