Can we ignore frames with invalid BSSID in IBSS mode?

[Ben Greear]

On 09/30/2015 11:30 AM, Johannes Berg wrote:
> On Wed, 2015-09-30 at 10:20 -0700, Ben Greear wrote:
>>
>> Yes, it is a transmitter side problem, and A-MSDU on IBSS
>> is disabled by default in all ath10k firmware versions that I am aware of.
>
> Right.
>
>> I was hoping there might be a way to allow A-MSDU + IBSS + ath10k
>> to work in future kernels without applying out-of-tree
>> kernel hacks.  This would let people with appropriate firmware
>> enable IBSS + A-MSDU for added performance in cases where they
>> knew the peer could support the needed work-around.
>>
>> I don't think it is worth a lot of effort, but if it were relatively
>> simple to fix, then maybe it is worth it.
>>
>
> Had it been a receiver-side issue, then it'd seem reasonable to work
> around it. But it being a transmitter-side issue it doesn't really seem
> so - *every* possible peer would have to be adjusted, and some might
> not even be able to get adjusted (e.g. devices that have A-MSDU
> deaggregation in hardware/firmware) ...
>
> So to do that properly you'd have to advertise some sort of quirk
> vendor IE, and all that, which seems excessive given the limited use.

I was figuring the main users of this would be people rolling out
IBSS mesh networks and such, and they might have good knowledge of exactly
what peers will be used.

It is a small enough hack to the stack to just ignore the BSSID for
adhoc, and since CT firmware related patches are not accepted upstream
anyway, I guess anyone doing this is likely running custom patches
already.

Thanks,
Ben


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com