On 09/28/2018 12:14 AM, Johannes Berg wrote:
Sorry, I'm a bit behind things ...
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.
The monitor port has the same mac as the wlanX in ath10k, ie the 'radio's mac'.
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?
radio-tap send on a monitor vdev.
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.
The code I quoted at the first of this thread make sure the monitor vdev is
not used if possible. But, maybe the driver has or had some ways to force certain
frames out the monitor port. That is my recollection. I added code to the firmware
to allow this to work, including bug fixes to crashes, so I am pretty sure there is *some*
way for that tx path to happen, at least in wave-1 firmware.
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?
Yes...because the monitor vdev chanctx was null and that method checks a bit later for it.
Maybe there is a way to create/configure the monitor vdev so that it has
a chanctx?
Thanks,
Ben
johannes
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
