Re: Is there a way to manually force the security protocol with IWD?

[James Prestwood <prestwoj@gmail.com>]

Hi Bryce,

On 1/30/26 9:21 AM, Bryce Johnson wrote:
> Hi James,
>
> On Fri, Jan 30, 2026 at 8:07 AM James Prestwood <prestwoj@gmail.com> wrote:
>> Hi,
>>
>> On 1/30/26 7:01 AM, Bryce Johnson wrote:
>>> Hi James
>>>
>>> On Fri, Jan 30, 2026 at 7:48 AM James Prestwood <prestwoj@gmail.com> wrote:
>>>> Hi Bryce,
>>>>
>>>> On 1/30/26 6:43 AM, Bryce Johnson wrote:
>>>>> Hi All
>>>>> We are working to get our product through wifi certification.  Our
>>>>> testing company mentioned there was several negative test cases that
>>>>> were failing where IWD was connecting anyways because it would decide
>>>>> on the security type based on the AP.  Is there a way to force IWD to
>>>>> use a security type that is different than the AP so it would fail the
>>>>> connection?  Can we disable WPA1-only connection or force WPA2 only
>>>>> connection?
>>>> There unfortunately isn't at the moment. We do have a "developer mode"
>>>> by specifying "-E" to IWD and this seems like it would fall into that
>>>> category, support would need to be added of course.
>>>>
>>>> But I'm somewhat confused (and maybe this is just poor test cases by
>>>> WFA?), why would you need to certify that IWD fails when using a
>>>> different security type than the AP? A client should not ever use a
>>>> security type the AP doesn't advertise support for... This feels like
>>>> its testing the AP, not IWD :)
>>>>
>>> I'm was requesting what test case fails and if I could get a copy of
>>> it.  The only thing I can think of is that they want to disable WPA1
>>> for example and show that the device won't connect to a WPA1 only AP.
>>> Or maybe for a product you only want to connect WPA3 and fail and not
>>> connect or not allow the AP to downgrade the connection.
>> Yeah I'd be interested in the test case.
>>> Maybe it would make sense to allow a blacklist of protocols you won't
>>> allow IWD to use?  For our product we wouldn't allow open or WEP
>>> connections for example (but we perform that check outside of IWD).
>> IWD already won't connect to a WEP network, so we're ok there. You may
>> be able to coax out some behavior with the following options:
>>
>> main.conf
>>
>> [General].ManagementFrameProtection
>>
>> network profile:
>>
>> [Settings].TransitionDisable
>>
>> [Settings].DisabledTransitionModes
>>
>> Anyways, lets hope you can get the test case. Shouldn't be too hard to
>> add some support for specific test/dev type requirements.
> Here were the test cases
> For test case 10153_1:  The test bed AP beacons with no security.  The
> test case requires the STAUT to connect with WPA2-PSK only.  Because
> of the mismatch of security protocols, the connection will fail.
>
> For test case 10165_1: The test bed AP advertises at WPA2-Personal
> only.  The test case requires the STAUT to connect with WPA3-Personal.
> Because of the mismatch of security protocols, the connection will
> also fail.

Both of these are pretty ridiculous. They want to test that a client 
chooses an incompatible security type than what the AP advertises.... 
what?!?

I know these are coming from the WFA, and not you... Its just rather 
annoying that they're so adapted to using wpa_supplicant which you can 
force to do stupid things like this. And the fact they wrote test cases 
around that is just sad.

I guess the only option if these are strictly required is to add some 
config option to the profiles that restrict what security types can be used.

>
> I got the PDFs of the test cases I can share offlist as well.  10153_1
> looks like it would not connect, but apparently hung up on the setting
> the STAUT to WPA2-PSK only.  So it looks like I need a way to restrict
> IWD from using other security types for these tests.  If you have any
> suggestions on a good way to do this, let me know.
>
> Thanks
> Bryce