Problem with sending pkt on a monitor port

Problem with sending pkt on a monitor port

[Ben Greear]

This is with a modified 4.16.18+ kernel, though the code in question
is from 2011, so this is not new...

I am attempting to use radiotap packet injection on a monitor port.

In the ieee80211_monitor_start_xmit method, before this code below
runs, sdata is 'moni6a', my monitor port.  But, since I have a
station wlan1 with the same MAC address, then when this code is
completed, stdata becomes wlan1.

Ath10k has all sorts of issues transmitting raw frames, and sending on
the wrong vdev only makes it even more broken!

If user-space binds a socket to a monitor vdev and transmits a frame,
why would we want to change the vdev here?

	list_for_each_entry_rcu(tmp_sdata, &local->interfaces, list) {
		if (!ieee80211_sdata_running(tmp_sdata))
			continue;
		if (tmp_sdata->vif.type == NL80211_IFTYPE_MONITOR ||
		    tmp_sdata->vif.type == NL80211_IFTYPE_AP_VLAN ||
		    tmp_sdata->vif.type == NL80211_IFTYPE_WDS)
			continue;
		if (ether_addr_equal(tmp_sdata->vif.addr, hdr->addr2)) {
			sdata = tmp_sdata;
			break;
		}
	}

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: Problem with sending pkt on a monitor port

[Johannes Berg]

On Wed, 2018-09-19 at 13:33 -0700, Ben Greear wrote:
> This is with a modified 4.16.18+ kernel, though the code in question
> is from 2011, so this is not new...
> 
> I am attempting to use radiotap packet injection on a monitor port.
> 
> In the ieee80211_monitor_start_xmit method, before this code below
> runs, sdata is 'moni6a', my monitor port.  But, since I have a
> station wlan1 with the same MAC address, then when this code is
> completed, stdata becomes wlan1.
> 
> Ath10k has all sorts of issues transmitting raw frames, and sending on
> the wrong vdev only makes it even more broken!
> 
> If user-space binds a socket to a monitor vdev and transmits a frame,
> why would we want to change the vdev here?

For one, the driver has no concept of the original vif, since monitor
vifs aren't added to it.

Secondly, the old hostapd code before nl80211 injects frames that way,
and they need to go there.

johannes

Re: Problem with sending pkt on a monitor port

[Ben Greear]

On 09/19/2018 01:35 PM, Johannes Berg wrote:
> On Wed, 2018-09-19 at 13:33 -0700, Ben Greear wrote:
>> This is with a modified 4.16.18+ kernel, though the code in question
>> is from 2011, so this is not new...
>>
>> I am attempting to use radiotap packet injection on a monitor port.
>>
>> In the ieee80211_monitor_start_xmit method, before this code below
>> runs, sdata is 'moni6a', my monitor port.  But, since I have a
>> station wlan1 with the same MAC address, then when this code is
>> completed, stdata becomes wlan1.
>>
>> Ath10k has all sorts of issues transmitting raw frames, and sending on
>> the wrong vdev only makes it even more broken!
>>
>> If user-space binds a socket to a monitor vdev and transmits a frame,
>> why would we want to change the vdev here?
>
> For one, the driver has no concept of the original vif, since monitor
> vifs aren't added to it.

ath10k does create a monitor vif, but maybe it is not mapped directly
to mac80211.

> Secondly, the old hostapd code before nl80211 injects frames that way,
> and they need to go there.

Ok, I agree we should not break backwards compat then.  I'll poke some more
to see if I can get it working.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: Problem with sending pkt on a monitor port

[Johannes Berg]

On Wed, 2018-09-19 at 13:47 -0700, Ben Greear wrote:

> > For one, the driver has no concept of the original vif, since monitor
> > vifs aren't added to it.
> 
> ath10k does create a monitor vif, but maybe it is not mapped directly
> to mac80211.

It's actually created by mac80211, but only once, and not directly
mapped to each vif seen by userspace - it's an internal construction.

> > Secondly, the old hostapd code before nl80211 injects frames that way,
> > and they need to go there.
> 
> Ok, I agree we should not break backwards compat then.  I'll poke some more
> to see if I can get it working.

We might get away with doing this only for cooked monitor mode, which it
used there ...

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.

Perhaps you should just use a different address, and then nothing of the
sort would happen?

johannes

Re: Problem with sending pkt on a monitor port

[Ben Greear]

On 09/20/2018 12:31 AM, Johannes Berg wrote:
> On Wed, 2018-09-19 at 13:47 -0700, Ben Greear wrote:
>
>>> For one, the driver has no concept of the original vif, since monitor
>>> vifs aren't added to it.
>>
>> ath10k does create a monitor vif, but maybe it is not mapped directly
>> to mac80211.
>
> 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).

>>> Secondly, the old hostapd code before nl80211 injects frames that way,
>>> and they need to go there.
>>
>> Ok, I agree we should not break backwards compat then.  I'll poke some more
>> to see if I can get it working.
>
> We might get away with doing this only for cooked monitor mode, which it
> used there ...
>
> 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.
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.

>
> Perhaps you should just use a different address, and then nothing of the
> sort would happen?

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.

Thanks,
Ben

>
> johannes
>

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: Problem with sending pkt on a monitor port

[Johannes Berg]

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.

> > 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

Re: Problem with sending pkt on a monitor port

[Ben Greear]

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@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com