Please don't puke: Modifying Frame Version, Beacon and Probe-Response values

Adrian Chadd adrian at
Wed Jun 1 12:33:31 PDT 2016

On 1 June 2016 at 12:29, Ben Greear <greearb at> 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...


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

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.


More information about the ath10k mailing list