Re: [PATCH V3 0/2] brcmfmac: initial work for adding monitor mode
On 2018-06-25 10:28, Arend van Spriel wrote: On 6/24/2018 4:20 PM, Rafał Miłecki wrote: On Fri, 22 Jun 2018 at 20:59, Arend van Spriel wrote: On 6/19/2018 10:25 PM, Rafał Miłecki wrote: On 2018-06-19 22:01, Arend van Spriel wrote: On 6/19/2018 5:48 PM, Rafał Miłecki wrote: From: Rafał Miłecki After a bit long discussions in various e-mail threads I'm coming with this simple & small patchset. It isn't complete support for monitor mode but just a pair of preparing patches that should be clear & well discussed by now to make them acceptable. The main missing bit is code setting MONITOR_FMT_RADIOTAP which I expect Arend to handle soon, as he already has a patch using "sta_monitor" iovar for that. Then we have to discuss a flag for marking firmwares which are capable for tagging monitor frames. While still incomplete, I believe that with my previous patches, we can agree this is a good direction. Arend: if you find these 2 patches OK, could you ack them, to make it clear for Kalle if they look OK now (or not yet)? I'd be great if you could sent your "sta_monitor" work on top of this. I acked them and I will submit my changes later. Either after these are applied or simply indicate the dependency. Now as for where we are with this. With what we have here we know firmware can monitor packets with and without radiotap. However, we do not have an indication whether firmware can transport these monitor packets to the host. What I need to look into next is whether the 802.11 flag in msgbuf is linked to a particular version of the protocol, but we may need to resort to the fwid table. Being able to detect if firmware tags monitor packets would be great. The 802.11 tag as opposed the 802.3 tag is specified in the PCIe host interface spec. The brcmfmac driver support rev 5 and 6 of that spec and both specify the tags. I did some digging and I believe it is safe to say that firmware that includes the "monitor" tag in the "cap" iovar does support these packets tags as well. OK, this is nice. The problem is we still need some fallback for the old firmwares. Only the newest ones specify "monitor" tag in the "cap" iovar. Older firmwares don't specify it but they still may include support for monitor mode and radiotap header. So in your list of firmwares, do you know (or can you find out :-p ) which ones return "monitor" and which do not? My educated guess was that only firmwares returning "monitor" tag have host-interface code in place to send monitor packets up to the host. You may prove me wrong. None of my firmwares have "monitor" flag in the "cap" iovar. This seems to be something really new. I'm still looking for some firmware new enough to report "monitor" flag. Unfortunately most vendors seem to be using 10.10.69.* or 10.10.122.20 which aren't new enough for that.
Re: [PATCH V3 0/2] brcmfmac: initial work for adding monitor mode
On 6/24/2018 4:20 PM, Rafał Miłecki wrote: On Fri, 22 Jun 2018 at 20:59, Arend van Spriel wrote: On 6/19/2018 10:25 PM, Rafał Miłecki wrote: On 2018-06-19 22:01, Arend van Spriel wrote: On 6/19/2018 5:48 PM, Rafał Miłecki wrote: From: Rafał Miłecki After a bit long discussions in various e-mail threads I'm coming with this simple & small patchset. It isn't complete support for monitor mode but just a pair of preparing patches that should be clear & well discussed by now to make them acceptable. The main missing bit is code setting MONITOR_FMT_RADIOTAP which I expect Arend to handle soon, as he already has a patch using "sta_monitor" iovar for that. Then we have to discuss a flag for marking firmwares which are capable for tagging monitor frames. While still incomplete, I believe that with my previous patches, we can agree this is a good direction. Arend: if you find these 2 patches OK, could you ack them, to make it clear for Kalle if they look OK now (or not yet)? I'd be great if you could sent your "sta_monitor" work on top of this. I acked them and I will submit my changes later. Either after these are applied or simply indicate the dependency. Now as for where we are with this. With what we have here we know firmware can monitor packets with and without radiotap. However, we do not have an indication whether firmware can transport these monitor packets to the host. What I need to look into next is whether the 802.11 flag in msgbuf is linked to a particular version of the protocol, but we may need to resort to the fwid table. Being able to detect if firmware tags monitor packets would be great. The 802.11 tag as opposed the 802.3 tag is specified in the PCIe host interface spec. The brcmfmac driver support rev 5 and 6 of that spec and both specify the tags. I did some digging and I believe it is safe to say that firmware that includes the "monitor" tag in the "cap" iovar does support these packets tags as well. OK, this is nice. The problem is we still need some fallback for the old firmwares. Only the newest ones specify "monitor" tag in the "cap" iovar. Older firmwares don't specify it but they still may include support for monitor mode and radiotap header. So in your list of firmwares, do you know (or can you find out :-p ) which ones return "monitor" and which do not? My educated guess was that only firmwares returning "monitor" tag have host-interface code in place to send monitor packets up to the host. You may prove me wrong. Regards, Arend
Re: [PATCH V3 0/2] brcmfmac: initial work for adding monitor mode
On Fri, 22 Jun 2018 at 20:59, Arend van Spriel wrote: > On 6/19/2018 10:25 PM, Rafał Miłecki wrote: > > On 2018-06-19 22:01, Arend van Spriel wrote: > >> On 6/19/2018 5:48 PM, Rafał Miłecki wrote: > >>> From: Rafał Miłecki > >>> > >>> After a bit long discussions in various e-mail threads I'm coming with > >>> this simple & small patchset. It isn't complete support for monitor mode > >>> but just a pair of preparing patches that should be clear & well > >>> discussed by now to make them acceptable. > >>> > >>> The main missing bit is code setting MONITOR_FMT_RADIOTAP which I expect > >>> Arend to handle soon, as he already has a patch using "sta_monitor" > >>> iovar for that. Then we have to discuss a flag for marking firmwares > >>> which are capable for tagging monitor frames. > >>> > >>> While still incomplete, I believe that with my previous patches, we can > >>> agree this is a good direction. > >>> > >>> Arend: if you find these 2 patches OK, could you ack them, to make it > >>> clear for Kalle if they look OK now (or not yet)? I'd be great if you > >>> could sent your "sta_monitor" work on top of this. > >> > >> I acked them and I will submit my changes later. Either after these > >> are applied or simply indicate the dependency. > >> > >> Now as for where we are with this. With what we have here we know > >> firmware can monitor packets with and without radiotap. However, we do > >> not have an indication whether firmware can transport these monitor > >> packets to the host. What I need to look into next is whether the > >> 802.11 flag in msgbuf is linked to a particular version of the > >> protocol, but we may need to resort to the fwid table. > > > > Being able to detect if firmware tags monitor packets would be great. > > The 802.11 tag as opposed the 802.3 tag is specified in the PCIe host > interface spec. The brcmfmac driver support rev 5 and 6 of that spec and > both specify the tags. I did some digging and I believe it is safe to > say that firmware that includes the "monitor" tag in the "cap" iovar > does support these packets tags as well. OK, this is nice. The problem is we still need some fallback for the old firmwares. Only the newest ones specify "monitor" tag in the "cap" iovar. Older firmwares don't specify it but they still may include support for monitor mode and radiotap header. > Unfortunately, the > BRCMF_C_MONITOR command support does not guarantee. So I just sent a > patch to remove the fall-back mechanism for detecting monitor mode support. -- Rafał
Re: [PATCH V3 0/2] brcmfmac: initial work for adding monitor mode
On 6/19/2018 10:25 PM, Rafał Miłecki wrote: On 2018-06-19 22:01, Arend van Spriel wrote: On 6/19/2018 5:48 PM, Rafał Miłecki wrote: From: Rafał Miłecki After a bit long discussions in various e-mail threads I'm coming with this simple & small patchset. It isn't complete support for monitor mode but just a pair of preparing patches that should be clear & well discussed by now to make them acceptable. The main missing bit is code setting MONITOR_FMT_RADIOTAP which I expect Arend to handle soon, as he already has a patch using "sta_monitor" iovar for that. Then we have to discuss a flag for marking firmwares which are capable for tagging monitor frames. While still incomplete, I believe that with my previous patches, we can agree this is a good direction. Arend: if you find these 2 patches OK, could you ack them, to make it clear for Kalle if they look OK now (or not yet)? I'd be great if you could sent your "sta_monitor" work on top of this. I acked them and I will submit my changes later. Either after these are applied or simply indicate the dependency. Now as for where we are with this. With what we have here we know firmware can monitor packets with and without radiotap. However, we do not have an indication whether firmware can transport these monitor packets to the host. What I need to look into next is whether the 802.11 flag in msgbuf is linked to a particular version of the protocol, but we may need to resort to the fwid table. Being able to detect if firmware tags monitor packets would be great. The 802.11 tag as opposed the 802.3 tag is specified in the PCIe host interface spec. The brcmfmac driver support rev 5 and 6 of that spec and both specify the tags. I did some digging and I believe it is safe to say that firmware that includes the "monitor" tag in the "cap" iovar does support these packets tags as well. Unfortunately, the BRCMF_C_MONITOR command support does not guarantee. So I just sent a patch to remove the fall-back mechanism for detecting monitor mode support. Regards, Arend
Re: [PATCH V3 0/2] brcmfmac: initial work for adding monitor mode
On 2018-06-19 22:01, Arend van Spriel wrote: On 6/19/2018 5:48 PM, Rafał Miłecki wrote: From: Rafał Miłecki After a bit long discussions in various e-mail threads I'm coming with this simple & small patchset. It isn't complete support for monitor mode but just a pair of preparing patches that should be clear & well discussed by now to make them acceptable. The main missing bit is code setting MONITOR_FMT_RADIOTAP which I expect Arend to handle soon, as he already has a patch using "sta_monitor" iovar for that. Then we have to discuss a flag for marking firmwares which are capable for tagging monitor frames. While still incomplete, I believe that with my previous patches, we can agree this is a good direction. Arend: if you find these 2 patches OK, could you ack them, to make it clear for Kalle if they look OK now (or not yet)? I'd be great if you could sent your "sta_monitor" work on top of this. I acked them and I will submit my changes later. Either after these are applied or simply indicate the dependency. Now as for where we are with this. With what we have here we know firmware can monitor packets with and without radiotap. However, we do not have an indication whether firmware can transport these monitor packets to the host. What I need to look into next is whether the 802.11 flag in msgbuf is linked to a particular version of the protocol, but we may need to resort to the fwid table. Being able to detect if firmware tags monitor packets would be great. Please let us know if you find anything and thanks a lot for looking at this patchset!
Re: [PATCH V3 0/2] brcmfmac: initial work for adding monitor mode
On 6/19/2018 5:48 PM, Rafał Miłecki wrote: From: Rafał Miłecki After a bit long discussions in various e-mail threads I'm coming with this simple & small patchset. It isn't complete support for monitor mode but just a pair of preparing patches that should be clear & well discussed by now to make them acceptable. The main missing bit is code setting MONITOR_FMT_RADIOTAP which I expect Arend to handle soon, as he already has a patch using "sta_monitor" iovar for that. Then we have to discuss a flag for marking firmwares which are capable for tagging monitor frames. While still incomplete, I believe that with my previous patches, we can agree this is a good direction. Arend: if you find these 2 patches OK, could you ack them, to make it clear for Kalle if they look OK now (or not yet)? I'd be great if you could sent your "sta_monitor" work on top of this. I acked them and I will submit my changes later. Either after these are applied or simply indicate the dependency. Now as for where we are with this. With what we have here we know firmware can monitor packets with and without radiotap. However, we do not have an indication whether firmware can transport these monitor packets to the host. What I need to look into next is whether the 802.11 flag in msgbuf is linked to a particular version of the protocol, but we may need to resort to the fwid table. Regards, Arend
[PATCH V3 0/2] brcmfmac: initial work for adding monitor mode
From: Rafał Miłecki After a bit long discussions in various e-mail threads I'm coming with this simple & small patchset. It isn't complete support for monitor mode but just a pair of preparing patches that should be clear & well discussed by now to make them acceptable. The main missing bit is code setting MONITOR_FMT_RADIOTAP which I expect Arend to handle soon, as he already has a patch using "sta_monitor" iovar for that. Then we have to discuss a flag for marking firmwares which are capable for tagging monitor frames. While still incomplete, I believe that with my previous patches, we can agree this is a good direction. Arend: if you find these 2 patches OK, could you ack them, to make it clear for Kalle if they look OK now (or not yet)? I'd be great if you could sent your "sta_monitor" work on top of this. Rafał Miłecki (2): brcmfmac: detect firmware support for monitor interface brcmfmac: handle monitor mode marked msgbuf packets .../wireless/broadcom/brcm80211/brcmfmac/core.c| 25 + .../wireless/broadcom/brcm80211/brcmfmac/core.h| 2 ++ .../wireless/broadcom/brcm80211/brcmfmac/feature.c | 26 ++ .../wireless/broadcom/brcm80211/brcmfmac/feature.h | 6 - .../wireless/broadcom/brcm80211/brcmfmac/fwil.h| 2 ++ .../wireless/broadcom/brcm80211/brcmfmac/msgbuf.c | 17 ++ 6 files changed, 77 insertions(+), 1 deletion(-) -- 2.13.7
