Hi Arend, On Wed, May 30, 2018 at 8:05 PM Arend van Spriel < arend.vanspriel@xxxxxxxxxxxx> wrote: > On 5/27/2018 7:34 AM, Julian Calaby wrote: > > Hi Arend, > > On Fri, May 25, 2018 at 12:38 PM Arend van Spriel < > > arend.vanspriel@xxxxxxxxxxxx> wrote: > > > >> On 5/22/2018 3:18 PM, Rafał Miłecki wrote: > >>> From: Rafał Miłecki <rafal@xxxxxxxxxx> > >>> > >>> 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.) > Hah. Yeah, with next to nil uncertainty I know the answer to this as > well. If you know how long it took before we committed to supporting the > upstream drivers. Despite my better judgement I will pass your idea, but > it is not something that is going to fall in the timeframe that Rafał > had in mind. Fair enough, I can't ask for more than that. Good Luck! -- Julian Calaby Email: julian.calaby@xxxxxxxxx Profile: http://www.google.com/profiles/julian.calaby/
