Re: Problem with sending pkt on a monitor port
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 Candela Technologies Inc http://www.candelatech.com
Re: Problem with sending pkt on a monitor port
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
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 Candela Technologies Inc http://www.candelatech.com
Re: Problem with sending pkt on a monitor port
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
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 Candela Technologies Inc http://www.candelatech.com
Re: Problem with sending pkt on a monitor port
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
Problem with sending pkt on a monitor port
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, >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
Candela Technologies Inc http://www.candelatech.com
