Hi, > > You could have two interfaces, one which is scanning right now, right? > > And then theoretically you don't care about the other one - it *should* > > be OK to remove/re-add (with new MAC address) the one that *isn't* > > scanning, right? > > Actually, I don't think you can? Unless I'm missing something? All the > scan state is stored on struct ieee80211_local, so if that struct is > allocated per phy as you point out below, then what you suggest is > currently not possible?
? The scan_req struct contains a reference to which interface is scanning, so it should very well be possible to have phy0: wlan0: IFF_UP & scanning wlan1: IFF_UP & change MAC address all the time just like it's possible to change the MAC address when wlan1 *isn't* IFF_UP even if wlan0 is scanning, right? > > But we don't have that granularity here for anything - you're just > > checking "sdata->local->something", and by going from sdata to local > > you've now checked the whole NIC, not just a single interface on that > > NIC. > > Right. But that seems to be a limitation of mac80211 actually. We > can't run two scans concurrently on different interfaces. This is > rather unintuitive given that scan requests require an ifindex/wdev. > > Can this be changed / fixed in mac80211 actually? I would expect that > if a card supports p2p and station simultaneously, then it can scan / go > offchannel on two interfaces simultaneously? Or not? What can iwlwifi > do for example? No, this typically cannot be fixed, and it doesn't really make sense. The NIC cannot possibly do two scans at a time since it has only a single radio resource :-) > > But it's also completely confusing to do it this way because you go from > > "sdata" to "local", and at that point the data that you're working on is > > no longer specific to that one interface, it's actually for the whole > > NIC. > > I agree its confusing, but that seems to be how mac80211 works? See above. > Given the above, I'm not sure I see anything wrong? The switch/case can > probably be gotten rid of, but it actually makes things clear that only > station/p2p_device and adhoc are handled specially. I just don't think they *should* be handled specially. Given your code now, you can have phy0: wlan0: STATION, IFF_UP & something is doing remain-on-channel wlan1: STATION, IFF_UP --> cannot change wlan1 MAC address phy0: wlan0: STATION, IFF_UP & something is doing remain-on-channel wlan1: AP, IFF_UP --> *can* change wlan1 MAC address This doesn't really make much sense? johannes
