| Message ID | 20200303115017.9845-1-markus.theil@tu-ilmenau.de (mailing list archive) |
|---|---|
| State | Rejected |
| Delegated to: | Johannes Berg |
| Headers | show |
| Series | [1/3] nl80211: add monitor mode scan feature | expand |
On Tue, 2020-03-03 at 12:50 +0100, Markus Theil wrote: > Back in 2007 "mac80211: don't allow scanning in monitor mode" > (f27b62d3e7ec) disabled scanning in monitor mode, because hw > controlled by the zd1211rw driver got confused during this operation. > > Nevertheless, it can be useful to scan in monitor mode, e.g. > when building a tool which processes scans, channel surveys and > monitors the channel passively in monitor mode. Hmm. I'm not really sure that this makes sense. You're in monitor mode, so you won't get any scan processing as such (you will not be able to use nl80211 to retrieve the results!), and there will be a lot of confusion over sending probe requests (the code now looks like it would in fact attempt to do so ... but how?). johannes
On Tue, Mar 3, 2020 at 1:28 PM Johannes Berg <johannes@sipsolutions.net> wrote: > > On Tue, 2020-03-03 at 12:50 +0100, Markus Theil wrote: > > Back in 2007 "mac80211: don't allow scanning in monitor mode" > > (f27b62d3e7ec) disabled scanning in monitor mode, because hw > > controlled by the zd1211rw driver got confused during this operation. > > > > Nevertheless, it can be useful to scan in monitor mode, e.g. > > when building a tool which processes scans, channel surveys and > > monitors the channel passively in monitor mode. > > Hmm. I'm not really sure that this makes sense. > > You're in monitor mode, so you won't get any scan processing as such > (you will not be able to use nl80211 to retrieve the results!), and > there will be a lot of confusion over sending probe requests (the code > now looks like it would in fact attempt to do so ... but how?). > Additionally, I don't see what this solves for sure. At least on an ath10k device I've been using, I can have two interfaces on one phy (phy0), wlan0 and mon0, and I can issue a `iw wlan0 scan` and it works famously and then capture fine on mon0. Granted, I haven't tried doing a scan while at the same time am actively capturing, but I wonder of the meaning of that anyway as the capturing radio would have to then go off channel and issue probe requests etc., sort of screwing up my capture for that time period. But anyway, can you not do this on your radio? - Steve
On 3/3/20 10:27 PM, Johannes Berg wrote: > On Tue, 2020-03-03 at 12:50 +0100, Markus Theil wrote: >> Back in 2007 "mac80211: don't allow scanning in monitor mode" >> (f27b62d3e7ec) disabled scanning in monitor mode, because hw >> controlled by the zd1211rw driver got confused during this operation. >> >> Nevertheless, it can be useful to scan in monitor mode, e.g. >> when building a tool which processes scans, channel surveys and >> monitors the channel passively in monitor mode. > Hmm. I'm not really sure that this makes sense. > > You're in monitor mode, so you won't get any scan processing as such > (you will not be able to use nl80211 to retrieve the results!), I used this patchset for some time to build a combined monitoring and channel survey tool. A mt76 based USB dongle is used, because mt76 supports the channel survey cmd which yields the channel's busy time. At the same time, the tool listens for beacons over the monitor interface to log available networks and their RSSI to the user. When the user changes into heatmap mode, he can issue active scan requests at different points on the floor plan. All of this this can be done with a single interface in monitor mode. I change the frequency of the monitoring interface periodically to passively listen at other channels. nl80211 is able to receive scan results in my setup. "iw dev $MON_IF scan" also works as expected. A combination of an unassociated STA VIF and a monitor VIF (scan on STA VIF, receive Wi-Fi frames on monitor VIF) does not work, because I cannot freely set the channel on an unassociated STA VIF. Trying to set the operating frequency on the monitor VIF also fails, when the STA VIF is up. Bringing the STA VIF up would be needed for scanning on it. Therefore this patches solved my solely monitoring-oriented use-case. > and > there will be a lot of confusion over sending probe requests (the code > now looks like it would in fact attempt to do so ... but how?). Yes, the code now uses the kernel mechanisms to send probe requests. > > johannes > Markus
On 3/3/20 10:59 PM, Steve deRosier wrote: > On Tue, Mar 3, 2020 at 1:28 PM Johannes Berg <johannes@sipsolutions.net> wrote: >> On Tue, 2020-03-03 at 12:50 +0100, Markus Theil wrote: >>> Back in 2007 "mac80211: don't allow scanning in monitor mode" >>> (f27b62d3e7ec) disabled scanning in monitor mode, because hw >>> controlled by the zd1211rw driver got confused during this operation. >>> >>> Nevertheless, it can be useful to scan in monitor mode, e.g. >>> when building a tool which processes scans, channel surveys and >>> monitors the channel passively in monitor mode. >> Hmm. I'm not really sure that this makes sense. >> >> You're in monitor mode, so you won't get any scan processing as such >> (you will not be able to use nl80211 to retrieve the results!), and >> there will be a lot of confusion over sending probe requests (the code >> now looks like it would in fact attempt to do so ... but how?). >> > Additionally, I don't see what this solves for sure. At least on an > ath10k device I've been using, I can have two interfaces on one phy > (phy0), wlan0 and mon0, and I can issue a `iw wlan0 scan` and it works > famously and then capture fine on mon0. Granted, I haven't tried doing > a scan while at the same time am actively capturing, but I wonder of > the meaning of that anyway as the capturing radio would have to then > go off channel and issue probe requests etc., sort of screwing up my > capture for that time period. But anyway, can you not do this on your > radio? > > - Steve I was not able to use this combination of interfaces, when only interested in monitoring networks. The STA VIF can only scan when its put up, but then I cannot choose the operating frequency of the monitor interface freely. Sure, I can build workarounds, like changing the interface type when I need an active scan and chaning it back to monitor mode afterwards, but this also seems not very clean. Markus
On Wed, Mar 4, 2020 at 1:34 AM Markus Theil <markus.theil@tu-ilmenau.de> wrote: > > > On 3/3/20 10:59 PM, Steve deRosier wrote: > > On Tue, Mar 3, 2020 at 1:28 PM Johannes Berg <johannes@sipsolutions.net> wrote: > >> On Tue, 2020-03-03 at 12:50 +0100, Markus Theil wrote: > >>> Back in 2007 "mac80211: don't allow scanning in monitor mode" > >>> (f27b62d3e7ec) disabled scanning in monitor mode, because hw > >>> controlled by the zd1211rw driver got confused during this operation. > >>> > >>> Nevertheless, it can be useful to scan in monitor mode, e.g. > >>> when building a tool which processes scans, channel surveys and > >>> monitors the channel passively in monitor mode. > >> Hmm. I'm not really sure that this makes sense. > >> > >> You're in monitor mode, so you won't get any scan processing as such > >> (you will not be able to use nl80211 to retrieve the results!), and > >> there will be a lot of confusion over sending probe requests (the code > >> now looks like it would in fact attempt to do so ... but how?). > >> > > Additionally, I don't see what this solves for sure. At least on an > > ath10k device I've been using, I can have two interfaces on one phy > > (phy0), wlan0 and mon0, and I can issue a `iw wlan0 scan` and it works > > famously and then capture fine on mon0. Granted, I haven't tried doing > > a scan while at the same time am actively capturing, but I wonder of > > the meaning of that anyway as the capturing radio would have to then > > go off channel and issue probe requests etc., sort of screwing up my > > capture for that time period. But anyway, can you not do this on your > > radio? > > > > - Steve > > I was not able to use this combination of interfaces, when only interested in monitoring networks. > The STA VIF can only scan when its put up, but then I cannot choose the operating frequency of the > monitor interface freely. Sure, I can build workarounds, like changing the interface type when I need > an active scan and chaning it back to monitor mode afterwards, but this also seems not very clean. > Hi Markus, I'm trying to understand the semantics of what happens when I'm actively doing a capture, and then issue a `iw mon0 scan` (or equiv). What happens to the capture and how do I make sense of it? Personally I prefer the explicit over the implicit with confusing results. The following sequence is clearer and explicit to me: ifconfig wlan0 up iw wlan0 scan ifconfig wlan0 down iw mon0 set channel 36 HT40+ tshark -i mon0 ..... Obviously I'm using command-line tools to illustrate, tools might use the API instead. In any case, there's no possible confusion over what the semantics might be because it's not possible to have the confusing state. I hear what you're saying, and you're right, in userspace you have to do multiple steps for your use-case. In thinking about it, _should_ the kernel have changes in it to make your specific use-case easier? And _should_ it do so for one particular NIC that works in a particular way? What happens with the other NICs that have different capabilities and semantics than the mt76? Seems to me that a clean and straightforward mechanism in the kernel is "very clean" while it's OK for userspace, which is where policy stuff is supposed to be, to have to jump through a few hoops. Do we want to add complexity and maintain that for all the drivers simply to avoid having two VIFs and avoid the extra steps of bringing one up and down when we want to do a scan? Your usecase is already possible, and IMHO, not that difficult to achieve. But maybe I'm missing some terrible hole here as I've not tried to write whatever app it is you're writing nor do I usually work with the mt76. Honestly, I don't have the answers, but I want to raise the questions as they impact more than your one usecase and NIC. The semantics of your mechanism don't seem very clean to me, and I worry that if other people on NICs decide to enable your feature flag, we're going to have a fun time supporting that. I'm sure the maintainers will sort it out. Thanks, - Steve
On 3/4/20 5:34 PM, Steve deRosier wrote: > On Wed, Mar 4, 2020 at 1:34 AM Markus Theil <markus.theil@tu-ilmenau.de> wrote: >> >> On 3/3/20 10:59 PM, Steve deRosier wrote: >>> On Tue, Mar 3, 2020 at 1:28 PM Johannes Berg <johannes@sipsolutions.net> wrote: >>>> On Tue, 2020-03-03 at 12:50 +0100, Markus Theil wrote: >>>>> Back in 2007 "mac80211: don't allow scanning in monitor mode" >>>>> (f27b62d3e7ec) disabled scanning in monitor mode, because hw >>>>> controlled by the zd1211rw driver got confused during this operation. >>>>> >>>>> Nevertheless, it can be useful to scan in monitor mode, e.g. >>>>> when building a tool which processes scans, channel surveys and >>>>> monitors the channel passively in monitor mode. >>>> Hmm. I'm not really sure that this makes sense. >>>> >>>> You're in monitor mode, so you won't get any scan processing as such >>>> (you will not be able to use nl80211 to retrieve the results!), and >>>> there will be a lot of confusion over sending probe requests (the code >>>> now looks like it would in fact attempt to do so ... but how?). >>>> >>> Additionally, I don't see what this solves for sure. At least on an >>> ath10k device I've been using, I can have two interfaces on one phy >>> (phy0), wlan0 and mon0, and I can issue a `iw wlan0 scan` and it works >>> famously and then capture fine on mon0. Granted, I haven't tried doing >>> a scan while at the same time am actively capturing, but I wonder of >>> the meaning of that anyway as the capturing radio would have to then >>> go off channel and issue probe requests etc., sort of screwing up my >>> capture for that time period. But anyway, can you not do this on your >>> radio? >>> >>> - Steve >> I was not able to use this combination of interfaces, when only interested in monitoring networks. >> The STA VIF can only scan when its put up, but then I cannot choose the operating frequency of the >> monitor interface freely. Sure, I can build workarounds, like changing the interface type when I need >> an active scan and chaning it back to monitor mode afterwards, but this also seems not very clean. >> > Hi Markus, > > I'm trying to understand the semantics of what happens when I'm > actively doing a capture, and then issue a `iw mon0 scan` (or equiv). > What happens to the capture and how do I make sense of it? > > Personally I prefer the explicit over the implicit with confusing > results. The following sequence is clearer and explicit to me: > > ifconfig wlan0 up > iw wlan0 scan > ifconfig wlan0 down > iw mon0 set channel 36 HT40+ > tshark -i mon0 ..... > > Obviously I'm using command-line tools to illustrate, tools might use > the API instead. In any case, there's no possible confusion over what > the semantics might be because it's not possible to have the confusing > state. > > I hear what you're saying, and you're right, in userspace you have to > do multiple steps for your use-case. In thinking about it, _should_ > the kernel have changes in it to make your specific use-case easier? > And _should_ it do so for one particular NIC that works in a > particular way? What happens with the other NICs that have different > capabilities and semantics than the mt76? Seems to me that a clean > and straightforward mechanism in the kernel is "very clean" while it's > OK for userspace, which is where policy stuff is supposed to be, to > have to jump through a few hoops. Do we want to add complexity and > maintain that for all the drivers simply to avoid having two VIFs and > avoid the extra steps of bringing one up and down when we want to do a > scan? Your usecase is already possible, and IMHO, not that difficult > to achieve. But maybe I'm missing some terrible hole here as I've not > tried to write whatever app it is you're writing nor do I usually work > with the mt76. Sure, I can achieve what I want to do with multiple steps, like you already sketched in your command-line example above. Should these patches introduce more issues in the long run than saving some steps in this particular use-case is worth it, I totally agree, that such a feature should not be included in the kernel. I only included the flag for mt76, because these were the NICs I had readily available to test with. > Honestly, I don't have the answers, but I want to raise the questions > as they impact more than your one usecase and NIC. The semantics of > your mechanism don't seem very clean to me, and I worry that if other > people on NICs decide to enable your feature flag, we're going to have > a fun time supporting that. I'm sure the maintainers will sort it out. > > Thanks, > - Steve Thanks for expressing your concerns and bringing more clarity into the discussion! Markus
On Wed, 2020-03-04 at 10:30 +0100, Markus Theil wrote: > > I used this patchset for some time to build a combined monitoring and > channel survey tool. > A mt76 based USB dongle is used, because mt76 supports the channel > survey cmd which yields the channel's busy time. > At the same time, the tool listens for beacons over the monitor > interface to log available networks and their RSSI to the user. > When the user changes into heatmap mode, he can issue active scan > requests at different points on the floor plan. All of this this > can be done with a single interface in monitor mode. I change the > frequency of the monitoring interface periodically to passively listen > at other channels. > > nl80211 is able to receive scan results in my setup. "iw dev $MON_IF > scan" also works as expected. > > A combination of an unassociated STA VIF and a monitor VIF (scan on STA > VIF, receive Wi-Fi frames on monitor VIF) does not work, because > I cannot freely set the channel on an unassociated STA VIF. Trying to > set the operating frequency on the monitor VIF also fails, when the STA > VIF is up. > Bringing the STA VIF up would be needed for scanning on it. > > Therefore this patches solved my solely monitoring-oriented use-case. Yeah, I kinda see where you're coming from, but I still don't think this makes a lot of sense. I'm actually surprised that "iw dev mon scan" works (in that it prints results) - would have expected the results to just go nowhere? And as you say, you're actually sending probe requests here, while you cannot even set the MAC address properly on a radiotap monitor interface. I don't really think we should mix all these concepts, the more things we try to allow in monitor mode, the more confusing that becomes (is it active now? or passive?) johannes
On 11.03.20 10:36, Johannes Berg wrote: > On Wed, 2020-03-04 at 10:30 +0100, Markus Theil wrote: >> I used this patchset for some time to build a combined monitoring and >> channel survey tool. >> A mt76 based USB dongle is used, because mt76 supports the channel >> survey cmd which yields the channel's busy time. >> At the same time, the tool listens for beacons over the monitor >> interface to log available networks and their RSSI to the user. >> When the user changes into heatmap mode, he can issue active scan >> requests at different points on the floor plan. All of this this >> can be done with a single interface in monitor mode. I change the >> frequency of the monitoring interface periodically to passively listen >> at other channels. >> >> nl80211 is able to receive scan results in my setup. "iw dev $MON_IF >> scan" also works as expected. >> >> A combination of an unassociated STA VIF and a monitor VIF (scan on STA >> VIF, receive Wi-Fi frames on monitor VIF) does not work, because >> I cannot freely set the channel on an unassociated STA VIF. Trying to >> set the operating frequency on the monitor VIF also fails, when the STA >> VIF is up. >> Bringing the STA VIF up would be needed for scanning on it. >> >> Therefore this patches solved my solely monitoring-oriented use-case. > Yeah, I kinda see where you're coming from, but I still don't think this > makes a lot of sense. I'm actually surprised that "iw dev mon scan" > works (in that it prints results) - would have expected the results to > just go nowhere? > > And as you say, you're actually sending probe requests here, while you > cannot even set the MAC address properly on a radiotap monitor > interface. > > I don't really think we should mix all these concepts, the more things > we try to allow in monitor mode, the more confusing that becomes (is it > active now? or passive?) Ok, I see your point. I think I'll just rework my tool in the way Steve has already suggested (use additional STA VIF and set it up for every active scan, set it down afterwards). So please feel free to drop these patches, if you haven't already :) > > johannes >
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h index b002ef2060fa..062519967e60 100644 --- a/include/uapi/linux/nl80211.h +++ b/include/uapi/linux/nl80211.h @@ -5642,6 +5642,9 @@ enum nl80211_feature_flags { * @NL80211_EXT_FEATURE_BEACON_PROTECTION: The driver supports Beacon protection * and can receive key configuration for BIGTK using key indexes 6 and 7. * + * @NL80211_EXT_FEATURE_MONITOR_MODE_SCAN: The driver supports scanning while in + * monitor mode. + * * @NUM_NL80211_EXT_FEATURES: number of extended features. * @MAX_NL80211_EXT_FEATURES: highest extended feature index. */ @@ -5690,6 +5693,7 @@ enum nl80211_ext_feature_index { NL80211_EXT_FEATURE_VLAN_OFFLOAD, NL80211_EXT_FEATURE_AQL, NL80211_EXT_FEATURE_BEACON_PROTECTION, + NL80211_EXT_FEATURE_MONITOR_MODE_SCAN, /* add new features before the definition below */ NUM_NL80211_EXT_FEATURES,
Back in 2007 "mac80211: don't allow scanning in monitor mode" (f27b62d3e7ec) disabled scanning in monitor mode, because hw controlled by the zd1211rw driver got confused during this operation. Nevertheless, it can be useful to scan in monitor mode, e.g. when building a tool which processes scans, channel surveys and monitors the channel passively in monitor mode. This patch adds a feature flag for scanning in monitor mode, which can be set by hw supporting this feature. Signed-off-by: Markus Theil <markus.theil@tu-ilmenau.de> --- include/uapi/linux/nl80211.h | 4 ++++ 1 file changed, 4 insertions(+)