Re: Problem with sending pkt on a monitor port
From: Johannes Berg <johannes@sipsolutions.net>
Date: 2018-09-28 07:14:52
Sorry, I'm a bit behind things ...
quoted
It's actually created by mac80211, but only once, and not directly mapped to each vif seen by userspace - it's an internal construction.I'm not sure it matters, but ath10k firmware can also create a monitor vdev itself for certain reasons. (Maybe offchannel tx on some FW, but I haven't looked at that code lately).
Yeah and I think it may actually do for active monitor, but I believe those get their own MAC address anyway? That might get used in the end as the vif to the driver too.
quoted
However, thinking about it, that also breaks userspace in other ways - for example if you do injection this way you actually get encryption and other nice things if you use the local address that matches an existing interface.I'm not entirely sure of a useful use-case for this feature in user-space.
Which feature? At least ancient versions of hostapd would rely on this, but clearly that's no longer super relevant. I don't know if anyone else relies on it, but in a way that is the problem. If I knew, then I could think about alternatives or how to keep that working if we change anything here.
I am using it just to test sending some test frames to debug some firmware features. I think another user sent hand-crafted specialized beacons in this manner using my 10.1 ath10k firmware & driver. For whatever reason, I didn't realize monitor vdevs were not directly used when I added that support..maybe I just got lucky before I had to dig closely.
They may be used if they were active monitor? I don't know ath10k well. But then they shouldn't have had the same MAC address to start with, IIRC.
If I make the code in my original email be skipped, so that sdata remains the monitor vdev, then it fails a check later in that method because there is no chanctxt for the monitor sdata object. I guess that changing the source MAC to something unique would cause the same issue and no frame would be sent towards the driver.
Hmm. This *should* work in one way or the other? But again, maybe ath10k has something special here? You skipped *just* that loop? johannes