On Mon, 18 Jun 2018 at 21:36, Arend van Spriel <arend.vanspriel@xxxxxxxxxxxx> wrote: > > On 6/18/2018 1:54 PM, Rafał Miłecki wrote: > > On Mon, 11 Jun 2018 at 12:48, Arend van Spriel > > <arend.vanspriel@xxxxxxxxxxxx> wrote: > >> On 5/30/2018 1:52 PM, Rafał Miłecki wrote: > >>> I'm providing extra version info of tested firmware images as requested > >>> by Arend in another e-mail thread. > >> > >> Looking into our firmware repo it there are two flags, ie. WL_MONITOR > >> and WL_RADIOTAP. It seems both are set for firmware containing -stamon- > >> feature. Your list below confirms that. I still plan to add indication > >> for WL_RADIOTAP in the "cap" iovar, but a stamon feature check could be > >> used for older firmwares. > > > > The problem is that there isn't a direct mapping between what's > > visible with the "tail" command and what firmware returns for the > > "cap" iovar. Just to be sure I bumped #define MAX_CAPS_BUFFER_SIZE to > > 1024. Firmware that has "stamon" when checked with "tail" command > > doesn't report "stamon" over "cap" iovar. So I can't detect if > > firmware was compiled with WL_MONITOR and WL_RADIOTAP using "cap" > > iovar. > > All true. My suggestion is to look for "monitor" and "rtap" in the "cap" > iovar response to detect if firmware is compiled with WL_MONITOR and > WL_RADIOTAP respectively. When one (or both) of these is not detected, > we could fallback to try a stamon iovar and if it is supported enable > both WL_MONITOR and WL_RADIOTAP. I am looking into a good candidate for > the stamon iovar so I can prepare a patch. Oh, I wasn't aware of the "stamon" iovar (or missed that in your e-mails). If that works, it'll be a very nice fallback way of detecting WL_MONITOR and WL_RADIOTAP! -- Rafał
