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

[Ben Greear]

On 01/31/2015 03:38 PM, Jouni Malinen wrote:
> On Sat, Jan 31, 2015 at 03:17:57PM -0800, Ben Greear wrote:
>> 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.
>
> If there is a broken driver, that driver should be fixed.. This specific
> case does not look very helpful for avoiding issues with a specific AP
> since Interworking networks are generated for any AP.
>
>> That said, testing is interesting too..lord knows a lot of APs could use the extra
>> testing!
>
> No issues with testing in general, but even for that case, it is a bit
> difficult to see why HT or VHT would need to be disabled in this way in
> wpa_supplicant for Interworking network blocks. It would seem to make
> more sense to me to have a global parameter for disabling HT/VHT (or
> some subset of those).

I use many virtual interfaces per supplicant, and all of those settings (disable ht, etc) are
already implemented on a per-network-block case.  I just wanted to re-use that logic for
interworking so that I could easily fake a 2x2 MIMO interworking client (or /a or whatever) when
I have an /a/b/g/n 3x3 NIC acting as stations...

If I put this in a global parameter block, then I'd have to basically re-implement
all of the old ways of implementing these options?

Or, am I missing something and it isn't that hard to re-use the existing logic?

Thanks,
Ben


>
>

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