[PATCH 07/15] supplicant: Allow user-defined defaults for Interworking network blocks.
greearb at candelatech.com
Sat Jan 31 18:17:57 EST 2015
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...
> 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
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc http://www.candelatech.com
More information about the HostAP