On 06/01/2016 12:33 PM, Adrian Chadd wrote:
On 1 June 2016 at 12:29, Ben Greear <gree...@candelatech.com> wrote:
On 06/01/2016 12:18 PM, Adrian Chadd wrote:
Hi,
Likely a mix of both. Eg, the RX filter stuff as mentioned above may
mean that you need to listen to /all/ frames for a BSS, rather than
just say data and beacon frames. If the beacon frame matching logic
checks the frame version, you need to listen to /all/ of the frames.
For power management things, it's likely none of that will work, so
you can't use things like auto-sleep based on beacon traffic / timers
/ TIM bitmap - you'd have to keep the NIC awake all the time.
I'm guessing little of this is in hardware, aside from rx filters,
so probably a few tweaks to the firmware would handle much of this...
Right.
And, if for AP mode, then the NIC is always awake anyway, right?
Right. But say, P2P/STA mode and no AP mode? Different story. (I'm
assuming he has clients AND APs..)
Yeah, I'm less sure about that. I still bet a few firmware tweaks
would resolve issues...surely the hardware is not baking a lot of
wifi frame constants into it's ROM...
Also, for ath10k chips, maybe it'll all need to be in raw mode? I
don't know what the hardware encap/decap engines will do if you try
passing it intentionally different frames like this.
Beacons and probe responses are not encrypted anyway, so probably doesn't
need to disable hw-crypt. Might be a fairly long tail of effort to
find every last place that makes some assumption on the values
though...
Thanks,
Ben
--
Ben Greear <gree...@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
