On 10/24/2017 06:38 AM, Johannes Berg wrote:
On Tue, 2017-10-24 at 06:36 -0700, Ben Greear wrote:
On 10/23/2017 10:54 PM, Johannes Berg wrote:
On Mon, 2017-10-23 at 13:59 -0700, Ben Greear wrote:
The CSI data has variable length [1] but it's fundamentally always tied
to a specific frame and as such we've always attached it to that frame
using a radiotap vendor namespace.
You can easily implement that in a mac80211 driver since it has support
for that via RX_FLAG_RADIOTAP_VENDOR_DATA and the associated struct
ieee80211_vendor_radiotap that you put into the skb's head.
Why should anything else be needed?
So this would only show up in user-space in something like a pkt-capture?
Sure. But since you can easily add virtual monitor interfaces at any
time, that doesn't really mean anything.
Adding a monitor device is a pretty big hammer on ath10k, at least, and
probably not something one would want running continuously in a production
environment.
We keep having this discussion. You need to fix this, it should be
really simple to fix this - just remove all checks for CONF_MONITOR
from ath10k and make it use WANT_MONITOR_VIF instead if it doesn't
already.
I don't recall having this discussion, but even if you can do a
non-promiscuous monitor mode, you would have to end up having a bpf
socket filter and packet socket, right?
Wouldn't that have a noticeable effect on performance on modest sized
AP hardware?
The CSI data is one part, but tx-beamforming is another area of interest.
If I get a chance, I'll try to add a way to pass some of this opaque
info up through netlink events. I'm thinking something like:
mac80211_nl_send_opaque_event(mac80211-handle, int data-type, u8* data, int data_len);
I will not accept this upstream.
Thanks for letting me know up front, at least.
Anyone know if there is a useful way to stream events from debugfs and/or sysfs w/out having to busy-poll
on it?
Thanks,
Ben
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
