On 16 May 2018 at 10:37, Arend van Spriel <arend.vanspriel@xxxxxxxxxxxx> wrote: > 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. 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 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. 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 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? 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. -- Rafał
