On 3/4/20 5:34 PM, Steve deRosier wrote: > On Wed, Mar 4, 2020 at 1:34 AM Markus Theil <markus.theil@xxxxxxxxxxxxx> wrote: >> >> On 3/3/20 10:59 PM, Steve deRosier wrote: >>> On Tue, Mar 3, 2020 at 1:28 PM Johannes Berg <johannes@xxxxxxxxxxxxxxxx> 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
