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 <[email protected]>
---
include/uapi/linux/nl80211.h | 4 ++++
1 file changed, 4 insertions(+)
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,
--
2.25.1
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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote:
>
>
> On 3/3/20 10:59 PM, Steve deRosier wrote:
> > On Tue, Mar 3, 2020 at 1:28 PM Johannes Berg <[email protected]> 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 <[email protected]> wrote:
>>
>> On 3/3/20 10:59 PM, Steve deRosier wrote:
>>> On Tue, Mar 3, 2020 at 1:28 PM Johannes Berg <[email protected]> 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
>