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

[Ben Greear]

On 06/01/2016 12:33 PM, Adrian Chadd wrote:
> On 1 June 2016 at 12:29, Ben Greear <greearb at 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 <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com