Hi Arend, On Fri, May 25, 2018 at 12:38 PM Arend van Spriel < [email protected]> wrote:
> On 5/22/2018 3:18 PM, Rafał Miłecki wrote: > > From: Rafał Miłecki <[email protected]> > > > > New Broadcom firmwares mark monitor mode packets using a newly defined > > bit in the flags field. Use it to filter them out and pass to the > > monitor interface. These defines were found in bcmmsgbuf.h from SDK. > > > > As not every firmware generates radiotap header this commit introduces > > BRCMF_FEAT_MON_FMT_RADIOTAP that has to be set per firmware version. If > > not present brcmf_netif_mon_rx() assumed packet being a raw 802.11 frame > > and prepends it with an empty radiotap header. > > > > It's limited to the msgbuf protocol. Adding support for SDIO/USB devices > > will require some extra research. > So I went looking on my shelf and found the patch I made for SDIO a > while back. It relies on firmware change and I did not introduce a > firmware flag for it. I will send the patch as RFT so you can have a > look at it. > I checked our internal driver and it turns out the raw vs. radiotap is a > compilation option. So depending on customer they would get either > firmware doing the radiotap header generation or the host driver, > without any run-time way to determine it. Not nice for brcmfmac. I pretty sure I know what the answer to this is going to be, however I still have to ask: Is it possible to open up _any_ part of the firmware? (Even if it's just the host-interface end and the hardware end is a big ugly blob) It'd make dealing with stuff like this so much easier if we can just toggle a flag and recompile. (I'm also sure that we'd be more than happy to pass some flag through telling us/you that it's unofficial firmware and has probably broken the hardware, etc.) Thanks, -- Julian Calaby Email: [email protected] Profile: http://www.google.com/profiles/julian.calaby/
