[PATCH 07/15] supplicant: Allow user-defined defaults for Interworking network blocks.

[Ben Greear]

On 01/31/2015 03:02 PM, Jouni Malinen wrote:
> On Thu, May 08, 2014 at 12:21:52PM -0700, Ben Greear wrote:
>> On 03/05/2014 04:19 PM, greearb at candelatech.com wrote:
>>> This way users can still configure the HT over-rides and some other
>>> constraints that Interworking has no interest or ability to configure.
>>
>> Jouni:  Would you re-consider this patch?
>>
>> This one, and a smaller additional patch fixes wpa_supplicant
>> so that it can do 802.11r and interworking at the same time.
>
> I don't think this type of extension of network blocks to yet another
> new not-really-a-network-profile use case is the cleanest way of doing
> this. FT support should certainly not depend on this (and well, it
> doesn't, i.e., FT for Interworking case was enabled automatically based
> on driver capabilities).

I honestly don't even remember why I had this comment about FT and interworking,
it was over a year ago that I originally worked on this...

>>> network={
>>>      interworking_defaults=1
>>>      disable_ht=0
>>>      disable_ht40=1
>>>      disable_sgi=0
>>>      ht_mcs=""
>>>      disable_max_amsdu=-1
>>>      ampdu_factor=-1
>>>      ampdu_density=-1
>>> }
>
> None of those parameters seem to make much sense for me apart from some
> very special testing purposes. Interworking networks are supposed to
> work automatically and without requiring this type of overrides, i.e.,
> driver capabilities are supposed to be enabled automatically. I cannot
> really think of a real use apart from testing something and that does
> not seem like a sufficient justification to add the extra complexity.

It is at least mostly for testing.  I guess there might be cases where someone
would work around bugs or poor performance in their driver or AP by specifying
lower rates (ie, ht_mcs) or force the station to work on HT20 instead of HT40.

That said, testing is interesting too..lord knows a lot of APs could use the extra
testing!

Thanks,
Ben

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