From boris at cation.de  Tue Feb  2 09:26:45 2021
From: boris at cation.de (Boris)
Date: Tue, 2 Feb 2021 15:26:45 +0100
Subject: questions with WLE900VX 7AA
Message-ID: <fbb1fbb4-8ff6-8f8a-36e9-99a2116f2658@cation.de>

Hej hostapd-list,
hej Jouni,

first let me thank you all for your nonprofit work! Great soaftware that 
many use since long time with great self-evidence. Thanks so much!!

This message contains a help request following:

For the use as a router-box, I run LEAF 
(http://leaf.zetam.org/bering-uclibc/), a dedicated small linux on a APU 
board (www.apu-board.de) equipped with a WLAN adapter Compex WLE900VX 7AA.

I got it running as 2,4GHz accesspoint and later, with some try and 
error as 5GHz accesspoint as well.

Reading from the tech specs of the WLE900VX, the adapter is introduced 
as 'dual band' module, what makes me hope to make it accessible with 2.4 
GHz _AND_ 5 GHz configuring two SSIDs within hostapd. But I did not 
manage to do so since months - with changing efforts.

Also I'm thinking about the possibility to adjust the radio power for 
the 5GHz accesspoint performs with weak range.

Now I'm at the point to ask for help: Is this adapter known? Is my idea 
feasible? Is there a description of how to do so? Or does anyone have 
such a configuration running and provide me inside in the simplest case?

Thanks very much and regards,


Boris


From greearb at candelatech.com  Tue Feb  2 09:50:13 2021
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 2 Feb 2021 06:50:13 -0800
Subject: questions with WLE900VX 7AA
In-Reply-To: <fbb1fbb4-8ff6-8f8a-36e9-99a2116f2658@cation.de>
References: <fbb1fbb4-8ff6-8f8a-36e9-99a2116f2658@cation.de>
Message-ID: <2c134277-74fb-0cee-a9a7-d43ea959a534@candelatech.com>

On 2/2/21 6:26 AM, Boris wrote:
> Hej hostapd-list,
> hej Jouni,
> 
> first let me thank you all for your nonprofit work! Great soaftware that many use since long time with great self-evidence. Thanks so much!!
> 
> This message contains a help request following:
> 
> For the use as a router-box, I run LEAF (http://leaf.zetam.org/bering-uclibc/), a dedicated small linux on a APU board (www.apu-board.de) equipped with a WLAN 
> adapter Compex WLE900VX 7AA.

That radio is dual band, but not dual concurrent, so it can be on only a single channel at a time.

It should work fine in apu2, we use it in the same chassis often.

Thanks,
Ben

> 
> I got it running as 2,4GHz accesspoint and later, with some try and error as 5GHz accesspoint as well.
> 
> Reading from the tech specs of the WLE900VX, the adapter is introduced as 'dual band' module, what makes me hope to make it accessible with 2.4 GHz _AND_ 5 GHz 
> configuring two SSIDs within hostapd. But I did not manage to do so since months - with changing efforts.
> 
> Also I'm thinking about the possibility to adjust the radio power for the 5GHz accesspoint performs with weak range.
> 
> Now I'm at the point to ask for help: Is this adapter known? Is my idea feasible? Is there a description of how to do so? Or does anyone have such a 
> configuration running and provide me inside in the simplest case?
> 
> Thanks very much and regards,
> 
> 
> Boris
> 
> _______________________________________________
> Hostap mailing list
> Hostap at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/hostap
> 


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


From boris at cation.de  Tue Feb  2 10:20:05 2021
From: boris at cation.de (Boris)
Date: Tue, 2 Feb 2021 16:20:05 +0100
Subject: questions with WLE900VX 7AA
In-Reply-To: <2c134277-74fb-0cee-a9a7-d43ea959a534@candelatech.com>
References: <fbb1fbb4-8ff6-8f8a-36e9-99a2116f2658@cation.de>
 <2c134277-74fb-0cee-a9a7-d43ea959a534@candelatech.com>
Message-ID: <28e313ae-b669-d9d0-d936-5957b6d60ebc@cation.de>

Am 02.02.21 um 15:50 schrieb Ben Greear:
> On 2/2/21 6:26 AM, Boris wrote:
>> Hej hostapd-list,
>> hej Jouni,
>>
>> first let me thank you all for your nonprofit work! Great soaftware 
>> that many use since long time with great self-evidence. Thanks so much!!
>>
>> This message contains a help request following:
>>
>> For the use as a router-box, I run LEAF 
>> (http://leaf.zetam.org/bering-uclibc/), a dedicated small linux on a 
>> APU board (www.apu-board.de) equipped with a WLAN adapter Compex 
>> WLE900VX 7AA.
> 
> That radio is dual band, but not dual concurrent, so it can be on only a 
> single channel at a time.
> 
> It should work fine in apu2, we use it in the same chassis often.
> 

Hej Ben,

thank you for your statement!

Yes, it works fine - in either the one or the other mode.

OK. So after all, I seem to have chosen not the right hardware for my plan.
Is there a suggestion what PCI-E adapter to use that supports 2,4 GHz 
and 5 GHz radio at the same time (perhaps even Wifi 6) ??

Thanks,

Boris


From greearb at candelatech.com  Tue Feb  2 10:25:02 2021
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 2 Feb 2021 07:25:02 -0800
Subject: questions with WLE900VX 7AA
In-Reply-To: <28e313ae-b669-d9d0-d936-5957b6d60ebc@cation.de>
References: <fbb1fbb4-8ff6-8f8a-36e9-99a2116f2658@cation.de>
 <2c134277-74fb-0cee-a9a7-d43ea959a534@candelatech.com>
 <28e313ae-b669-d9d0-d936-5957b6d60ebc@cation.de>
Message-ID: <3aa7ca9d-c593-db4f-f275-e4d7987f022f@candelatech.com>

On 2/2/21 7:20 AM, Boris wrote:
> Am 02.02.21 um 15:50 schrieb Ben Greear:
>> On 2/2/21 6:26 AM, Boris wrote:
>>> Hej hostapd-list,
>>> hej Jouni,
>>>
>>> first let me thank you all for your nonprofit work! Great soaftware that many use since long time with great self-evidence. Thanks so much!!
>>>
>>> This message contains a help request following:
>>>
>>> For the use as a router-box, I run LEAF (http://leaf.zetam.org/bering-uclibc/), a dedicated small linux on a APU board (www.apu-board.de) equipped with a 
>>> WLAN adapter Compex WLE900VX 7AA.
>>
>> That radio is dual band, but not dual concurrent, so it can be on only a single channel at a time.
>>
>> It should work fine in apu2, we use it in the same chassis often.
>>
> 
> Hej Ben,
> 
> thank you for your statement!
> 
> Yes, it works fine - in either the one or the other mode.
> 
> OK. So after all, I seem to have chosen not the right hardware for my plan.
> Is there a suggestion what PCI-E adapter to use that supports 2,4 GHz and 5 GHz radio at the same time (perhaps even Wifi 6) ??

None that I know about.  Just put two wle900vx in your APU2 and then you can run two bands concurrently.

There are no commercially available pcie 6E nics available that can do AP mode as far as I know.

The Intel ax210 can do 6E station mode with 5.11+ kernels.

Thanks,
Ben


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


From boris at cation.de  Tue Feb  2 11:02:17 2021
From: boris at cation.de (Boris)
Date: Tue, 2 Feb 2021 17:02:17 +0100
Subject: questions with WLE900VX 7AA
In-Reply-To: <3aa7ca9d-c593-db4f-f275-e4d7987f022f@candelatech.com>
References: <fbb1fbb4-8ff6-8f8a-36e9-99a2116f2658@cation.de>
 <2c134277-74fb-0cee-a9a7-d43ea959a534@candelatech.com>
 <28e313ae-b669-d9d0-d936-5957b6d60ebc@cation.de>
 <3aa7ca9d-c593-db4f-f275-e4d7987f022f@candelatech.com>
Message-ID: <957a900a-bcdf-e3e9-5270-43eeebd6f2b1@cation.de>

Am 02.02.21 um 16:25 schrieb Ben Greear:
> On 2/2/21 7:20 AM, Boris wrote:
>> Am 02.02.21 um 15:50 schrieb Ben Greear:
>>> On 2/2/21 6:26 AM, Boris wrote:
>>>> Hej hostapd-list,
>>>> hej Jouni,
>>>>
>>>> first let me thank you all for your nonprofit work! Great soaftware 
>>>> that many use since long time with great self-evidence. Thanks so 
>>>> much!!
>>>>
>>>> This message contains a help request following:
>>>>
>>>> For the use as a router-box, I run LEAF 
>>>> (http://leaf.zetam.org/bering-uclibc/), a dedicated small linux on a 
>>>> APU board (www.apu-board.de) equipped with a WLAN adapter Compex 
>>>> WLE900VX 7AA.
>>>
>>> That radio is dual band, but not dual concurrent, so it can be on 
>>> only a single channel at a time.
>>>
>>> It should work fine in apu2, we use it in the same chassis often.
>>>
>>
>> Hej Ben,
>>
>> thank you for your statement!
>>
>> Yes, it works fine - in either the one or the other mode.
>>
>> OK. So after all, I seem to have chosen not the right hardware for my 
>> plan.
>> Is there a suggestion what PCI-E adapter to use that supports 2,4 GHz 
>> and 5 GHz radio at the same time (perhaps even Wifi 6) ??
> 
> None that I know about.? Just put two wle900vx in your APU2 and then you 
> can run two bands concurrently.
> 
> There are no commercially available pcie 6E nics available that can do 
> AP mode as far as I know.
> 
> The Intel ax210 can do 6E station mode with 5.11+ kernels.

Thank you again! I also had the idea with two adapters but the 
APU-manual describes the two other slots (J13 and J14) explicitely as 
_not_ suitable for wifi adapters (if I understand correst):

J13 mSATA miniPCI express
/ This slot can be used for mSATA SSD, or 3G/LTE modem (USB based).
No PCI express = no wifi. Connects to SIM J2.

J14 miniPCI express
/ This slot can be used for 3G/LTE modems (USB based). No PCI express
= no wifi. Connects to SIM J1.

J15 miniPCI express
/ This slot includes PCI express, and is intended for wifi modules. No 
SIM connected.

Did you try with two adapters although?

Boris


From greearb at candelatech.com  Tue Feb  2 11:04:45 2021
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 2 Feb 2021 08:04:45 -0800
Subject: questions with WLE900VX 7AA
In-Reply-To: <957a900a-bcdf-e3e9-5270-43eeebd6f2b1@cation.de>
References: <fbb1fbb4-8ff6-8f8a-36e9-99a2116f2658@cation.de>
 <2c134277-74fb-0cee-a9a7-d43ea959a534@candelatech.com>
 <28e313ae-b669-d9d0-d936-5957b6d60ebc@cation.de>
 <3aa7ca9d-c593-db4f-f275-e4d7987f022f@candelatech.com>
 <957a900a-bcdf-e3e9-5270-43eeebd6f2b1@cation.de>
Message-ID: <162fb351-360c-98c5-c60b-6ba9d0f8339e@candelatech.com>

On 2/2/21 8:02 AM, Boris wrote:
> Am 02.02.21 um 16:25 schrieb Ben Greear:
>> On 2/2/21 7:20 AM, Boris wrote:
>>> Am 02.02.21 um 15:50 schrieb Ben Greear:
>>>> On 2/2/21 6:26 AM, Boris wrote:
>>>>> Hej hostapd-list,
>>>>> hej Jouni,
>>>>>
>>>>> first let me thank you all for your nonprofit work! Great soaftware that many use since long time with great self-evidence. Thanks so much!!
>>>>>
>>>>> This message contains a help request following:
>>>>>
>>>>> For the use as a router-box, I run LEAF (http://leaf.zetam.org/bering-uclibc/), a dedicated small linux on a APU board (www.apu-board.de) equipped with a 
>>>>> WLAN adapter Compex WLE900VX 7AA.
>>>>
>>>> That radio is dual band, but not dual concurrent, so it can be on only a single channel at a time.
>>>>
>>>> It should work fine in apu2, we use it in the same chassis often.
>>>>
>>>
>>> Hej Ben,
>>>
>>> thank you for your statement!
>>>
>>> Yes, it works fine - in either the one or the other mode.
>>>
>>> OK. So after all, I seem to have chosen not the right hardware for my plan.
>>> Is there a suggestion what PCI-E adapter to use that supports 2,4 GHz and 5 GHz radio at the same time (perhaps even Wifi 6) ??
>>
>> None that I know about.? Just put two wle900vx in your APU2 and then you can run two bands concurrently.
>>
>> There are no commercially available pcie 6E nics available that can do AP mode as far as I know.
>>
>> The Intel ax210 can do 6E station mode with 5.11+ kernels.
> 
> Thank you again! I also had the idea with two adapters but the APU-manual describes the two other slots (J13 and J14) explicitely as _not_ suitable for wifi 
> adapters (if I understand correst):
> 
> J13 mSATA miniPCI express
> / This slot can be used for mSATA SSD, or 3G/LTE modem (USB based).
> No PCI express = no wifi. Connects to SIM J2.
> 
> J14 miniPCI express
> / This slot can be used for 3G/LTE modems (USB based). No PCI express
> = no wifi. Connects to SIM J1.
> 
> J15 miniPCI express
> / This slot includes PCI express, and is intended for wifi modules. No SIM connected.
> 
> Did you try with two adapters although?

We use the apu2 board that has 2 mini-pcie slots plus an msata.  Your model may only support
a single pcie nic.

Thanks,
Ben

> 
> Boris
> 


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


From boris at cation.de  Tue Feb  2 13:50:19 2021
From: boris at cation.de (Boris)
Date: Tue, 2 Feb 2021 19:50:19 +0100
Subject: [closed] Re: questions with WLE900VX 7AA
In-Reply-To: <162fb351-360c-98c5-c60b-6ba9d0f8339e@candelatech.com>
References: <fbb1fbb4-8ff6-8f8a-36e9-99a2116f2658@cation.de>
 <2c134277-74fb-0cee-a9a7-d43ea959a534@candelatech.com>
 <28e313ae-b669-d9d0-d936-5957b6d60ebc@cation.de>
 <3aa7ca9d-c593-db4f-f275-e4d7987f022f@candelatech.com>
 <957a900a-bcdf-e3e9-5270-43eeebd6f2b1@cation.de>
 <162fb351-360c-98c5-c60b-6ba9d0f8339e@candelatech.com>
Message-ID: <8b20ba2b-748f-05cc-91b9-1d9e9f6da5bf@cation.de>

Am 02.02.21 um 17:04 schrieb Ben Greear:
> On 2/2/21 8:02 AM, Boris wrote:
>> Am 02.02.21 um 16:25 schrieb Ben Greear:
>>> On 2/2/21 7:20 AM, Boris wrote:
>>>> Am 02.02.21 um 15:50 schrieb Ben Greear:
>>>>> On 2/2/21 6:26 AM, Boris wrote:
>>>>>> Hej hostapd-list,
>>>>>> hej Jouni,
>>>>>>
>>>>>> first let me thank you all for your nonprofit work! Great 
>>>>>> soaftware that many use since long time with great self-evidence. 
>>>>>> Thanks so much!!
>>>>>>
>>>>>> This message contains a help request following:
>>>>>>
>>>>>> For the use as a router-box, I run LEAF 
>>>>>> (http://leaf.zetam.org/bering-uclibc/), a dedicated small linux on 
>>>>>> a APU board (www.apu-board.de) equipped with a WLAN adapter Compex 
>>>>>> WLE900VX 7AA.
>>>>>
>>>>> That radio is dual band, but not dual concurrent, so it can be on 
>>>>> only a single channel at a time.
>>>>>
>>>>> It should work fine in apu2, we use it in the same chassis often.
>>>>>
>>>>
>>>> Hej Ben,
>>>>
>>>> thank you for your statement!
>>>>
>>>> Yes, it works fine - in either the one or the other mode.
>>>>
>>>> OK. So after all, I seem to have chosen not the right hardware for 
>>>> my plan.
>>>> Is there a suggestion what PCI-E adapter to use that supports 2,4 
>>>> GHz and 5 GHz radio at the same time (perhaps even Wifi 6) ??
>>>
>>> None that I know about.? Just put two wle900vx in your APU2 and then 
>>> you can run two bands concurrently.
>>>
>>> There are no commercially available pcie 6E nics available that can 
>>> do AP mode as far as I know.
>>>
>>> The Intel ax210 can do 6E station mode with 5.11+ kernels.
>>
>> Thank you again! I also had the idea with two adapters but the 
>> APU-manual describes the two other slots (J13 and J14) explicitely as 
>> _not_ suitable for wifi adapters (if I understand correst):
>>
>> J13 mSATA miniPCI express
>> / This slot can be used for mSATA SSD, or 3G/LTE modem (USB based).
>> No PCI express = no wifi. Connects to SIM J2.
>>
>> J14 miniPCI express
>> / This slot can be used for 3G/LTE modems (USB based). No PCI express
>> = no wifi. Connects to SIM J1.
>>
>> J15 miniPCI express
>> / This slot includes PCI express, and is intended for wifi modules. No 
>> SIM connected.
>>
>> Did you try with two adapters although?
> 
> We use the apu2 board that has 2 mini-pcie slots plus an msata.? Your 
> model may only support
> a single pcie nic.
> 

OK. I'll see...

Thanks, over and out!

Boris



From matthias.may at westermo.com  Wed Feb  3 02:27:46 2021
From: matthias.may at westermo.com (Matthias May)
Date: Wed, 3 Feb 2021 08:27:46 +0100
Subject: [closed] Re: questions with WLE900VX 7AA
In-Reply-To: <8b20ba2b-748f-05cc-91b9-1d9e9f6da5bf@cation.de>
References: <fbb1fbb4-8ff6-8f8a-36e9-99a2116f2658@cation.de>
 <2c134277-74fb-0cee-a9a7-d43ea959a534@candelatech.com>
 <28e313ae-b669-d9d0-d936-5957b6d60ebc@cation.de>
 <3aa7ca9d-c593-db4f-f275-e4d7987f022f@candelatech.com>
 <957a900a-bcdf-e3e9-5270-43eeebd6f2b1@cation.de>
 <162fb351-360c-98c5-c60b-6ba9d0f8339e@candelatech.com>
 <8b20ba2b-748f-05cc-91b9-1d9e9f6da5bf@cation.de>
Message-ID: <130e9983-4cde-b7de-8cb9-43ee3674f44a@westermo.com>

On 02/02/2021 19:50, Boris wrote:
> Am 02.02.21 um 17:04 schrieb Ben Greear:
>> On 2/2/21 8:02 AM, Boris wrote:
>>> Am 02.02.21 um 16:25 schrieb Ben Greear:
>>>> On 2/2/21 7:20 AM, Boris wrote:
>>>>> Am 02.02.21 um 15:50 schrieb Ben Greear:
>>>>>> On 2/2/21 6:26 AM, Boris wrote:
>>>>>>> Hej hostapd-list,
>>>>>>> hej Jouni,
>>>>>>>
>>>>>>> first let me thank you all for your nonprofit work! Great soaftware that many use since long time with great
>>>>>>> self-evidence. Thanks so much!!
>>>>>>>
>>>>>>> This message contains a help request following:
>>>>>>>
>>>>>>> For the use as a router-box, I run LEAF
>>>>>>> (https://urldefense.com/v3/__http://leaf.zetam.org/bering-uclibc/__;!!I9LPvj3b!VUEvr93lqRO_aDPSnAcXVeGvtLxx5S_cW6gUiHWguMQy8HR3t0b60hiYke4pfVj5Vts$
>>>>>>> ), a dedicated small linux on a APU board
>>>>>>> (https://urldefense.com/v3/__http://www.apu-board.de__;!!I9LPvj3b!VUEvr93lqRO_aDPSnAcXVeGvtLxx5S_cW6gUiHWguMQy8HR3t0b60hiYke4p5s9zfMw$
>>>>>>> ) equipped with a WLAN adapter Compex WLE900VX 7AA.
>>>>>>
>>>>>> That radio is dual band, but not dual concurrent, so it can be on only a single channel at a time.
>>>>>>
>>>>>> It should work fine in apu2, we use it in the same chassis often.
>>>>>>
>>>>>
>>>>> Hej Ben,
>>>>>
>>>>> thank you for your statement!
>>>>>
>>>>> Yes, it works fine - in either the one or the other mode.
>>>>>
>>>>> OK. So after all, I seem to have chosen not the right hardware for my plan.
>>>>> Is there a suggestion what PCI-E adapter to use that supports 2,4 GHz and 5 GHz radio at the same time (perhaps
>>>>> even Wifi 6) ??
>>>>
>>>> None that I know about.? Just put two wle900vx in your APU2 and then you can run two bands concurrently.
>>>>
>>>> There are no commercially available pcie 6E nics available that can do AP mode as far as I know.
>>>>
>>>> The Intel ax210 can do 6E station mode with 5.11+ kernels.
>>>
>>> Thank you again! I also had the idea with two adapters but the APU-manual describes the two other slots (J13 and J14)
>>> explicitely as _not_ suitable for wifi adapters (if I understand correst):
>>>
>>> J13 mSATA miniPCI express
>>> / This slot can be used for mSATA SSD, or 3G/LTE modem (USB based).
>>> No PCI express = no wifi. Connects to SIM J2.
>>>
>>> J14 miniPCI express
>>> / This slot can be used for 3G/LTE modems (USB based). No PCI express
>>> = no wifi. Connects to SIM J1.
>>>
>>> J15 miniPCI express
>>> / This slot includes PCI express, and is intended for wifi modules. No SIM connected.
>>>
>>> Did you try with two adapters although?
>>
>> We use the apu2 board that has 2 mini-pcie slots plus an msata.? Your model may only support
>> a single pcie nic.
>>
> 
> OK. I'll see...
> 
> Thanks, over and out!
> 
> Boris
> 
> 
> _______________________________________________
> Hostap mailing list
> Hostap at lists.infradead.org
> https://urldefense.com/v3/__http://lists.infradead.org/mailman/listinfo/hostap__;!!I9LPvj3b!VUEvr93lqRO_aDPSnAcXVeGvtLxx5S_cW6gUiHWguMQy8HR3t0b60hiYke4pdIDGOGs$
> 


PCengines itself has a list of all models here:
https://pcengines.ch/apu2.htm

APU2: J12 mSATA,                   J13 full miniPCIe (with SIM), J14 full miniPCIe (no SIM)
APU3: J14 USB or mSATA,            J15 USB only (with SIM),      J16 full miniPCIe (no SIM)
APU4: J13 USB or mSATA (with SIM), J14 USB only (with SIM),      J15 full miniPCIe (no SIM)

Unless you are using USB connected devices you probably want to go with the APU2.

BR
Matthias


From boris at cation.de  Wed Feb  3 02:37:33 2021
From: boris at cation.de (Boris)
Date: Wed, 3 Feb 2021 08:37:33 +0100
Subject: [closed] Re: questions with WLE900VX 7AA
In-Reply-To: <130e9983-4cde-b7de-8cb9-43ee3674f44a@westermo.com>
References: <fbb1fbb4-8ff6-8f8a-36e9-99a2116f2658@cation.de>
 <2c134277-74fb-0cee-a9a7-d43ea959a534@candelatech.com>
 <28e313ae-b669-d9d0-d936-5957b6d60ebc@cation.de>
 <3aa7ca9d-c593-db4f-f275-e4d7987f022f@candelatech.com>
 <957a900a-bcdf-e3e9-5270-43eeebd6f2b1@cation.de>
 <162fb351-360c-98c5-c60b-6ba9d0f8339e@candelatech.com>
 <8b20ba2b-748f-05cc-91b9-1d9e9f6da5bf@cation.de>
 <130e9983-4cde-b7de-8cb9-43ee3674f44a@westermo.com>
Message-ID: <190eb84e-8bff-37eb-2a84-082dcf9dae72@cation.de>

Am 03.02.21 um 08:27 schrieb Matthias May:
> On 02/02/2021 19:50, Boris wrote:
>> Am 02.02.21 um 17:04 schrieb Ben Greear:
>>> On 2/2/21 8:02 AM, Boris wrote:
>>>> Am 02.02.21 um 16:25 schrieb Ben Greear:
>>>>> On 2/2/21 7:20 AM, Boris wrote:
>>>>>> Am 02.02.21 um 15:50 schrieb Ben Greear:
>>>>>>> On 2/2/21 6:26 AM, Boris wrote:
>>>>>>>> Hej hostapd-list,
>>>>>>>> hej Jouni,
>>>>>>>>
>>>>>>>> first let me thank you all for your nonprofit work! Great soaftware that many use since long time with great
>>>>>>>> self-evidence. Thanks so much!!
>>>>>>>>
>>>>>>>> This message contains a help request following:
>>>>>>>>
>>>>>>>> For the use as a router-box, I run LEAF
>>>>>>>> (https://urldefense.com/v3/__http://leaf.zetam.org/bering-uclibc/__;!!I9LPvj3b!VUEvr93lqRO_aDPSnAcXVeGvtLxx5S_cW6gUiHWguMQy8HR3t0b60hiYke4pfVj5Vts$
>>>>>>>> ), a dedicated small linux on a APU board
>>>>>>>> (https://urldefense.com/v3/__http://www.apu-board.de__;!!I9LPvj3b!VUEvr93lqRO_aDPSnAcXVeGvtLxx5S_cW6gUiHWguMQy8HR3t0b60hiYke4p5s9zfMw$
>>>>>>>> ) equipped with a WLAN adapter Compex WLE900VX 7AA.
>>>>>>>
>>>>>>> That radio is dual band, but not dual concurrent, so it can be on only a single channel at a time.
>>>>>>>
>>>>>>> It should work fine in apu2, we use it in the same chassis often.
>>>>>>>
>>>>>>
>>>>>> Hej Ben,
>>>>>>
>>>>>> thank you for your statement!
>>>>>>
>>>>>> Yes, it works fine - in either the one or the other mode.
>>>>>>
>>>>>> OK. So after all, I seem to have chosen not the right hardware for my plan.
>>>>>> Is there a suggestion what PCI-E adapter to use that supports 2,4 GHz and 5 GHz radio at the same time (perhaps
>>>>>> even Wifi 6) ??
>>>>>
>>>>> None that I know about.? Just put two wle900vx in your APU2 and then you can run two bands concurrently.
>>>>>
>>>>> There are no commercially available pcie 6E nics available that can do AP mode as far as I know.
>>>>>
>>>>> The Intel ax210 can do 6E station mode with 5.11+ kernels.
>>>>
>>>> Thank you again! I also had the idea with two adapters but the APU-manual describes the two other slots (J13 and J14)
>>>> explicitely as _not_ suitable for wifi adapters (if I understand correst):
>>>>
>>>> J13 mSATA miniPCI express
>>>> / This slot can be used for mSATA SSD, or 3G/LTE modem (USB based).
>>>> No PCI express = no wifi. Connects to SIM J2.
>>>>
>>>> J14 miniPCI express
>>>> / This slot can be used for 3G/LTE modems (USB based). No PCI express
>>>> = no wifi. Connects to SIM J1.
>>>>
>>>> J15 miniPCI express
>>>> / This slot includes PCI express, and is intended for wifi modules. No SIM connected.
>>>>
>>>> Did you try with two adapters although?
>>>
>>> We use the apu2 board that has 2 mini-pcie slots plus an msata.? Your model may only support
>>> a single pcie nic.
>>>
>>
>> OK. I'll see...
>>
>> Thanks, over and out!
>>
>> Boris
>>
>>
>> _______________________________________________
>> Hostap mailing list
>> Hostap at lists.infradead.org
>> https://urldefense.com/v3/__http://lists.infradead.org/mailman/listinfo/hostap__;!!I9LPvj3b!VUEvr93lqRO_aDPSnAcXVeGvtLxx5S_cW6gUiHWguMQy8HR3t0b60hiYke4pdIDGOGs$
>>
> 
> 
> PCengines itself has a list of all models here:
> https://pcengines.ch/apu2.htm
> 
> APU2: J12 mSATA,                   J13 full miniPCIe (with SIM), J14 full miniPCIe (no SIM)
> APU3: J14 USB or mSATA,            J15 USB only (with SIM),      J16 full miniPCIe (no SIM)
> APU4: J13 USB or mSATA (with SIM), J14 USB only (with SIM),      J15 full miniPCIe (no SIM)
> 
> Unless you are using USB connected devices you probably want to go with the APU2.
> 

Thanks Matthias,

I am using a APU4 and I think I'll ask Pascal Dornier (Mr. PC-Engines) 
what it's about: PCI-Express slot without PCI express???

Dank und Gr??e,


Boris


From matthias.may at westermo.com  Wed Feb  3 03:02:15 2021
From: matthias.may at westermo.com (Matthias May)
Date: Wed, 3 Feb 2021 09:02:15 +0100
Subject: [closed] Re: questions with WLE900VX 7AA
In-Reply-To: <190eb84e-8bff-37eb-2a84-082dcf9dae72@cation.de>
References: <fbb1fbb4-8ff6-8f8a-36e9-99a2116f2658@cation.de>
 <2c134277-74fb-0cee-a9a7-d43ea959a534@candelatech.com>
 <28e313ae-b669-d9d0-d936-5957b6d60ebc@cation.de>
 <3aa7ca9d-c593-db4f-f275-e4d7987f022f@candelatech.com>
 <957a900a-bcdf-e3e9-5270-43eeebd6f2b1@cation.de>
 <162fb351-360c-98c5-c60b-6ba9d0f8339e@candelatech.com>
 <8b20ba2b-748f-05cc-91b9-1d9e9f6da5bf@cation.de>
 <130e9983-4cde-b7de-8cb9-43ee3674f44a@westermo.com>
 <190eb84e-8bff-37eb-2a84-082dcf9dae72@cation.de>
Message-ID: <8c2a5f46-1b38-0a6c-51b0-2d5b18596c78@westermo.com>

On 03/02/2021 08:37, Boris wrote:
> Am 03.02.21 um 08:27 schrieb Matthias May:
>> On 02/02/2021 19:50, Boris wrote:
>>> Am 02.02.21 um 17:04 schrieb Ben Greear:
>>>> On 2/2/21 8:02 AM, Boris wrote:
>>>>> Am 02.02.21 um 16:25 schrieb Ben Greear:
>>>>>> On 2/2/21 7:20 AM, Boris wrote:
>>>>>>> Am 02.02.21 um 15:50 schrieb Ben Greear:
>>>>>>>> On 2/2/21 6:26 AM, Boris wrote:
>>>>>>>>> Hej hostapd-list,
>>>>>>>>> hej Jouni,
>>>>>>>>>
>>>>>>>>> first let me thank you all for your nonprofit work! Great soaftware that many use since long time with great
>>>>>>>>> self-evidence. Thanks so much!!
>>>>>>>>>
>>>>>>>>> This message contains a help request following:
>>>>>>>>>
>>>>>>>>> For the use as a router-box, I run LEAF
>>>>>>>>> (https://urldefense.com/v3/__http://leaf.zetam.org/bering-uclibc/__;!!I9LPvj3b!VUEvr93lqRO_aDPSnAcXVeGvtLxx5S_cW6gUiHWguMQy8HR3t0b60hiYke4pfVj5Vts$
>>>>>>>>>
>>>>>>>>> ), a dedicated small linux on a APU board
>>>>>>>>> (https://urldefense.com/v3/__http://www.apu-board.de__;!!I9LPvj3b!VUEvr93lqRO_aDPSnAcXVeGvtLxx5S_cW6gUiHWguMQy8HR3t0b60hiYke4p5s9zfMw$
>>>>>>>>>
>>>>>>>>> ) equipped with a WLAN adapter Compex WLE900VX 7AA.
>>>>>>>>
>>>>>>>> That radio is dual band, but not dual concurrent, so it can be on only a single channel at a time.
>>>>>>>>
>>>>>>>> It should work fine in apu2, we use it in the same chassis often.
>>>>>>>>
>>>>>>>
>>>>>>> Hej Ben,
>>>>>>>
>>>>>>> thank you for your statement!
>>>>>>>
>>>>>>> Yes, it works fine - in either the one or the other mode.
>>>>>>>
>>>>>>> OK. So after all, I seem to have chosen not the right hardware for my plan.
>>>>>>> Is there a suggestion what PCI-E adapter to use that supports 2,4 GHz and 5 GHz radio at the same time (perhaps
>>>>>>> even Wifi 6) ??
>>>>>>
>>>>>> None that I know about.? Just put two wle900vx in your APU2 and then you can run two bands concurrently.
>>>>>>
>>>>>> There are no commercially available pcie 6E nics available that can do AP mode as far as I know.
>>>>>>
>>>>>> The Intel ax210 can do 6E station mode with 5.11+ kernels.
>>>>>
>>>>> Thank you again! I also had the idea with two adapters but the APU-manual describes the two other slots (J13 and J14)
>>>>> explicitely as _not_ suitable for wifi adapters (if I understand correst):
>>>>>
>>>>> J13 mSATA miniPCI express
>>>>> / This slot can be used for mSATA SSD, or 3G/LTE modem (USB based).
>>>>> No PCI express = no wifi. Connects to SIM J2.
>>>>>
>>>>> J14 miniPCI express
>>>>> / This slot can be used for 3G/LTE modems (USB based). No PCI express
>>>>> = no wifi. Connects to SIM J1.
>>>>>
>>>>> J15 miniPCI express
>>>>> / This slot includes PCI express, and is intended for wifi modules. No SIM connected.
>>>>>
>>>>> Did you try with two adapters although?
>>>>
>>>> We use the apu2 board that has 2 mini-pcie slots plus an msata.? Your model may only support
>>>> a single pcie nic.
>>>>
>>>
>>> OK. I'll see...
>>>
>>> Thanks, over and out!
>>>
>>> Boris
>>>
>>>
>>> _______________________________________________
>>> Hostap mailing list
>>> Hostap at lists.infradead.org
>>> https://urldefense.com/v3/__http://lists.infradead.org/mailman/listinfo/hostap__;!!I9LPvj3b!VUEvr93lqRO_aDPSnAcXVeGvtLxx5S_cW6gUiHWguMQy8HR3t0b60hiYke4pdIDGOGs$
>>>
>>>
>>
>>
>> PCengines itself has a list of all models here:
>> https://urldefense.com/v3/__https://pcengines.ch/apu2.htm__;!!I9LPvj3b!Um3_4cXZIfkuoATHpy32axk3LmqcGsOqIDPQjjuf-FccchE1S82A43-YKqU2A2cYvOw$
>>
>> APU2: J12 mSATA,?????????????????? J13 full miniPCIe (with SIM), J14 full miniPCIe (no SIM)
>> APU3: J14 USB or mSATA,??????????? J15 USB only (with SIM),????? J16 full miniPCIe (no SIM)
>> APU4: J13 USB or mSATA (with SIM), J14 USB only (with SIM),????? J15 full miniPCIe (no SIM)
>>
>> Unless you are using USB connected devices you probably want to go with the APU2.
>>
> 
> Thanks Matthias,
> 
> I am using a APU4 and I think I'll ask Pascal Dornier (Mr. PC-Engines) what it's about: PCI-Express slot without PCI
> express???
> 
> Dank und Gr??e,
> 
> 
> Boris
> 
> _______________________________________________
> Hostap mailing list
> Hostap at lists.infradead.org
> https://urldefense.com/v3/__http://lists.infradead.org/mailman/listinfo/hostap__;!!I9LPvj3b!Um3_4cXZIfkuoATHpy32axk3LmqcGsOqIDPQjjuf-FccchE1S82A43-YKqU2W2Fi8QA$
> 

This is quite standard practice.
The connector is the same but you can have different things on it:
mSATA, USB, PCIe, SIM.
Connecting only the USB and SIM is useful for LTE-modems that are almost always connected via USB.
This is the intention of the APU boards >2.
The documentation of the boards clearly states what you can connect on each slot.

M.2 goes even further, but denotes via the notching what type of lines are connected.
E.g SSDs are usually attached via M.2-M and LTE devices via M.2-B.
But even then not all lines have to be connected.
You may encounter an M.2-B with only USB and SIM.

BR
Matthias


From diabonas at archlinux.org  Wed Feb  3 11:51:02 2021
From: diabonas at archlinux.org (Jonas Witschel)
Date: Wed, 3 Feb 2021 17:51:02 +0100
Subject: Buffer overflow in p2p_copy_client_info (CVE-2021-0326)
Message-ID: <20210203165102.rx2y3jbllrnyvr5g@archlinux.org>

Hi,

according to the recently released Android Security Bulletin?February 2021 [1],
wpa_supplicant as used by Android is affected by a buffer overflow in
p2p_copy_client_info. The issue is deemed critical by Google and given the CVE
identifier CVE-2021-0326, a patch is available at [2].

However, I could not find this patch in the current master branch of the
upstream hostapd repository at w1.fi [3]. Should it be applied upstream as
well?

Best regards,
Jonas

[1] https://source.android.com/security/bulletin/2021-02-01
[2] https://android.googlesource.com/platform/external/wpa_supplicant_8/+/0b60cb210510c68871c8d735285bc4915de3bd80%5E!
[3] https://w1.fi/cgit/hostap/tree/src/p2p/p2p.c
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/hostap/attachments/20210203/7ba20368/attachment.sig>

From j at w1.fi  Wed Feb  3 18:05:14 2021
From: j at w1.fi (Jouni Malinen)
Date: Thu, 4 Feb 2021 01:05:14 +0200
Subject: wpa_supplicant P2P group information processing vulnerability
Message-ID: <20210203230514.GA431400@w1.fi>

Published: February 4, 2021
Latest version available from: https://w1.fi/security/2020-2/


Vulnerability

A vulnerability was discovered in how wpa_supplicant processing P2P
(Wi-Fi Direct) group information from active group owners. The actual
parsing of that information validates field lengths appropriately, but
processing of the parsed information misses a length check when storing
a copy of the secondary device types. This can result in writing
attacker controlled data into the peer entry after the area assigned for
the secondary device type. The overflow can result in corrupting
pointers for heap allocations. This can result in an attacker within
radio range of the device running P2P discovery being able to cause
unexpected behavior, including termination of the wpa_supplicant process
and potentially arbitrary code execution.


Vulnerable versions/configurations

wpa_supplicant v1.0-v2.9 with CONFIG_P2P build option enabled

An attacker (or a system controlled by the attacker) needs to be within
radio range of the vulnerable system to send a suitably constructed
management frame that triggers a P2P peer device information to be
created or updated.


Acknowledgments

This issue was discovered by fuzz testing of wpa_supplicant by Google's
OSS-Fuzz.

Possible mitigation steps

- Merge the following commit to wpa_supplicant and rebuild it:

  P2P: Fix copying of secondary device types for P2P group client
  
  This patch is available from https://w1.fi/security/2020-2/
  
- Update to wpa_supplicant v2.10 or newer, once available

- Disable P2P (control interface command "P2P_SET disabled 1" or
  "p2p_disabled=1" in (each, if multiple interfaces used) wpa_supplicant
  configuration file)

- Disable P2P from the build (remove CONFIG_P2P=y)

-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Wed Feb  3 18:16:16 2021
From: j at w1.fi (Jouni Malinen)
Date: Thu, 4 Feb 2021 01:16:16 +0200
Subject: Buffer overflow in p2p_copy_client_info (CVE-2021-0326)
In-Reply-To: <20210203165102.rx2y3jbllrnyvr5g@archlinux.org>
References: <20210203165102.rx2y3jbllrnyvr5g@archlinux.org>
Message-ID: <20210203231616.GA431856@w1.fi>

On Wed, Feb 03, 2021 at 05:51:02PM +0100, Jonas Witschel wrote:
> according to the recently released Android Security Bulletin?February 2021 [1],
> wpa_supplicant as used by Android is affected by a buffer overflow in
> p2p_copy_client_info. The issue is deemed critical by Google and given the CVE
> identifier CVE-2021-0326, a patch is available at [2].
> 
> However, I could not find this patch in the current master branch of the
> upstream hostapd repository at w1.fi [3]. Should it be applied upstream as
> well?

Yes, it is there now:
https://w1.fi/cgit/hostap/commit/?id=947272febe24a8f0ea828b5b2f35f13c3821901e

-- 
Jouni Malinen                                            PGP id EFC895FA


From piotr.lobacz at softgent.com  Thu Feb  4 06:51:40 2021
From: piotr.lobacz at softgent.com (Piotr Lobacz)
Date: Thu, 4 Feb 2021 11:51:40 +0000
Subject: wpa_supplicant with hotspot 2.0 support and network manager on
 rtl8192fs wireless wifi
Message-ID: <AM0PR10MB32044D6E8FC612806A207CC0E4B39@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>

Hi all,
i have compiled wpa_supplicant 2.9 version together with network manager 1.22 on my px30 arm board. The hotspot is being made with nmcli command like this:

nmcli device wifi hotspot password 12345678 ssid softgent

and i can see that the hotspot has been put on using this command:

nmcli d show wlan0

GENERAL.DEVICE:                         wlan0
GENERAL.TYPE:                           wifi
GENERAL.HWADDR:                         74:4C:A1:FF:DC:FD
GENERAL.MTU:                            1500
GENERAL.STATE:                          100 (connected)
GENERAL.CONNECTION:                     Hotspot
GENERAL.CON-PATH:                       /org/freedesktop/NetworkManager/ActiveConnection/2
IP4.ADDRESS[1]:                         10.42.0.1/24
IP4.GATEWAY:                            --
IP4.ROUTE[1]:                           dst = 10.42.0.0/24, nh = 0.0.0.0, mt = 600
IP6.ADDRESS[1]:                         fe80::764c:a1ff:feff:dcfd/64
IP6.GATEWAY:                            --
IP6.ROUTE[1]:                           dst = fe80::/64, nh = ::, mt = 256
IP6.ROUTE[2]:                           dst = ff00::/8, nh = ::, mt = 256


but, if i try to connect thi this hotspot from my mobile i get an error:

Feb 04 11:04:16 px30-64 wpa_supplicant[241]: WPA: EAPOL-Key MIC using HMAC-SHA1
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: WPA: 6e:95:7c:a0:99:3d WPA_PTK entering state PTKCALCNEGOTIATING2
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: WPA: 6e:95:7c:a0:99:3d WPA_PTK entering state PTKINITNEGOTIATING
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: hostapd_logger: STA 6e:95:7c:a0:99:3d - sending 3/4 msg of 4-Way Handshake
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: WPA: Send EAPOL(version=2 secure=1 mic=1 ack=1 install=1 pairwise=1 kde_len=50 keyidx=1 encr=1)
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: WPA: Replay Counter - hexdump(len=8): 00 00 00 00 00 00 00 02
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: Plaintext EAPOL-Key Key Data - hexdump(len=64): [REMOVED]
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: WPA: Encrypt Key Data using AES-WRAP (KEK length 16)
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: WPA: EAPOL-Key MIC using HMAC-SHA1
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: WPA: Use EAPOL-Key timeout of 1000 ms (retry counter 1)
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: nl80211: Drv Event 20 (NL80211_CMD_DEL_STATION) received for wlan0
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: nl80211: Delete station 6e:95:7c:a0:99:3d
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: wlan0: Event DISASSOC (1) received
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: wlan0: Disassociation notification
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: wlan0:  * reason 0 (UNKNOWN)
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: wlan0:  * address 6e:95:7c:a0:99:3d
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: Disassociation frame IE(s) - hexdump(len=0): [NULL]
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: hostapd_logger: STA 6e:95:7c:a0:99:3d - disassociated
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: hostapd_logger: STA 6e:95:7c:a0:99:3d - event 2 notification

So i see that the connection is being made and for some reason it fails, due to this EAPOL-Key timeout i think.

BR
Piotr
[https://softgent.com/wp-content/uploads/2020/01/Zasob-14.png]<https://www.softgent.com>

Softgent Sp. z o.o., Budowlanych 31d, 80-298 Gdansk, POLAND

KRS: 0000674406, NIP: 9581679801, REGON: 367090912

www.softgent.com

S?d Rejonowy Gda?sk-P??noc w Gda?sku, VII Wydzia? Gospodarczy Krajowego Rejestru S?dowego

KRS 0000674406, Kapita? zak?adowy: 25 000,00 z? wp?acony w ca?o?ci.


From raphael.melotte at mind.be  Thu Feb  4 10:01:04 2021
From: raphael.melotte at mind.be (=?UTF-8?q?Rapha=C3=ABl=20M=C3=A9lotte?=)
Date: Thu,  4 Feb 2021 16:01:04 +0100
Subject: [PATCH v2 1/2] wps: reconfigure credentials on reload
In-Reply-To: <20201218105028.12775-2-raphael.melotte@mind.be>
References: <20201218105028.12775-2-raphael.melotte@mind.be>
Message-ID: <20210204150104.6847-1-raphael.melotte@mind.be>

When new credentials are configured and hostapd is reconfigured using
SIGHUP (or reload on the ctrl_iface), also update the wps credentials.

Before these changes, when WPS is triggered the registar always serves
the credentials that were configured when hostapd started.

Signed-off-by: Rapha?l M?lotte <raphael.melotte at mind.be>

---
Changes v1 -> v2:
  - add missing ifdef for CONFIG_WEP

Signed-off-by: Rapha?l M?lotte <raphael.melotte at mind.be>
---
 src/ap/wps_hostapd.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/ap/wps_hostapd.c b/src/ap/wps_hostapd.c
index 8b1dad518..ff942a67b 100644
--- a/src/ap/wps_hostapd.c
+++ b/src/ap/wps_hostapd.c
@@ -1471,6 +1471,7 @@ void hostapd_update_wps(struct hostapd_data *hapd)
 		wpa_snprintf_hex((char *) wps->network_key, 2 * PMK_LEN + 1,
 				 conf->ssid.wpa_psk->psk, PMK_LEN);
 		wps->network_key_len = 2 * PMK_LEN;
+#ifdef CONFIG_WEP
 	} else if (conf->ssid.wep.keys_set && conf->ssid.wep.key[0]) {
 		wps->network_key = os_malloc(conf->ssid.wep.len[0]);
 		if (wps->network_key == NULL)
@@ -1478,6 +1479,7 @@ void hostapd_update_wps(struct hostapd_data *hapd)
 		os_memcpy(wps->network_key, conf->ssid.wep.key[0],
 			  conf->ssid.wep.len[0]);
 		wps->network_key_len = conf->ssid.wep.len[0];
+#endif /* CONFIG_WEP */
 	}
 
 	if (conf->ssid.wpa_psk) {
-- 
2.29.2



From raphael.melotte at mind.be  Thu Feb  4 10:36:13 2021
From: raphael.melotte at mind.be (=?UTF-8?q?Rapha=C3=ABl=20M=C3=A9lotte?=)
Date: Thu,  4 Feb 2021 16:36:13 +0100
Subject: [PATCH v3 1/2] wps: reconfigure credentials on reload
In-Reply-To: <20210204150104.6847-1-raphael.melotte@mind.be>
References: <20210204150104.6847-1-raphael.melotte@mind.be>
Message-ID: <20210204153613.10356-1-raphael.melotte@mind.be>

When new credentials are configured and hostapd is reconfigured using
SIGHUP (or reload on the ctrl_iface), also update the wps credentials.

Before these changes, when WPS is triggered the registar always serves
the credentials that were configured when hostapd started.

Signed-off-by: Rapha?l M?lotte <raphael.melotte at mind.be>

---
Changes v2 -> v3:
  - By mistake, v2 contained only the CONFIG_WEP change

Changes v1 -> v2:
  - add missing ifdef for CONFIG_WEP

Signed-off-by: Rapha?l M?lotte <raphael.melotte at mind.be>
---
 src/ap/wps_hostapd.c    | 86 +++++++++++++++++++++++++++++++++++++++--
 src/wps/wps.h           |  6 +++
 src/wps/wps_registrar.c | 29 ++++++++++++++
 3 files changed, 118 insertions(+), 3 deletions(-)

diff --git a/src/ap/wps_hostapd.c b/src/ap/wps_hostapd.c
index dc8aa8f65..ff942a67b 100644
--- a/src/ap/wps_hostapd.c
+++ b/src/ap/wps_hostapd.c
@@ -1375,6 +1375,43 @@ static void hostapd_wps_nfc_clear(struct wps_context *wps)
 #endif /* CONFIG_WPS_NFC */
 }
 
+int hostapd_wps_update_multi_ap(struct hostapd_data *hapd,
+				struct wps_registrar *reg) {
+	struct hostapd_bss_config *conf = hapd->conf;
+	u8 *multi_ap_backhaul_network_key = NULL;
+	size_t multi_ap_backhaul_network_key_len = 0;
+	int ret = -1;
+
+	if ((conf->multi_ap & FRONTHAUL_BSS) &&
+	    conf->multi_ap_backhaul_ssid.ssid_len) {
+		if (conf->multi_ap_backhaul_ssid.wpa_passphrase) {
+			multi_ap_backhaul_network_key =
+				(u8 *) os_strdup(conf->multi_ap_backhaul_ssid.wpa_passphrase);
+			if (multi_ap_backhaul_network_key == NULL)
+				return -1;
+			multi_ap_backhaul_network_key_len =
+				os_strlen(conf->multi_ap_backhaul_ssid.wpa_passphrase);
+		} else if (conf->multi_ap_backhaul_ssid.wpa_psk) {
+			multi_ap_backhaul_network_key = os_malloc(2 * PMK_LEN + 1);
+			if (multi_ap_backhaul_network_key == NULL)
+				return -1;
+			wpa_snprintf_hex((char *) multi_ap_backhaul_network_key,
+					 2 * PMK_LEN + 1,
+					 conf->multi_ap_backhaul_ssid.wpa_psk->psk,
+					 PMK_LEN);
+			multi_ap_backhaul_network_key_len = 2 * PMK_LEN;
+		}
+		ret = wps_registrar_update_multi_ap(reg,
+						    conf->multi_ap_backhaul_ssid.ssid,
+						    conf->multi_ap_backhaul_ssid.ssid_len,
+						    multi_ap_backhaul_network_key,
+						    multi_ap_backhaul_network_key_len);
+		os_free(multi_ap_backhaul_network_key);
+	}
+	return ret;
+}
+
+
 
 void hostapd_deinit_wps(struct hostapd_data *hapd)
 {
@@ -1409,11 +1446,54 @@ void hostapd_update_wps(struct hostapd_data *hapd)
 	hapd->wps->upc = hapd->conf->upc;
 #endif /* CONFIG_WPS_UPNP */
 
-	hostapd_wps_set_vendor_ext(hapd, hapd->wps);
-	hostapd_wps_set_application_ext(hapd, hapd->wps);
+	struct wps_context *wps = hapd->wps;
+	struct hostapd_bss_config *conf = hapd->conf;
+
+	os_memcpy(wps->ssid, conf->ssid.ssid, conf->ssid.ssid_len);
+	wps->ssid_len = conf->ssid.ssid_len;
+
+	/* Clear wps settings, then fill them again */
+	os_free(wps->network_key);
+	wps->network_key = NULL;
+	wps->network_key_len = 0;
+	wps->psk_set = 0;
+	if (conf->ssid.wpa_psk_file) {
+		/* Use per-device PSKs */
+	} else if (conf->ssid.wpa_passphrase) {
+		wps->network_key = (u8 *) os_strdup(conf->ssid.wpa_passphrase);
+		if (wps->network_key == NULL)
+			return;
+		wps->network_key_len = os_strlen(conf->ssid.wpa_passphrase);
+	} else if (conf->ssid.wpa_psk) {
+		wps->network_key = os_malloc(2 * PMK_LEN + 1);
+		if (wps->network_key == NULL)
+			return;
+		wpa_snprintf_hex((char *) wps->network_key, 2 * PMK_LEN + 1,
+				 conf->ssid.wpa_psk->psk, PMK_LEN);
+		wps->network_key_len = 2 * PMK_LEN;
+#ifdef CONFIG_WEP
+	} else if (conf->ssid.wep.keys_set && conf->ssid.wep.key[0]) {
+		wps->network_key = os_malloc(conf->ssid.wep.len[0]);
+		if (wps->network_key == NULL)
+			return;
+		os_memcpy(wps->network_key, conf->ssid.wep.key[0],
+			  conf->ssid.wep.len[0]);
+		wps->network_key_len = conf->ssid.wep.len[0];
+#endif /* CONFIG_WEP */
+	}
+
+	if (conf->ssid.wpa_psk) {
+		os_memcpy(wps->psk, conf->ssid.wpa_psk->psk, PMK_LEN);
+		wps->psk_set = 1;
+	}
+
+	hostapd_wps_update_multi_ap(hapd, wps->registrar);
+
+	hostapd_wps_set_vendor_ext(hapd, wps);
+	hostapd_wps_set_application_ext(hapd, wps);
 
 	if (hapd->conf->wps_state)
-		wps_registrar_update_ie(hapd->wps->registrar);
+		wps_registrar_update_ie(wps->registrar);
 	else
 		hostapd_deinit_wps(hapd);
 }
diff --git a/src/wps/wps.h b/src/wps/wps.h
index 93888b011..110e3ea52 100644
--- a/src/wps/wps.h
+++ b/src/wps/wps.h
@@ -938,6 +938,12 @@ struct wpabuf * wps_build_nfc_handover_sel_p2p(struct wps_context *ctx,
 					       struct wpabuf *nfc_dh_pubkey,
 					       struct wpabuf *nfc_dev_pw);
 
+int wps_registrar_update_multi_ap(struct wps_registrar *reg,
+				  const u8 *multi_ap_backhaul_ssid,
+				  size_t multi_ap_backhaul_ssid_len,
+				  const u8 *multi_ap_backhaul_network_key,
+				  size_t multi_ap_backhaul_network_key_len);
+
 /* ndef.c */
 struct wpabuf * ndef_parse_wifi(const struct wpabuf *buf);
 struct wpabuf * ndef_build_wifi(const struct wpabuf *buf);
diff --git a/src/wps/wps_registrar.c b/src/wps/wps_registrar.c
index 9e1ee36da..d6b27be28 100644
--- a/src/wps/wps_registrar.c
+++ b/src/wps/wps_registrar.c
@@ -3669,6 +3669,35 @@ int wps_registrar_config_ap(struct wps_registrar *reg,
 }
 
 
+int wps_registrar_update_multi_ap(struct wps_registrar *reg,
+				  const u8 *multi_ap_backhaul_ssid,
+				  size_t multi_ap_backhaul_ssid_len,
+				  const u8 *multi_ap_backhaul_network_key,
+				  size_t multi_ap_backhaul_network_key_len)
+{
+	if (multi_ap_backhaul_ssid != NULL) {
+		os_memcpy(reg->multi_ap_backhaul_ssid,
+			  multi_ap_backhaul_ssid,
+			  multi_ap_backhaul_ssid_len);
+		reg->multi_ap_backhaul_ssid_len =
+			multi_ap_backhaul_ssid_len;
+	}
+	os_free(reg->multi_ap_backhaul_network_key);
+	reg->multi_ap_backhaul_network_key = NULL;
+	reg->multi_ap_backhaul_network_key_len = 0;
+
+	if (multi_ap_backhaul_network_key != NULL) {
+		reg->multi_ap_backhaul_network_key =
+			os_memdup(multi_ap_backhaul_network_key,
+				  multi_ap_backhaul_network_key_len);
+		if (reg->multi_ap_backhaul_network_key == NULL)
+			return -1;
+		reg->multi_ap_backhaul_network_key_len =
+			multi_ap_backhaul_network_key_len;
+	}
+	return 0;
+}
+
 #ifdef CONFIG_WPS_NFC
 
 int wps_registrar_add_nfc_pw_token(struct wps_registrar *reg,
-- 
2.29.2



From johannes at sipsolutions.net  Thu Feb  4 15:20:15 2021
From: johannes at sipsolutions.net (Johannes Berg)
Date: Thu,  4 Feb 2021 21:20:15 +0100
Subject: [PATCH] driver_nl80211: skip frame filter config for P2P-Device
Message-ID: <1612470015-Ifb8df0dca1aa3d952733b3db30060243db7e72b7@changeid>

From: Johannes Berg <johannes.berg at intel.com>

There's no point in attempting to configure frame filters on
a P2P-Devices that doesn't even have a netdev (nor passes any
data traffic), that just results in error messages. Skip it.

Signed-off-by: Johannes Berg <johannes.berg at intel.com>
---
 src/drivers/driver_nl80211.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/src/drivers/driver_nl80211.c b/src/drivers/driver_nl80211.c
index 919c6128d8f1..b443bb137ba3 100644
--- a/src/drivers/driver_nl80211.c
+++ b/src/drivers/driver_nl80211.c
@@ -11506,6 +11506,10 @@ static int nl80211_configure_data_frame_filters(void *priv, u32 filter_flags)
 	char path[128];
 	int ret;
 
+	/* P2P-Device has no netdev that can (or should) be configured here */
+	if (nl80211_get_ifmode(bss) == NL80211_IFTYPE_P2P_DEVICE)
+		return;
+
 	wpa_printf(MSG_DEBUG, "nl80211: Data frame filter flags=0x%x",
 		   filter_flags);
 
-- 
2.26.2



From johannes at sipsolutions.net  Thu Feb  4 15:26:40 2021
From: johannes at sipsolutions.net (Johannes Berg)
Date: Thu,  4 Feb 2021 21:26:40 +0100
Subject: [PATCH v2] driver_nl80211: skip frame filter config for P2P-Device
Message-ID: <1612470400-Ifb8df0dca1aa3d952733b3db30060243db7e72b7@changeid>

From: Johannes Berg <johannes.berg at intel.com>

There's no point in attempting to configure frame filters on
a P2P-Devices that doesn't even have a netdev (nor passes any
data traffic), that just results in error messages. Skip it.

Signed-off-by: Johannes Berg <johannes.berg at intel.com>
---
v2: return 0, oops
---
 src/drivers/driver_nl80211.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/src/drivers/driver_nl80211.c b/src/drivers/driver_nl80211.c
index 919c6128d8f1..a137ba293186 100644
--- a/src/drivers/driver_nl80211.c
+++ b/src/drivers/driver_nl80211.c
@@ -11506,6 +11506,10 @@ static int nl80211_configure_data_frame_filters(void *priv, u32 filter_flags)
 	char path[128];
 	int ret;
 
+	/* P2P-Device has no netdev that can (or should) be configured here */
+	if (nl80211_get_ifmode(bss) == NL80211_IFTYPE_P2P_DEVICE)
+		return 0;
+
 	wpa_printf(MSG_DEBUG, "nl80211: Data frame filter flags=0x%x",
 		   filter_flags);
 
-- 
2.26.2



From piotr.lobacz at softgent.com  Fri Feb  5 13:11:59 2021
From: piotr.lobacz at softgent.com (Piotr Lobacz)
Date: Fri, 5 Feb 2021 18:11:59 +0000
Subject: ODP: wpa_supplicant with hotspot 2.0 support and network manager on
 rtl8192fs wireless wifi
In-Reply-To: <AM0PR10MB32044D6E8FC612806A207CC0E4B39@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
References: <AM0PR10MB32044D6E8FC612806A207CC0E4B39@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
Message-ID: <AM0PR10MB3204FB2B30FD462FB0E4455DE4B29@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>

Ok i have found something. With older version of wpa_supplicant 2.6 and hostapd also 2.6 everything is working correctly. My mobile now gets connected with ap made like before. Can it be possible that newer version of wpa_supplicant/hostapd may not work correctly, with old kernel 4.4? Or maybe there is some new bug?

BR
Piotr Lobacz


Od: Piotr Lobacz
Wys?ane: czwartek, 4 lutego 2021 12:51
Do: hostap at lists.infradead.org <hostap at lists.infradead.org>
Temat: wpa_supplicant with hotspot 2.0 support and network manager on rtl8192fs wireless wifi

Hi all,
i have compiled wpa_supplicant 2.9 version together with network manager 1.22 on my px30 arm board. The hotspot is being made with nmcli command like this:

nmcli device wifi hotspot password 12345678 ssid softgent

and i can see that the hotspot has been put on using this command:

nmcli d show wlan0

GENERAL.DEVICE:                         wlan0
GENERAL.TYPE:                           wifi
GENERAL.HWADDR:                         74:4C:A1:FF:DC:FD
GENERAL.MTU:                            1500
GENERAL.STATE:                          100 (connected)
GENERAL.CONNECTION:                     Hotspot
GENERAL.CON-PATH:                       /org/freedesktop/NetworkManager/ActiveConnection/2
IP4.ADDRESS[1]:                         10.42.0.1/24
IP4.GATEWAY:                            --
IP4.ROUTE[1]:                           dst = 10.42.0.0/24, nh = 0.0.0.0, mt = 600
IP6.ADDRESS[1]:                         fe80::764c:a1ff:feff:dcfd/64
IP6.GATEWAY:                            --
IP6.ROUTE[1]:                           dst = fe80::/64, nh = ::, mt = 256
IP6.ROUTE[2]:                           dst = ff00::/8, nh = ::, mt = 256


but, if i try to connect thi this hotspot from my mobile i get an error:

Feb 04 11:04:16 px30-64 wpa_supplicant[241]: WPA: EAPOL-Key MIC using HMAC-SHA1
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: WPA: 6e:95:7c:a0:99:3d WPA_PTK entering state PTKCALCNEGOTIATING2
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: WPA: 6e:95:7c:a0:99:3d WPA_PTK entering state PTKINITNEGOTIATING
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: hostapd_logger: STA 6e:95:7c:a0:99:3d - sending 3/4 msg of 4-Way Handshake
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: WPA: Send EAPOL(version=2 secure=1 mic=1 ack=1 install=1 pairwise=1 kde_len=50 keyidx=1 encr=1)
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: WPA: Replay Counter - hexdump(len=8): 00 00 00 00 00 00 00 02
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: Plaintext EAPOL-Key Key Data - hexdump(len=64): [REMOVED]
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: WPA: Encrypt Key Data using AES-WRAP (KEK length 16)
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: WPA: EAPOL-Key MIC using HMAC-SHA1
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: WPA: Use EAPOL-Key timeout of 1000 ms (retry counter 1)
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: nl80211: Drv Event 20 (NL80211_CMD_DEL_STATION) received for wlan0
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: nl80211: Delete station 6e:95:7c:a0:99:3d
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: wlan0: Event DISASSOC (1) received
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: wlan0: Disassociation notification
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: wlan0:  * reason 0 (UNKNOWN)
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: wlan0:  * address 6e:95:7c:a0:99:3d
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: Disassociation frame IE(s) - hexdump(len=0): [NULL]
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: hostapd_logger: STA 6e:95:7c:a0:99:3d - disassociated
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: hostapd_logger: STA 6e:95:7c:a0:99:3d - event 2 notification

So i see that the connection is being made and for some reason it fails, due to this EAPOL-Key timeout i think.

BR
Piotr
[https://softgent.com/wp-content/uploads/2020/01/Zasob-14.png]<https://www.softgent.com>

Softgent Sp. z o.o., Budowlanych 31d, 80-298 Gdansk, POLAND

KRS: 0000674406, NIP: 9581679801, REGON: 367090912

www.softgent.com

S?d Rejonowy Gda?sk-P??noc w Gda?sku, VII Wydzia? Gospodarczy Krajowego Rejestru S?dowego

KRS 0000674406, Kapita? zak?adowy: 25 000,00 z? wp?acony w ca?o?ci.


From piotr.lobacz at softgent.com  Fri Feb  5 16:03:24 2021
From: piotr.lobacz at softgent.com (Piotr Lobacz)
Date: Fri, 5 Feb 2021 21:03:24 +0000
Subject: ODP: wpa_supplicant with hotspot 2.0 support and network manager on
 rtl8192fs wireless wifi
In-Reply-To: <AM0PR10MB3204FB2B30FD462FB0E4455DE4B29@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
References: <AM0PR10MB32044D6E8FC612806A207CC0E4B39@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>,
 <AM0PR10MB3204FB2B30FD462FB0E4455DE4B29@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
Message-ID: <AM0PR10MB3204D29C406E805696B1B3C5E4B29@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>

I'm sorry but there was a mistake in my earlier message. I am not using hostapd, but only wpa_supplicant with hotspot 2.0 support.

BR
Piotr Lobacz


Od: Hostap <hostap-bounces at lists.infradead.org> w imieniu u?ytkownika Piotr Lobacz <piotr.lobacz at softgent.com>
Wys?ane: pi?tek, 5 lutego 2021 19:11
Do: hostap at lists.infradead.org <hostap at lists.infradead.org>
Temat: ODP: wpa_supplicant with hotspot 2.0 support and network manager on rtl8192fs wireless wifi 
?
Ok i have found something. With older version of wpa_supplicant 2.6 and hostapd also 2.6 everything is working correctly. My mobile now gets connected with ap made like before. Can it be possible that newer version of wpa_supplicant/hostapd may not work correctly, with old kernel 4.4? Or maybe there is some new bug?

BR
Piotr Lobacz


Od: Piotr Lobacz
Wys?ane: czwartek, 4 lutego 2021 12:51
Do: hostap at lists.infradead.org <hostap at lists.infradead.org>
Temat: wpa_supplicant with hotspot 2.0 support and network manager on rtl8192fs wireless wifi

Hi all,
i have compiled wpa_supplicant 2.9 version together with network manager 1.22 on my px30 arm board. The hotspot is being made with nmcli command like this:

nmcli device wifi hotspot password 12345678 ssid softgent

and i can see that the hotspot has been put on using this command:

nmcli d show wlan0

GENERAL.DEVICE:???????????????????????? wlan0
GENERAL.TYPE:?????????????????????????? wifi
GENERAL.HWADDR:???????????????????????? 74:4C:A1:FF:DC:FD
GENERAL.MTU:??????????????????????????? 1500
GENERAL.STATE:????????????????????????? 100 (connected)
GENERAL.CONNECTION:???????????????????? Hotspot
GENERAL.CON-PATH:?????????????????????? /org/freedesktop/NetworkManager/ActiveConnection/2
IP4.ADDRESS[1]:???????????????????????? 10.42.0.1/24
IP4.GATEWAY:??????????????????????????? --
IP4.ROUTE[1]:?????????????????????????? dst = 10.42.0.0/24, nh = 0.0.0.0, mt = 600
IP6.ADDRESS[1]:???????????????????????? fe80::764c:a1ff:feff:dcfd/64
IP6.GATEWAY:??????????????????????????? --
IP6.ROUTE[1]:?????????????????????????? dst = fe80::/64, nh = ::, mt = 256
IP6.ROUTE[2]:?????????????????????????? dst = ff00::/8, nh = ::, mt = 256


but, if i try to connect thi this hotspot from my mobile i get an error:

Feb 04 11:04:16 px30-64 wpa_supplicant[241]: WPA: EAPOL-Key MIC using HMAC-SHA1
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: WPA: 6e:95:7c:a0:99:3d WPA_PTK entering state PTKCALCNEGOTIATING2
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: WPA: 6e:95:7c:a0:99:3d WPA_PTK entering state PTKINITNEGOTIATING
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: hostapd_logger: STA 6e:95:7c:a0:99:3d - sending 3/4 msg of 4-Way Handshake
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: WPA: Send EAPOL(version=2 secure=1 mic=1 ack=1 install=1 pairwise=1 kde_len=50 keyidx=1 encr=1)
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: WPA: Replay Counter - hexdump(len=8): 00 00 00 00 00 00 00 02
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: Plaintext EAPOL-Key Key Data - hexdump(len=64): [REMOVED]
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: WPA: Encrypt Key Data using AES-WRAP (KEK length 16)
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: WPA: EAPOL-Key MIC using HMAC-SHA1
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: WPA: Use EAPOL-Key timeout of 1000 ms (retry counter 1)
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: nl80211: Drv Event 20 (NL80211_CMD_DEL_STATION) received for wlan0
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: nl80211: Delete station 6e:95:7c:a0:99:3d
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: wlan0: Event DISASSOC (1) received
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: wlan0: Disassociation notification
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: wlan0:? * reason 0 (UNKNOWN)
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: wlan0:? * address 6e:95:7c:a0:99:3d
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: Disassociation frame IE(s) - hexdump(len=0): [NULL]
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: hostapd_logger: STA 6e:95:7c:a0:99:3d - disassociated
Feb 04 11:04:16 px30-64 wpa_supplicant[241]: hostapd_logger: STA 6e:95:7c:a0:99:3d - event 2 notification

So i see that the connection is being made and for some reason it fails, due to this EAPOL-Key timeout i think.

BR
Piotr
[https://softgent.com/wp-content/uploads/2020/01/Zasob-14.png]<https://www.softgent.com>

Softgent Sp. z o.o., Budowlanych 31d, 80-298 Gdansk, POLAND

KRS: 0000674406, NIP: 9581679801, REGON: 367090912

www.softgent.com

S?d Rejonowy Gda?sk-P??noc w Gda?sku, VII Wydzia? Gospodarczy Krajowego Rejestru S?dowego

KRS 0000674406, Kapita? zak?adowy: 25 000,00 z? wp?acony w ca?o?ci.

_______________________________________________
Hostap mailing list
Hostap at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/hostap

From j at w1.fi  Sat Feb  6 04:35:37 2021
From: j at w1.fi (Jouni Malinen)
Date: Sat, 6 Feb 2021 11:35:37 +0200
Subject: [PATCH] nl80211: use the process_bss_event for the nl_connect
 handler
In-Reply-To: <20210121154037.32654-3-andrei.otcheretianski@intel.com>
References: <20210121154037.32654-1-andrei.otcheretianski@intel.com>
 <20210121154037.32654-3-andrei.otcheretianski@intel.com>
Message-ID: <20210206093537.GA9770@w1.fi>

On Thu, Jan 21, 2021 at 05:40:34PM +0200, Andrei Otcheretianski wrote:
> Fix it by using the process_bss_event() handler when the nl_connect
> handler is used.

In general, that sounds fine, but there is one detail that is missed
here in the implementation:

> +send_and_recv_msgs_connect_handle(struct wpa_driver_nl80211_data *drv,
> +				  struct nl_msg *msg, struct i802_bss *bss)
> +{
> +	struct nl_sock *nl_connect = get_connect_handle(bss);
> +
> +	if (nl_connect)
> +		return send_and_recv_msgs_owner(drv, msg, nl_connect, 1,
> +						process_bss_event, bss, NULL,
> +						NULL);

> @@ -6196,8 +6199,7 @@ skip_auth_type:
> -	ret = send_and_recv_msgs_owner(drv, msg, nl_connect, 1, NULL,
> -				       (void *) -1, NULL, NULL);
> +	ret = send_and_recv_msgs_connect_handle(drv, msg, bss);

This would lose that special valid_handler = NULL, valid_data = (void *)
-1 combination that is needed at the end of send_and_recv() to be able
to use nl80211_nlmsg_clear(msg) to get any private material like keys
explicitly cleared from freed heap memory. See commit bbd89bfca0b4i
("nl80211: Clear nlmsg payload with keys before freeing") for more
details.

That special case needs to be covered here. Since it may be inconvenient
to cover this without adding new arguments to all send_and_recv
functions, it may be worth considering whether that conditional
nl80211_nlmsg_clear() call at the end of send_and_recv() should simply
be made unconditional.. It would burn some more resources clearing
memory unnecessarily for most messages, but that's unlikely to be much
of and issue in practice.
    
-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Sat Feb  6 05:12:21 2021
From: j at w1.fi (Jouni Malinen)
Date: Sat, 6 Feb 2021 12:12:21 +0200
Subject: [PATCH v2] robust_av: use wpa_bss_ext_capab() helper
In-Reply-To: <1611083256-I3a247a9b30b9de89e994dadf9c1d76c524830df5@changeid>
References: <1611083256-I3a247a9b30b9de89e994dadf9c1d76c524830df5@changeid>
Message-ID: <20210206101221.GA425095@w1.fi>

On Tue, Jan 19, 2021 at 08:07:36PM +0100, Johannes Berg wrote:
> Use the helper instead of open-coding the check. Since the
> helper doesn't handle a NULL BSS, keep that extra check.

Thanks, applied.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Sat Feb  6 05:12:36 2021
From: j at w1.fi (Jouni Malinen)
Date: Sat, 6 Feb 2021 12:12:36 +0200
Subject: [PATCH] DPP: Fix compiler warning
In-Reply-To: <20210121154037.32654-1-andrei.otcheretianski@intel.com>
References: <20210121154037.32654-1-andrei.otcheretianski@intel.com>
Message-ID: <20210206101236.GB425095@w1.fi>

On Thu, Jan 21, 2021 at 05:40:32PM +0200, Andrei Otcheretianski wrote:
> Old gcc versions complain about signed/unsigned comparison in
> dpp_rx_gas_resp(). Fix it.

Thanks, applied.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Sat Feb  6 05:14:33 2021
From: j at w1.fi (Jouni Malinen)
Date: Sat, 6 Feb 2021 12:14:33 +0200
Subject: [PATCH 1/2] WPA: Ignore RSNX element in WPA connection
In-Reply-To: <20210121154037.32654-2-andrei.otcheretianski@intel.com>
References: <20210121154037.32654-1-andrei.otcheretianski@intel.com>
 <20210121154037.32654-2-andrei.otcheretianski@intel.com>
Message-ID: <20210206101433.GC425095@w1.fi>

On Thu, Jan 21, 2021 at 05:40:33PM +0200, Andrei Otcheretianski wrote:
> When an AP publishes both RSN, RSNX and WPA IE, it incorrectly removes
> the RSN IE in the EAPOL 3/4 message if the STA associates with WPA,
> leaving only RSNXE instead of WPA IE. WPA STA fails to connect to such
> AP as the WPA IE is missing.
> Since RSNX is not really needed in non RSN connection, just remove it.

Thanks, applied both patches, but for this part:

> In addition, make sure that the non RSN STA doesn't store and validate
> RSNX element which would be "missing" now in EAPOL 3/4 message.

I did not like the idea of not storing RSNXE in some cases and instead,
addressed this corner case in the actual validation step. This is not
really something that is supposed to ever happen in real production use
cases (i.e., SAE would be used instead of there is support for RSNXE),
but anyway, I guess this is convenient to have available for testing
purposes.

-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Sat Feb  6 05:14:54 2021
From: j at w1.fi (Jouni Malinen)
Date: Sat, 6 Feb 2021 12:14:54 +0200
Subject: [PATCH] tests: Fix ap_ft_r0_key_expiration test
In-Reply-To: <20210121154037.32654-4-andrei.otcheretianski@intel.com>
References: <20210121154037.32654-1-andrei.otcheretianski@intel.com>
 <20210121154037.32654-4-andrei.otcheretianski@intel.com>
Message-ID: <20210206101454.GD425095@w1.fi>

On Thu, Jan 21, 2021 at 05:40:35PM +0200, Andrei Otcheretianski wrote:
> The test configures ft_r0_key_lifetime parameter, however ft_params
> already contain the r0_key_lifetime. Since both options are accepted by
> hostapd and set the same field, one of them gets overwritten.
> As the dictionary enumeration order is not guaranteed in python, the
> test may sporadically fail.
> Fix that by explicitely removing the unneeded parameter.

Thanks, applied.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Sat Feb  6 05:15:08 2021
From: j at w1.fi (Jouni Malinen)
Date: Sat, 6 Feb 2021 12:15:08 +0200
Subject: [PATCH] tests: Fix sporadic failures in p2p_channel_avoid3
In-Reply-To: <20210121154037.32654-5-andrei.otcheretianski@intel.com>
References: <20210121154037.32654-1-andrei.otcheretianski@intel.com>
 <20210121154037.32654-5-andrei.otcheretianski@intel.com>
Message-ID: <20210206101508.GE425095@w1.fi>

On Thu, Jan 21, 2021 at 05:40:36PM +0200, Andrei Otcheretianski wrote:
> The p2p group may be originally formated on UNII-3, so disabling UNII-1
> and UNII-2 will not result in a channel switch failing the test.
> Fix this by setting 44 as a preferred channel.

Thanks, applied.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Sat Feb  6 05:15:34 2021
From: j at w1.fi (Jouni Malinen)
Date: Sat, 6 Feb 2021 12:15:34 +0200
Subject: [PATCH] Disable HE capabilites when using wrong config
In-Reply-To: <20210127160117.8862-1-shay.bar@celeno.com>
References: <20210127160117.8862-1-shay.bar@celeno.com>
Message-ID: <20210206101534.GF425095@w1.fi>

On Wed, Jan 27, 2021 at 06:01:17PM +0200, Shay Bar wrote:
> Add 11ax configuration check similar to HT/VHT.

Thanks, applied.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Sat Feb  6 05:15:56 2021
From: j at w1.fi (Jouni Malinen)
Date: Sat, 6 Feb 2021 12:15:56 +0200
Subject: [PATCH v2] driver_nl80211: skip frame filter config for P2P-Device
In-Reply-To: <1612470400-Ifb8df0dca1aa3d952733b3db30060243db7e72b7@changeid>
References: <1612470400-Ifb8df0dca1aa3d952733b3db30060243db7e72b7@changeid>
Message-ID: <20210206101556.GG425095@w1.fi>

On Thu, Feb 04, 2021 at 09:26:40PM +0100, Johannes Berg wrote:
> There's no point in attempting to configure frame filters on
> a P2P-Devices that doesn't even have a netdev (nor passes any
> data traffic), that just results in error messages. Skip it.

Thanks, applied.

-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Sat Feb  6 05:49:15 2021
From: j at w1.fi (Jouni Malinen)
Date: Sat, 6 Feb 2021 12:49:15 +0200
Subject: Fwd: keeping up to date, kernel 4 -> 5, cannot ACS anymore
In-Reply-To: <CA++fYEgW_ENswbPqhxjL0s72fzk8humch5=xT862U7UMhF89KQ@mail.gmail.com>
References: <CA++fYEiNvuSYhACuD4Q4arnZ2rTORQyqgv+sZHJhOrnZQxCHSg@mail.gmail.com>
 <CA++fYEgW_ENswbPqhxjL0s72fzk8humch5=xT862U7UMhF89KQ@mail.gmail.com>
Message-ID: <20210206104915.GA425833@w1.fi>

On Mon, Jan 25, 2021 at 12:10:17PM -0500, Sven F. wrote:
> # hostapd -d -B -i wlan0 /tmp/0_CUSTOM_0
> ACS: No available channels found
> wlan0: IEEE 802.11 Configured channel (0) or frequency (0) not found from\
> the channel list of the current mode (2) IEEE 802.11a
> wlan0: IEEE 802.11 Hardware does not support configured channel
> Could not select hw_mode and channel. (-3)

The driver used here does not support the configured channel.

> hw_mode=a
> channel=0

That is a request to use a channel on the 5 GHz band.

> but iw list is saying that :
> 
> * 5180 MHz [36] (disabled)
> * 5200 MHz [40] (disabled)
> * 5220 MHz [44] (disabled)
> * 5240 MHz [48] (disabled)
> * 5260 MHz [52] (disabled)
> * 5280 MHz [56] (disabled)
> * 5300 MHz [60] (disabled)
> * 5320 MHz [64] (disabled)
> * 5500 MHz [100] (20.0 dBm) (no IR, radar detection)
> * 5520 MHz [104] (20.0 dBm) (no IR, radar detection)
> * 5540 MHz [108] (20.0 dBm) (no IR, radar detection)
> * 5560 MHz [112] (20.0 dBm) (no IR, radar detection)
> * 5580 MHz [116] (20.0 dBm) (no IR, radar detection)
> * 5600 MHz [120] (20.0 dBm) (no IR, radar detection)
> * 5620 MHz [124] (20.0 dBm) (no IR, radar detection)
> * 5640 MHz [128] (20.0 dBm) (no IR, radar detection)
> * 5660 MHz [132] (20.0 dBm) (no IR, radar detection)
> * 5680 MHz [136] (20.0 dBm) (no IR, radar detection)
> * 5700 MHz [140] (20.0 dBm) (no IR, radar detection)
> * 5720 MHz [144] (20.0 dBm) (no IR, radar detection)
> * 5745 MHz [149] (20.0 dBm) (no IR)
> * 5765 MHz [153] (20.0 dBm) (no IR)
> * 5785 MHz [157] (20.0 dBm) (no IR)
> * 5805 MHz [161] (20.0 dBm) (no IR)
> * 5825 MHz [165] (20.0 dBm) (no IR)
> * 5845 MHz [169] (disabled)
> * 5865 MHz [173] (disabled)

But there is no available 5 GHz channel for AP mode functionality from
the driver.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Sat Feb  6 05:53:05 2021
From: j at w1.fi (Jouni Malinen)
Date: Sat, 6 Feb 2021 12:53:05 +0200
Subject: [PATCH 3/6] wpa_supplicant: Added support for multiple global
 sae_passwords
In-Reply-To: <11e347ec-7b47-e139-4ddf-97c77def21a@lysator.liu.se>
References: <11e347ec-7b47-e139-4ddf-97c77def21a@lysator.liu.se>
Message-ID: <20210206105305.GB425833@w1.fi>

On Fri, Jan 22, 2021 at 03:58:20PM +0100, Peter ?strand wrote:
> diff --git a/wpa_supplicant/config.h b/wpa_supplicant/config.h
> @@ -1200,6 +1200,12 @@ struct wpa_config {
> +	/**
> +	 * sae_password entries - added to a list of available passwords
> +	 */
> +	struct sae_password_entry *sae_passwords;

This is not the proper place for configuring SAE passwords in
wpa_supplicant. These would apply to all network blocks while the
configuration should be specific to a single network block just like the
existing sae_password parameter.

> diff --git a/wpa_supplicant/wpa_supplicant.conf b/wpa_supplicant/wpa_supplicant.conf
> @@ -409,6 +409,39 @@ fast_reauth=1
> +# SAE password
> +# This parameter can be used to set passwords for SAE, in addition to
> +# a sae_password in a network block.

I don't think this would be acceptable as a global parameter.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Sat Feb  6 05:54:06 2021
From: j at w1.fi (Jouni Malinen)
Date: Sat, 6 Feb 2021 12:54:06 +0200
Subject: [PATCH 4/6] SAE: Add sae_password to wpas global password list
In-Reply-To: <46a8ae1b-ad8-10c5-1af3-c66e53e7a8@lysator.liu.se>
References: <46a8ae1b-ad8-10c5-1af3-c66e53e7a8@lysator.liu.se>
Message-ID: <20210206105406.GC425833@w1.fi>

On Fri, Jan 22, 2021 at 03:58:43PM +0100, Peter ?strand wrote:
> For Mesh, add the global password list to bss->conf.

Same here, this needs a design change to not depend on global list of
passwords that would apply to all network profiles.

-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Sat Feb  6 05:58:50 2021
From: j at w1.fi (Jouni Malinen)
Date: Sat, 6 Feb 2021 12:58:50 +0200
Subject: [PATCH 6/6] SAE: Make H2E work with multiple passwords
In-Reply-To: <775d39b6-c57d-41f-db82-7f11c27b5376@lysator.liu.se>
References: <775d39b6-c57d-41f-db82-7f11c27b5376@lysator.liu.se>
Message-ID: <20210206105850.GD425833@w1.fi>

On Fri, Jan 22, 2021 at 03:59:59PM +0100, Peter ?strand wrote:
> Need to derive pt for all sae_passwords, as well as
> initially call auth_sae_send_commit with update=1.

Similar comments here..

What kind of testing did you do with this set of patches? When I tried
using SAE Password Identifier with the mac80211 implementation not
supporting RSNXE inclusion in Beacon/Probe Response frames. Has that
been implemented now?

In addition to the change on where the SAE passwords would be stored,
I'd like to see this functionality working with mac80211_hwsim before
I'd consider applying it. In other words, new test cases to
tests/hwsim/test_wpas_mesh.py would be highly appreciated. For now, I'm
dropping the patches since it does not seem very useful to apply the
first two before the password configuration location has been resolved.

-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Sat Feb  6 08:57:44 2021
From: j at w1.fi (Jouni Malinen)
Date: Sat, 6 Feb 2021 15:57:44 +0200
Subject: [PATCH 1/2] hostapd: Add an option to notify management frames
 on ctrl_iface
In-Reply-To: <20201130111047.15646-1-raphael.melotte@mind.be>
References: <20201130111047.15646-1-raphael.melotte@mind.be>
Message-ID: <20210206135744.GA834446@w1.fi>

On Mon, Nov 30, 2020 at 12:10:46PM +0100, Rapha?l M?lotte wrote:
> In some contexts (e.g. Multi-AP) it can be useful to have access to
> some of the management frames in upper layers (e.g. to be able to
> process the content of association requests externally).
> 
> Add 'notify_mgmt_frames'. When enabled, it will notify the ctrl_iface
> when a management frame arrives using 'AP_MGMT_FRAME_RECEIVED'.
> 
> Note that to avoid completely flooding the ctrl_iface, not all
> management frames are included (e.g. beacons are excluded).

Thanks, both patches applied.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Sat Feb  6 08:58:11 2021
From: j at w1.fi (Jouni Malinen)
Date: Sat, 6 Feb 2021 15:58:11 +0200
Subject: [PATCH] BSD: If route socket overflows, sync drivers to system
 interfaces
In-Reply-To: <20210101141643.644-1-roy@marples.name>
References: <20210101141643.644-1-roy@marples.name>
Message-ID: <20210206135811.GB834446@w1.fi>

On Fri, Jan 01, 2021 at 02:16:43PM +0000, Roy Marples wrote:
> Messages such as RTM_IFNFO or RTM_IFANNOUNCE could have been lost.
> As such, sync the state of our internal driver to the state of the
> system interfaces as reports by getifaddrs(2).
> 
> This change requires the routing socket be placed in non-blocking
> mode. While here, set the routing and inet sockets to close on exec.
> 
> BSD's that support SO_RERROR include NetBSD and DragonFly.
> There is a review underway to add this to FreeBSD.

Thanks, applied.

-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Sat Feb  6 08:58:35 2021
From: j at w1.fi (Jouni Malinen)
Date: Sat, 6 Feb 2021 15:58:35 +0200
Subject: [PATCH] Adding option to manage device drivers creating random
 MAC addresses
In-Reply-To: <20210124153358.2182-1-amacri@tiscali.it>
References: <20210124153358.2182-1-amacri@tiscali.it>
Message-ID: <20210206135835.GC834446@w1.fi>

On Sun, Jan 24, 2021 at 04:33:58PM +0100, Ircama wrote:
> Adding option 2 to the "p2p_device_random_mac_addr" configuration option
> in order to support device drivers which use by default random MAC adresses
> when creating a new P2P Device interface (for instance, the BCM2711 80211
> wireless device driver included in Raspberry Pi 4 Model B); in such case,
> this option allows to create the P2P Device interface correctly when using
> P2P permanent groups, enabling wpa_supplicant to reuse the same MAC address
> when re-invoking a P2P permanent group.

Thanks, applied.

-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Sat Feb  6 09:14:37 2021
From: j at w1.fi (Jouni Malinen)
Date: Sat, 6 Feb 2021 16:14:37 +0200
Subject: [PATCH 2/2] wpa_supplicant: fix chirping on sta enrollee scenario
In-Reply-To: <20201215093455.51933-2-kazikcz@gmail.com>
References: <20201215093455.51933-1-kazikcz@gmail.com>
 <20201215093455.51933-2-kazikcz@gmail.com>
Message-ID: <20210206141437.GA834632@w1.fi>

On Tue, Dec 15, 2020 at 09:34:55AM +0000, Michal Kazior wrote:
> Some time ago it was found some drivers are
> setting their hw/ucode rx filters restrictively
> enough to prevent DPP multicast frames from being
> delivered.
> 
> A set of patches was introduced to the kernel and
> ath9k driver as well as hostapd, eg.
> 
>   a39e9af90 ("nl80211: DPP listen mode callback")
>   4d2ec436e ("DPP: Add driver operation for enabling/disabling listen mode")

So all this applies to patch 1/2 where hostapd side was not previously
covered. However, I'm not sure I understand why that description is here
in patch 2/2 as well..

> Turns out chirping was omitted. As such chirping
> wasn't working on drivers with restrictive rx
> filters.

This sounds strange.. The response to chirping would be a unicast frame,
so that hardware/firmware RX filter change should not have any impact
here.

> diff --git a/wpa_supplicant/dpp_supplicant.c b/wpa_supplicant/dpp_supplicant.c
> @@ -3420,6 +3420,7 @@ static void wpas_dpp_chirp_tx_status(struct wpa_supplicant *wpa_s,
>  	wpa_printf(MSG_DEBUG, "DPP: Chirp send completed - wait for response");
> +	wpas_dpp_listen_start(wpa_s, freq);

This looks quite incorrect thing to do.. This function is called when
the TX operation with 2000 ms wait for response gets TX status. It would
not be appropriate to start DPP listen while that 2000 ms wait for the
response is ongoing.

Could you please provide more details on what exactly this is trying to
do and what kind of a frame is not received without this addition?

-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Sat Feb  6 09:38:19 2021
From: j at w1.fi (Jouni Malinen)
Date: Sat, 6 Feb 2021 16:38:19 +0200
Subject: [PATCH] tests: Fix regdom cleanup in some p2p_channel tests
In-Reply-To: <20201214124206.7724-1-andrei.otcheretianski@intel.com>
References: <20201214124206.7724-1-andrei.otcheretianski@intel.com>
Message-ID: <20210206143819.GA1240037@w1.fi>

On Mon, Dec 14, 2020 at 02:42:06PM +0200, Andrei Otcheretianski wrote:
> Cfg80211 may ignore user hints while there are active COUNTRY_IE hints,
> thus at some timings it may ignore the country setting back to world
> domain. Fix it by making sure the country is set only after all the
> interfaces are stopped. In addition, call a more robust
> clear_regdom_dev() function.

Thanks, applied.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Sat Feb  6 09:38:50 2021
From: j at w1.fi (Jouni Malinen)
Date: Sat, 6 Feb 2021 16:38:50 +0200
Subject: [PATCH 1/2] hostapd: fix dpp_listen in dpp responder scenario
In-Reply-To: <20201215093455.51933-1-kazikcz@gmail.com>
References: <20201215093455.51933-1-kazikcz@gmail.com>
Message-ID: <20210206143850.GB1240037@w1.fi>

On Tue, Dec 15, 2020 at 09:34:54AM +0000, Michal Kazior wrote:
> Some time ago it was found some drivers are
> setting their hw/ucode rx filters restrictively
> enough to prevent DPP multicast frames from being
> delivered.
> 
> A set of patches was introduced to the kernel and
> ath9k driver as well as hostapd, eg.
> 
>   a39e9af90 ("nl80211: DPP listen mode callback")
>   4d2ec436e ("DPP: Add driver operation for enabling/disabling listen mode")
> 
> The hostapd code itself was not calling the new
> multicast registration. As such the AP side of
> things wasn't working as expected in some
> scenarios.
> 
> I've found this while trying to get ath9k working
> as an AP Responder/Configurator.
> 
> The problem wasn't seen on, eg. mac80211 hwsim
> driver.

Thanks, applied patch 1/2.

-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Sat Feb  6 09:44:02 2021
From: j at w1.fi (Jouni Malinen)
Date: Sat, 6 Feb 2021 16:44:02 +0200
Subject: [PATCH v2] wpa_supplicant: Should disconnect on deinit whatever
 WOWLAN is enable or disable
In-Reply-To: <20201207061754.16796-1-zhao.chen@mediatek.com>
References: <20201207061754.16796-1-zhao.chen@mediatek.com>
Message-ID: <20210206144402.GC1240037@w1.fi>

On Mon, Dec 07, 2020 at 02:17:54PM +0800, Zhao Chen wrote:
> Add new configuration option send_deauth_when_down to control whether need send deauth to kernel when 
> wifi interface down, this variable control whether wpa_supplicant send deauth to kernel when terminate to
> sync disconnect status with kernel.
> 0 = Not need to send deauth when down, assume the device will be power off(Default)
> 1 = Need to send deauth to sync disconnect status with kernel to avoid potential unsync
> problem when restart wifi

Sorry, I somehow missed this one when going through another patch that
does practically the same thing with a different name for that
configuration parameter:
https://w1.fi/cgit/hostap/commit/?id=62657365f896108da7bb22d6b0a767337a9624f1

-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Sat Feb  6 11:07:59 2021
From: j at w1.fi (Jouni Malinen)
Date: Sat, 6 Feb 2021 18:07:59 +0200
Subject: [PATCH 2/2] tests: multi AP extend tests
In-Reply-To: <20201013101627.17868-2-janusz.dziedzic@gmail.com>
References: <20201013101627.17868-1-janusz.dziedzic@gmail.com>
 <20201013101627.17868-2-janusz.dziedzic@gmail.com>
Message-ID: <20210206160759.GA1678256@w1.fi>

On Tue, Oct 13, 2020 at 12:16:27PM +0200, Janusz Dziedzic wrote:
> Add option to:
>  - add new AP on the same phy that bhaul-sta using
>  - run CSA from the parent
> 
> Adding new AP (bhaul/fhaul) on the same
> phy we have for bhaul-sta is closer to
> the real repeater implementation.
> 
> Add test case for that and run CSA.
> 
> This is common problem when we have on the same phy:
>  - connected bhaul STA
>  - we started fhaul/bhaul AP
>  - we receive (from parent) CSA on sta interface
> 
> This is multi_ap_wps_shared_apdev_csa test case,
> which fail today - even with hwsim.

Thanks, both patches applied. However, I do not want to add test cases
that are known to fail always, so I modified
multi_ap_wps_shared_apdev_csa to ignore the error for now until the
issue has been addressed.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Sat Feb  6 11:08:21 2021
From: j at w1.fi (Jouni Malinen)
Date: Sat, 6 Feb 2021 18:08:21 +0200
Subject: [PATCH] wpa_supplicant: Notify freq change on CH_SWITCH
In-Reply-To: <20201103192001.2581719-1-arowa@google.com>
References: <20201103011053.2357991-1-arowa@google.com>
 <20201103192001.2581719-1-arowa@google.com>
Message-ID: <20210206160821.GB1678256@w1.fi>

On Tue, Nov 03, 2020 at 11:20:01AM -0800, Arowa Suliman wrote:
> wpa_supplicant does not send a D-Bus notification of the BSS frequency
> change when a CSA happens. Sending a PropertyChanged signal with the
> updated frequency will notify the network manager quickly, instead of
> waiting for the next scan results.

Thanks, applied.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Sat Feb  6 11:08:46 2021
From: j at w1.fi (Jouni Malinen)
Date: Sat, 6 Feb 2021 18:08:46 +0200
Subject: [PATCH] wpa_supplicant: Configurable fast-associate timer
 threshold
In-Reply-To: <20201104093027.23457-1-mikael.kanstrup@sony.com>
References: <20201104093027.23457-1-mikael.kanstrup@sony.com>
Message-ID: <20210206160846.GC1678256@w1.fi>

On Wed, Nov 04, 2020 at 10:30:27AM +0100, Mikael Kanstrup wrote:
> For Android the default value of 5 seconds is usually too short for
> scan results from last scan initiated from settings app to be
> considered for fast-associate. Make the fast-associate timer value
> configurable so that a suitable value can be set based on a systems
> regular scan interval.

Thanks, applied.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Sat Feb  6 11:09:04 2021
From: j at w1.fi (Jouni Malinen)
Date: Sat, 6 Feb 2021 18:09:04 +0200
Subject: [PATCH] hostapd: Add multi_ap settings to get_config() output
In-Reply-To: <20201202165145.23578-1-raphael.melotte@mind.be>
References: <20201202165145.23578-1-raphael.melotte@mind.be>
Message-ID: <20210206160904.GD1678256@w1.fi>

On Wed, Dec 02, 2020 at 05:51:45PM +0100, Rapha?l M?lotte wrote:
> Since a running hostapd is not necessarily using the settings that are
> in the configuration file (if they were changed at runtime, or the
> file was changed but not reloaded, etc.), being able to get their
> value at runtime can be useful (to know if they have to be updated for
> example).
> 
> If multi_ap is set, also print the ssid and passphrase (or psk).

Thanks, applied.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Sat Feb  6 11:09:33 2021
From: j at w1.fi (Jouni Malinen)
Date: Sat, 6 Feb 2021 18:09:33 +0200
Subject: [PATCH 0/2] hostapd: update WPS credentials on SIGHUP
In-Reply-To: <20201218105028.12775-1-raphael.melotte@mind.be>
References: <20201218105028.12775-1-raphael.melotte@mind.be>
Message-ID: <20210206160933.GE1678256@w1.fi>

On Fri, Dec 18, 2020 at 11:50:26AM +0100, Rapha?l M?lotte wrote:
> This is an attempt at addressing the comment in [1].
> 
> When hostapd is reconfigured, update the wps credentials.
> 
> It covers both the regular credentials and the multi_ap credentials.
> 
> [1]: https://lists.infradead.org/pipermail/hostap/2020-October/039016.html
> 
> Rapha?l M?lotte (2):
>   wps: reconfigure credentials on reload
>   tests: add wps test with dynamic update

Thanks, both applied.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Sun Feb  7 04:13:19 2021
From: j at w1.fi (Jouni Malinen)
Date: Sun, 7 Feb 2021 11:13:19 +0200
Subject: [PATCH] hostapd: Fix dynamic MAC ACL management over control
 interface.
In-Reply-To: <1601359921-69455-1-git-send-email-mutsugi@allied-telesis.co.jp>
References: <1601359921-69455-1-git-send-email-mutsugi@allied-telesis.co.jp>
Message-ID: <20210207091319.GA424704@w1.fi>

On Tue, Sep 29, 2020 at 03:12:01PM +0900, Masafumi UTSUGI wrote:
> hostapd_disassoc_accept_mac() is called after accept mac address
> added but this function should be called after accept mac address
> removed and accept mac list cleared to disconnect a STA which is
> not listed in accept mac address list.
> Also, this codes does not handle error case so I added error case
> handling codes.

Thanks, applied.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Sun Feb  7 04:13:39 2021
From: j at w1.fi (Jouni Malinen)
Date: Sun, 7 Feb 2021 11:13:39 +0200
Subject: [PATCH v2 1/2] hostapd: dfs: allow switch to available channel
In-Reply-To: <20201011190153.15064-1-janusz.dziedzic@gmail.com>
References: <20201011190153.15064-1-janusz.dziedzic@gmail.com>
Message-ID: <20210207091339.GB424704@w1.fi>

On Sun, Oct 11, 2020 at 09:01:52PM +0200, Janusz Dziedzic wrote:
> For EU, where preCAC is allowed, we should
> allow switch to DFS available channels, instead
> of restart BSS.

Thanks, both applied.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From ps at pks.im  Sun Feb  7 12:48:27 2021
From: ps at pks.im (Patrick Steinhardt)
Date: Sun, 7 Feb 2021 18:48:27 +0100
Subject: [PATCH 0/2] File-backed external password store
Message-ID: <cover.1612720013.git.ps@pks.im>

Hi,

I've recently tried to somehow split up configuration and credentials
such that I can deploy configuration to multiple nodes while credentials
are stored separately. Could very well be I'm blind, but I didn't find
any straight-forward way to do this with wpa_supplicant.

To fix this, I've thus implemented a new external password backend which
reads passwords from a separate file. This piggy-backs on the external
password framework which already exists.

This series is rather a RFC to see whether there's any interest. The
code works and I'm currently using it, but documentation is still
missing. So if there's any interest, I'll create a v2 with missing docs
amended. I think usage should be clear enough with the description in
patch 2/2 for now.

Patrick

Patrick Steinhardt (2):
  wpa_supplicant: Move `wpa_config_get_line()` into utils
  ext_password: Implement new file-based backend

 src/utils/config.c            |  97 +++++++++++++++++++++++++
 src/utils/config.h            |  31 ++++++++
 src/utils/ext_password.c      |   3 +
 src/utils/ext_password_file.c | 129 ++++++++++++++++++++++++++++++++++
 src/utils/ext_password_i.h    |   4 ++
 wpa_supplicant/Makefile       |   8 +++
 wpa_supplicant/config_file.c  | 100 +-------------------------
 7 files changed, 273 insertions(+), 99 deletions(-)
 create mode 100644 src/utils/config.c
 create mode 100644 src/utils/config.h
 create mode 100644 src/utils/ext_password_file.c

-- 
2.30.0

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/hostap/attachments/20210207/cbe5404c/attachment.sig>

From ps at pks.im  Sun Feb  7 12:48:31 2021
From: ps at pks.im (Patrick Steinhardt)
Date: Sun, 7 Feb 2021 18:48:31 +0100
Subject: [PATCH 1/2] wpa_supplicant: Move `wpa_config_get_line()` into utils
In-Reply-To: <cover.1612720013.git.ps@pks.im>
References: <cover.1612720013.git.ps@pks.im>
Message-ID: <66a77558af5b131b74f50beff5550f5e8d5e1b72.1612720013.git.ps@pks.im>

The function `wpa_config_get_line()` is used by the wpa_supplicant
config file parser in order to retrieve the next non-commend non-blank
line. We'll need the same kind of functionality in order to implement
the file-based external password backend, so as a preparatory step this
commit extracts the function into its own standalone file in the utils
package.

No functional changes are expected from this commit.

Signed-off-by: Patrick Steinhardt <ps at pks.im>
---
 src/utils/config.c           |  97 +++++++++++++++++++++++++++++++++
 src/utils/config.h           |  31 +++++++++++
 wpa_supplicant/Makefile      |   2 +
 wpa_supplicant/config_file.c | 100 +----------------------------------
 4 files changed, 131 insertions(+), 99 deletions(-)
 create mode 100644 src/utils/config.c
 create mode 100644 src/utils/config.h

diff --git a/src/utils/config.c b/src/utils/config.c
new file mode 100644
index 000000000..4670536f3
--- /dev/null
+++ b/src/utils/config.c
@@ -0,0 +1,97 @@
+/*
+ * Configuration parsing
+ * Copyright (c) 2021, Patrick Steinhardt <ps at pks.im>
+ *
+ * This software may be distributed under the terms of the BSD license.
+ * See README for more details.
+ */
+
+#include "includes.h"
+
+#include "utils/config.h"
+#include "common.h"
+
+
+static int newline_terminated(const char *buf, size_t buflen)
+{
+	size_t len = os_strlen(buf);
+	if (len == 0)
+		return 0;
+	if (len == buflen - 1 && buf[buflen - 1] != '\r' &&
+	    buf[len - 1] != '\n')
+		return 0;
+	return 1;
+}
+
+
+static void skip_line_end(FILE *stream)
+{
+	char buf[100];
+	while (fgets(buf, sizeof(buf), stream)) {
+		buf[sizeof(buf) - 1] = '\0';
+		if (newline_terminated(buf, sizeof(buf)))
+			return;
+	}
+}
+
+
+char * wpa_config_get_line(char *s, int size, FILE *stream, int *line,
+				  char **_pos)
+{
+	char *pos, *end, *sstart;
+
+	while (fgets(s, size, stream)) {
+		(*line)++;
+		s[size - 1] = '\0';
+		if (!newline_terminated(s, size)) {
+			/*
+			 * The line was truncated - skip rest of it to avoid
+			 * confusing error messages.
+			 */
+			wpa_printf(MSG_INFO, "Long line in configuration file "
+				   "truncated");
+			skip_line_end(stream);
+		}
+		pos = s;
+
+		/* Skip white space from the beginning of line. */
+		while (*pos == ' ' || *pos == '\t' || *pos == '\r')
+			pos++;
+
+		/* Skip comment lines and empty lines */
+		if (*pos == '#' || *pos == '\n' || *pos == '\0')
+			continue;
+
+		/*
+		 * Remove # comments unless they are within a double quoted
+		 * string.
+		 */
+		sstart = os_strchr(pos, '"');
+		if (sstart)
+			sstart = os_strrchr(sstart + 1, '"');
+		if (!sstart)
+			sstart = pos;
+		end = os_strchr(sstart, '#');
+		if (end)
+			*end-- = '\0';
+		else
+			end = pos + os_strlen(pos) - 1;
+
+		/* Remove trailing white space. */
+		while (end > pos &&
+		       (*end == '\n' || *end == ' ' || *end == '\t' ||
+			*end == '\r'))
+			*end-- = '\0';
+
+		if (*pos == '\0')
+			continue;
+
+		if (_pos)
+			*_pos = pos;
+		return pos;
+	}
+
+	if (_pos)
+		*_pos = NULL;
+	return NULL;
+}
diff --git a/src/utils/config.h b/src/utils/config.h
new file mode 100644
index 000000000..fd4472a34
--- /dev/null
+++ b/src/utils/config.h
@@ -0,0 +1,31 @@
+/*
+ * Configuration parsing
+ * Copyright (c) 2021, Patrick Steinhardt <ps at pks.im>
+ *
+ * This software may be distributed under the terms of the BSD license.
+ * See README for more details.
+ */
+
+#ifndef UTILS_CONFIG_H
+#define UTILS_CONFIG_H
+
+#include "includes.h"
+
+/**
+ * wpa_config_get_line - Read the next configuration file line
+ * @s: Buffer for the line
+ * @size: The buffer length
+ * @stream: File stream to read from
+ * @line: Pointer to a variable storing the file line number
+ * @_pos: Buffer for the pointer to the beginning of data on the text line or
+ * %NULL if not needed (returned value used instead)
+ * Returns: Pointer to the beginning of data on the text line or %NULL if no
+ * more text lines are available.
+ *
+ * This function reads the next non-empty line from the configuration file and
+ * removes comments. The returned string is guaranteed to be null-terminated.
+ */
+char * wpa_config_get_line(char *s, int size, FILE *stream, int *line,
+			   char **_pos);
+
+#endif /* UTILS_CONFIG_H */
diff --git a/wpa_supplicant/Makefile b/wpa_supplicant/Makefile
index 59b054cd2..6a92aaace 100644
--- a/wpa_supplicant/Makefile
+++ b/wpa_supplicant/Makefile
@@ -83,6 +83,7 @@ OBJS += notify.o
 OBJS += bss.o
 OBJS += eap_register.o
 OBJS += ../src/utils/common.o
+OBJS += ../src/utils/config.o
 OBJS += ../src/utils/wpa_debug.o
 OBJS += ../src/utils/wpabuf.o
 OBJS += ../src/utils/bitfield.o
@@ -93,6 +94,7 @@ OBJS += rrm.o
 OBJS += robust_av.o
 OBJS_p = wpa_passphrase.o
 OBJS_p += ../src/utils/common.o
+OBJS_p += ../src/utils/config.o
 OBJS_p += ../src/utils/wpa_debug.o
 OBJS_p += ../src/utils/wpabuf.o
 OBJS_c = wpa_cli.o ../src/common/wpa_ctrl.o
diff --git a/wpa_supplicant/config_file.c b/wpa_supplicant/config_file.c
index fd6275e22..a535e3f08 100644
--- a/wpa_supplicant/config_file.c
+++ b/wpa_supplicant/config_file.c
@@ -23,105 +23,7 @@
 #include "p2p/p2p.h"
 #include "eap_peer/eap_methods.h"
 #include "eap_peer/eap.h"
-
-
-static int newline_terminated(const char *buf, size_t buflen)
-{
-	size_t len = os_strlen(buf);
-	if (len == 0)
-		return 0;
-	if (len == buflen - 1 && buf[buflen - 1] != '\r' &&
-	    buf[len - 1] != '\n')
-		return 0;
-	return 1;
-}
-
-
-static void skip_line_end(FILE *stream)
-{
-	char buf[100];
-	while (fgets(buf, sizeof(buf), stream)) {
-		buf[sizeof(buf) - 1] = '\0';
-		if (newline_terminated(buf, sizeof(buf)))
-			return;
-	}
-}
-
-
-/**
- * wpa_config_get_line - Read the next configuration file line
- * @s: Buffer for the line
- * @size: The buffer length
- * @stream: File stream to read from
- * @line: Pointer to a variable storing the file line number
- * @_pos: Buffer for the pointer to the beginning of data on the text line or
- * %NULL if not needed (returned value used instead)
- * Returns: Pointer to the beginning of data on the text line or %NULL if no
- * more text lines are available.
- *
- * This function reads the next non-empty line from the configuration file and
- * removes comments. The returned string is guaranteed to be null-terminated.
- */
-static char * wpa_config_get_line(char *s, int size, FILE *stream, int *line,
-				  char **_pos)
-{
-	char *pos, *end, *sstart;
-
-	while (fgets(s, size, stream)) {
-		(*line)++;
-		s[size - 1] = '\0';
-		if (!newline_terminated(s, size)) {
-			/*
-			 * The line was truncated - skip rest of it to avoid
-			 * confusing error messages.
-			 */
-			wpa_printf(MSG_INFO, "Long line in configuration file "
-				   "truncated");
-			skip_line_end(stream);
-		}
-		pos = s;
-
-		/* Skip white space from the beginning of line. */
-		while (*pos == ' ' || *pos == '\t' || *pos == '\r')
-			pos++;
-
-		/* Skip comment lines and empty lines */
-		if (*pos == '#' || *pos == '\n' || *pos == '\0')
-			continue;
-
-		/*
-		 * Remove # comments unless they are within a double quoted
-		 * string.
-		 */
-		sstart = os_strchr(pos, '"');
-		if (sstart)
-			sstart = os_strrchr(sstart + 1, '"');
-		if (!sstart)
-			sstart = pos;
-		end = os_strchr(sstart, '#');
-		if (end)
-			*end-- = '\0';
-		else
-			end = pos + os_strlen(pos) - 1;
-
-		/* Remove trailing white space. */
-		while (end > pos &&
-		       (*end == '\n' || *end == ' ' || *end == '\t' ||
-			*end == '\r'))
-			*end-- = '\0';
-
-		if (*pos == '\0')
-			continue;
-
-		if (_pos)
-			*_pos = pos;
-		return pos;
-	}
-
-	if (_pos)
-		*_pos = NULL;
-	return NULL;
-}
+#include "utils/config.h"
 
 
 static int wpa_config_validate_network(struct wpa_ssid *ssid, int line)
-- 
2.30.0

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/hostap/attachments/20210207/89768e25/attachment.sig>

From ps at pks.im  Sun Feb  7 12:48:36 2021
From: ps at pks.im (Patrick Steinhardt)
Date: Sun, 7 Feb 2021 18:48:36 +0100
Subject: [PATCH 2/2] ext_password: Implement new file-based backend
In-Reply-To: <cover.1612720013.git.ps@pks.im>
References: <cover.1612720013.git.ps@pks.im>
Message-ID: <6f9819204cd32b37ad98c3d24c18469d1d7db3ea.1612720013.git.ps@pks.im>

It's currently not easily possible to separate configuration of an
interface and credentials. This makes it hard to distribute
configuration across a set of nodes which use wpa_supplicant without
also having to store credentials in the same file. While this can be
solved via scripting, having a native way to achieve this would be
preferable.

Turns out there already is a framework to have external password
storages. It only has a single "test" backend though, which is kind of
an in-memory store which gets initialized with all passwords up front.
This isn't really suitable for above usecase: the backend cannot be
initialized as part of the central configuration given that it needs the
credentials, and we want to avoid scripting.

This commit thus extends the infrastructure to implement a new backend,
which instead uses a simple configuration file containing key-value
pairs. The file follows the format which wpa_supplicant.conf(5) uses:
empty lines and comments are ignored, while passwords can be specified
with simple `password-name=password-value` assignments.

With this new backend, splitting up credentials and configuration
becomes trivial:

    # /etc/wpa_supplicant/wpa_supplicant.conf
    ext_password_backend=file:/etc/wpa_supplicant/psk.conf

    network={
        ssid="foobar"
        psk=ext:foobar
    }

    # /etc/wpa_supplicant/psk.conf
    foobar=ecdabff9c80632ec6fcffc4a8875e95d45cf93376d3b99da6881298853dc686b

Alternative approaches would be to support including other configuration
files in the main configuration, such that common configuration and
network declarations including credentials are split up into separate
files. But the implementation would probably have been more complex
compared to reusing the already-existing framework for external password
backends.

Signed-off-by: Patrick Steinhardt <ps at pks.im>
---
 src/utils/ext_password.c      |   3 +
 src/utils/ext_password_file.c | 129 ++++++++++++++++++++++++++++++++++
 src/utils/ext_password_i.h    |   4 ++
 wpa_supplicant/Makefile       |   6 ++
 4 files changed, 142 insertions(+)
 create mode 100644 src/utils/ext_password_file.c

diff --git a/src/utils/ext_password.c b/src/utils/ext_password.c
index 5615bd72a..cbf92de8c 100644
--- a/src/utils/ext_password.c
+++ b/src/utils/ext_password.c
@@ -20,6 +20,9 @@ static const struct ext_password_backend *backends[] = {
 #ifdef CONFIG_EXT_PASSWORD_TEST
 	&ext_password_test,
 #endif /* CONFIG_EXT_PASSWORD_TEST */
+#ifdef CONFIG_EXT_PASSWORD_FILE
+	&ext_password_file,
+#endif /* CONFIG_EXT_PASSWORD_FILE */
 	NULL
 };
 
diff --git a/src/utils/ext_password_file.c b/src/utils/ext_password_file.c
new file mode 100644
index 000000000..9bb0cb823
--- /dev/null
+++ b/src/utils/ext_password_file.c
@@ -0,0 +1,129 @@
+/*
+ * External backend for file-backed passwords
+ * Copyright (c) 2021, Patrick Steinhardt <ps at pks.im>
+ *
+ * This software may be distributed under the terms of the BSD license.
+ * See README for more details.
+ */
+
+#include "includes.h"
+
+#include "common.h"
+#include "ext_password_i.h"
+#include "utils/config.h"
+
+
+/**
+ * Data structure for the file-backed password backend.
+ */
+struct ext_password_file_data {
+	char *path; /* path of the password file */
+};
+
+
+/**
+ * ext_password_file_init - Initialize file-backed password backend
+ * @params: Parameters passed by the user.
+ * Returns: Pointer to the initialized backend.
+ *
+ * This function initializes a new file-backed password backend. The user is
+ * expected to initialize this backend with the parameters being the path of
+ * the file that contains the passwords.
+ */
+static void * ext_password_file_init(const char *params)
+{
+	struct ext_password_file_data *data;
+
+	if (!params) {
+		wpa_printf(MSG_ERROR, "EXT PW FILE: no path given");
+		return NULL;
+	}
+
+	data = os_zalloc(sizeof(*data));
+	if (data == NULL)
+		return NULL;
+	data->path = os_strdup(params);
+
+	return data;
+}
+
+
+/**
+ * ext_password_file_deinit - Deinitialize file-backed password backend
+ * @param ctx: The file-backed password backend
+ *
+ * This function frees all data associated with the file-backed password
+ * backend.
+ */
+static void ext_password_file_deinit(void *ctx)
+{
+	struct ext_password_file_data *data = ctx;
+
+	str_clear_free(data->path);
+	os_free(data);
+}
+
+/**
+ * ext_password_file_get - Retrieve password from the file-backed password backend
+ * @param ctx: The file-backed password backend
+ * @param name: Name of the password to retrieve
+ * Returns: Buffer containing the password if one was found or %NULL.
+ *
+ * This function tries to find a password identified by name in the password
+ * file. The password is expected to be stored in `NAME=PASSWORD` format.
+ * Comments and empty lines in the file are ignored. Invalid lines will cause
+ * an error message, but will not cause the function to fail.
+ */
+static struct wpabuf * ext_password_file_get(void *ctx, const char *name)
+{
+	struct ext_password_file_data *data = ctx;
+	struct wpabuf *password = NULL;
+	char buf[512], *pos;
+	int line = 0;
+	FILE *f;
+
+	f = fopen(data->path, "r");
+	if (f == NULL) {
+		wpa_printf(MSG_ERROR, "EXT PW FILE: could not open file '%s': %s",
+			   data->path, strerror(errno));
+		return NULL;
+	}
+
+	wpa_printf(MSG_DEBUG, "EXT PW FILE: get(%s)", name);
+
+	while (wpa_config_get_line(buf, sizeof(buf), f, &line, &pos)) {
+		char *sep = os_strchr(pos, '=');
+		if (!sep) {
+			wpa_printf(MSG_ERROR, "Invalid password line %d: '%s'.",
+				   line, buf);
+			continue;
+		}
+
+		if (!sep[1]) {
+			wpa_printf(MSG_ERROR, "No password for line %d: '%s'.",
+				   line, buf);
+			continue;
+
+		}
+
+		if (os_strncmp(name, pos, sep - pos))
+			continue;
+
+		password = wpabuf_alloc_copy(sep + 1, os_strlen(sep + 1));
+		goto done;
+	}
+
+	wpa_printf(MSG_ERROR, "Password for '%s' was not found.", name);
+
+done:
+	fclose(f);
+	return password;
+}
+
+
+const struct ext_password_backend ext_password_file = {
+	.name = "file",
+	.init = ext_password_file_init,
+	.deinit = ext_password_file_deinit,
+	.get = ext_password_file_get,
+};
diff --git a/src/utils/ext_password_i.h b/src/utils/ext_password_i.h
index 948eaf542..872ccd195 100644
--- a/src/utils/ext_password_i.h
+++ b/src/utils/ext_password_i.h
@@ -26,4 +26,8 @@ struct wpabuf * ext_password_alloc(size_t len);
 extern const struct ext_password_backend ext_password_test;
 #endif /* CONFIG_EXT_PASSWORD_TEST */
 
+#ifdef CONFIG_EXT_PASSWORD_FILE
+extern const struct ext_password_backend ext_password_file;
+#endif /* CONFIG_EXT_PASSWORD_FILE */
+
 #endif /* EXT_PASSWORD_I_H */
diff --git a/wpa_supplicant/Makefile b/wpa_supplicant/Makefile
index 6a92aaace..a59003ef2 100644
--- a/wpa_supplicant/Makefile
+++ b/wpa_supplicant/Makefile
@@ -1752,6 +1752,12 @@ CFLAGS += -DCONFIG_EXT_PASSWORD_TEST
 NEED_EXT_PASSWORD=y
 endif
 
+ifdef CONFIG_EXT_PASSWORD_FILE
+OBJS += ../src/utils/ext_password_file.o
+CFLAGS += -DCONFIG_EXT_PASSWORD_FILE
+NEED_EXT_PASSWORD=y
+endif
+
 ifdef NEED_EXT_PASSWORD
 OBJS += ../src/utils/ext_password.o
 CFLAGS += -DCONFIG_EXT_PASSWORD
-- 
2.30.0

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/hostap/attachments/20210207/a3141922/attachment-0001.sig>

From astrand at lysator.liu.se  Sun Feb  7 15:07:56 2021
From: astrand at lysator.liu.se (=?UTF-8?Q?Peter_=C3=85strand?=)
Date: Sun, 7 Feb 2021 21:07:56 +0100 (CET)
Subject: [PATCH 6/6] SAE: Make H2E work with multiple passwords
In-Reply-To: <20210206105850.GD425833@w1.fi>
References: <775d39b6-c57d-41f-db82-7f11c27b5376@lysator.liu.se>
 <20210206105850.GD425833@w1.fi>
Message-ID: <23a3fe71-af2f-a480-e076-84fa2d52d65@lysator.liu.se>

On Sat, 6 Feb 2021, Jouni Malinen wrote:

> On Fri, Jan 22, 2021 at 03:59:59PM +0100, Peter ?strand wrote:
> > Need to derive pt for all sae_passwords, as well as
> > initially call auth_sae_send_commit with update=1.
> 
> Similar comments here..
> 
> What kind of testing did you do with this set of patches? When I tried
> using SAE Password Identifier with the mac80211 implementation not
> supporting RSNXE inclusion in Beacon/Probe Response frames. Has that
> been implemented now?

Thanks for all feedback. I have tested Mesh connections between an iMX6 
system as well as multiple BeagleBone Green Wireless systems. All running 
Linux 5.4.24, and with WiFi chip TI WL1835. No kernel patches except the 
TI WiLink patches (port to 5.4 per 
https://github.com/astrand/wilink8-wlan-build-utilites/commits/r8.8). 
Communication has been monitored using Wireshark, so I have confirmed that 
H2E is really used. Don't know anything about RSNXE, unfortunately.


> In addition to the change on where the SAE passwords would be stored,
> I'd like to see this functionality working with mac80211_hwsim before
> I'd consider applying it. In other words, new test cases to
> tests/hwsim/test_wpas_mesh.py would be highly appreciated. For now, I'm
> dropping the patches since it does not seem very useful to apply the
> first two before the password configuration location has been resolved.

Makes sense! It might take some time, but I'll make a try.

Best regards,
Peter

From j at w1.fi  Sun Feb  7 17:42:53 2021
From: j at w1.fi (Jouni Malinen)
Date: Mon, 8 Feb 2021 00:42:53 +0200
Subject: [PATCH] nl80211: clear VHT and HE MCS rates in legacy beacon tx
 rate
In-Reply-To: <1601717108-1030-1-git-send-email-rmanohar@codeaurora.org>
References: <1601717108-1030-1-git-send-email-rmanohar@codeaurora.org>
Message-ID: <20210207224253.GA1781959@w1.fi>

On Sat, Oct 03, 2020 at 02:25:08AM -0700, Rajkumar Manoharan wrote:
> While configuring legacy beacon rate, VHT and HE MCS rates must be cleared.
> Otherwise the default MCS rates is filled by cfg80211 while validating beacon
> tx rate netlink attribute. This issue is exposed by ap_beacon_rate_legacy2
> test case while validating HE MCS beacon tx rate support.

I'm dropping this based on the discussion on where this should be fixed
(in kernel instead of hostapd).

-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Sun Feb  7 18:12:47 2021
From: j at w1.fi (Jouni Malinen)
Date: Mon, 8 Feb 2021 01:12:47 +0200
Subject: [PATCH v2] hostapd: Add HE 6 GHz band capability configuration
In-Reply-To: <1601706856-11792-1-git-send-email-rmanohar@codeaurora.org>
References: <1601706856-11792-1-git-send-email-rmanohar@codeaurora.org>
Message-ID: <20210207231247.GA2200231@w1.fi>

On Fri, Oct 02, 2020 at 11:34:16PM -0700, Rajkumar Manoharan wrote:
> Enable user to configure Maximum MPDU Length, Maximum A-MPDU Length
> Exponent, Rx Antenna Pattern Consistency and Tx Antenna Pattern
> Consistency of 6 GHz capability through config file.

Thanks, applied.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Sun Feb  7 18:14:14 2021
From: j at w1.fi (Jouni Malinen)
Date: Mon, 8 Feb 2021 01:14:14 +0200
Subject: [PATCH 1/2] nl80211: Allow HE MCS rate selection for beacon frame
In-Reply-To: <1601717476-7674-1-git-send-email-rmanohar@codeaurora.org>
References: <1601717476-7674-1-git-send-email-rmanohar@codeaurora.org>
Message-ID: <20210207231414.GB2200231@w1.fi>

On Sat, Oct 03, 2020 at 02:31:15AM -0700, Rajkumar Manoharan wrote:
> Allow HE MCS rate to be used for beacon transmission when the driver
> advertises the support.

Thanks, both applied.

> diff --git a/src/drivers/driver_nl80211.c b/src/drivers/driver_nl80211.c
> @@ -4182,7 +4183,10 @@ static int nl80211_put_beacon_rate(struct nl_msg *msg, const u64 flags,
>  	case HOSTAPD_MODE_IEEE80211A:
> -		band = nla_nest_start(msg, NL80211_BAND_5GHZ);
> +		if (is_6ghz_freq(params->freq->freq))
> +			band = nla_nest_start(msg, NL80211_BAND_6GHZ);
> +		else
> +			band = nla_nest_start(msg, NL80211_BAND_5GHZ);

This does not seem to belong into this patch, so I moved it into a
separate commit.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Sun Feb  7 18:14:37 2021
From: j at w1.fi (Jouni Malinen)
Date: Mon, 8 Feb 2021 01:14:37 +0200
Subject: [PATCH] hw_feature: Correctly select mode in case of 6GHz
In-Reply-To: <20201022110025.16987-1-andrei.otcheretianski@intel.com>
References: <20201022110025.16987-1-andrei.otcheretianski@intel.com>
Message-ID: <20210207231437.GC2200231@w1.fi>

On Thu, Oct 22, 2020 at 02:00:25PM +0300, Andrei Otcheretianski wrote:
> There are 2 HW modes with IEEE80211_MODE_A: one for the 5GHz channels
> and one for 6GHz channels. Since hw_get_chan() checks all the compatible
> hw modes, eventually, an incorrect hw mode is selected.
> 
> To fix this, add a function that checks if a specific mode supports
> the requested frequency and if so use it as the current mode.

Thanks, applied.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From johannes at sipsolutions.net  Mon Feb  8 03:08:06 2021
From: johannes at sipsolutions.net (Johannes Berg)
Date: Mon, 08 Feb 2021 09:08:06 +0100
Subject: [PATCH] nl80211: clear VHT and HE MCS rates in legacy beacon tx
 rate
In-Reply-To: <20210207224253.GA1781959@w1.fi>
References: <1601717108-1030-1-git-send-email-rmanohar@codeaurora.org>
 <20210207224253.GA1781959@w1.fi>
Message-ID: <039f4c32deb2b4495bd87548db57648da9d69363.camel@sipsolutions.net>

On Mon, 2021-02-08 at 00:42 +0200, Jouni Malinen wrote:
> On Sat, Oct 03, 2020 at 02:25:08AM -0700, Rajkumar Manoharan wrote:
> > While configuring legacy beacon rate, VHT and HE MCS rates must be cleared.
> > Otherwise the default MCS rates is filled by cfg80211 while validating beacon
> > tx rate netlink attribute. This issue is exposed by ap_beacon_rate_legacy2
> > test case while validating HE MCS beacon tx rate support.
> 
> I'm dropping this based on the discussion on where this should be fixed
> (in kernel instead of hostapd).

And indeed has been.

johannes



From kazikcz at gmail.com  Mon Feb  8 10:32:05 2021
From: kazikcz at gmail.com (Michal Kazior)
Date: Mon,  8 Feb 2021 15:32:05 +0000
Subject: [PATCH 1/3] wpa_supplicant: expose DPP config object AKM
Message-ID: <20210208153207.108755-1-kazikcz@gmail.com>

From: Michal Kazior <michal at plume.com>

Hostapd was already exposing this. There's no
reason not to expose it in wpa_supplicant.

This allows 3rd party apps interacting with the
control interface to handle DPP events to get
configs instead of needing to dance around with
update_config=1 and save_config.

Signed-off-by: Michal Kazior <michal at plume.com>
---
 wpa_supplicant/dpp_supplicant.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/wpa_supplicant/dpp_supplicant.c b/wpa_supplicant/dpp_supplicant.c
index 910602e34..01e7fce26 100644
--- a/wpa_supplicant/dpp_supplicant.c
+++ b/wpa_supplicant/dpp_supplicant.c
@@ -1441,6 +1441,8 @@ static int wpas_dpp_handle_config_obj(struct wpa_supplicant *wpa_s,
 				      struct dpp_config_obj *conf)
 {
 	wpa_msg(wpa_s, MSG_INFO, DPP_EVENT_CONF_RECEIVED);
+	wpa_msg(wpa_s, MSG_INFO, DPP_EVENT_CONFOBJ_AKM "%s",
+		dpp_akm_str(conf->akm));
 	if (conf->ssid_len)
 		wpa_msg(wpa_s, MSG_INFO, DPP_EVENT_CONFOBJ_SSID "%s",
 			wpa_ssid_txt(conf->ssid, conf->ssid_len));
-- 
2.27.0



From kazikcz at gmail.com  Mon Feb  8 10:32:07 2021
From: kazikcz at gmail.com (Michal Kazior)
Date: Mon,  8 Feb 2021 15:32:07 +0000
Subject: [PATCH 3/3] DPP: prevent processing dpp action frames when stopped
In-Reply-To: <20210208153207.108755-1-kazikcz@gmail.com>
References: <20210208153207.108755-1-kazikcz@gmail.com>
Message-ID: <20210208153207.108755-3-kazikcz@gmail.com>

From: Michal Kazior <michal at plume.com>

DPP configurator params can be configured per
interface. DPP listening can also be started and
stopped per interface.

However DPP rx processing was always doomed to
process incomming frames even on interfaces which
were not explicitly started to do DPP listen. This
happened because not only the initial value but
also because the dpp_allowed_roles could never be
reset to 0.

This would result in random failures in
configuring Enrollees when running multiple AP
interfaces if some of these APs happened to not
have DPP configurator params set.

Signed-off-by: Michal Kazior <michal at plume.com>
---
 src/ap/dpp_hostapd.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/ap/dpp_hostapd.c b/src/ap/dpp_hostapd.c
index e106df513..a787666cf 100644
--- a/src/ap/dpp_hostapd.c
+++ b/src/ap/dpp_hostapd.c
@@ -704,6 +704,7 @@ int hostapd_dpp_listen(struct hostapd_data *hapd, const char *cmd)
 
 void hostapd_dpp_listen_stop(struct hostapd_data *hapd)
 {
+	hapd->dpp_allowed_roles = 0;
 	hostapd_drv_dpp_listen(hapd, false);
 	/* TODO: Stop listen operation on non-operating channel */
 }
@@ -2226,7 +2227,7 @@ static int hostapd_dpp_add_controllers(struct hostapd_data *hapd)
 
 int hostapd_dpp_init(struct hostapd_data *hapd)
 {
-	hapd->dpp_allowed_roles = DPP_CAPAB_CONFIGURATOR | DPP_CAPAB_ENROLLEE;
+	hapd->dpp_allowed_roles = 0;
 	hapd->dpp_init_done = 1;
 	return hostapd_dpp_add_controllers(hapd);
 }
-- 
2.27.0



From kazikcz at gmail.com  Mon Feb  8 10:32:06 2021
From: kazikcz at gmail.com (Michal Kazior)
Date: Mon,  8 Feb 2021 15:32:06 +0000
Subject: [PATCH 2/3] wpa_supplicant: expose DPP config object PSK/PMK
In-Reply-To: <20210208153207.108755-1-kazikcz@gmail.com>
References: <20210208153207.108755-1-kazikcz@gmail.com>
Message-ID: <20210208153207.108755-2-kazikcz@gmail.com>

From: Michal Kazior <michal at plume.com>

Hostapd was already exposing this. There's no
reason not to expose it in wpa_supplicant.

This allows 3rd party apps interacting with the
control interface to handle DPP events to get
configs instead of needing to dance around with
update_config=1 and save_config.

Signed-off-by: Michal Kazior <michal at plume.com>
---
 wpa_supplicant/dpp_supplicant.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/wpa_supplicant/dpp_supplicant.c b/wpa_supplicant/dpp_supplicant.c
index 01e7fce26..efa75ff8e 100644
--- a/wpa_supplicant/dpp_supplicant.c
+++ b/wpa_supplicant/dpp_supplicant.c
@@ -1458,6 +1458,21 @@ static int wpas_dpp_handle_config_obj(struct wpa_supplicant *wpa_s,
 		wpa_msg(wpa_s, MSG_INFO, DPP_EVENT_CONNECTOR "%s",
 			conf->connector);
 	}
+	if (conf->passphrase[0]) {
+		char hex[64 * 2 + 1];
+
+		wpa_snprintf_hex(hex, sizeof(hex),
+				 (const u8 *) conf->passphrase,
+				 os_strlen(conf->passphrase));
+		wpa_msg(wpa_s, MSG_INFO, DPP_EVENT_CONFOBJ_PASS "%s",
+			hex);
+	} else if (conf->psk_set) {
+		char hex[PMK_LEN * 2 + 1];
+
+		wpa_snprintf_hex(hex, sizeof(hex), conf->psk, PMK_LEN);
+		wpa_msg(wpa_s, MSG_INFO, DPP_EVENT_CONFOBJ_PSK "%s",
+			hex);
+	}
 	if (conf->c_sign_key) {
 		char *hex;
 		size_t hexlen;
-- 
2.27.0



From raphael.melotte at mind.be  Mon Feb  8 12:28:23 2021
From: raphael.melotte at mind.be (=?UTF-8?q?Rapha=C3=ABl=20M=C3=A9lotte?=)
Date: Mon,  8 Feb 2021 18:28:23 +0100
Subject: [PATCH] wpa_supplicant: multi_ap: only enable 4addr mode if not
 already enabled
Message-ID: <20210208172823.11536-1-raphael.melotte@mind.be>

If 4addr mode is already enabled, the call to enable it a second time
may fail. If this happens when roaming, it leads to deauthentication.

Signed-off-by: Rapha?l M?lotte <raphael.melotte at mind.be>
---
 wpa_supplicant/events.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/wpa_supplicant/events.c b/wpa_supplicant/events.c
index 199829bcf..7682dae76 100644
--- a/wpa_supplicant/events.c
+++ b/wpa_supplicant/events.c
@@ -2627,11 +2627,13 @@ static void multi_ap_set_4addr_mode(struct wpa_supplicant *wpa_s)
 		goto fail;
 	}
 
-	if (wpa_drv_set_4addr_mode(wpa_s, 1) < 0) {
-		wpa_printf(MSG_ERROR, "Failed to set 4addr mode");
-		goto fail;
+	if (wpa_s->enabled_4addr_mode == 0) {
+		if (wpa_drv_set_4addr_mode(wpa_s, 1) < 0) {
+			wpa_printf(MSG_ERROR, "Failed to set 4addr mode");
+			goto fail;
+		}
+		wpa_s->enabled_4addr_mode = 1;
 	}
-	wpa_s->enabled_4addr_mode = 1;
 	return;
 
 fail:
-- 
2.29.2



From juliusz at wolfssl.com  Mon Feb  8 03:34:07 2021
From: juliusz at wolfssl.com (Juliusz Sosinowicz)
Date: Mon,  8 Feb 2021 09:34:07 +0100
Subject: [PATCH] wolfSSL: wolfSSL_use_PrivateKey_* correct return codes
Message-ID: <20210208083407.6213-1-juliusz@wolfssl.com>

The wolfSSL_use_PrivateKey_* APIs return 1 on success. 0 is also an error.

Signed-off-by: Juliusz Sosinowicz <juliusz at wolfssl.com>
---
 src/crypto/tls_wolfssl.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/crypto/tls_wolfssl.c b/src/crypto/tls_wolfssl.c
index ea8f7063b..cf482bfc3 100644
--- a/src/crypto/tls_wolfssl.c
+++ b/src/crypto/tls_wolfssl.c
@@ -534,7 +534,7 @@ static int tls_connection_private_key(void *tls_ctx,
 	if (private_key_blob) {
 		if (wolfSSL_use_PrivateKey_buffer(conn->ssl,
 						  private_key_blob, blob_len,
-						  SSL_FILETYPE_ASN1) < 0) {
+						  SSL_FILETYPE_ASN1) <= 0) {
 			wpa_printf(MSG_INFO,
 				   "SSL: use private DER blob failed");
 		} else {
@@ -545,11 +545,11 @@ static int tls_connection_private_key(void *tls_ctx,
 
 	if (!ok && private_key) {
 		if (wolfSSL_use_PrivateKey_file(conn->ssl, private_key,
-						SSL_FILETYPE_PEM) < 0) {
+						SSL_FILETYPE_PEM) <= 0) {
 			wpa_printf(MSG_INFO,
 				   "SSL: use private key PEM file failed");
 			if (wolfSSL_use_PrivateKey_file(conn->ssl, private_key,
-							SSL_FILETYPE_ASN1) < 0)
+							SSL_FILETYPE_ASN1) <= 0)
 			{
 				wpa_printf(MSG_INFO,
 					   "SSL: use private key DER file failed");
-- 
2.25.1



From michal at plume.com  Mon Feb  8 09:20:37 2021
From: michal at plume.com (Michal Kazior)
Date: Mon, 8 Feb 2021 15:20:37 +0100
Subject: [PATCH 2/2] wpa_supplicant: fix chirping on sta enrollee scenario
In-Reply-To: <20210206141437.GA834632@w1.fi>
References: <20201215093455.51933-1-kazikcz@gmail.com>
 <20201215093455.51933-2-kazikcz@gmail.com>
 <20210206141437.GA834632@w1.fi>
Message-ID: <CABqz6Wx-nYGmSDLrwW+gqcwGAAJ=HTnNye92LOzcz8gX4Y7h6g@mail.gmail.com>

On Sat, Feb 6, 2021 at 3:14 PM Jouni Malinen <j at w1.fi> wrote:
>
> On Tue, Dec 15, 2020 at 09:34:55AM +0000, Michal Kazior wrote:
> > Some time ago it was found some drivers are
> > setting their hw/ucode rx filters restrictively
> > enough to prevent DPP multicast frames from being
> > delivered.
> >
> > A set of patches was introduced to the kernel and
> > ath9k driver as well as hostapd, eg.
> >
> >   a39e9af90 ("nl80211: DPP listen mode callback")
> >   4d2ec436e ("DPP: Add driver operation for enabling/disabling listen mode")
>
> So all this applies to patch 1/2 where hostapd side was not previously
> covered. However, I'm not sure I understand why that description is here
> in patch 2/2 as well..

I felt it's similar enough it warrants the same context to be provided.


> > Turns out chirping was omitted. As such chirping
> > wasn't working on drivers with restrictive rx
> > filters.
>
> This sounds strange.. The response to chirping would be a unicast frame,
> so that hardware/firmware RX filter change should not have any impact
> here.

Now that you say it, it would make sense to expect a unicast frame to
be sent back to the chirping station. But that's not what is
happening.

This is output from a script I used to test the problem. It prefixes
prints from wpa_s and hostapd, and you can see hostapd is responding
with a type=0 bcast.

> wpas    wlp11s0: DPP-TX dst=ff:ff:ff:ff:ff:ff freq=2437 type=13
> wpas    wlp11s0: DPP-TX dst=ff:ff:ff:ff:ff:ff freq=5745 type=13
> wpas    wlp11s0: DPP-TX dst=ff:ff:ff:ff:ff:ff freq=2412 type=13
> hapd    wlp2s0: DPP-RX src=2c:d0:5a:66:88:74 freq=2412 type=13
> hapd    wlp2s0: DPP-CHIRP-RX id=1 src=2c:d0:5a:66:88:74 freq=2412 hash=c4919f3a9600ad74f07614e2efcb63879bc6dbebf57a55a31dfcea9514ecc9d5
> hapd    wlp2s0: DPP-TX dst=ff:ff:ff:ff:ff:ff freq=2412 type=0
> wpas    wlp11s0: DPP-RX src=9c:b7:0d:43:77:48 freq=2412 type=0
> wpas    wlp11s0: DPP-CHIRP-STOPPED
> wpas    wlp11s0: DPP-TX dst=9c:b7:0d:43:77:48 freq=2412 type=1
> hapd    wlp2s0: DPP-RX src=2c:d0:5a:66:88:74 freq=2412 type=1
> hapd    wlp2s0: DPP-AUTH-DIRECTION mutual=0
> hapd    wlp2s0: DPP-TX dst=2c:d0:5a:66:88:74 freq=2412 type=2
> hapd    wlp2s0: DPP-TX-STATUS dst=2c:d0:5a:66:88:74 result=SUCCESS
> hapd    wlp2s0: DPP-AUTH-SUCCESS init=1
> hapd    wlp2s0: DPP-CONF-REQ-RX src=2c:d0:5a:66:88:74
> hapd    wlp2s0: DPP-BAND-SUPPORT 81,83,84,115,116,117,118,119,120,121,122,123,124,125,126,127
> hapd    wlp2s0: DPP-RX src=2c:d0:5a:66:88:74 freq=2412 type=11
> hapd    wlp2s0: DPP-CONF-SENT
(snip)

This is buffered a bit but it is roughly chronological.

Without this patch what I see is this:

> wpas    wlp11s0: DPP-TX dst=ff:ff:ff:ff:ff:ff freq=2437 type=13
> hapd    wlp2s0: DPP-RX src=2c:d0:5a:66:88:74 freq=2412 type=13
> hapd    wlp2s0: DPP-CHIRP-RX id=1 src=2c:d0:5a:66:88:74 freq=2412 hash=5da8e3eaea337eca38b78a12787e83382b99628a16f675003757ed73720f1318
> hapd    wlp2s0: DPP-TX dst=ff:ff:ff:ff:ff:ff freq=2412 type=0
> wpas    wlp11s0: DPP-TX dst=ff:ff:ff:ff:ff:ff freq=5745 type=13
> wpas    wlp11s0: DPP-TX dst=ff:ff:ff:ff:ff:ff freq=2412 type=13
> hapd    wlp2s0: DPP-TX dst=ff:ff:ff:ff:ff:ff freq=2412 type=0
> hapd    nl80211: kernel reports: Match already configured
> hapd    wlp2s0: DPP-TX dst=ff:ff:ff:ff:ff:ff freq=2412 type=0
> hapd    nl80211: kernel reports: Match already configured
> hapd    wlp2s0: DPP-TX dst=ff:ff:ff:ff:ff:ff freq=2412 type=0
> hapd    nl80211: kernel reports: Match already configured
> wpas    wlp11s0: DPP-TX dst=ff:ff:ff:ff:ff:ff freq=2437 type=13
> wpas    wlp11s0: DPP-TX dst=ff:ff:ff:ff:ff:ff freq=5745 type=13
> wpas    wlp11s0: DPP-TX dst=ff:ff:ff:ff:ff:ff freq=2412 type=13
> hapd    wlp2s0: DPP-TX dst=ff:ff:ff:ff:ff:ff freq=2412 type=0
> hapd    nl80211: kernel reports: Match already configured
> hapd    DPP: No response received from responder - stopping initiation attempt
> hapd    wlp2s0: DPP-AUTH-INIT-FAILED


> > diff --git a/wpa_supplicant/dpp_supplicant.c b/wpa_supplicant/dpp_supplicant.c
> > @@ -3420,6 +3420,7 @@ static void wpas_dpp_chirp_tx_status(struct wpa_supplicant *wpa_s,
> >       wpa_printf(MSG_DEBUG, "DPP: Chirp send completed - wait for response");
> > +     wpas_dpp_listen_start(wpa_s, freq);
>
> This looks quite incorrect thing to do.. This function is called when
> the TX operation with 2000 ms wait for response gets TX status. It would
> not be appropriate to start DPP listen while that 2000 ms wait for the
> response is ongoing.

Do you mean that it's racy? I guess it is... The response may already
be lost when tx-status for the chirp is processed. Or do you mean
something else here?


Micha?


From janusz.dziedzic at gmail.com  Tue Feb  9 04:26:51 2021
From: janusz.dziedzic at gmail.com (Janusz Dziedzic)
Date: Tue, 9 Feb 2021 10:26:51 +0100
Subject: [PATCH] wpa_supplicant: multi_ap: only enable 4addr mode if not
 already enabled
In-Reply-To: <20210208172823.11536-1-raphael.melotte@mind.be>
References: <20210208172823.11536-1-raphael.melotte@mind.be>
Message-ID: <CAFED-jn5W09baaLteiu++GyoZCg4aq6-eK47=-NyaxhwLek0RA@mail.gmail.com>

pon., 8 lut 2021 o 18:30 Rapha?l M?lotte <raphael.melotte at mind.be> napisa?(a):
>
> If 4addr mode is already enabled, the call to enable it a second time
> may fail. If this happens when roaming, it leads to deauthentication.
>
> Signed-off-by: Rapha?l M?lotte <raphael.melotte at mind.be>
> ---
>  wpa_supplicant/events.c | 10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/wpa_supplicant/events.c b/wpa_supplicant/events.c
> index 199829bcf..7682dae76 100644
> --- a/wpa_supplicant/events.c
> +++ b/wpa_supplicant/events.c
> @@ -2627,11 +2627,13 @@ static void multi_ap_set_4addr_mode(struct wpa_supplicant *wpa_s)
>                 goto fail;
>         }
>
> -       if (wpa_drv_set_4addr_mode(wpa_s, 1) < 0) {
> -               wpa_printf(MSG_ERROR, "Failed to set 4addr mode");
> -               goto fail;
> +       if (wpa_s->enabled_4addr_mode == 0) {
> +               if (wpa_drv_set_4addr_mode(wpa_s, 1) < 0) {
> +                       wpa_printf(MSG_ERROR, "Failed to set 4addr mode");
> +                       goto fail;
> +               }
> +               wpa_s->enabled_4addr_mode = 1;
>         }
> -       wpa_s->enabled_4addr_mode = 1;
>         return;
>
Thanks for patch.

Today set_4addr_mode(1) fail with EBUSY if netdev is already in the bridge.
So, maybe we should fix it in cfg80211?

janusz at t2:~$ sudo ifconfig wlp1s0 up

janusz at t2:~$ sudo iw wlp1s0 set 4addr on
janusz at t2:~$ sudo iw wlp1s0 set 4addr on
janusz at t2:~$ sudo iw wlp1s0 set 4addr on

janusz at t2:~$ sudo brctl addbr br0
janusz at t2:~$ sudo brctl addif br0 wlp1s0
janusz at t2:~$ sudo iw wlp1s0 set 4addr on
command failed: Device or resource busy (-16)

janusz at t2:~$ sudo iw wlp1s0 info
Interface wlp1s0
ifindex 3
wdev 0x1
addr 68:94:23:28:a7:25
type managed
wiphy 0
txpower 16.00 dBm
multicast TXQ:
qsz-byt qsz-pkt flows drops marks overlmt hashcol tx-bytes tx-packets
0 0 0 0 0 0 0 0 0
4addr: on

BR
Janusz


From j at w1.fi  Tue Feb  9 13:40:40 2021
From: j at w1.fi (Jouni Malinen)
Date: Tue, 9 Feb 2021 20:40:40 +0200
Subject: [PATCH 2/2] wpa_supplicant: fix chirping on sta enrollee scenario
In-Reply-To: <CABqz6Wx-nYGmSDLrwW+gqcwGAAJ=HTnNye92LOzcz8gX4Y7h6g@mail.gmail.com>
References: <20201215093455.51933-1-kazikcz@gmail.com>
 <20201215093455.51933-2-kazikcz@gmail.com>
 <20210206141437.GA834632@w1.fi>
 <CABqz6Wx-nYGmSDLrwW+gqcwGAAJ=HTnNye92LOzcz8gX4Y7h6g@mail.gmail.com>
Message-ID: <20210209184040.GA36462@w1.fi>

On Mon, Feb 08, 2021 at 03:20:37PM +0100, Michal Kazior wrote:
> On Sat, Feb 6, 2021 at 3:14 PM Jouni Malinen <j at w1.fi> wrote:
> > This sounds strange.. The response to chirping would be a unicast frame,
> > so that hardware/firmware RX filter change should not have any impact
> > here.
> 
> Now that you say it, it would make sense to expect a unicast frame to
> be sent back to the chirping station. But that's not what is
> happening.
> 
> This is output from a script I used to test the problem. It prefixes
> prints from wpa_s and hostapd, and you can see hostapd is responding
> with a type=0 bcast.

That's a bug.. I'll fix it so that the Authentication Request frame goes
out as a unicast frame to the source address of the Presence
Announcement which is what the tech spec defines for this sequence.

> > > diff --git a/wpa_supplicant/dpp_supplicant.c b/wpa_supplicant/dpp_supplicant.c
> > > @@ -3420,6 +3420,7 @@ static void wpas_dpp_chirp_tx_status(struct wpa_supplicant *wpa_s,
> > >       wpa_printf(MSG_DEBUG, "DPP: Chirp send completed - wait for response");
> > > +     wpas_dpp_listen_start(wpa_s, freq);
> >
> > This looks quite incorrect thing to do.. This function is called when
> > the TX operation with 2000 ms wait for response gets TX status. It would
> > not be appropriate to start DPP listen while that 2000 ms wait for the
> > response is ongoing.
> 
> Do you mean that it's racy? I guess it is... The response may already
> be lost when tx-status for the chirp is processed. Or do you mean
> something else here?

Starting listen mode (ROC in mac80211) while already in
offchannel-TX-with-wait-for-response (also ROC) does not sound good
since there are constraints on how mac80211 allows ROCs to be combined
or extended.

This would also be a race condition since this call happens from TX
status handler and the Authentication Request frame may have already
been transmitted, but this was not my main concern (but it sounds like a
valid concern).

Since there are cases where the Authentication Request frame might still
be sent to the broadcast address while the Enrollee is in the chirping
loop, it would make sense to update the hardware RX filters. However,
this should be done without introducing a separate listen operation.
Wouldn't a call to wpa_drv_dpp_listen(wpa_s, true) when starting
chirping be all that's needed here? That would then need to be stopped
when chirping state terminates.

-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Tue Feb  9 13:53:15 2021
From: j at w1.fi (Jouni Malinen)
Date: Tue, 9 Feb 2021 20:53:15 +0200
Subject: [PATCH 3/3] DPP: prevent processing dpp action frames when stopped
In-Reply-To: <20210208153207.108755-3-kazikcz@gmail.com>
References: <20210208153207.108755-1-kazikcz@gmail.com>
 <20210208153207.108755-3-kazikcz@gmail.com>
Message-ID: <20210209185315.GB36462@w1.fi>

On Mon, Feb 08, 2021 at 03:32:07PM +0000, Michal Kazior wrote:
> DPP configurator params can be configured per
> interface. DPP listening can also be started and
> stopped per interface.
> 
> However DPP rx processing was always doomed to
> process incomming frames even on interfaces which
> were not explicitly started to do DPP listen. This
> happened because not only the initial value but
> also because the dpp_allowed_roles could never be
> reset to 0.

This is not really the way the DPP_LISTEN was designed for hostapd
originally. The expectation was the AP side does not need an explicit
DPP_LISTEN command to receive DPP frames on the operating channel, i.e.,
DPP_LISTEN would only be needed to do an off-channel listen operation.
Only later extensions to being able to configure parameters and HW RX
filters brought in cases where the DPP_LISTEN command might be needed.

> This would result in random failures in
> configuring Enrollees when running multiple AP
> interfaces if some of these APs happened to not
> have DPP configurator params set.

Can you please provide more details on where you are seeing issues from
this? The Responder should ignore the incoming DPP messages if they are
not targeting it (have a match in the bootstrapping key).

> diff --git a/src/ap/dpp_hostapd.c b/src/ap/dpp_hostapd.c

>  void hostapd_dpp_listen_stop(struct hostapd_data *hapd)
>  {
> +	hapd->dpp_allowed_roles = 0;

This might be a reasonable thing to do on an explicit DPP_LISTEN_STOP
operation.

>  int hostapd_dpp_init(struct hostapd_data *hapd)
>  {
> -	hapd->dpp_allowed_roles = DPP_CAPAB_CONFIGURATOR | DPP_CAPAB_ENROLLEE;
> +	hapd->dpp_allowed_roles = 0;

But this is the part that I'm a bit worried about since it changes the
past expectation of not requiring an explicit DPP_LISTEN command in some
cases.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Tue Feb  9 15:03:56 2021
From: j at w1.fi (Jouni Malinen)
Date: Tue, 9 Feb 2021 22:03:56 +0200
Subject: [PATCH] wolfSSL: wolfSSL_use_PrivateKey_* correct return codes
In-Reply-To: <20210208083407.6213-1-juliusz@wolfssl.com>
References: <20210208083407.6213-1-juliusz@wolfssl.com>
Message-ID: <20210209200356.GA439636@w1.fi>

On Mon, Feb 08, 2021 at 09:34:07AM +0100, Juliusz Sosinowicz wrote:
> The wolfSSL_use_PrivateKey_* APIs return 1 on success. 0 is also an error.

Thanks, applied.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Tue Feb  9 15:04:17 2021
From: j at w1.fi (Jouni Malinen)
Date: Tue, 9 Feb 2021 22:04:17 +0200
Subject: [PATCH 1/3] wpa_supplicant: expose DPP config object AKM
In-Reply-To: <20210208153207.108755-1-kazikcz@gmail.com>
References: <20210208153207.108755-1-kazikcz@gmail.com>
Message-ID: <20210209200417.GB439636@w1.fi>

On Mon, Feb 08, 2021 at 03:32:05PM +0000, Michal Kazior wrote:
> Hostapd was already exposing this. There's no
> reason not to expose it in wpa_supplicant.
> 
> This allows 3rd party apps interacting with the
> control interface to handle DPP events to get
> configs instead of needing to dance around with
> update_config=1 and save_config.

Thanks, patch 1 and 2 applied.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Tue Feb  9 16:43:01 2021
From: j at w1.fi (Jouni Malinen)
Date: Tue, 9 Feb 2021 23:43:01 +0200
Subject: [PATCH] hostap: Transmit Power Envelope also for 11ax
In-Reply-To: <20201208152019.32238-1-shay.bar@celeno.com>
References: <20201208152019.32238-1-shay.bar@celeno.com>
Message-ID: <20210209214301.GA441834@w1.fi>

On Tue, Dec 08, 2020 at 05:20:19PM +0200, Shay Bar wrote:
> According to latest IEEE802.11 spec, Transmit Power Envelope element should
> also be added to 11ax and is no longer called VHT Transmit Power Envelope.

IEEE P802.11ax/D8.0 seems to have conditions on when this is included.
Only the 6 GHz HE AP case seems to be unconditionally including this
element.

> Remove the VHT naming from the element.
> move hostapd_eid_txpower_envelope() from ieee802_11_vht.c to ieee802_11.c.
> use hostapd_get_oper_chwidth(iconf) instead of iface->conf->vht_oper_chwidth.

That type of renaming should be in a separate patch alone to make the
changes easier to review.

> diff --git a/src/ap/beacon.c b/src/ap/beacon.c
> index 47b260e81..c6597c6cd 100644
> --- a/src/ap/beacon.c
> +++ b/src/ap/beacon.c
> @@ -559,13 +559,14 @@ static u8 * hostapd_gen_probe_resp(struct hostapd_data *hapd,
>  	    !is_6ghz_op_class(hapd->iconf->op_class)) {
>  		pos = hostapd_eid_vht_capabilities(hapd, pos, 0);
>  		pos = hostapd_eid_vht_operation(hapd, pos);
> -		pos = hostapd_eid_txpower_envelope(hapd, pos);
>  	}
>  #endif /* CONFIG_IEEE80211AC */
>  
>  	if ((hapd->iconf->ieee80211ac && !hapd->conf->disable_11ac) ||
> -	    (hapd->iconf->ieee80211ax && !hapd->conf->disable_11ax))
> +	    (hapd->iconf->ieee80211ax && !hapd->conf->disable_11ax)) {
>  		pos = hostapd_eid_wb_chsw_wrapper(hapd, pos);
> +		pos = hostapd_eid_txpower_envelope(hapd, pos);
> +	}

The order of the IEs is strictly specified in the standard and the
Transmit Power Envelope element needs to be before the Channel Switch
Wrapper element, so this type of reordering of the elements is not
correct.

Are the conditions for including Transmit Power Envelope element in that
manner correct? In particular, is this correct to include in all 2.4 GHz
cases?

> @@ -1287,13 +1288,14 @@ int ieee802_11_build_ap_params(struct hostapd_data *hapd,
>  	if (hapd->iconf->ieee80211ac && !hapd->conf->disable_11ac) {
>  		tailpos = hostapd_eid_vht_capabilities(hapd, tailpos, 0);
>  		tailpos = hostapd_eid_vht_operation(hapd, tailpos);
> -		tailpos = hostapd_eid_txpower_envelope(hapd, tailpos);
>  	}
>  #endif /* CONFIG_IEEE80211AC */
>  
>  	if ((hapd->iconf->ieee80211ac && !hapd->conf->disable_11ac) ||
> -	    (hapd->iconf->ieee80211ax && !hapd->conf->disable_11ax))
> +	    (hapd->iconf->ieee80211ax && !hapd->conf->disable_11ax)) {
>  		tailpos = hostapd_eid_wb_chsw_wrapper(hapd, tailpos);
> +		tailpos = hostapd_eid_txpower_envelope(hapd, tailpos);
> +	}

Same comments apply here.

-- 
Jouni Malinen                                            PGP id EFC895FA


From piotr.lobacz at softgent.com  Tue Feb  9 20:31:43 2021
From: piotr.lobacz at softgent.com (Piotr Lobacz)
Date: Wed, 10 Feb 2021 01:31:43 +0000
Subject: question about error nl80211: Frame command failed: ret=-1 (Operation
 not permitted)
Message-ID: <AM7PR10MB3206CBD5ECEB8E0DBC36609BE48D9@AM7PR10MB3206.EURPRD10.PROD.OUTLOOK.COM>

Hi All,
Hi Jouni,

I am trying to use NetworkManager together with wpa_supplicant 2.9 with closed driver for rtl8192f chip. I have set a hotspot connection and the problem is that if i try to connect to it from any device i get this error from subject. I have also attached full log in here: https://pastebin.com/VyTgz0WA .

Now I'm at the point to ask for help, because i really have no idea, what is wrong and don't have much experience  with wpa_supplicant code to find it by myself.


Thanks very much and regards,

Piotr
[https://softgent.com/wp-content/uploads/2020/01/Zasob-14.png]<https://www.softgent.com>

Softgent Sp. z o.o., Budowlanych 31d, 80-298 Gdansk, POLAND

KRS: 0000674406, NIP: 9581679801, REGON: 367090912

www.softgent.com

S?d Rejonowy Gda?sk-P??noc w Gda?sku, VII Wydzia? Gospodarczy Krajowego Rejestru S?dowego

KRS 0000674406, Kapita? zak?adowy: 25 000,00 z? wp?acony w ca?o?ci.


From janusz.dziedzic at gmail.com  Wed Feb 10 04:07:42 2021
From: janusz.dziedzic at gmail.com (Janusz Dziedzic)
Date: Wed, 10 Feb 2021 10:07:42 +0100
Subject: [PATCH] wpa_supplicant: multi_ap: only enable 4addr mode if not
 already enabled
In-Reply-To: <CAFED-jn5W09baaLteiu++GyoZCg4aq6-eK47=-NyaxhwLek0RA@mail.gmail.com>
References: <20210208172823.11536-1-raphael.melotte@mind.be>
 <CAFED-jn5W09baaLteiu++GyoZCg4aq6-eK47=-NyaxhwLek0RA@mail.gmail.com>
Message-ID: <CAFED-j=OtthxoPafFVp7zgHMCqLBrNt1_4WRsGpp+HbEnEz1Ww@mail.gmail.com>

wt., 9 lut 2021 o 10:26 Janusz Dziedzic <janusz.dziedzic at gmail.com> napisa?(a):
>
> pon., 8 lut 2021 o 18:30 Rapha?l M?lotte <raphael.melotte at mind.be> napisa?(a):
> >
> > If 4addr mode is already enabled, the call to enable it a second time
> > may fail. If this happens when roaming, it leads to deauthentication.
> >
> > Signed-off-by: Rapha?l M?lotte <raphael.melotte at mind.be>
> > ---
> >  wpa_supplicant/events.c | 10 ++++++----
> >  1 file changed, 6 insertions(+), 4 deletions(-)
> >
> > diff --git a/wpa_supplicant/events.c b/wpa_supplicant/events.c
> > index 199829bcf..7682dae76 100644
> > --- a/wpa_supplicant/events.c
> > +++ b/wpa_supplicant/events.c
> > @@ -2627,11 +2627,13 @@ static void multi_ap_set_4addr_mode(struct wpa_supplicant *wpa_s)
> >                 goto fail;
> >         }
> >
> > -       if (wpa_drv_set_4addr_mode(wpa_s, 1) < 0) {
> > -               wpa_printf(MSG_ERROR, "Failed to set 4addr mode");
> > -               goto fail;
> > +       if (wpa_s->enabled_4addr_mode == 0) {
> > +               if (wpa_drv_set_4addr_mode(wpa_s, 1) < 0) {
> > +                       wpa_printf(MSG_ERROR, "Failed to set 4addr mode");
> > +                       goto fail;
> > +               }
> > +               wpa_s->enabled_4addr_mode = 1;
> >         }
> > -       wpa_s->enabled_4addr_mode = 1;
> >         return;
> >
> Thanks for patch.
>
> Today set_4addr_mode(1) fail with EBUSY if netdev is already in the bridge.
> So, maybe we should fix it in cfg80211?
>
> janusz at t2:~$ sudo ifconfig wlp1s0 up
>
> janusz at t2:~$ sudo iw wlp1s0 set 4addr on
> janusz at t2:~$ sudo iw wlp1s0 set 4addr on
> janusz at t2:~$ sudo iw wlp1s0 set 4addr on
>
> janusz at t2:~$ sudo brctl addbr br0
> janusz at t2:~$ sudo brctl addif br0 wlp1s0
> janusz at t2:~$ sudo iw wlp1s0 set 4addr on
> command failed: Device or resource busy (-16)
>
> janusz at t2:~$ sudo iw wlp1s0 info
> Interface wlp1s0
> ifindex 3
> wdev 0x1
> addr 68:94:23:28:a7:25
> type managed
> wiphy 0
> txpower 16.00 dBm
> multicast TXQ:
> qsz-byt qsz-pkt flows drops marks overlmt hashcol tx-bytes tx-packets
> 0 0 0 0 0 0 0 0 0
> 4addr: on
>

Did fast patch (didn't check code deeply yet - just check set 4addr
when busy issuey, seems works correctly):

janusz at t1:~/work/linux$ git diff
diff --git a/net/wireless/util.c b/net/wireless/util.c
index b4acc805114b..fec068f48113 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -1027,6 +1027,7 @@ int cfg80211_change_iface(struct
cfg80211_registered_device *rdev,

        /* if it's part of a bridge, reject changing type to station/ibss */
        if (netif_is_bridge_port(dev) &&
+           (ntype != otype) &&
            (ntype == NL80211_IFTYPE_ADHOC ||
             ntype == NL80211_IFTYPE_STATION ||
             ntype == NL80211_IFTYPE_P2P_CLIENT))

@Johannes Berg - could you check if this will be correct?

For old kernels/cfg80211 maybe we should introduce
wpa_drv_get_4addr_mode() and set only if required?

BR
Janusz


From michal at plume.com  Wed Feb 10 03:08:06 2021
From: michal at plume.com (Michal Kazior)
Date: Wed, 10 Feb 2021 09:08:06 +0100
Subject: [PATCH 2/2] wpa_supplicant: fix chirping on sta enrollee scenario
In-Reply-To: <20210209184040.GA36462@w1.fi>
References: <20201215093455.51933-1-kazikcz@gmail.com>
 <20201215093455.51933-2-kazikcz@gmail.com>
 <20210206141437.GA834632@w1.fi>
 <CABqz6Wx-nYGmSDLrwW+gqcwGAAJ=HTnNye92LOzcz8gX4Y7h6g@mail.gmail.com>
 <20210209184040.GA36462@w1.fi>
Message-ID: <CABqz6Wym+k5J_Spf3F=p6e4rHMoHvaeL9Ddpxz4ihdB4bb3b5w@mail.gmail.com>

On Tue, Feb 9, 2021 at 7:40 PM Jouni Malinen <j at w1.fi> wrote:
> On Mon, Feb 08, 2021 at 03:20:37PM +0100, Michal Kazior wrote:
> > On Sat, Feb 6, 2021 at 3:14 PM Jouni Malinen <j at w1.fi> wrote:
> > > This sounds strange.. The response to chirping would be a unicast frame,
> > > so that hardware/firmware RX filter change should not have any impact
> > > here.
> >
> > Now that you say it, it would make sense to expect a unicast frame to
> > be sent back to the chirping station. But that's not what is
> > happening.
> >
> > This is output from a script I used to test the problem. It prefixes
> > prints from wpa_s and hostapd, and you can see hostapd is responding
> > with a type=0 bcast.
>
> That's a bug.. I'll fix it so that the Authentication Request frame goes
> out as a unicast frame to the source address of the Presence
> Announcement which is what the tech spec defines for this sequence.

Thanks!


> > > > diff --git a/wpa_supplicant/dpp_supplicant.c b/wpa_supplicant/dpp_supplicant.c
> > > > @@ -3420,6 +3420,7 @@ static void wpas_dpp_chirp_tx_status(struct wpa_supplicant *wpa_s,
> > > >       wpa_printf(MSG_DEBUG, "DPP: Chirp send completed - wait for response");
> > > > +     wpas_dpp_listen_start(wpa_s, freq);
> > >
> > > This looks quite incorrect thing to do.. This function is called when
> > > the TX operation with 2000 ms wait for response gets TX status. It would
> > > not be appropriate to start DPP listen while that 2000 ms wait for the
> > > response is ongoing.
> >
> > Do you mean that it's racy? I guess it is... The response may already
> > be lost when tx-status for the chirp is processed. Or do you mean
> > something else here?
>
> Starting listen mode (ROC in mac80211) while already in
> offchannel-TX-with-wait-for-response (also ROC) does not sound good
> since there are constraints on how mac80211 allows ROCs to be combined
> or extended.

Oh, you're right.


> This would also be a race condition since this call happens from TX
> status handler and the Authentication Request frame may have already
> been transmitted, but this was not my main concern (but it sounds like a
> valid concern).
>
> Since there are cases where the Authentication Request frame might still
> be sent to the broadcast address while the Enrollee is in the chirping
> loop, it would make sense to update the hardware RX filters. However,
> this should be done without introducing a separate listen operation.
> Wouldn't a call to wpa_drv_dpp_listen(wpa_s, true) when starting
> chirping be all that's needed here? That would then need to be stopped
> when chirping state terminates.

I think this is what I tried originally, but apparently didn't go that
route for some reason that I can't remember anymore. I'll see what I
can do.


Micha?


From j at w1.fi  Wed Feb 10 04:38:03 2021
From: j at w1.fi (Jouni Malinen)
Date: Wed, 10 Feb 2021 11:38:03 +0200
Subject: [PATCH] wpa_supplicant: multi_ap: only enable 4addr mode if not
 already enabled
In-Reply-To: <CAFED-j=OtthxoPafFVp7zgHMCqLBrNt1_4WRsGpp+HbEnEz1Ww@mail.gmail.com>
References: <20210208172823.11536-1-raphael.melotte@mind.be>
 <CAFED-jn5W09baaLteiu++GyoZCg4aq6-eK47=-NyaxhwLek0RA@mail.gmail.com>
 <CAFED-j=OtthxoPafFVp7zgHMCqLBrNt1_4WRsGpp+HbEnEz1Ww@mail.gmail.com>
Message-ID: <20210210093803.GB3792@w1.fi>

On Wed, Feb 10, 2021 at 10:07:42AM +0100, Janusz Dziedzic wrote:
> wt., 9 lut 2021 o 10:26 Janusz Dziedzic <janusz.dziedzic at gmail.com> napisa?(a):
> > pon., 8 lut 2021 o 18:30 Rapha?l M?lotte <raphael.melotte at mind.be> napisa?(a):
> > > If 4addr mode is already enabled, the call to enable it a second time
> > > may fail. If this happens when roaming, it leads to deauthentication.

What is the case where 4ddr mode would have already been enabled? Does
this happen every time when there is roaming since
multi_ap_set_4addr_mode() did not have this check before? Or are you
considering cases where something external to wpa_supplicant is changing
this parameter?

> > > -       if (wpa_drv_set_4addr_mode(wpa_s, 1) < 0) {
> > > -               wpa_printf(MSG_ERROR, "Failed to set 4addr mode");
> > > -               goto fail;
> > > +       if (wpa_s->enabled_4addr_mode == 0) {
> > > +               if (wpa_drv_set_4addr_mode(wpa_s, 1) < 0) {
> > > +                       wpa_printf(MSG_ERROR, "Failed to set 4addr mode");
> > > +                       goto fail;
> > > +               }
> > > +               wpa_s->enabled_4addr_mode = 1;
> > >         }
> > > -       wpa_s->enabled_4addr_mode = 1;

This looks safer to me if it is clear that no external entity is messing
up with the kernel parameter.

> > Today set_4addr_mode(1) fail with EBUSY if netdev is already in the bridge.
> > So, maybe we should fix it in cfg80211?

> > janusz at t2:~$ sudo ifconfig wlp1s0 up
> > janusz at t2:~$ sudo iw wlp1s0 set 4addr on
> > janusz at t2:~$ sudo iw wlp1s0 set 4addr on
> > janusz at t2:~$ sudo brctl addbr br0
> > janusz at t2:~$ sudo brctl addif br0 wlp1s0
> > janusz at t2:~$ sudo iw wlp1s0 set 4addr on
> > command failed: Device or resource busy (-16)

That specific EBUSY seems unnecessary for a no-change operation, but
disabling 4addr mode in station interface that is in a bridge should
still be prevented.
 
> Did fast patch (didn't check code deeply yet - just check set 4addr
> when busy issuey, seems works correctly):

> diff --git a/net/wireless/util.c b/net/wireless/util.c
> @@ -1027,6 +1027,7 @@ int cfg80211_change_iface(struct
> cfg80211_registered_device *rdev,
> 
>         /* if it's part of a bridge, reject changing type to station/ibss */
>         if (netif_is_bridge_port(dev) &&
> +           (ntype != otype) &&
>             (ntype == NL80211_IFTYPE_ADHOC ||
>              ntype == NL80211_IFTYPE_STATION ||
>              ntype == NL80211_IFTYPE_P2P_CLIENT))

How would that prevent disabling of 4addr mode when the netdev is in a
bridge?

> For old kernels/cfg80211 maybe we should introduce
> wpa_drv_get_4addr_mode() and set only if required?

Do we really need that complexity? Isn't the internal tracking with
wpa_s->enabled_4addr_mode sufficient? In other words, simply apply this
patch as-is..

-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Wed Feb 10 04:29:54 2021
From: j at w1.fi (Jouni Malinen)
Date: Wed, 10 Feb 2021 11:29:54 +0200
Subject: question about error nl80211: Frame command failed: ret=-1
 (Operation not permitted)
In-Reply-To: <AM7PR10MB3206CBD5ECEB8E0DBC36609BE48D9@AM7PR10MB3206.EURPRD10.PROD.OUTLOOK.COM>
References: <AM7PR10MB3206CBD5ECEB8E0DBC36609BE48D9@AM7PR10MB3206.EURPRD10.PROD.OUTLOOK.COM>
Message-ID: <20210210092954.GA3792@w1.fi>

On Wed, Feb 10, 2021 at 01:31:43AM +0000, Piotr Lobacz wrote:
> I am trying to use NetworkManager together with wpa_supplicant 2.9 with closed driver for rtl8192f chip. I have set a hotspot connection and the problem is that if i try to connect to it from any device i get this error from subject. I have also attached full log in here: https://pastebin.com/VyTgz0WA .

That NL80211_CMD_FRAME failure is reported for the case where
wpa_supplicant (in AP mode) is trying to send a Probe Response frame as
a response to the Probe Request frame that the driver delivered to upper
layers. However, the driver seems to refuse to transmit the response.

Taken into account that "closed driver" part, I'm not going to try to
speculate on this more than note that there are many drivers that handle
Probe Request frame processing internally and as such, I would not be
very surprised if they do not accept Probe Response frames from user
space. If the driver is indeed taking care of that functionality, I
would simply ignore this failure.

-- 
Jouni Malinen                                            PGP id EFC895FA


From shay.bar at celeno.com  Wed Feb 10 06:07:16 2021
From: shay.bar at celeno.com (Shay Bar)
Date: Wed, 10 Feb 2021 13:07:16 +0200
Subject: [PATCH 0/3] hostap: Tx Power Envelope also for 6GHz 11ax AP
Message-ID: <20210210110719.6007-1-shay.bar@celeno.com>

According to latest IEEE802.11 spec, Transmit Power Envelope element should
also be added to 6GHz 11ax AP and is no longer called VHT Transmit Power Envelope.

Shay Bar (3):
  hostap: Remove the VHT naming from the element
  hostap: hostap: use hostapd_get_oper_chwidth
  hostap: hostap: Tx Power Envelope also for 6GHz HE AP

 src/ap/beacon.c              |  12 ++++
 src/ap/ieee802_11.c          | 112 +++++++++++++++++++++++++++++++++++
 src/ap/ieee802_11_vht.c      | 112 -----------------------------------
 src/common/ieee802_11_defs.h |   2 +-
 4 files changed, 125 insertions(+), 113 deletions(-)

-- 
2.17.1



From shay.bar at celeno.com  Wed Feb 10 06:07:17 2021
From: shay.bar at celeno.com (Shay Bar)
Date: Wed, 10 Feb 2021 13:07:17 +0200
Subject: [PATCH 1/3] hostap: Remove the VHT naming from the element
In-Reply-To: <20210210110719.6007-1-shay.bar@celeno.com>
References: <20210210110719.6007-1-shay.bar@celeno.com>
Message-ID: <20210210110719.6007-2-shay.bar@celeno.com>

According to latest IEEE802.11 spec, Transmit Power Envelope element is also
relevant to 11ax and is no longer called VHT Transmit Power Envelope.
Remove the VHT naming from the element.
move hostapd_eid_txpower_envelope() from ieee802_11_vht.c to ieee802_11.c.

Signed-off-by: Shay Bar <shay.bar at celeno.com>
---
 src/ap/ieee802_11.c          | 112 +++++++++++++++++++++++++++++++++++
 src/ap/ieee802_11_vht.c      | 112 -----------------------------------
 src/common/ieee802_11_defs.h |   2 +-
 3 files changed, 113 insertions(+), 113 deletions(-)

diff --git a/src/ap/ieee802_11.c b/src/ap/ieee802_11.c
index 76a7ffa9e..13fa450df 100644
--- a/src/ap/ieee802_11.c
+++ b/src/ap/ieee802_11.c
@@ -6766,6 +6766,118 @@ void ieee802_11_rx_from_unknown(struct hostapd_data *hapd, const u8 *src,
 }
 
 
+u8 * hostapd_eid_txpower_envelope(struct hostapd_data *hapd, u8 *eid)
+{
+	struct hostapd_iface *iface = hapd->iface;
+	struct hostapd_config *iconf = iface->conf;
+	struct hostapd_hw_modes *mode = iface->current_mode;
+	struct hostapd_channel_data *chan;
+	int dfs, i;
+	u8 channel, tx_pwr_count, local_pwr_constraint;
+	int max_tx_power;
+	u8 tx_pwr;
+
+	if (!mode)
+		return eid;
+
+	if (ieee80211_freq_to_chan(iface->freq, &channel) == NUM_HOSTAPD_MODES)
+		return eid;
+
+	for (i = 0; i < mode->num_channels; i++) {
+		if (mode->channels[i].freq == iface->freq)
+			break;
+	}
+	if (i == mode->num_channels)
+		return eid;
+
+	switch (iface->conf->vht_oper_chwidth) {
+	case CHANWIDTH_USE_HT:
+		if (iconf->secondary_channel == 0) {
+			/* Max Transmit Power count = 0 (20 MHz) */
+			tx_pwr_count = 0;
+		} else {
+			/* Max Transmit Power count = 1 (20, 40 MHz) */
+			tx_pwr_count = 1;
+		}
+		break;
+	case CHANWIDTH_80MHZ:
+		/* Max Transmit Power count = 2 (20, 40, and 80 MHz) */
+		tx_pwr_count = 2;
+		break;
+	case CHANWIDTH_80P80MHZ:
+	case CHANWIDTH_160MHZ:
+		/* Max Transmit Power count = 3 (20, 40, 80, 160/80+80 MHz) */
+		tx_pwr_count = 3;
+		break;
+	default:
+		return eid;
+	}
+
+	/*
+	 * Below local_pwr_constraint logic is referred from
+	 * hostapd_eid_pwr_constraint.
+	 *
+	 * Check if DFS is required by regulatory.
+	 */
+	dfs = hostapd_is_dfs_required(hapd->iface);
+	if (dfs < 0)
+		dfs = 0;
+
+	/*
+	 * In order to meet regulations when TPC is not implemented using
+	 * a transmit power that is below the legal maximum (including any
+	 * mitigation factor) should help. In this case, indicate 3 dB below
+	 * maximum allowed transmit power.
+	 */
+	if (hapd->iconf->local_pwr_constraint == -1)
+		local_pwr_constraint = (dfs == 0) ? 0 : 3;
+	else
+		local_pwr_constraint = hapd->iconf->local_pwr_constraint;
+
+	/*
+	 * A STA that is not an AP shall use a transmit power less than or
+	 * equal to the local maximum transmit power level for the channel.
+	 * The local maximum transmit power can be calculated from the formula:
+	 * local max TX pwr = max TX pwr - local pwr constraint
+	 * Where max TX pwr is maximum transmit power level specified for
+	 * channel in Country element and local pwr constraint is specified
+	 * for channel in this Power Constraint element.
+	 */
+	chan = &mode->channels[i];
+	max_tx_power = chan->max_tx_power - local_pwr_constraint;
+
+	/*
+	 * Local Maximum Transmit power is encoded as two's complement
+	 * with a 0.5 dB step.
+	 */
+	max_tx_power *= 2; /* in 0.5 dB steps */
+	if (max_tx_power > 127) {
+		/* 63.5 has special meaning of 63.5 dBm or higher */
+		max_tx_power = 127;
+	}
+	if (max_tx_power < -128)
+		max_tx_power = -128;
+	if (max_tx_power < 0)
+		tx_pwr = 0x80 + max_tx_power + 128;
+	else
+		tx_pwr = max_tx_power;
+
+	*eid++ = WLAN_EID_TRANSMIT_POWER_ENVELOPE;
+	*eid++ = 2 + tx_pwr_count;
+
+	/*
+	 * Max Transmit Power count and
+	 * Max Transmit Power units = 0 (EIRP)
+	 */
+	*eid++ = tx_pwr_count;
+
+	for (i = 0; i <= tx_pwr_count; i++)
+		*eid++ = tx_pwr;
+
+	return eid;
+}
+
+
 u8 * hostapd_eid_wb_chsw_wrapper(struct hostapd_data *hapd, u8 *eid)
 {
 	u8 bw, chan1, chan2 = 0;
diff --git a/src/ap/ieee802_11_vht.c b/src/ap/ieee802_11_vht.c
index c925bf12c..d0370229c 100644
--- a/src/ap/ieee802_11_vht.c
+++ b/src/ap/ieee802_11_vht.c
@@ -167,118 +167,6 @@ static int check_valid_vht_mcs(struct hostapd_hw_modes *mode,
 }
 
 
-u8 * hostapd_eid_txpower_envelope(struct hostapd_data *hapd, u8 *eid)
-{
-	struct hostapd_iface *iface = hapd->iface;
-	struct hostapd_config *iconf = iface->conf;
-	struct hostapd_hw_modes *mode = iface->current_mode;
-	struct hostapd_channel_data *chan;
-	int dfs, i;
-	u8 channel, tx_pwr_count, local_pwr_constraint;
-	int max_tx_power;
-	u8 tx_pwr;
-
-	if (!mode)
-		return eid;
-
-	if (ieee80211_freq_to_chan(iface->freq, &channel) == NUM_HOSTAPD_MODES)
-		return eid;
-
-	for (i = 0; i < mode->num_channels; i++) {
-		if (mode->channels[i].freq == iface->freq)
-			break;
-	}
-	if (i == mode->num_channels)
-		return eid;
-
-	switch (iface->conf->vht_oper_chwidth) {
-	case CHANWIDTH_USE_HT:
-		if (iconf->secondary_channel == 0) {
-			/* Max Transmit Power count = 0 (20 MHz) */
-			tx_pwr_count = 0;
-		} else {
-			/* Max Transmit Power count = 1 (20, 40 MHz) */
-			tx_pwr_count = 1;
-		}
-		break;
-	case CHANWIDTH_80MHZ:
-		/* Max Transmit Power count = 2 (20, 40, and 80 MHz) */
-		tx_pwr_count = 2;
-		break;
-	case CHANWIDTH_80P80MHZ:
-	case CHANWIDTH_160MHZ:
-		/* Max Transmit Power count = 3 (20, 40, 80, 160/80+80 MHz) */
-		tx_pwr_count = 3;
-		break;
-	default:
-		return eid;
-	}
-
-	/*
-	 * Below local_pwr_constraint logic is referred from
-	 * hostapd_eid_pwr_constraint.
-	 *
-	 * Check if DFS is required by regulatory.
-	 */
-	dfs = hostapd_is_dfs_required(hapd->iface);
-	if (dfs < 0)
-		dfs = 0;
-
-	/*
-	 * In order to meet regulations when TPC is not implemented using
-	 * a transmit power that is below the legal maximum (including any
-	 * mitigation factor) should help. In this case, indicate 3 dB below
-	 * maximum allowed transmit power.
-	 */
-	if (hapd->iconf->local_pwr_constraint == -1)
-		local_pwr_constraint = (dfs == 0) ? 0 : 3;
-	else
-		local_pwr_constraint = hapd->iconf->local_pwr_constraint;
-
-	/*
-	 * A STA that is not an AP shall use a transmit power less than or
-	 * equal to the local maximum transmit power level for the channel.
-	 * The local maximum transmit power can be calculated from the formula:
-	 * local max TX pwr = max TX pwr - local pwr constraint
-	 * Where max TX pwr is maximum transmit power level specified for
-	 * channel in Country element and local pwr constraint is specified
-	 * for channel in this Power Constraint element.
-	 */
-	chan = &mode->channels[i];
-	max_tx_power = chan->max_tx_power - local_pwr_constraint;
-
-	/*
-	 * Local Maximum Transmit power is encoded as two's complement
-	 * with a 0.5 dB step.
-	 */
-	max_tx_power *= 2; /* in 0.5 dB steps */
-	if (max_tx_power > 127) {
-		/* 63.5 has special meaning of 63.5 dBm or higher */
-		max_tx_power = 127;
-	}
-	if (max_tx_power < -128)
-		max_tx_power = -128;
-	if (max_tx_power < 0)
-		tx_pwr = 0x80 + max_tx_power + 128;
-	else
-		tx_pwr = max_tx_power;
-
-	*eid++ = WLAN_EID_VHT_TRANSMIT_POWER_ENVELOPE;
-	*eid++ = 2 + tx_pwr_count;
-
-	/*
-	 * Max Transmit Power count and
-	 * Max Transmit Power units = 0 (EIRP)
-	 */
-	*eid++ = tx_pwr_count;
-
-	for (i = 0; i <= tx_pwr_count; i++)
-		*eid++ = tx_pwr;
-
-	return eid;
-}
-
-
 u16 copy_sta_vht_capab(struct hostapd_data *hapd, struct sta_info *sta,
 		       const u8 *vht_capab)
 {
diff --git a/src/common/ieee802_11_defs.h b/src/common/ieee802_11_defs.h
index 4fdc3b2d9..87d01d58a 100644
--- a/src/common/ieee802_11_defs.h
+++ b/src/common/ieee802_11_defs.h
@@ -434,7 +434,7 @@
 #define WLAN_EID_VHT_OPERATION 192
 #define WLAN_EID_VHT_EXTENDED_BSS_LOAD 193
 #define WLAN_EID_VHT_WIDE_BW_CHSWITCH  194
-#define WLAN_EID_VHT_TRANSMIT_POWER_ENVELOPE 195
+#define WLAN_EID_TRANSMIT_POWER_ENVELOPE 195
 #define WLAN_EID_VHT_CHANNEL_SWITCH_WRAPPER 196
 #define WLAN_EID_VHT_AID 197
 #define WLAN_EID_VHT_QUIET_CHANNEL 198
-- 
2.17.1



From shay.bar at celeno.com  Wed Feb 10 06:07:18 2021
From: shay.bar at celeno.com (Shay Bar)
Date: Wed, 10 Feb 2021 13:07:18 +0200
Subject: [PATCH 2/3] hostap: use hostapd_get_oper_chwidth
In-Reply-To: <20210210110719.6007-1-shay.bar@celeno.com>
References: <20210210110719.6007-1-shay.bar@celeno.com>
Message-ID: <20210210110719.6007-3-shay.bar@celeno.com>

use hostapd_get_oper_chwidth(iconf) instead of iface->conf->vht_oper_chwidth.

Signed-off-by: Shay Bar <shay.bar at celeno.com>
---
 src/ap/ieee802_11.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/ap/ieee802_11.c b/src/ap/ieee802_11.c
index 13fa450df..233da7bfc 100644
--- a/src/ap/ieee802_11.c
+++ b/src/ap/ieee802_11.c
@@ -6790,7 +6790,7 @@ u8 * hostapd_eid_txpower_envelope(struct hostapd_data *hapd, u8 *eid)
 	if (i == mode->num_channels)
 		return eid;
 
-	switch (iface->conf->vht_oper_chwidth) {
+	switch (hostapd_get_oper_chwidth(iconf)) {
 	case CHANWIDTH_USE_HT:
 		if (iconf->secondary_channel == 0) {
 			/* Max Transmit Power count = 0 (20 MHz) */
-- 
2.17.1



From shay.bar at celeno.com  Wed Feb 10 06:07:19 2021
From: shay.bar at celeno.com (Shay Bar)
Date: Wed, 10 Feb 2021 13:07:19 +0200
Subject: [PATCH 3/3] hostap: Tx Power Envelope also for 6GHz HE AP
In-Reply-To: <20210210110719.6007-1-shay.bar@celeno.com>
References: <20210210110719.6007-1-shay.bar@celeno.com>
Message-ID: <20210210110719.6007-4-shay.bar@celeno.com>

According to IEEE P802.11ax/D8.0, Add Transmit Power Envelope element
for 6GHz HE AP.

Signed-off-by: Shay Bar <shay.bar at celeno.com>
---
 src/ap/beacon.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/src/ap/beacon.c b/src/ap/beacon.c
index 477caa494..c8ac0e007 100644
--- a/src/ap/beacon.c
+++ b/src/ap/beacon.c
@@ -563,6 +563,12 @@ static u8 * hostapd_gen_probe_resp(struct hostapd_data *hapd,
 	}
 #endif /* CONFIG_IEEE80211AC */
 
+#ifdef CONFIG_IEEE80211AX
+	if ((hapd->iconf->ieee80211ax && !hapd->conf->disable_11ax) &&
+	    (is_6ghz_op_class(hapd->iconf->op_class)))
+		pos = hostapd_eid_txpower_envelope(hapd, pos);
+#endif /* CONFIG_IEEE80211AX */
+
 	if ((hapd->iconf->ieee80211ac && !hapd->conf->disable_11ac) ||
 	    (hapd->iconf->ieee80211ax && !hapd->conf->disable_11ax))
 		pos = hostapd_eid_wb_chsw_wrapper(hapd, pos);
@@ -1291,6 +1297,12 @@ int ieee802_11_build_ap_params(struct hostapd_data *hapd,
 	}
 #endif /* CONFIG_IEEE80211AC */
 
+#ifdef CONFIG_IEEE80211AX
+	if ((hapd->iconf->ieee80211ax && !hapd->conf->disable_11ax) &&
+	    (is_6ghz_op_class(hapd->iconf->op_class)))
+		tailpos = hostapd_eid_txpower_envelope(hapd, tailpos);
+#endif /* CONFIG_IEEE80211AX */
+
 	if ((hapd->iconf->ieee80211ac && !hapd->conf->disable_11ac) ||
 	    (hapd->iconf->ieee80211ax && !hapd->conf->disable_11ax))
 		tailpos = hostapd_eid_wb_chsw_wrapper(hapd, tailpos);
-- 
2.17.1



From shay.bar at celeno.com  Wed Feb 10 06:11:41 2021
From: shay.bar at celeno.com (Shay Bar)
Date: Wed, 10 Feb 2021 13:11:41 +0200
Subject: [PATCH] hostap: Transmit Power Envelope also for 11ax
In-Reply-To: <20210209214301.GA441834@w1.fi>
References: <20201208152019.32238-1-shay.bar@celeno.com>
 <20210209214301.GA441834@w1.fi>
Message-ID: <4317386f-ce8c-a5c1-5d5e-7debf9ded998@celeno.com>


On 09/02/2021 23:43, Jouni Malinen wrote:
> On Tue, Dec 08, 2020 at 05:20:19PM +0200, Shay Bar wrote:
>> According to latest IEEE802.11 spec, Transmit Power Envelope element should
>> also be added to 11ax and is no longer called VHT Transmit Power Envelope.
> IEEE P802.11ax/D8.0 seems to have conditions on when this is included.
> Only the 6 GHz HE AP case seems to be unconditionally including this
> element.
Right, fixed in the new patch series.
>> Remove the VHT naming from the element.
>> move hostapd_eid_txpower_envelope() from ieee802_11_vht.c to ieee802_11.c.
>> use hostapd_get_oper_chwidth(iconf) instead of iface->conf->vht_oper_chwidth.
> That type of renaming should be in a separate patch alone to make the
> changes easier to review.
fixed in the new patch series.
>> diff --git a/src/ap/beacon.c b/src/ap/beacon.c
>> index 47b260e81..c6597c6cd 100644
>> --- a/src/ap/beacon.c
>> +++ b/src/ap/beacon.c
>> @@ -559,13 +559,14 @@ static u8 * hostapd_gen_probe_resp(struct hostapd_data *hapd,
>>            !is_6ghz_op_class(hapd->iconf->op_class)) {
>>                pos = hostapd_eid_vht_capabilities(hapd, pos, 0);
>>                pos = hostapd_eid_vht_operation(hapd, pos);
>> -             pos = hostapd_eid_txpower_envelope(hapd, pos);
>>        }
>>   #endif /* CONFIG_IEEE80211AC */
>>
>>        if ((hapd->iconf->ieee80211ac && !hapd->conf->disable_11ac) ||
>> -         (hapd->iconf->ieee80211ax && !hapd->conf->disable_11ax))
>> +         (hapd->iconf->ieee80211ax && !hapd->conf->disable_11ax)) {
>>                pos = hostapd_eid_wb_chsw_wrapper(hapd, pos);
>> +             pos = hostapd_eid_txpower_envelope(hapd, pos);
>> +     }
> The order of the IEs is strictly specified in the standard and the
> Transmit Power Envelope element needs to be before the Channel Switch
> Wrapper element, so this type of reordering of the elements is not
> correct.
fixed in the new patch series.


From janusz.dziedzic at gmail.com  Wed Feb 10 06:37:55 2021
From: janusz.dziedzic at gmail.com (Janusz Dziedzic)
Date: Wed, 10 Feb 2021 12:37:55 +0100
Subject: [PATCH] wpa_supplicant: multi_ap: only enable 4addr mode if not
 already enabled
In-Reply-To: <20210210093803.GB3792@w1.fi>
References: <20210208172823.11536-1-raphael.melotte@mind.be>
 <CAFED-jn5W09baaLteiu++GyoZCg4aq6-eK47=-NyaxhwLek0RA@mail.gmail.com>
 <CAFED-j=OtthxoPafFVp7zgHMCqLBrNt1_4WRsGpp+HbEnEz1Ww@mail.gmail.com>
 <20210210093803.GB3792@w1.fi>
Message-ID: <CAFED-j=nQAFSQ00Tz81TiVmYu1OZqTtii=4wRNPHvKTC8z0B+g@mail.gmail.com>

?r., 10 lut 2021 o 10:38 Jouni Malinen <j at w1.fi> napisa?(a):
>
> On Wed, Feb 10, 2021 at 10:07:42AM +0100, Janusz Dziedzic wrote:
> > wt., 9 lut 2021 o 10:26 Janusz Dziedzic <janusz.dziedzic at gmail.com> napisa?(a):
> > > pon., 8 lut 2021 o 18:30 Rapha?l M?lotte <raphael.melotte at mind.be> napisa?(a):
> > > > If 4addr mode is already enabled, the call to enable it a second time
> > > > may fail. If this happens when roaming, it leads to deauthentication.
>
> What is the case where 4ddr mode would have already been enabled? Does
> this happen every time when there is roaming since
> multi_ap_set_4addr_mode() did not have this check before? Or are you
> considering cases where something external to wpa_supplicant is changing
> this parameter?
>
> > > > -       if (wpa_drv_set_4addr_mode(wpa_s, 1) < 0) {
> > > > -               wpa_printf(MSG_ERROR, "Failed to set 4addr mode");
> > > > -               goto fail;
> > > > +       if (wpa_s->enabled_4addr_mode == 0) {
> > > > +               if (wpa_drv_set_4addr_mode(wpa_s, 1) < 0) {
> > > > +                       wpa_printf(MSG_ERROR, "Failed to set 4addr mode");
> > > > +                       goto fail;
> > > > +               }
> > > > +               wpa_s->enabled_4addr_mode = 1;
> > > >         }
> > > > -       wpa_s->enabled_4addr_mode = 1;
>
> This looks safer to me if it is clear that no external entity is messing
> up with the kernel parameter.
>
> > > Today set_4addr_mode(1) fail with EBUSY if netdev is already in the bridge.
> > > So, maybe we should fix it in cfg80211?
>
> > > janusz at t2:~$ sudo ifconfig wlp1s0 up
> > > janusz at t2:~$ sudo iw wlp1s0 set 4addr on
> > > janusz at t2:~$ sudo iw wlp1s0 set 4addr on
> > > janusz at t2:~$ sudo brctl addbr br0
> > > janusz at t2:~$ sudo brctl addif br0 wlp1s0
> > > janusz at t2:~$ sudo iw wlp1s0 set 4addr on
> > > command failed: Device or resource busy (-16)
>
> That specific EBUSY seems unnecessary for a no-change operation, but
> disabling 4addr mode in station interface that is in a bridge should
> still be prevented.
>
> > Did fast patch (didn't check code deeply yet - just check set 4addr
> > when busy issuey, seems works correctly):
>
> > diff --git a/net/wireless/util.c b/net/wireless/util.c
> > @@ -1027,6 +1027,7 @@ int cfg80211_change_iface(struct
> > cfg80211_registered_device *rdev,
> >
> >         /* if it's part of a bridge, reject changing type to station/ibss */
> >         if (netif_is_bridge_port(dev) &&
> > +           (ntype != otype) &&
> >             (ntype == NL80211_IFTYPE_ADHOC ||
> >              ntype == NL80211_IFTYPE_STATION ||
> >              ntype == NL80211_IFTYPE_P2P_CLIENT))
>
> How would that prevent disabling of 4addr mode when the netdev is in a
> bridge?
>
This what I have with cfg80211 patch included:
root at t2:~# brctl addif br0 wlp1s0
root at t2:~# iw wlp1s0 set 4addr on
root at t2:~# brctl show
bridge name bridge id STP enabled interfaces
br0 8000.68942328a725 no wlp1s0

root at t2:~# iw wlp1s0 set 4addr off
command failed: Device or resource busy (-16)
root at t2:~# iw wlp1s0 set 4addr on
root at t2:~# iw wlp1s0 set 4addr on

Seems there is another check in cfg80211 that already handle this.

> > For old kernels/cfg80211 maybe we should introduce
> > wpa_drv_get_4addr_mode() and set only if required?
>
> Do we really need that complexity? Isn't the internal tracking with
> wpa_s->enabled_4addr_mode sufficient? In other words, simply apply this
> patch as-is..
>
Sounds good, not sure about case where:
- iw wlX set 4addr on
- brctl add br0 wlX
- supplicant (wlX)
- wpa_cli -i wlX wps_pbc multi_ap=1

This test case failed for me (or simply restart supplicant after wlX
in bridge) - because of 4addr on failed.

Will check this with original patch.

BR
Janusz


From andrei.otcheretianski at intel.com  Wed Feb 10 07:58:53 2021
From: andrei.otcheretianski at intel.com (Otcheretianski, Andrei)
Date: Wed, 10 Feb 2021 12:58:53 +0000
Subject: [PATCH] nl80211: use the process_bss_event for the nl_connect
 handler
In-Reply-To: <20210206093537.GA9770@w1.fi>
References: <20210121154037.32654-1-andrei.otcheretianski@intel.com>
 <20210121154037.32654-3-andrei.otcheretianski@intel.com>
 <20210206093537.GA9770@w1.fi>
Message-ID: <SJ0PR11MB4941B7B5141CB028291278B1F58D9@SJ0PR11MB4941.namprd11.prod.outlook.com>

> > @@ -6196,8 +6199,7 @@ skip_auth_type:
> > -	ret = send_and_recv_msgs_owner(drv, msg, nl_connect, 1, NULL,
> > -				       (void *) -1, NULL, NULL);
> > +	ret = send_and_recv_msgs_connect_handle(drv, msg, bss);
> 
> This would lose that special valid_handler = NULL, valid_data = (void *)
> -1 combination that is needed at the end of send_and_recv() to be able to
> use nl80211_nlmsg_clear(msg) to get any private material like keys explicitly
> cleared from freed heap memory. See commit bbd89bfca0b4i
> ("nl80211: Clear nlmsg payload with keys before freeing") for more details.
> 
> That special case needs to be covered here. Since it may be inconvenient to
> cover this without adding new arguments to all send_and_recv functions, it
> may be worth considering whether that conditional
> nl80211_nlmsg_clear() call at the end of send_and_recv() should simply be
> made unconditional.. It would burn some more resources clearing memory
> unnecessarily for most messages, but that's unlikely to be much of and issue
> in practice.

This is a good point that I missed in the review. I will submit a fixed version.
Thank you for reviewing.
Andrei

> 
> --
> Jouni Malinen                                            PGP id EFC895FA


From raphael.melotte at mind.be  Wed Feb 10 11:37:07 2021
From: raphael.melotte at mind.be (=?UTF-8?B?UmFwaGHDq2wgTcOpbG90dGU=?=)
Date: Wed, 10 Feb 2021 17:37:07 +0100
Subject: [PATCH] wpa_supplicant: multi_ap: only enable 4addr mode if not
 already enabled
In-Reply-To: <20210210093803.GB3792@w1.fi>
References: <20210208172823.11536-1-raphael.melotte@mind.be>
 <CAFED-jn5W09baaLteiu++GyoZCg4aq6-eK47=-NyaxhwLek0RA@mail.gmail.com>
 <CAFED-j=OtthxoPafFVp7zgHMCqLBrNt1_4WRsGpp+HbEnEz1Ww@mail.gmail.com>
 <20210210093803.GB3792@w1.fi>
Message-ID: <76f70216-8861-7771-b498-98d9671e03dc@mind.be>

On 2/10/21 10:38 AM, Jouni Malinen wrote:
> On Wed, Feb 10, 2021 at 10:07:42AM +0100, Janusz Dziedzic wrote:
>> wt., 9 lut 2021 o 10:26 Janusz Dziedzic <janusz.dziedzic at gmail.com> napisa?(a):
>>> pon., 8 lut 2021 o 18:30 Rapha?l M?lotte <raphael.melotte at mind.be> napisa?(a):
>>>> If 4addr mode is already enabled, the call to enable it a second time
>>>> may fail. If this happens when roaming, it leads to deauthentication.
> 
> What is the case where 4ddr mode would have already been enabled? Does
> this happen every time when there is roaming since
> multi_ap_set_4addr_mode() did not have this check before? Or are you
> considering cases where something external to wpa_supplicant is changing
> this parameter?

In my specific case I think 4addr mode is always enabled (by the supplicant) 
before roaming, because I'm trying to switch from one backhaul AP to another one 
(which means the supplicant enables 4addr mode when connecting to the first bAP).

As Janusz pointed out, it seems the actual problem I'm facing is not the fact 
that 4addr mode is already enabled, but the fact that the interface is already 
part of the bridge (so my patch description is not accurate). No external entity 
changes this parameter in my case.


Thanks,

Rapha?l


From michal at plume.com  Wed Feb 10 04:43:48 2021
From: michal at plume.com (Michal Kazior)
Date: Wed, 10 Feb 2021 10:43:48 +0100
Subject: [PATCH 3/3] DPP: prevent processing dpp action frames when stopped
In-Reply-To: <20210209185315.GB36462@w1.fi>
References: <20210208153207.108755-1-kazikcz@gmail.com>
 <20210208153207.108755-3-kazikcz@gmail.com>
 <20210209185315.GB36462@w1.fi>
Message-ID: <CABqz6Wys+c=Tg=aKNhyrvzaXR887AxJ9N-S8QFfYNzZcJSmmxw@mail.gmail.com>

On Tue, Feb 9, 2021 at 7:53 PM Jouni Malinen <j at w1.fi> wrote:
>
> On Mon, Feb 08, 2021 at 03:32:07PM +0000, Michal Kazior wrote:
> > DPP configurator params can be configured per
> > interface. DPP listening can also be started and
> > stopped per interface.
> >
> > However DPP rx processing was always doomed to
> > process incomming frames even on interfaces which
> > were not explicitly started to do DPP listen. This
> > happened because not only the initial value but
> > also because the dpp_allowed_roles could never be
> > reset to 0.
>
> This is not really the way the DPP_LISTEN was designed for hostapd
> originally. The expectation was the AP side does not need an explicit
> DPP_LISTEN command to receive DPP frames on the operating channel, i.e.,
> DPP_LISTEN would only be needed to do an off-channel listen operation.
> Only later extensions to being able to configure parameters and HW RX
> filters brought in cases where the DPP_LISTEN command might be needed.
>
> > This would result in random failures in
> > configuring Enrollees when running multiple AP
> > interfaces if some of these APs happened to not
> > have DPP configurator params set.
>
> Can you please provide more details on where you are seeing issues from
> this? The Responder should ignore the incoming DPP messages if they are
> not targeting it (have a match in the bootstrapping key).

When running global hostapd instances BIs are shared across all
interfaces. If some of them don't have dpp_configurator_params set
then it's up to the driver's frame event ordering which will determine
whether dpp configuration will be handed out properly or not. If the
problem is hit the configurator responds with status=5 to Enrollee.

For example I have wlan0+wlan02. Only wlan02 has the
dpp_configurator_params set. wlan0 does not. If wlan0 kicks off first
then status=5 is reported to Enrollee for ConfReq:

> $ awk '/Enrollee/ || /DPP-/ || /sa=/' /tmp/hostapd.log
> 1612949875.849099: PTKSA: Deinit. n_ptksa=0
> 1612949878.849732: nl80211: RX frame da=ff:ff:ff:ff:ff:ff sa=02:00:00:00:01:00 bssid=ff:ff:ff:ff:ff:ff freq=2437 ssi_signal=-50 fc=0xd0 seq_ctrl=0x0 stype=13 (WLAN_FC_STYPE_ACTION) len=222
> 1612949878.849734: wlan0: DPP-RX src=02:00:00:00:01:00 freq=2437 type=0
> 1612949878.849745: wlan0: DPP-TX dst=02:00:00:00:01:00 freq=2437 type=1
> 1612949878.849749: nl80211: RX frame da=ff:ff:ff:ff:ff:ff sa=02:00:00:00:01:00 bssid=ff:ff:ff:ff:ff:ff freq=2437 ssi_signal=-50 fc=0xd0 seq_ctrl=0x0 stype=13 (WLAN_FC_STYPE_ACTION) len=222
> 1612949878.849750: wlan02: DPP-RX src=02:00:00:00:01:00 freq=2437 type=0
> 1612949878.849769: wlan02: DPP-TX dst=02:00:00:00:01:00 freq=2437 type=1
> 1612949878.849774: wlan0: DPP-TX-STATUS dst=02:00:00:00:01:00 result=SUCCESS
> 1612949878.849776: nl80211: RX frame da=02:00:00:00:00:00 sa=02:00:00:00:01:00 bssid=ff:ff:ff:ff:ff:ff freq=2437 ssi_signal=-50 fc=0xd0 seq_ctrl=0x10 stype=13 (WLAN_FC_STYPE_ACTION) len=129
> 1612949878.849778: wlan0: DPP-RX src=02:00:00:00:01:00 freq=2437 type=2
> 1612949878.849785: wlan0: DPP-AUTH-SUCCESS init=0
> 1612949878.849789: nl80211: RX frame da=02:00:00:00:00:00 sa=02:00:00:00:01:00 bssid=ff:ff:ff:ff:ff:ff freq=2437 ssi_signal=-50 fc=0xd0 seq_ctrl=0x20 stype=13 (WLAN_FC_STYPE_ACTION) len=227
> 1612949878.849791: wlan0: DPP-CONF-REQ-RX src=02:00:00:00:01:00
> 1612949878.849792: DPP: Enrollee Nonce - hexdump(len=16): 0a 30 74 29 5e c2 69 a0 c5 01 6c ff 49 aa ce 06
> 1612949878.849793: DPP: Enrollee name = 'Test'
> 1612949878.849800: wlan0: DPP-BAND-SUPPORT 81,82,83,84,115,116,117,118,119,120,121,122,123,124,125,126,127,128,129,130
> 1612949878.849800: DPP: No configuration available for Enrollee(sta) - reject configuration request
> 1612949878.849804: wlan0: DPP-CONF-SENT
> 1612949878.849819: wlan02: DPP-TX-STATUS dst=02:00:00:00:01:00 result=SUCCESS
> 1612949879.850821: wlan02: DPP-FAIL No Auth Confirm received

This is on hwsim, but I'm seeing it on qca closed driver too.


> > diff --git a/src/ap/dpp_hostapd.c b/src/ap/dpp_hostapd.c
>
> >  void hostapd_dpp_listen_stop(struct hostapd_data *hapd)
> >  {
> > +     hapd->dpp_allowed_roles = 0;
>
> This might be a reasonable thing to do on an explicit DPP_LISTEN_STOP
> operation.
>
> >  int hostapd_dpp_init(struct hostapd_data *hapd)
> >  {
> > -     hapd->dpp_allowed_roles = DPP_CAPAB_CONFIGURATOR | DPP_CAPAB_ENROLLEE;
> > +     hapd->dpp_allowed_roles = 0;
>
> But this is the part that I'm a bit worried about since it changes the
> past expectation of not requiring an explicit DPP_LISTEN command in some
> cases.

I have no good reason to keep this except it kind of makes sense from
a consistency point of view. But I do understand you don't want to
break past expectations. We can drop this part.


Micha?


From piotr.lobacz at softgent.com  Wed Feb 10 05:10:01 2021
From: piotr.lobacz at softgent.com (Piotr Lobacz)
Date: Wed, 10 Feb 2021 10:10:01 +0000
Subject: ODP: question about error nl80211: Frame command failed: ret=-1
 (Operation not permitted)
In-Reply-To: <20210210092954.GA3792@w1.fi>
References: <AM7PR10MB3206CBD5ECEB8E0DBC36609BE48D9@AM7PR10MB3206.EURPRD10.PROD.OUTLOOK.COM>,
 <20210210092954.GA3792@w1.fi>
Message-ID: <AM0PR10MB3204263BEC99F4B99E53E265E48D9@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>

Hi Jouni,
thx for your quick and very helpfull response. So if the driver handles Probe Request frame processing internally, what could possibly cause, that my mobile device is not being connected (being disconnected) to the wpa_supplicant (in AP mode)?

BR
Piotr


Od: Jouni Malinen <j at w1.fi>
Wys?ane: ?roda, 10 lutego 2021 10:29
Do: Piotr Lobacz <piotr.lobacz at softgent.com>
DW: hostap at lists.infradead.org <hostap at lists.infradead.org>
Temat: Re: question about error nl80211: Frame command failed: ret=-1 (Operation not permitted)

On Wed, Feb 10, 2021 at 01:31:43AM +0000, Piotr Lobacz wrote:
> I am trying to use NetworkManager together with wpa_supplicant 2.9 with closed driver for rtl8192f chip. I have set a hotspot connection and the problem is that if i try to connect to it from any device i get this error from subject. I have also attached full log in here: https://pastebin.com/VyTgz0WA .

That NL80211_CMD_FRAME failure is reported for the case where
wpa_supplicant (in AP mode) is trying to send a Probe Response frame as
a response to the Probe Request frame that the driver delivered to upper
layers. However, the driver seems to refuse to transmit the response.

Taken into account that "closed driver" part, I'm not going to try to
speculate on this more than note that there are many drivers that handle
Probe Request frame processing internally and as such, I would not be
very surprised if they do not accept Probe Response frames from user
space. If the driver is indeed taking care of that functionality, I
would simply ignore this failure.

--
Jouni Malinen                                            PGP id EFC895FA
[https://softgent.com/wp-content/uploads/2020/01/Zasob-14.png]<https://www.softgent.com>

Softgent Sp. z o.o., Budowlanych 31d, 80-298 Gdansk, POLAND

KRS: 0000674406, NIP: 9581679801, REGON: 367090912

www.softgent.com

S?d Rejonowy Gda?sk-P??noc w Gda?sku, VII Wydzia? Gospodarczy Krajowego Rejestru S?dowego

KRS 0000674406, Kapita? zak?adowy: 25 000,00 z? wp?acony w ca?o?ci.


From piotr.lobacz at softgent.com  Wed Feb 10 06:19:41 2021
From: piotr.lobacz at softgent.com (Piotr Lobacz)
Date: Wed, 10 Feb 2021 11:19:41 +0000
Subject: ODP: question about error nl80211: Frame command failed: ret=-1
 (Operation not permitted)
In-Reply-To: <AM0PR10MB3204263BEC99F4B99E53E265E48D9@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
References: <AM7PR10MB3206CBD5ECEB8E0DBC36609BE48D9@AM7PR10MB3206.EURPRD10.PROD.OUTLOOK.COM>,
 <20210210092954.GA3792@w1.fi>,
 <AM0PR10MB3204263BEC99F4B99E53E265E48D9@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
Message-ID: <AM0PR10MB3204A18DD460393E8C6A6547E48D9@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>

Hi again,
i have verified it once again and i can now tell it with 100% that you are right about this frame command issue. That is not the problem.

The real problem is that part 4/4 for handshake is not even being called. I have switched back to wpa_supplicant 2.6 and compared the log results.

This is what i get with 2.6 version:

Feb 10 10:27:15 px30-64 wpa_supplicant[239]: WPA: 6e:95:7c:a0:99:3d WPA_PTK entering state PTKCALCNEGOTIATING2
Feb 10 10:27:15 px30-64 wpa_supplicant[239]: WPA: 6e:95:7c:a0:99:3d WPA_PTK entering state PTKINITNEGOTIATING
Feb 10 10:27:15 px30-64 wpa_supplicant[239]: hostapd_logger: STA 6e:95:7c:a0:99:3d - sending 3/4 msg of 4-Way Handshake
Feb 10 10:27:15 px30-64 wpa_supplicant[239]: WPA: Send EAPOL(version=2 secure=1 mic=1 ack=1 install=1 pairwise=1 kde_len=46 keyidx=1 encr=1)
Feb 10 10:27:15 px30-64 wpa_supplicant[239]: WPA: Replay Counter - hexdump(len=8): 00 00 00 00 00 00 00 02
Feb 10 10:27:15 px30-64 wpa_supplicant[239]: Plaintext EAPOL-Key Key Data - hexdump(len=56): [REMOVED]
Feb 10 10:27:15 px30-64 wpa_supplicant[239]: WPA: Use EAPOL-Key timeout of 1000 ms (retry counter 1)
Feb 10 10:27:15 px30-64 wpa_supplicant[239]: l2_packet_receive: src=6e:95:7c:a0:99:3d len=99
Feb 10 10:27:15 px30-64 wpa_supplicant[239]: wlan0: RX EAPOL from 6e:95:7c:a0:99:3d
Feb 10 10:27:15 px30-64 wpa_supplicant[239]: RX EAPOL - hexdump(len=99): 02 03 00 5f 02 03 0a 00 10 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2a f6 11 ae c0 15 3e 89 65 df b8 79 51 03 22 03 00 00
Feb 10 10:27:15 px30-64 wpa_supplicant[239]: IEEE 802.1X: 99 bytes from 6e:95:7c:a0:99:3d
Feb 10 10:27:15 px30-64 wpa_supplicant[239]:    IEEE 802.1X: version=2 type=3 length=95
Feb 10 10:27:15 px30-64 wpa_supplicant[239]: WPA: Received EAPOL-Key from 6e:95:7c:a0:99:3d key_info=0x30a type=2 key_data_length=0
Feb 10 10:27:15 px30-64 wpa_supplicant[239]: WPA: Received Key Nonce - hexdump(len=32): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Feb 10 10:27:15 px30-64 wpa_supplicant[239]: WPA: Received Replay Counter - hexdump(len=8): 00 00 00 00 00 00 00 02
Feb 10 10:27:15 px30-64 wpa_supplicant[239]: hostapd_logger: STA 6e:95:7c:a0:99:3d - received EAPOL-Key frame (4/4 Pairwise)
Feb 10 10:27:15 px30-64 wpa_supplicant[239]: WPA: 6e:95:7c:a0:99:3d WPA_PTK entering state PTKINITDONE
Feb 10 10:27:15 px30-64 wpa_supplicant[239]: wpa_driver_nl80211_set_key: ifindex=3 (wlan0) alg=3 addr=0x3002e390 key_idx=0 set_tx=1 seq_len=0 key_len=16
Feb 10 10:27:15 px30-64 wpa_supplicant[239]: nl80211: KEY_DATA - hexdump(len=16): [REMOVED]
Feb 10 10:27:15 px30-64 wpa_supplicant[239]:    addr=6e:95:7c:a0:99:3d
Feb 10 10:27:15 px30-64 wpa_supplicant[239]: wlan0: P2P: Marking group formation completed on GO on first data connection
Feb 10 10:27:15 px30-64 wpa_supplicant[239]: dbus: Station MAC address '6e:95:7c:a0:99:3d' 'StaAuthorized'
Feb 10 10:27:15 px30-64 wpa_supplicant[239]: wlan0: AP-STA-CONNECTED 6e:95:7c:a0:99:3d
Feb 10 10:27:15 px30-64 wpa_supplicant[239]: nl80211: Set STA flags - ifname=wlan0 addr=6e:95:7c:a0:99:3d total_flags=0x61 flags_or=0x1 flags_and=0xffffffff authorized=1
Feb 10 10:27:15 px30-64 wpa_supplicant[239]: hostapd_logger: STA 6e:95:7c:a0:99:3d - authorizing port
Feb 10 10:27:15 px30-64 wpa_supplicant[239]: hostapd_logger: STA 6e:95:7c:a0:99:3d - pairwise key handshake completed (RSN)

And this result is for 2.9 version:

Feb 10 01:18:14 px30-64 wpa_supplicant[243]: WPA: EAPOL-Key MIC using HMAC-SHA1
Feb 10 01:18:14 px30-64 wpa_supplicant[243]: WPA: 6e:95:7c:a0:99:3d WPA_PTK entering state PTKCALCNEGOTIATING2
Feb 10 01:18:14 px30-64 wpa_supplicant[243]: WPA: 6e:95:7c:a0:99:3d WPA_PTK entering state PTKINITNEGOTIATING
Feb 10 01:18:14 px30-64 wpa_supplicant[243]: hostapd_logger: STA 6e:95:7c:a0:99:3d - sending 3/4 msg of 4-Way Handshake
Feb 10 01:18:14 px30-64 wpa_supplicant[243]: WPA: Send EAPOL(version=2 secure=1 mic=1 ack=1 install=1 pairwise=1 kde_len=50 keyidx=1 encr=1)
Feb 10 01:18:14 px30-64 wpa_supplicant[243]: WPA: Replay Counter - hexdump(len=8): 00 00 00 00 00 00 00 02
Feb 10 01:18:14 px30-64 wpa_supplicant[243]: Plaintext EAPOL-Key Key Data - hexdump(len=64): [REMOVED]
Feb 10 01:18:14 px30-64 wpa_supplicant[243]: WPA: Encrypt Key Data using AES-WRAP (KEK length 16)
Feb 10 01:18:14 px30-64 wpa_supplicant[243]: WPA: EAPOL-Key MIC using HMAC-SHA1
Feb 10 01:18:14 px30-64 wpa_supplicant[243]: WPA: Use EAPOL-Key timeout of 1000 ms (retry counter 1)
Feb 10 01:18:14 px30-64 wpa_supplicant[243]: nl80211: Event message available
Feb 10 01:18:14 px30-64 wpa_supplicant[243]: nl80211: Drv Event 20 (NL80211_CMD_DEL_STATION) received for wlan0
Feb 10 01:18:14 px30-64 wpa_supplicant[243]: nl80211: Delete station 6e:95:7c:a0:99:3d
Feb 10 01:18:14 px30-64 wpa_supplicant[243]: wlan0: Event DISASSOC (1) received
Feb 10 01:18:14 px30-64 wpa_supplicant[243]: wlan0: Disassociation notification
Feb 10 01:18:14 px30-64 wpa_supplicant[243]: wlan0:  * reason 0 (UNKNOWN)
Feb 10 01:18:14 px30-64 wpa_supplicant[243]: wlan0: * address 6e:95:7c:a0:99:3d

The question is what has changed in between that prevents me from connecting?

BR
Piotr

Od: Piotr Lobacz <piotr.lobacz at softgent.com>
Wys?ane: ?roda, 10 lutego 2021 11:10
Do: Jouni Malinen <j at w1.fi>
DW: hostap at lists.infradead.org <hostap at lists.infradead.org>
Temat: ODP: question about error nl80211: Frame command failed: ret=-1 (Operation not permitted)

Hi Jouni,
thx for your quick and very helpfull response. So if the driver handles Probe Request frame processing internally, what could possibly cause, that my mobile device is not being connected (being disconnected) to the wpa_supplicant (in AP mode)?

BR
Piotr


Od: Jouni Malinen <j at w1.fi>
Wys?ane: ?roda, 10 lutego 2021 10:29
Do: Piotr Lobacz <piotr.lobacz at softgent.com>
DW: hostap at lists.infradead.org <hostap at lists.infradead.org>
Temat: Re: question about error nl80211: Frame command failed: ret=-1 (Operation not permitted)

On Wed, Feb 10, 2021 at 01:31:43AM +0000, Piotr Lobacz wrote:
> I am trying to use NetworkManager together with wpa_supplicant 2.9 with closed driver for rtl8192f chip. I have set a hotspot connection and the problem is that if i try to connect to it from any device i get this error from subject. I have also attached full log in here: https://pastebin.com/VyTgz0WA .

That NL80211_CMD_FRAME failure is reported for the case where
wpa_supplicant (in AP mode) is trying to send a Probe Response frame as
a response to the Probe Request frame that the driver delivered to upper
layers. However, the driver seems to refuse to transmit the response.

Taken into account that "closed driver" part, I'm not going to try to
speculate on this more than note that there are many drivers that handle
Probe Request frame processing internally and as such, I would not be
very surprised if they do not accept Probe Response frames from user
space. If the driver is indeed taking care of that functionality, I
would simply ignore this failure.

--
Jouni Malinen                                            PGP id EFC895FA
[https://softgent.com/wp-content/uploads/2020/01/Zasob-14.png]<https://www.softgent.com>

Softgent Sp. z o.o., Budowlanych 31d, 80-298 Gdansk, POLAND

KRS: 0000674406, NIP: 9581679801, REGON: 367090912

www.softgent.com

S?d Rejonowy Gda?sk-P??noc w Gda?sku, VII Wydzia? Gospodarczy Krajowego Rejestru S?dowego

KRS 0000674406, Kapita? zak?adowy: 25 000,00 z? wp?acony w ca?o?ci.


From wystans at gmail.com  Wed Feb 10 19:04:38 2021
From: wystans at gmail.com (Wystan Schmidt)
Date: Wed, 10 Feb 2021 17:04:38 -0700
Subject: [PATCH] DPP: Convert AKM to PSK/SAE for legacy DPP1 client
Message-ID: <CA+XRdEALwk5mx-XwA-roJF-Jjf4Gz0FUvG8RXc=S2x0_7C-Dcw@mail.gmail.com>

Currently, hostapd will convert a DPP2 Config object
to a DPP-only config for a legacy DPP1 client.

However, Android 10+ phones, the only potential DPP1
clients (AFAIK), do not support the DPP-AKM and will fail
when given a DPP-AKM object.

This will ensure the current Android implementation
can connect using DPP.

Signed-off-by: Wystan Schmidt <wystans at gmail.com>
---
 src/common/dpp.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/src/common/dpp.c b/src/common/dpp.c
index 3c8c7682d..aad99253e 100644
--- a/src/common/dpp.c
+++ b/src/common/dpp.c
@@ -1450,9 +1450,15 @@ dpp_build_conf_obj_dpp(struct dpp_authentication *auth,

        akm = conf->akm;
        if (dpp_akm_ver2(akm) && auth->peer_version < 2) {
-               wpa_printf(MSG_DEBUG,
-                          "DPP: Convert DPP+legacy credential to
DPP-only for peer that does not support version 2");
-               akm = DPP_AKM_DPP;
+               if (akm == DPP_AKM_PSK_SAE_DPP) {
+            wpa_printf(MSG_DEBUG,
+                   "DPP: Convert DPP+legacy credential to legacy
WPA2-PSK for peer that does not support version 2");
+            akm = DPP_AKM_PSK;
+        } else if (akm == DPP_AKM_SAE_DPP) {
+            wpa_printf(MSG_DEBUG,
+                   "DPP: Convert DPP+legacy credential to WPA3 for
peer that does not support version 2");
+            akm = DPP_AKM_SAE;
+        }
        }

 #ifdef CONFIG_TESTING_OPTIONS
--
2.24.3 (Apple Git-128)


From wystans at gmail.com  Wed Feb 10 19:18:32 2021
From: wystans at gmail.com (Wystan Schmidt)
Date: Wed, 10 Feb 2021 17:18:32 -0700
Subject: [PATCH] DPP: Convert AKM to PSK/SAE for legacy DPP1 client
In-Reply-To: <CA+XRdEALwk5mx-XwA-roJF-Jjf4Gz0FUvG8RXc=S2x0_7C-Dcw@mail.gmail.com>
References: <CA+XRdEALwk5mx-XwA-roJF-Jjf4Gz0FUvG8RXc=S2x0_7C-Dcw@mail.gmail.com>
Message-ID: <CA+XRdEDJaWJUSd4n9HMXH1HFY1-Tgbs31WL3rcQJ8o3CeuMcAw@mail.gmail.com>

Fix the new lines in the patch.

---
 src/common/dpp.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/src/common/dpp.c b/src/common/dpp.c
index 3c8c7682d..aad99253e 100644
--- a/src/common/dpp.c
+++ b/src/common/dpp.c
@@ -1450,9 +1450,15 @@ dpp_build_conf_obj_dpp(struct dpp_authentication *auth,

        akm = conf->akm;
        if (dpp_akm_ver2(akm) && auth->peer_version < 2) {
-               wpa_printf(MSG_DEBUG,
-                          "DPP: Convert DPP+legacy credential to
DPP-only for peer that does not support version 2");
-               akm = DPP_AKM_DPP;
+               if (akm == DPP_AKM_PSK_SAE_DPP) {
+            wpa_printf(MSG_DEBUG,
+                   "DPP: Convert DPP+legacy credential to legacy
WPA2-PSK for peer that does not support version 2");
+            akm = DPP_AKM_PSK;
+        } else if (akm == DPP_AKM_SAE_DPP) {
+            wpa_printf(MSG_DEBUG,
+                   "DPP: Convert DPP+legacy credential to WPA3 for
peer that does not support version 2");
+            akm = DPP_AKM_SAE;
+        }
        }

 #ifdef CONFIG_TESTING_OPTIONS
--
2.24.3 (Apple Git-128)

On Wed, Feb 10, 2021 at 5:04 PM Wystan Schmidt <wystans at gmail.com> wrote:
>
> Currently, hostapd will convert a DPP2 Config object
> to a DPP-only config for a legacy DPP1 client.
>
> However, Android 10+ phones, the only potential DPP1
> clients (AFAIK), do not support the DPP-AKM and will fail
> when given a DPP-AKM object.
>
> This will ensure the current Android implementation
> can connect using DPP.
>
> Signed-off-by: Wystan Schmidt <wystans at gmail.com>
> ---
>  src/common/dpp.c | 12 +++++++++---
>  1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/src/common/dpp.c b/src/common/dpp.c
> index 3c8c7682d..aad99253e 100644
> --- a/src/common/dpp.c
> +++ b/src/common/dpp.c
> @@ -1450,9 +1450,15 @@ dpp_build_conf_obj_dpp(struct dpp_authentication *auth,
>
>         akm = conf->akm;
>         if (dpp_akm_ver2(akm) && auth->peer_version < 2) {
> -               wpa_printf(MSG_DEBUG,
> -                          "DPP: Convert DPP+legacy credential to
> DPP-only for peer that does not support version 2");
> -               akm = DPP_AKM_DPP;
> +               if (akm == DPP_AKM_PSK_SAE_DPP) {
> +            wpa_printf(MSG_DEBUG,
> +                   "DPP: Convert DPP+legacy credential to legacy
> WPA2-PSK for peer that does not support version 2");
> +            akm = DPP_AKM_PSK;
> +        } else if (akm == DPP_AKM_SAE_DPP) {
> +            wpa_printf(MSG_DEBUG,
> +                   "DPP: Convert DPP+legacy credential to WPA3 for
> peer that does not support version 2");
> +            akm = DPP_AKM_SAE;
> +        }
>         }
>
>  #ifdef CONFIG_TESTING_OPTIONS
> --
> 2.24.3 (Apple Git-128)


From piotr.lobacz at softgent.com  Thu Feb 11 13:25:29 2021
From: piotr.lobacz at softgent.com (Piotr Lobacz)
Date: Thu, 11 Feb 2021 18:25:29 +0000
Subject: connection time out because of a WRONG_KEY (WPA-PSK client connection)
Message-ID: <AM0PR10MB3204CE4AE6F72AC61F2CEE27E48C9@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>

Hi All,
after struggling for a couple of few days with my rtl8182fs wifi card i have fixed some issues with it.

I've added few patches to rockchip kernel 4.4:
- ipv4: add option to drop unicast encapsulated in L2 multicast
- ipv4: add option to drop gratuitous ARP packets
- ipv6: add option to drop unicast encapsulated in L2 multicast
- ipv6: add option to drop unsolicited neighbor advertisements

Now with this patch all is working for me (i can run hotspot, i can connect to the client wifi) with wpa_supplicant 2.6. The problem is that this driver supposedly supports wpa3. So in order to have it support available i have switched from wpa_supplicant 2.6 to 2.9. But the real problem started. I am no longer able to connect to my wifi. As i was able earlier to connect to WPA-PSK encryptet network now i am not able to. The log looks like that:

Feb 11 17:56:45 px30-64 wpa_supplicant[249]: wlan0-vxd: SME: Trying to authenticate with ec:08:6b:e7:f3:40 (SSID='beherith' freq=2462 MHz)
Feb 11 17:56:46 px30-64 wpa_supplicant[249]: wlan0-vxd: Trying to associate with ec:08:6b:e7:f3:40 (SSID='beherith' freq=2462 MHz)
Feb 11 17:56:46 px30-64 wpa_supplicant[249]: wlan0-vxd: Associated with ec:08:6b:e7:f3:40
Feb 11 17:56:46 px30-64 wpa_supplicant[249]: wlan0-vxd: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
Feb 11 17:56:57 px30-64 wpa_supplicant[249]: wlan0-vxd: Authentication with ec:08:6b:e7:f3:40 timed out.
Feb 11 17:56:57 px30-64 wpa_supplicant[249]: wlan0-vxd: CTRL-EVENT-DISCONNECTED bssid=ec:08:6b:e7:f3:40 reason=3 locally_generated=1
Feb 11 17:56:57 px30-64 wpa_supplicant[249]: wlan0-vxd: WPA: 4-Way Handshake failed - pre-shared key may be incorrect
Feb 11 17:56:57 px30-64 wpa_supplicant[249]: wlan0-vxd: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="beherith" auth_failures=1 duration=10 reason=WRONG_KEY

I see that it has succesfully been associated, but handshake failed due to the connection time out. Can anybody point me what am i missing? Does wpa_supplicant 2.9 may run on kernel 4.4 or do i need a newer one? I've been searching for reason why this situation occurs and found that timer has passed (10 seconds) during handshake and that is why connection is being closed, but that still doesn't tell me anything.

BR
Piotr
[https://softgent.com/wp-content/uploads/2020/01/Zasob-14.png]<https://www.softgent.com>

Softgent Sp. z o.o., Budowlanych 31d, 80-298 Gdansk, POLAND

KRS: 0000674406, NIP: 9581679801, REGON: 367090912

www.softgent.com

S?d Rejonowy Gda?sk-P??noc w Gda?sku, VII Wydzia? Gospodarczy Krajowego Rejestru S?dowego

KRS 0000674406, Kapita? zak?adowy: 25 000,00 z? wp?acony w ca?o?ci.


From aland at deployingradius.com  Thu Feb 11 14:47:53 2021
From: aland at deployingradius.com (Alan DeKok)
Date: Thu, 11 Feb 2021 14:47:53 -0500
Subject: Patch to set TLS maximum version
Message-ID: <09E2AD6F-BBDF-4479-A3D8-C11817A26841@deployingradius.com>

  Found as part of TLS 1.3 testing.

  On a related note, I've been adding automated tests to FreeRADIUS for the various EAP methods, and the various TLS versions.  If I enabled one TLS version via "tls_disable_tlsv1_0=0" and disabled all others, then eapol_test would always use TLS 1.3!  The behavior was the same for TLS 1.0 and TLS 1.1.  But doing the same thing for TLS 1.2 was OK.

  It seems like an issue in OpenSSL.  I'm summarizing it here so that other people don't have the same problems I did.

  The code in src/crypto/tls_openssl.c calls:

	SSL_set_options(ssl, ...);

  to enable / disable the TLS versions.  Then it *also* calls SSL_set_min_proto_version(),  and with this patch it also calls SSL_set_max_proto_version().  That's all well and good for TLS 1.2, but it doesn't work for TLS 1.0 and TLS 1.1.

  However... calling *either* SSL_set_min_proto_version() or SSL_set_max_proto_version(), seems to over-ride the earlier calls to SSL_set_option().  Even worse, whatever version was set via SSL_set_min_proto_version() is *also* ignored, and OpenSSL always proposed TLS 1.3.

  That behavior seems bad.  :(  My short-term work-around locally is to just comment out the code in tls_openssl.c which calls SSL_set_min_proto_version().  So that only SSL_set_options() is called.  It then works.

  This is on OSX with OpenSSL 1.1.0 installed from homebrew.  I haven't checked other versions of OpenSSL yet.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Set-maximum-TLS-version-too.patch
Type: application/octet-stream
Size: 1676 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/hostap/attachments/20210211/c18ae7b5/attachment.obj>

From johannes at sipsolutions.net  Fri Feb 12 04:22:17 2021
From: johannes at sipsolutions.net (Johannes Berg)
Date: Fri, 12 Feb 2021 10:22:17 +0100
Subject: [PATCH] wpa_supplicant: multi_ap: only enable 4addr mode if not
 already enabled
In-Reply-To: <CAFED-j=nQAFSQ00Tz81TiVmYu1OZqTtii=4wRNPHvKTC8z0B+g@mail.gmail.com>
 (sfid-20210210_123807_729383_7DBCC0F2)
References: <20210208172823.11536-1-raphael.melotte@mind.be>
 <CAFED-jn5W09baaLteiu++GyoZCg4aq6-eK47=-NyaxhwLek0RA@mail.gmail.com>
 <CAFED-j=OtthxoPafFVp7zgHMCqLBrNt1_4WRsGpp+HbEnEz1Ww@mail.gmail.com>
 <20210210093803.GB3792@w1.fi>
 <CAFED-j=nQAFSQ00Tz81TiVmYu1OZqTtii=4wRNPHvKTC8z0B+g@mail.gmail.com>
 (sfid-20210210_123807_729383_7DBCC0F2)
Message-ID: <341102d930530ee1810fbf653ed1f1f1e6090520.camel@sipsolutions.net>

On Wed, 2021-02-10 at 12:37 +0100, Janusz Dziedzic wrote:

> > > Did fast patch (didn't check code deeply yet - just check set 4addr
> > > when busy issuey, seems works correctly):
> > > diff --git a/net/wireless/util.c b/net/wireless/util.c
> > > @@ -1027,6 +1027,7 @@ int cfg80211_change_iface(struct
> > > cfg80211_registered_device *rdev,
> > > 
> > >         /* if it's part of a bridge, reject changing type to station/ibss */
> > >         if (netif_is_bridge_port(dev) &&
> > > +           (ntype != otype) &&
> > >             (ntype == NL80211_IFTYPE_ADHOC ||
> > >              ntype == NL80211_IFTYPE_STATION ||
> > >              ntype == NL80211_IFTYPE_P2P_CLIENT))
> > 
> > How would that prevent disabling of 4addr mode when the netdev is in a
> > bridge?
> > 
> This what I have with cfg80211 patch included:
> root at t2:~# brctl addif br0 wlp1s0
> root at t2:~# iw wlp1s0 set 4addr on
> root at t2:~# brctl show
> bridge name bridge id STP enabled interfaces
> br0 8000.68942328a725 no wlp1s0
> 
> root at t2:~# iw wlp1s0 set 4addr off
> command failed: Device or resource busy (-16)
> root at t2:~# iw wlp1s0 set 4addr on
> root at t2:~# iw wlp1s0 set 4addr on
> 
> Seems there is another check in cfg80211 that already handle this.

It's a different code path to set 4addr on/off in this function, so this
is not really a surprise?

Anyway, from a code POV this seems OK, though I'd prefer moving the
bridge port check into the existing "ntype != otype" if there.

johannes



From andrew at shadura.me  Fri Feb 12 04:53:27 2021
From: andrew at shadura.me (Andrej Shadura)
Date: Fri, 12 Feb 2021 10:53:27 +0100
Subject: [PATCH] Hostapd does not update WPS credentials on SIGHUP
In-Reply-To: <20201011171447.GA29333@w1.fi>
References: <fdadce6eddc483bb5f4cd1a6a343e046@oktetlabs.ru>
 <20201011171447.GA29333@w1.fi>
Message-ID: <d1319e6e-e78a-4cc0-aa52-4c1bc97ee05b@www.fastmail.com>

Hi,

On Sun, 11 Oct 2020, at 19:14, Jouni Malinen wrote:
> On Thu, Aug 20, 2020 at 01:46:57PM +0300, Dmitry Koroban wrote:
> > Faced this issue on v2.6, but 2.10 seems to have it too.
> > Steps to reproduce:
> > 1. Start hostapd with WPS enabled
> > 2. Change passphrase in hostapd.conf
> > 3. Send SIGHUP to hostapd
> > 4. Try to connect client using wps_pbc
> > 5. Client receives old passphrase and cannot connect
 
> There is a call to hostapd_update_wps() just before this context and
> that function is the place to update whatever needs to be updated for
> WPS. It would be cleaner to do this type of restarting of WPS there in
> case WPS was started before reconfiguration instead of hardcoding
> deinit/init to happen after that update function is executed.

Has there been any follow-up on this, maybe an alternative implementation? I don?t see anything on the mailing list, but maybe I?m looking in a wrong place?

-- 
Cheers,
  Andrej


From raphael.melotte at mind.be  Fri Feb 12 05:33:43 2021
From: raphael.melotte at mind.be (=?UTF-8?B?UmFwaGHDq2wgTcOpbG90dGU=?=)
Date: Fri, 12 Feb 2021 11:33:43 +0100
Subject: [PATCH] Hostapd does not update WPS credentials on SIGHUP
In-Reply-To: <d1319e6e-e78a-4cc0-aa52-4c1bc97ee05b@www.fastmail.com>
References: <fdadce6eddc483bb5f4cd1a6a343e046@oktetlabs.ru>
 <20201011171447.GA29333@w1.fi>
 <d1319e6e-e78a-4cc0-aa52-4c1bc97ee05b@www.fastmail.com>
Message-ID: <a62efae1-723a-e24b-2597-c08bf3a65cae@mind.be>



On 2/12/21 10:53 AM, Andrej Shadura wrote:
> Hi,
> 
> On Sun, 11 Oct 2020, at 19:14, Jouni Malinen wrote:
>> On Thu, Aug 20, 2020 at 01:46:57PM +0300, Dmitry Koroban wrote:
>>> Faced this issue on v2.6, but 2.10 seems to have it too.
>>> Steps to reproduce:
>>> 1. Start hostapd with WPS enabled
>>> 2. Change passphrase in hostapd.conf
>>> 3. Send SIGHUP to hostapd
>>> 4. Try to connect client using wps_pbc
>>> 5. Client receives old passphrase and cannot connect
>   
>> There is a call to hostapd_update_wps() just before this context and
>> that function is the place to update whatever needs to be updated for
>> WPS. It would be cleaner to do this type of restarting of WPS there in
>> case WPS was started before reconfiguration instead of hardcoding
>> deinit/init to happen after that update function is executed.
> 
> Has there been any follow-up on this, maybe an alternative implementation? I don?t see anything on the mailing list, but maybe I?m looking in a wrong place?
> 

Hi,

This should be fixed on master starting from 
'f95ccc102a6e55bb2543ba68164d6a007a188b25'.

The related patches on the mailing list are:
https://lists.infradead.org/pipermail/hostap/2021-February/039299.html
https://lists.infradead.org/pipermail/hostap/2020-December/039205.html

Kind regards,

Rapha?l


From kazikcz at gmail.com  Fri Feb 12 08:27:53 2021
From: kazikcz at gmail.com (Michal Kazior)
Date: Fri, 12 Feb 2021 13:27:53 +0000
Subject: [PATCH 1/2] wpa_supplicant: defer chirp scan if other scan is queued
 up
Message-ID: <20210212132754.11028-1-kazikcz@gmail.com>

From: Michal Kazior <michal at plume.com>

The chirp scan could override the
scan_res_handler. This could lead to
wpa_supplicant getting stuck in a scanning state
while not scanning at all until forced to, eg. via
explicit SCAN control command.

The condition for trigerring this problem in my
testing was when (interface_count % 3) == 2.
This introduced 2s delay before actual scan was
triggered after starting wpa_s instance up. If dpp
chirping was requested fast enough, in between
the queueing and triggering, it would punt the
scan request, never to be resumed again. Chirp
scan handler wouldn't resume it leaving wpa_s
inadvertently idle.

Signed-off-by: Michal Kazior <michal at plume.com>
---
 wpa_supplicant/dpp_supplicant.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/wpa_supplicant/dpp_supplicant.c b/wpa_supplicant/dpp_supplicant.c
index 910602e34..a34a4ea80 100644
--- a/wpa_supplicant/dpp_supplicant.c
+++ b/wpa_supplicant/dpp_supplicant.c
@@ -3608,6 +3608,17 @@ static void wpas_dpp_chirp_next(void *eloop_ctx, void *timeout_ctx)
 	if (wpa_s->dpp_chirp_freq == 0) {
 		if (wpa_s->dpp_chirp_round % 4 == 0 &&
 		    !wpa_s->dpp_chirp_scan_done) {
+			if (wpas_scan_scheduled(wpa_s)) {
+				wpa_printf(MSG_DEBUG,
+					   "DPP: Deferring chirp scan because another scan is planned alredy",
+					   wpa_s->dpp_chirp_freq);
+				if (eloop_register_timeout(1, 0, wpas_dpp_chirp_next,
+							   wpa_s, NULL) < 0) {
+					wpas_dpp_chirp_stop(wpa_s);
+					return;
+				}
+				return;
+			}
 			wpa_printf(MSG_DEBUG,
 				   "DPP: Update channel list for chirping");
 			wpa_s->scan_req = MANUAL_SCAN_REQ;
-- 
2.27.0



From kazikcz at gmail.com  Fri Feb 12 08:27:54 2021
From: kazikcz at gmail.com (Michal Kazior)
Date: Fri, 12 Feb 2021 13:27:54 +0000
Subject: [PATCH 2/2] wpa_supplicant: dont exit scanning state on config reload
In-Reply-To: <20210212132754.11028-1-kazikcz@gmail.com>
References: <20210212132754.11028-1-kazikcz@gmail.com>
Message-ID: <20210212132754.11028-2-kazikcz@gmail.com>

From: Michal Kazior <michal at plume.com>

There's a chance that prior to config reload being
requested a scan work was started. As such forcing
wpa_s to WPA_DISCONNECTED was removing any hints
that the actual driver is busy with work. That led
to wpa_s reporting "Failed to initialize AP scan"
over and over again for a few seconds (depending
on driver/capabilities) until the untracked scan
finished.

Cancelling a scan isn't really a solution because
there's a bunch of scanning state bits sprinkled
across wpa_s structure and they get updated as
driver events actually flow in in async manner.

As far as I can tell this is only preventing
unnecessary warning messages. This doesn't seem
like it was crippling any logic per se.

Signed-off-by: Michal Kazior <michal at plume.com>
---
 wpa_supplicant/wpa_supplicant.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/wpa_supplicant/wpa_supplicant.c b/wpa_supplicant/wpa_supplicant.c
index db99d9597..8e6b232ea 100644
--- a/wpa_supplicant/wpa_supplicant.c
+++ b/wpa_supplicant/wpa_supplicant.c
@@ -1099,13 +1099,19 @@ static void wpa_supplicant_terminate(int sig, void *signal_ctx)
 void wpa_supplicant_clear_status(struct wpa_supplicant *wpa_s)
 {
 	enum wpa_states old_state = wpa_s->wpa_state;
+	enum wpa_states new_state;
+
+	if (old_state == WPA_SCANNING)
+		new_state = WPA_SCANNING;
+	else
+		new_state = WPA_DISCONNECTED;
 
 	wpa_s->pairwise_cipher = 0;
 	wpa_s->group_cipher = 0;
 	wpa_s->mgmt_group_cipher = 0;
 	wpa_s->key_mgmt = 0;
 	if (wpa_s->wpa_state != WPA_INTERFACE_DISABLED)
-		wpa_supplicant_set_state(wpa_s, WPA_DISCONNECTED);
+		wpa_supplicant_set_state(wpa_s, new_state);
 
 	if (wpa_s->wpa_state != old_state)
 		wpas_notify_state_changed(wpa_s, wpa_s->wpa_state, old_state);
-- 
2.27.0



From briannorris at chromium.org  Fri Feb 12 22:03:35 2021
From: briannorris at chromium.org (Brian Norris)
Date: Fri, 12 Feb 2021 19:03:35 -0800
Subject: [PATCH] wlantest: avoid unaligned iphdr pointers
Message-ID: <20210213030335.777799-1-briannorris@chromium.org>

Buffers passed to rx_data_ip() may not be naturally-aligned, and so we
get unpredictable behavior when we cast that to an IP header. In
particular, this code may crash on ARM.

Signed-off-by: Brian Norris <briannorris at chromium.org>
---
We have have the same problem in ICMP code, but I haven't hit such a
crash yet.

 wlantest/rx_ip.c | 35 ++++++++++++++++++-----------------
 1 file changed, 18 insertions(+), 17 deletions(-)

diff --git a/wlantest/rx_ip.c b/wlantest/rx_ip.c
index fdf80b7d77a1..00ee544a18de 100644
--- a/wlantest/rx_ip.c
+++ b/wlantest/rx_ip.c
@@ -120,63 +120,64 @@ void rx_data_ip(struct wlantest *wt, const u8 *bssid, const u8 *sta_addr,
 		const u8 *dst, const u8 *src, const u8 *data, size_t len,
 		const u8 *peer_addr)
 {
-	const struct ip *ip;
+	struct ip ip;
 	const u8 *payload;
 	size_t plen;
 	uint16_t frag_off, ip_len;
 
-	ip = (const struct ip *) data;
-	if (len < sizeof(*ip))
+	if (len < sizeof(ip))
 		return;
-	if (ip->ip_v != 4) {
+	memcpy(&ip, data, sizeof(ip));
+
+	if (ip.ip_v != 4) {
 		if (hwsim_test_packet(data, len)) {
 			add_note(wt, MSG_INFO, "hwsim_test package");
 			return;
 		}
 		add_note(wt, MSG_DEBUG, "Unexpected IP protocol version %u in "
 			 "IPv4 packet (bssid=" MACSTR " str=" MACSTR
-			 " dst=" MACSTR ")", ip->ip_v, MAC2STR(bssid),
+			 " dst=" MACSTR ")", ip.ip_v, MAC2STR(bssid),
 			 MAC2STR(src), MAC2STR(dst));
 		return;
 	}
-	if (ip->ip_hl * 4 < sizeof(*ip)) {
+	if (ip.ip_hl * 4 < sizeof(ip)) {
 		add_note(wt, MSG_DEBUG, "Unexpected IP header length %u in "
 			 "IPv4 packet (bssid=" MACSTR " str=" MACSTR
-			 " dst=" MACSTR ")", ip->ip_hl, MAC2STR(bssid),
+			 " dst=" MACSTR ")", ip.ip_hl, MAC2STR(bssid),
 			 MAC2STR(src), MAC2STR(dst));
 		return;
 	}
-	if (ip->ip_hl * 4 > len) {
+	if (ip.ip_hl * 4 > len) {
 		add_note(wt, MSG_DEBUG, "Truncated IP header (ihl=%u len=%u) "
 			 "in IPv4 packet (bssid=" MACSTR " str=" MACSTR
-			 " dst=" MACSTR ")", ip->ip_hl, (unsigned) len,
+			 " dst=" MACSTR ")", ip.ip_hl, (unsigned) len,
 			 MAC2STR(bssid), MAC2STR(src), MAC2STR(dst));
 		return;
 	}
 
-	/* TODO: check header checksum in ip->ip_sum */
+	/* TODO: check header checksum in ip.ip_sum */
 
-	frag_off = be_to_host16(ip->ip_off);
+	frag_off = be_to_host16(ip.ip_off);
 	if (frag_off & 0x1fff) {
 		wpa_printf(MSG_EXCESSIVE, "IP fragment reassembly not yet "
 			   "supported");
 		return;
 	}
 
-	ip_len = be_to_host16(ip->ip_len);
+	ip_len = be_to_host16(ip.ip_len);
 	if (ip_len > len)
 		return;
 	if (ip_len < len)
 		len = ip_len;
 
-	payload = data + 4 * ip->ip_hl;
-	plen = len - 4 * ip->ip_hl;
+	payload = data + 4 * ip.ip_hl;
+	plen = len - 4 * ip.ip_hl;
 
-	switch (ip->ip_p) {
+	switch (ip.ip_p) {
 #ifndef __APPLE__
 	case IPPROTO_ICMP:
-		rx_data_icmp(wt, bssid, sta_addr, ip->ip_dst.s_addr,
-			     ip->ip_src.s_addr, payload, plen, peer_addr);
+		rx_data_icmp(wt, bssid, sta_addr, ip.ip_dst.s_addr,
+			     ip.ip_src.s_addr, payload, plen, peer_addr);
 		break;
 #endif /* __APPLE__ */
 	}
-- 
2.30.0.478.g8a0d178c01-goog



From j at w1.fi  Sat Feb 13 16:30:02 2021
From: j at w1.fi (Jouni Malinen)
Date: Sat, 13 Feb 2021 23:30:02 +0200
Subject: [PATCH] DPP: Convert AKM to PSK/SAE for legacy DPP1 client
In-Reply-To: <CA+XRdEALwk5mx-XwA-roJF-Jjf4Gz0FUvG8RXc=S2x0_7C-Dcw@mail.gmail.com>
References: <CA+XRdEALwk5mx-XwA-roJF-Jjf4Gz0FUvG8RXc=S2x0_7C-Dcw@mail.gmail.com>
Message-ID: <20210213213002.GA468580@w1.fi>

On Wed, Feb 10, 2021 at 05:04:38PM -0700, Wystan Schmidt wrote:
> Currently, hostapd will convert a DPP2 Config object
> to a DPP-only config for a legacy DPP1 client.
> 
> However, Android 10+ phones, the only potential DPP1
> clients (AFAIK), do not support the DPP-AKM and will fail
> when given a DPP-AKM object.

That is unfortunate taken into account DPP AKM support in DPP (v1) is
mandatory while support for DPP to provision SAE credential is not.

What kind of a use case is this targeting? PSK+SAE+DPP enabled in
Configurator for all Enrollees regardless of the Enrollee capabilities?

> diff --git a/src/common/dpp.c b/src/common/dpp.c
> @@ -1450,9 +1450,15 @@ dpp_build_conf_obj_dpp(struct dpp_authentication *auth,
> 
>         akm = conf->akm;
>         if (dpp_akm_ver2(akm) && auth->peer_version < 2) {
> -               wpa_printf(MSG_DEBUG,
> -                          "DPP: Convert DPP+legacy credential to
> DPP-only for peer that does not support version 2");
> -               akm = DPP_AKM_DPP;
> +               if (akm == DPP_AKM_PSK_SAE_DPP) {
> +            wpa_printf(MSG_DEBUG,
> +                   "DPP: Convert DPP+legacy credential to legacy
> WPA2-PSK for peer that does not support version 2");
> +            akm = DPP_AKM_PSK;

PSK is the least secure option of those three included AKMs. This looks
a really bad way of handling this case.. DPP_AKM_DPP is used here to
pick the strongest option (and one that is actually mandatory to
support). At minimum, this should use DPP_AKM_PSK_SAE which was defined
in DPP v1.

> +        } else if (akm == DPP_AKM_SAE_DPP) {
> +            wpa_printf(MSG_DEBUG,
> +                   "DPP: Convert DPP+legacy credential to WPA3 for
> peer that does not support version 2");
> +            akm = DPP_AKM_SAE;
> +        }

DPP AKM support is mandatory while SAE AKM support is optional. This
does not really look like a good default behavior from the protocol view
point.

-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Sat Feb 13 17:09:21 2021
From: j at w1.fi (Jouni Malinen)
Date: Sun, 14 Feb 2021 00:09:21 +0200
Subject: [PATCH 1/2] wpa_supplicant: Move `wpa_config_get_line()` into
 utils
In-Reply-To: <66a77558af5b131b74f50beff5550f5e8d5e1b72.1612720013.git.ps@pks.im>
References: <cover.1612720013.git.ps@pks.im>
 <66a77558af5b131b74f50beff5550f5e8d5e1b72.1612720013.git.ps@pks.im>
Message-ID: <20210213220921.GB468580@w1.fi>

On Sun, Feb 07, 2021 at 06:48:31PM +0100, Patrick Steinhardt wrote:
> The function `wpa_config_get_line()` is used by the wpa_supplicant
> config file parser in order to retrieve the next non-commend non-blank
> line. We'll need the same kind of functionality in order to implement
> the file-based external password backend, so as a preparatory step this
> commit extracts the function into its own standalone file in the utils
> package.
> 
> No functional changes are expected from this commit.

> diff --git a/src/utils/config.c b/src/utils/config.c
> @@ -0,0 +1,97 @@
> +/*
> + * Configuration parsing
> + * Copyright (c) 2021, Patrick Steinhardt <ps at pks.im>

Isn't this just moving existing functionality from
wpa_supplicant/config_file.c to another file? Changing copyright
statement for the otherwise unmodified implementation does not sound
appropriate.

> diff --git a/wpa_supplicant/Makefile b/wpa_supplicant/Makefile

This would need matching changes in wpa_supplicant/Android.mk to avoid
breaking Android builds. And actually also in wpa_supplicant/nmake.mak
and wpa_supplicant/vs2005/*/*.vcproj.

-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Sat Feb 13 17:18:22 2021
From: j at w1.fi (Jouni Malinen)
Date: Sun, 14 Feb 2021 00:18:22 +0200
Subject: [PATCH 2/2] ext_password: Implement new file-based backend
In-Reply-To: <6f9819204cd32b37ad98c3d24c18469d1d7db3ea.1612720013.git.ps@pks.im>
References: <cover.1612720013.git.ps@pks.im>
 <6f9819204cd32b37ad98c3d24c18469d1d7db3ea.1612720013.git.ps@pks.im>
Message-ID: <20210213221822.GC468580@w1.fi>

On Sun, Feb 07, 2021 at 06:48:36PM +0100, Patrick Steinhardt wrote:
> It's currently not easily possible to separate configuration of an
> interface and credentials. This makes it hard to distribute
> configuration across a set of nodes which use wpa_supplicant without
> also having to store credentials in the same file. While this can be
> solved via scripting, having a native way to achieve this would be
> preferable.
> 
> Turns out there already is a framework to have external password
> storages. It only has a single "test" backend though, which is kind of
> an in-memory store which gets initialized with all passwords up front.
> This isn't really suitable for above usecase: the backend cannot be
> initialized as part of the central configuration given that it needs the
> credentials, and we want to avoid scripting.
> 
> This commit thus extends the infrastructure to implement a new backend,
> which instead uses a simple configuration file containing key-value
> pairs. The file follows the format which wpa_supplicant.conf(5) uses:
> empty lines and comments are ignored, while passwords can be specified
> with simple `password-name=password-value` assignments.

This sounds like a reasonable addition.

> diff --git a/src/utils/ext_password_file.c b/src/utils/ext_password_file.c
> +#include "common.h"
> +#include "ext_password_i.h"
> +#include "utils/config.h"

I'd prefer to list the src/*/*.h before wpa_supplicant/*.h in include
statements.

> +static void * ext_password_file_init(const char *params)
> +{
> +	struct ext_password_file_data *data;
> +
> +	if (!params) {
> +		wpa_printf(MSG_ERROR, "EXT PW FILE: no path given");
> +		return NULL;
> +	}
> +
> +	data = os_zalloc(sizeof(*data));
> +	if (data == NULL)
> +		return NULL;
> +	data->path = os_strdup(params);
> +
> +	return data;

That os_strdup() might fail. It would be better check for that here and
return NULL instead of assuming everything is fine and later crashing
due to NULL pointer dereferencing..

> +static void ext_password_file_deinit(void *ctx)
> +{
> +	struct ext_password_file_data *data = ctx;
> +
> +	str_clear_free(data->path);

str_clear_free() sounds a bit heavy for a path name, but well, if that
contains some secure information.. However:

> +static struct wpabuf * ext_password_file_get(void *ctx, const char *name)
> +{
> +	struct ext_password_file_data *data = ctx;
> +	struct wpabuf *password = NULL;
> +	char buf[512], *pos;

This buf[] is used to read the actual passwords, so it would be more
useful to explicitly clear that memory after use here.. And probably not
the best design to use wpa_printf(MSG_ERROR, "stuff with the raw line
from the password file") to get passwords exposed in debug logs and/or
stdout. Maybe just print the line number without any of the payload.

> +	while (wpa_config_get_line(buf, sizeof(buf), f, &line, &pos)) {
> +done:
> +	fclose(f);
> +	return password;

In other words, forced_memzero(buf, sizeof(buf)) before returning from
the function.

> diff --git a/wpa_supplicant/Makefile b/wpa_supplicant/Makefile

And also similar changes for wpa_supplicant/Android.mk.

-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Sat Feb 13 17:52:17 2021
From: j at w1.fi (Jouni Malinen)
Date: Sun, 14 Feb 2021 00:52:17 +0200
Subject: [PATCH 0/3] hostap: Tx Power Envelope also for 6GHz 11ax AP
In-Reply-To: <20210210110719.6007-1-shay.bar@celeno.com>
References: <20210210110719.6007-1-shay.bar@celeno.com>
Message-ID: <20210213225217.GA878952@w1.fi>

On Wed, Feb 10, 2021 at 01:07:16PM +0200, Shay Bar wrote:
> According to latest IEEE802.11 spec, Transmit Power Envelope element should
> also be added to 6GHz 11ax AP and is no longer called VHT Transmit Power Envelope.
> 
> Shay Bar (3):
>   hostap: Remove the VHT naming from the element
>   hostap: hostap: use hostapd_get_oper_chwidth
>   hostap: hostap: Tx Power Envelope also for 6GHz HE AP

Thanks, applied.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Sat Feb 13 17:52:40 2021
From: j at w1.fi (Jouni Malinen)
Date: Sun, 14 Feb 2021 00:52:40 +0200
Subject: [PATCH 1/2] wpa_supplicant: defer chirp scan if other scan is
 queued up
In-Reply-To: <20210212132754.11028-1-kazikcz@gmail.com>
References: <20210212132754.11028-1-kazikcz@gmail.com>
Message-ID: <20210213225240.GB878952@w1.fi>

Thanks, both applied.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Sat Feb 13 17:53:04 2021
From: j at w1.fi (Jouni Malinen)
Date: Sun, 14 Feb 2021 00:53:04 +0200
Subject: [PATCH] wlantest: avoid unaligned iphdr pointers
In-Reply-To: <20210213030335.777799-1-briannorris@chromium.org>
References: <20210213030335.777799-1-briannorris@chromium.org>
Message-ID: <20210213225304.GC878952@w1.fi>

On Fri, Feb 12, 2021 at 07:03:35PM -0800, Brian Norris wrote:
> Buffers passed to rx_data_ip() may not be naturally-aligned, and so we
> get unpredictable behavior when we cast that to an IP header. In
> particular, this code may crash on ARM.

Thanks, applied.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From wystans at gmail.com  Sat Feb 13 17:54:14 2021
From: wystans at gmail.com (Wystan Schmidt)
Date: Sat, 13 Feb 2021 15:54:14 -0700
Subject: [PATCH] DPP: Convert AKM to PSK/SAE for legacy DPP1 client
In-Reply-To: <20210213213002.GA468580@w1.fi>
References: <CA+XRdEALwk5mx-XwA-roJF-Jjf4Gz0FUvG8RXc=S2x0_7C-Dcw@mail.gmail.com>
 <20210213213002.GA468580@w1.fi>
Message-ID: <CA+XRdEBtJLB7=GHKD_DzwF6K7wyUYJUkHF-YW7uSo6sD6_8+3w@mail.gmail.com>

> That is unfortunate taken into account DPP AKM support in DPP (v1) is
> mandatory while support for DPP to provision SAE credential is not.

It is unfortunate. As a service provider this puts us in the difficult
position of having to
choose between adhering to the spec and supporting a flawed but
widespread implementation.

> What kind of a use case is this targeting? PSK+SAE+DPP enabled in
> Configurator for all Enrollees regardless of the Enrollee capabilities?

This is just targeting DPP1 Initiator-Enrollees. DPP1 does not support enrolling
additional configurators.

> At minimum, this should use DPP_AKM_PSK_SAE which was defined
> in DPP v1.

This is good feedback. I agree that DPP_AKM_PSK_SAE is a better option than
splitting into two cases. And Android supports SAE.

On Sat, Feb 13, 2021 at 2:30 PM Jouni Malinen <j at w1.fi> wrote:
>
> On Wed, Feb 10, 2021 at 05:04:38PM -0700, Wystan Schmidt wrote:
> > Currently, hostapd will convert a DPP2 Config object
> > to a DPP-only config for a legacy DPP1 client.
> >
> > However, Android 10+ phones, the only potential DPP1
> > clients (AFAIK), do not support the DPP-AKM and will fail
> > when given a DPP-AKM object.
>
> That is unfortunate taken into account DPP AKM support in DPP (v1) is
> mandatory while support for DPP to provision SAE credential is not.
>
> What kind of a use case is this targeting? PSK+SAE+DPP enabled in
> Configurator for all Enrollees regardless of the Enrollee capabilities?
>
> > diff --git a/src/common/dpp.c b/src/common/dpp.c
> > @@ -1450,9 +1450,15 @@ dpp_build_conf_obj_dpp(struct dpp_authentication *auth,
> >
> >         akm = conf->akm;
> >         if (dpp_akm_ver2(akm) && auth->peer_version < 2) {
> > -               wpa_printf(MSG_DEBUG,
> > -                          "DPP: Convert DPP+legacy credential to
> > DPP-only for peer that does not support version 2");
> > -               akm = DPP_AKM_DPP;
> > +               if (akm == DPP_AKM_PSK_SAE_DPP) {
> > +            wpa_printf(MSG_DEBUG,
> > +                   "DPP: Convert DPP+legacy credential to legacy
> > WPA2-PSK for peer that does not support version 2");
> > +            akm = DPP_AKM_PSK;
>
> PSK is the least secure option of those three included AKMs. This looks
> a really bad way of handling this case.. DPP_AKM_DPP is used here to
> pick the strongest option (and one that is actually mandatory to
> support). At minimum, this should use DPP_AKM_PSK_SAE which was defined
> in DPP v1.
>
> > +        } else if (akm == DPP_AKM_SAE_DPP) {
> > +            wpa_printf(MSG_DEBUG,
> > +                   "DPP: Convert DPP+legacy credential to WPA3 for
> > peer that does not support version 2");
> > +            akm = DPP_AKM_SAE;
> > +        }
>
> DPP AKM support is mandatory while SAE AKM support is optional. This
> does not really look like a good default behavior from the protocol view
> point.
>
> --
> Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Sat Feb 13 17:56:22 2021
From: j at w1.fi (Jouni Malinen)
Date: Sun, 14 Feb 2021 00:56:22 +0200
Subject: [PATCH] wpa_supplicant: multi_ap: only enable 4addr mode if not
 already enabled
In-Reply-To: <20210208172823.11536-1-raphael.melotte@mind.be>
References: <20210208172823.11536-1-raphael.melotte@mind.be>
Message-ID: <20210213225622.GA879085@w1.fi>

On Mon, Feb 08, 2021 at 06:28:23PM +0100, Rapha?l M?lotte wrote:
> If 4addr mode is already enabled, the call to enable it a second time
> may fail. If this happens when roaming, it leads to deauthentication.

Based on the discussion, I addressed this issue differently by ignoring
the nl80211 command failure when trying to enable the 4addr mode in case
it is already enabled.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From ps at pks.im  Sun Feb 14 05:40:16 2021
From: ps at pks.im (Patrick Steinhardt)
Date: Sun, 14 Feb 2021 11:40:16 +0100
Subject: [PATCH 1/2] wpa_supplicant: Move `wpa_config_get_line()` into
 utils
In-Reply-To: <20210213220921.GB468580@w1.fi>
References: <cover.1612720013.git.ps@pks.im>
 <66a77558af5b131b74f50beff5550f5e8d5e1b72.1612720013.git.ps@pks.im>
 <20210213220921.GB468580@w1.fi>
Message-ID: <YCj+EKG/POJCbsiH@ncase>

On Sun, Feb 14, 2021 at 12:09:21AM +0200, Jouni Malinen wrote:
> On Sun, Feb 07, 2021 at 06:48:31PM +0100, Patrick Steinhardt wrote:
> > The function `wpa_config_get_line()` is used by the wpa_supplicant
> > config file parser in order to retrieve the next non-commend non-blank
> > line. We'll need the same kind of functionality in order to implement
> > the file-based external password backend, so as a preparatory step this
> > commit extracts the function into its own standalone file in the utils
> > package.
> > 
> > No functional changes are expected from this commit.
> 
> > diff --git a/src/utils/config.c b/src/utils/config.c
> > @@ -0,0 +1,97 @@
> > +/*
> > + * Configuration parsing
> > + * Copyright (c) 2021, Patrick Steinhardt <ps at pks.im>
> 
> Isn't this just moving existing functionality from
> wpa_supplicant/config_file.c to another file? Changing copyright
> statement for the otherwise unmodified implementation does not sound
> appropriate.

Yeah, I wasn't quite sure how to handle it given that it's a new file
with old code. I'll use the old copyright in v2.

> > diff --git a/wpa_supplicant/Makefile b/wpa_supplicant/Makefile
> 
> This would need matching changes in wpa_supplicant/Android.mk to avoid
> breaking Android builds. And actually also in wpa_supplicant/nmake.mak
> and wpa_supplicant/vs2005/*/*.vcproj.

Thanks, I wasn't aware.

Patrick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/hostap/attachments/20210214/e87335d4/attachment.sig>

From ps at pks.im  Sun Feb 14 06:03:21 2021
From: ps at pks.im (Patrick Steinhardt)
Date: Sun, 14 Feb 2021 12:03:21 +0100
Subject: [PATCH 2/2] ext_password: Implement new file-based backend
In-Reply-To: <20210213221822.GC468580@w1.fi>
References: <cover.1612720013.git.ps@pks.im>
 <6f9819204cd32b37ad98c3d24c18469d1d7db3ea.1612720013.git.ps@pks.im>
 <20210213221822.GC468580@w1.fi>
Message-ID: <YCkDeW4c3SbwKKNM@ncase>

On Sun, Feb 14, 2021 at 12:18:22AM +0200, Jouni Malinen wrote:
> On Sun, Feb 07, 2021 at 06:48:36PM +0100, Patrick Steinhardt wrote:
[snip]
> > +static void ext_password_file_deinit(void *ctx)
> > +{
> > +	struct ext_password_file_data *data = ctx;
> > +
> > +	str_clear_free(data->path);
> 
> str_clear_free() sounds a bit heavy for a path name, but well, if that
> contains some secure information.. However:

Right, that could be a simple `os_free` call. I'll leave it as-is for
now, but I'm happy to change it.

> > +static struct wpabuf * ext_password_file_get(void *ctx, const char *name)
> > +{
> > +	struct ext_password_file_data *data = ctx;
> > +	struct wpabuf *password = NULL;
> > +	char buf[512], *pos;
> 
> This buf[] is used to read the actual passwords, so it would be more
> useful to explicitly clear that memory after use here.. And probably not
> the best design to use wpa_printf(MSG_ERROR, "stuff with the raw line
> from the password file") to get passwords exposed in debug logs and/or
> stdout. Maybe just print the line number without any of the payload.
> 
> > +	while (wpa_config_get_line(buf, sizeof(buf), f, &line, &pos)) {
> > +done:
> > +	fclose(f);
> > +	return password;
> 
> In other words, forced_memzero(buf, sizeof(buf)) before returning from
> the function.

Yup, makes sense.

Patrick

> > diff --git a/wpa_supplicant/Makefile b/wpa_supplicant/Makefile
> 
> And also similar changes for wpa_supplicant/Android.mk.
> 
> -- 
> Jouni Malinen                                            PGP id EFC895FA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/hostap/attachments/20210214/0ceb5ffc/attachment.sig>

From ps at pks.im  Sun Feb 14 06:16:24 2021
From: ps at pks.im (Patrick Steinhardt)
Date: Sun, 14 Feb 2021 12:16:24 +0100
Subject: [PATCH v2 0/2] File-backed external password store
Message-ID: <cover.1613300948.git.ps@pks.im>

Hi,

this is v2 of my patch series to implement a file-backed external
password store.

Changes compared to v1:

    - Retained copyright on moved code.

    - Adapted both Android.mk and VS2005 build instructions to include
      the shared config parsing code as well as the new backend. Note
      that because I do not have any setups for those environments,
      those changes are untested. I'd welcome it if somebody could
      verify those changes for me.

    - Password lines are no longer logged in case anything goes wrong.
      Instead, onyl their line number is logged now.

    - Allocation errors of the path now get detected correctly.

    - The password buffer now gets cleared on exit.

    - defconfig was amended to contain the new CONFIG_EXT_PASSWORD_FILE
      key.

    - wpa_supplicant.conf now contains an example for
      `ext_password_backend=file`.

Thanks for your feedback, Jouni!

Patrick

Patrick Steinhardt (2):
  wpa_supplicant: Move `wpa_config_get_line()` into utils
  ext_password: Implement new file-based backend

 src/utils/config.c                            |  97 +++++++++++++
 src/utils/config.h                            |  31 ++++
 src/utils/ext_password.c                      |   3 +
 src/utils/ext_password_file.c                 | 133 ++++++++++++++++++
 src/utils/ext_password_i.h                    |   4 +
 wpa_supplicant/Android.mk                     |   7 +
 wpa_supplicant/Makefile                       |   8 ++
 wpa_supplicant/config_file.c                  | 100 +------------
 wpa_supplicant/defconfig                      |   2 +
 .../vs2005/eapol_test/eapol_test.vcproj       |   4 +
 .../wpa_supplicant/wpa_supplicant.vcproj      |   4 +
 wpa_supplicant/vs2005/wpasvc/wpasvc.vcproj    |   4 +
 wpa_supplicant/wpa_supplicant.conf            |   7 +
 13 files changed, 305 insertions(+), 99 deletions(-)
 create mode 100644 src/utils/config.c
 create mode 100644 src/utils/config.h
 create mode 100644 src/utils/ext_password_file.c

Range-diff against v1:
1:  0748b785b ! 1:  c0db0abb7 wpa_supplicant: Move `wpa_config_get_line()` into utils
    @@ src/utils/config.c (new)
     @@
     +/*
     + * Configuration parsing
    -+ * Copyright (c) 2021, Patrick Steinhardt <ps at pks.im>
    ++ * Copyright (c) 2003-2019, Jouni Malinen <j at w1.fi>
     + *
     + * This software may be distributed under the terms of the BSD license.
     + * See README for more details.
    @@ src/utils/config.h (new)
     @@
     +/*
     + * Configuration parsing
    -+ * Copyright (c) 2021, Patrick Steinhardt <ps at pks.im>
    ++ * Copyright (c) 2003-2019, Jouni Malinen <j at w1.fi>
     + *
     + * This software may be distributed under the terms of the BSD license.
     + * See README for more details.
    @@ src/utils/config.h (new)
     +
     +#endif /* UTILS_CONFIG_H */
     
    + ## wpa_supplicant/Android.mk ##
    +@@ wpa_supplicant/Android.mk: OBJS += notify.c
    + OBJS += bss.c
    + OBJS += eap_register.c
    + OBJS += src/utils/common.c
    ++OBJS += src/utils/config.o
    + OBJS += src/utils/wpa_debug.c
    + OBJS += src/utils/wpabuf.c
    + OBJS += src/utils/bitfield.c
    +
      ## wpa_supplicant/Makefile ##
     @@ wpa_supplicant/Makefile: OBJS += notify.o
      OBJS += bss.o
    @@ wpa_supplicant/config_file.c
      
      
      static int wpa_config_validate_network(struct wpa_ssid *ssid, int line)
    +
    + ## wpa_supplicant/vs2005/eapol_test/eapol_test.vcproj ##
    +@@
    + 				RelativePath="..\..\..\src\utils\common.c"
    + 				>
    + 			</File>
    ++			<File
    ++				RelativePath="..\..\..\src\utils\config.c"
    ++				>
    ++			</File>
    + 			<File
    + 				RelativePath="..\..\config.c"
    + 				>
    +
    + ## wpa_supplicant/vs2005/wpa_supplicant/wpa_supplicant.vcproj ##
    +@@
    + 				RelativePath="..\..\..\src\utils\common.c"
    + 				>
    + 			</File>
    ++			<File
    ++				RelativePath="..\..\..\src\utils\config.c"
    ++				>
    ++			</File>
    + 			<File
    + 				RelativePath="..\..\config.c"
    + 				>
    +
    + ## wpa_supplicant/vs2005/wpasvc/wpasvc.vcproj ##
    +@@
    + 				RelativePath="..\..\..\src\utils\common.c"
    + 				>
    + 			</File>
    ++			<File
    ++				RelativePath="..\..\..\src\utils\config.c"
    ++				>
    ++			</File>
    + 			<File
    + 				RelativePath="..\..\config.c"
    + 				>
2:  99f02abf9 ! 2:  0ec799a93 ext_password: Implement new file-based backend
    @@ src/utils/ext_password_file.c (new)
     +
     +#include "includes.h"
     +
    ++#include "utils/config.h"
     +#include "common.h"
     +#include "ext_password_i.h"
    -+#include "utils/config.h"
     +
     +
     +/**
    @@ src/utils/ext_password_file.c (new)
     +	data = os_zalloc(sizeof(*data));
     +	if (data == NULL)
     +		return NULL;
    ++
     +	data->path = os_strdup(params);
    ++	if (data->path == NULL) {
    ++		os_free(data);
    ++		return NULL;
    ++	}
     +
     +	return data;
     +}
    @@ src/utils/ext_password_file.c (new)
     +	while (wpa_config_get_line(buf, sizeof(buf), f, &line, &pos)) {
     +		char *sep = os_strchr(pos, '=');
     +		if (!sep) {
    -+			wpa_printf(MSG_ERROR, "Invalid password line %d: '%s'.",
    -+				   line, buf);
    ++			wpa_printf(MSG_ERROR, "Invalid password line %d.", line);
     +			continue;
     +		}
     +
     +		if (!sep[1]) {
    -+			wpa_printf(MSG_ERROR, "No password for line %d: '%s'.",
    -+				   line, buf);
    ++			wpa_printf(MSG_ERROR, "No password for line %d.", line);
     +			continue;
     +
     +		}
    @@ src/utils/ext_password_file.c (new)
     +	wpa_printf(MSG_ERROR, "Password for '%s' was not found.", name);
     +
     +done:
    ++	forced_memzero(buf, sizeof(buf));
     +	fclose(f);
     +	return password;
     +}
    @@ src/utils/ext_password_i.h: struct wpabuf * ext_password_alloc(size_t len);
     +
      #endif /* EXT_PASSWORD_I_H */
     
    + ## wpa_supplicant/Android.mk ##
    +@@ wpa_supplicant/Android.mk: L_CFLAGS += -DCONFIG_EXT_PASSWORD_TEST
    + NEED_EXT_PASSWORD=y
    + endif
    + 
    ++ifdef CONFIG_EXT_PASSWORD_FILE
    ++OBJS += src/utils/ext_password_file.c
    ++L_CFLAGS += -DCONFIG_EXT_PASSWORD_FILE
    ++NEED_EXT_PASSWORD=y
    ++endif
    ++
    + ifdef NEED_EXT_PASSWORD
    + OBJS += src/utils/ext_password.c
    + L_CFLAGS += -DCONFIG_EXT_PASSWORD
    +
      ## wpa_supplicant/Makefile ##
     @@ wpa_supplicant/Makefile: CFLAGS += -DCONFIG_EXT_PASSWORD_TEST
      NEED_EXT_PASSWORD=y
    @@ wpa_supplicant/Makefile: CFLAGS += -DCONFIG_EXT_PASSWORD_TEST
      ifdef NEED_EXT_PASSWORD
      OBJS += ../src/utils/ext_password.o
      CFLAGS += -DCONFIG_EXT_PASSWORD
    +
    + ## wpa_supplicant/defconfig ##
    +@@ wpa_supplicant/defconfig: CONFIG_WIFI_DISPLAY=y
    + #
    + # External password backend for testing purposes (developer use)
    + #CONFIG_EXT_PASSWORD_TEST=y
    ++# File-based backend to read passwords from an external file.
    ++#CONFIG_EXT_PASSWORD_FILE=y
    + 
    + # Enable Fast Session Transfer (FST)
    + #CONFIG_FST=y
    +
    + ## wpa_supplicant/wpa_supplicant.conf ##
    +@@ wpa_supplicant/wpa_supplicant.conf: fast_reauth=1
    + 
    + # Password (and passphrase, etc.) backend for external storage
    + # format: <backend name>[:<optional backend parameters>]
    ++# Test backend which stores passwords in memory. Should only be used for
    ++# development purposes.
    + #ext_password_backend=test:pw1=password|pw2=testing
    ++# File-based backend which reads passwords from a file. The parameter
    ++# identifies the file to read passwords from. The password file follows the
    ++# format of wpa_supplicant.conf and accepts simple `key=passphrase` formatted
    ++# passwords.
    ++#ext_password_backend=file:/path/to/passwords.conf
    + 
    + 
    + # Disable P2P functionality
-- 
2.30.1

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/hostap/attachments/20210214/832fdfdc/attachment-0001.sig>

From ps at pks.im  Sun Feb 14 06:16:28 2021
From: ps at pks.im (Patrick Steinhardt)
Date: Sun, 14 Feb 2021 12:16:28 +0100
Subject: [PATCH v2 1/2] wpa_supplicant: Move `wpa_config_get_line()` into utils
In-Reply-To: <cover.1613300948.git.ps@pks.im>
References: <cover.1613300948.git.ps@pks.im>
Message-ID: <c0db0abb7b6e6ee108a89e840fc575252a601530.1613300948.git.ps@pks.im>

The function `wpa_config_get_line()` is used by the wpa_supplicant
config file parser in order to retrieve the next non-commend non-blank
line. We'll need the same kind of functionality in order to implement
the file-based external password backend, so as a preparatory step this
commit extracts the function into its own standalone file in the utils
package.

No functional changes are expected from this commit.

Signed-off-by: Patrick Steinhardt <ps at pks.im>
---
 src/utils/config.c                            |  97 +++++++++++++++++
 src/utils/config.h                            |  31 ++++++
 wpa_supplicant/Android.mk                     |   1 +
 wpa_supplicant/Makefile                       |   2 +
 wpa_supplicant/config_file.c                  | 100 +-----------------
 .../vs2005/eapol_test/eapol_test.vcproj       |   4 +
 .../wpa_supplicant/wpa_supplicant.vcproj      |   4 +
 wpa_supplicant/vs2005/wpasvc/wpasvc.vcproj    |   4 +
 8 files changed, 144 insertions(+), 99 deletions(-)
 create mode 100644 src/utils/config.c
 create mode 100644 src/utils/config.h

diff --git a/src/utils/config.c b/src/utils/config.c
new file mode 100644
index 000000000..2f101abe2
--- /dev/null
+++ b/src/utils/config.c
@@ -0,0 +1,97 @@
+/*
+ * Configuration parsing
+ * Copyright (c) 2003-2019, Jouni Malinen <j at w1.fi>
+ *
+ * This software may be distributed under the terms of the BSD license.
+ * See README for more details.
+ */
+
+#include "includes.h"
+
+#include "utils/config.h"
+#include "common.h"
+
+
+static int newline_terminated(const char *buf, size_t buflen)
+{
+	size_t len = os_strlen(buf);
+	if (len == 0)
+		return 0;
+	if (len == buflen - 1 && buf[buflen - 1] != '\r' &&
+	    buf[len - 1] != '\n')
+		return 0;
+	return 1;
+}
+
+
+static void skip_line_end(FILE *stream)
+{
+	char buf[100];
+	while (fgets(buf, sizeof(buf), stream)) {
+		buf[sizeof(buf) - 1] = '\0';
+		if (newline_terminated(buf, sizeof(buf)))
+			return;
+	}
+}
+
+
+char * wpa_config_get_line(char *s, int size, FILE *stream, int *line,
+				  char **_pos)
+{
+	char *pos, *end, *sstart;
+
+	while (fgets(s, size, stream)) {
+		(*line)++;
+		s[size - 1] = '\0';
+		if (!newline_terminated(s, size)) {
+			/*
+			 * The line was truncated - skip rest of it to avoid
+			 * confusing error messages.
+			 */
+			wpa_printf(MSG_INFO, "Long line in configuration file "
+				   "truncated");
+			skip_line_end(stream);
+		}
+		pos = s;
+
+		/* Skip white space from the beginning of line. */
+		while (*pos == ' ' || *pos == '\t' || *pos == '\r')
+			pos++;
+
+		/* Skip comment lines and empty lines */
+		if (*pos == '#' || *pos == '\n' || *pos == '\0')
+			continue;
+
+		/*
+		 * Remove # comments unless they are within a double quoted
+		 * string.
+		 */
+		sstart = os_strchr(pos, '"');
+		if (sstart)
+			sstart = os_strrchr(sstart + 1, '"');
+		if (!sstart)
+			sstart = pos;
+		end = os_strchr(sstart, '#');
+		if (end)
+			*end-- = '\0';
+		else
+			end = pos + os_strlen(pos) - 1;
+
+		/* Remove trailing white space. */
+		while (end > pos &&
+		       (*end == '\n' || *end == ' ' || *end == '\t' ||
+			*end == '\r'))
+			*end-- = '\0';
+
+		if (*pos == '\0')
+			continue;
+
+		if (_pos)
+			*_pos = pos;
+		return pos;
+	}
+
+	if (_pos)
+		*_pos = NULL;
+	return NULL;
+}
diff --git a/src/utils/config.h b/src/utils/config.h
new file mode 100644
index 000000000..a7c977601
--- /dev/null
+++ b/src/utils/config.h
@@ -0,0 +1,31 @@
+/*
+ * Configuration parsing
+ * Copyright (c) 2003-2019, Jouni Malinen <j at w1.fi>
+ *
+ * This software may be distributed under the terms of the BSD license.
+ * See README for more details.
+ */
+
+#ifndef UTILS_CONFIG_H
+#define UTILS_CONFIG_H
+
+#include "includes.h"
+
+/**
+ * wpa_config_get_line - Read the next configuration file line
+ * @s: Buffer for the line
+ * @size: The buffer length
+ * @stream: File stream to read from
+ * @line: Pointer to a variable storing the file line number
+ * @_pos: Buffer for the pointer to the beginning of data on the text line or
+ * %NULL if not needed (returned value used instead)
+ * Returns: Pointer to the beginning of data on the text line or %NULL if no
+ * more text lines are available.
+ *
+ * This function reads the next non-empty line from the configuration file and
+ * removes comments. The returned string is guaranteed to be null-terminated.
+ */
+char * wpa_config_get_line(char *s, int size, FILE *stream, int *line,
+			   char **_pos);
+
+#endif /* UTILS_CONFIG_H */
diff --git a/wpa_supplicant/Android.mk b/wpa_supplicant/Android.mk
index 4cbce995c..7a79fd5d2 100644
--- a/wpa_supplicant/Android.mk
+++ b/wpa_supplicant/Android.mk
@@ -94,6 +94,7 @@ OBJS += notify.c
 OBJS += bss.c
 OBJS += eap_register.c
 OBJS += src/utils/common.c
+OBJS += src/utils/config.o
 OBJS += src/utils/wpa_debug.c
 OBJS += src/utils/wpabuf.c
 OBJS += src/utils/bitfield.c
diff --git a/wpa_supplicant/Makefile b/wpa_supplicant/Makefile
index 59b054cd2..6a92aaace 100644
--- a/wpa_supplicant/Makefile
+++ b/wpa_supplicant/Makefile
@@ -83,6 +83,7 @@ OBJS += notify.o
 OBJS += bss.o
 OBJS += eap_register.o
 OBJS += ../src/utils/common.o
+OBJS += ../src/utils/config.o
 OBJS += ../src/utils/wpa_debug.o
 OBJS += ../src/utils/wpabuf.o
 OBJS += ../src/utils/bitfield.o
@@ -93,6 +94,7 @@ OBJS += rrm.o
 OBJS += robust_av.o
 OBJS_p = wpa_passphrase.o
 OBJS_p += ../src/utils/common.o
+OBJS_p += ../src/utils/config.o
 OBJS_p += ../src/utils/wpa_debug.o
 OBJS_p += ../src/utils/wpabuf.o
 OBJS_c = wpa_cli.o ../src/common/wpa_ctrl.o
diff --git a/wpa_supplicant/config_file.c b/wpa_supplicant/config_file.c
index fd6275e22..a535e3f08 100644
--- a/wpa_supplicant/config_file.c
+++ b/wpa_supplicant/config_file.c
@@ -23,105 +23,7 @@
 #include "p2p/p2p.h"
 #include "eap_peer/eap_methods.h"
 #include "eap_peer/eap.h"
-
-
-static int newline_terminated(const char *buf, size_t buflen)
-{
-	size_t len = os_strlen(buf);
-	if (len == 0)
-		return 0;
-	if (len == buflen - 1 && buf[buflen - 1] != '\r' &&
-	    buf[len - 1] != '\n')
-		return 0;
-	return 1;
-}
-
-
-static void skip_line_end(FILE *stream)
-{
-	char buf[100];
-	while (fgets(buf, sizeof(buf), stream)) {
-		buf[sizeof(buf) - 1] = '\0';
-		if (newline_terminated(buf, sizeof(buf)))
-			return;
-	}
-}
-
-
-/**
- * wpa_config_get_line - Read the next configuration file line
- * @s: Buffer for the line
- * @size: The buffer length
- * @stream: File stream to read from
- * @line: Pointer to a variable storing the file line number
- * @_pos: Buffer for the pointer to the beginning of data on the text line or
- * %NULL if not needed (returned value used instead)
- * Returns: Pointer to the beginning of data on the text line or %NULL if no
- * more text lines are available.
- *
- * This function reads the next non-empty line from the configuration file and
- * removes comments. The returned string is guaranteed to be null-terminated.
- */
-static char * wpa_config_get_line(char *s, int size, FILE *stream, int *line,
-				  char **_pos)
-{
-	char *pos, *end, *sstart;
-
-	while (fgets(s, size, stream)) {
-		(*line)++;
-		s[size - 1] = '\0';
-		if (!newline_terminated(s, size)) {
-			/*
-			 * The line was truncated - skip rest of it to avoid
-			 * confusing error messages.
-			 */
-			wpa_printf(MSG_INFO, "Long line in configuration file "
-				   "truncated");
-			skip_line_end(stream);
-		}
-		pos = s;
-
-		/* Skip white space from the beginning of line. */
-		while (*pos == ' ' || *pos == '\t' || *pos == '\r')
-			pos++;
-
-		/* Skip comment lines and empty lines */
-		if (*pos == '#' || *pos == '\n' || *pos == '\0')
-			continue;
-
-		/*
-		 * Remove # comments unless they are within a double quoted
-		 * string.
-		 */
-		sstart = os_strchr(pos, '"');
-		if (sstart)
-			sstart = os_strrchr(sstart + 1, '"');
-		if (!sstart)
-			sstart = pos;
-		end = os_strchr(sstart, '#');
-		if (end)
-			*end-- = '\0';
-		else
-			end = pos + os_strlen(pos) - 1;
-
-		/* Remove trailing white space. */
-		while (end > pos &&
-		       (*end == '\n' || *end == ' ' || *end == '\t' ||
-			*end == '\r'))
-			*end-- = '\0';
-
-		if (*pos == '\0')
-			continue;
-
-		if (_pos)
-			*_pos = pos;
-		return pos;
-	}
-
-	if (_pos)
-		*_pos = NULL;
-	return NULL;
-}
+#include "utils/config.h"
 
 
 static int wpa_config_validate_network(struct wpa_ssid *ssid, int line)
diff --git a/wpa_supplicant/vs2005/eapol_test/eapol_test.vcproj b/wpa_supplicant/vs2005/eapol_test/eapol_test.vcproj
index af7b3fe9c..3087a1659 100755
--- a/wpa_supplicant/vs2005/eapol_test/eapol_test.vcproj
+++ b/wpa_supplicant/vs2005/eapol_test/eapol_test.vcproj
@@ -230,6 +230,10 @@
 				RelativePath="..\..\..\src\utils\common.c"
 				>
 			</File>
+			<File
+				RelativePath="..\..\..\src\utils\config.c"
+				>
+			</File>
 			<File
 				RelativePath="..\..\config.c"
 				>
diff --git a/wpa_supplicant/vs2005/wpa_supplicant/wpa_supplicant.vcproj b/wpa_supplicant/vs2005/wpa_supplicant/wpa_supplicant.vcproj
index 51acab927..f8c7b3c2f 100755
--- a/wpa_supplicant/vs2005/wpa_supplicant/wpa_supplicant.vcproj
+++ b/wpa_supplicant/vs2005/wpa_supplicant/wpa_supplicant.vcproj
@@ -230,6 +230,10 @@
 				RelativePath="..\..\..\src\utils\common.c"
 				>
 			</File>
+			<File
+				RelativePath="..\..\..\src\utils\config.c"
+				>
+			</File>
 			<File
 				RelativePath="..\..\config.c"
 				>
diff --git a/wpa_supplicant/vs2005/wpasvc/wpasvc.vcproj b/wpa_supplicant/vs2005/wpasvc/wpasvc.vcproj
index 6fd8af803..853ee2bba 100755
--- a/wpa_supplicant/vs2005/wpasvc/wpasvc.vcproj
+++ b/wpa_supplicant/vs2005/wpasvc/wpasvc.vcproj
@@ -230,6 +230,10 @@
 				RelativePath="..\..\..\src\utils\common.c"
 				>
 			</File>
+			<File
+				RelativePath="..\..\..\src\utils\config.c"
+				>
+			</File>
 			<File
 				RelativePath="..\..\config.c"
 				>
-- 
2.30.1

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/hostap/attachments/20210214/57a1d548/attachment-0001.sig>

From ps at pks.im  Sun Feb 14 06:16:33 2021
From: ps at pks.im (Patrick Steinhardt)
Date: Sun, 14 Feb 2021 12:16:33 +0100
Subject: [PATCH v2 2/2] ext_password: Implement new file-based backend
In-Reply-To: <cover.1613300948.git.ps@pks.im>
References: <cover.1613300948.git.ps@pks.im>
Message-ID: <0ec799a93f45160d3666615236fe57b54d89b897.1613300948.git.ps@pks.im>

It's currently not easily possible to separate configuration of an
interface and credentials. This makes it hard to distribute
configuration across a set of nodes which use wpa_supplicant without
also having to store credentials in the same file. While this can be
solved via scripting, having a native way to achieve this would be
preferable.

Turns out there already is a framework to have external password
storages. It only has a single "test" backend though, which is kind of
an in-memory store which gets initialized with all passwords up front.
This isn't really suitable for above usecase: the backend cannot be
initialized as part of the central configuration given that it needs the
credentials, and we want to avoid scripting.

This commit thus extends the infrastructure to implement a new backend,
which instead uses a simple configuration file containing key-value
pairs. The file follows the format which wpa_supplicant.conf(5) uses:
empty lines and comments are ignored, while passwords can be specified
with simple `password-name=password-value` assignments.

With this new backend, splitting up credentials and configuration
becomes trivial:

    # /etc/wpa_supplicant/wpa_supplicant.conf
    ext_password_backend=file:/etc/wpa_supplicant/psk.conf

    network={
        ssid="foobar"
        psk=ext:foobar
    }

    # /etc/wpa_supplicant/psk.conf
    foobar=ecdabff9c80632ec6fcffc4a8875e95d45cf93376d3b99da6881298853dc686b

Alternative approaches would be to support including other configuration
files in the main configuration, such that common configuration and
network declarations including credentials are split up into separate
files. But the implementation would probably have been more complex
compared to reusing the already-existing framework for external password
backends.

Signed-off-by: Patrick Steinhardt <ps at pks.im>
---
 src/utils/ext_password.c           |   3 +
 src/utils/ext_password_file.c      | 133 +++++++++++++++++++++++++++++
 src/utils/ext_password_i.h         |   4 +
 wpa_supplicant/Android.mk          |   6 ++
 wpa_supplicant/Makefile            |   6 ++
 wpa_supplicant/defconfig           |   2 +
 wpa_supplicant/wpa_supplicant.conf |   7 ++
 7 files changed, 161 insertions(+)
 create mode 100644 src/utils/ext_password_file.c

diff --git a/src/utils/ext_password.c b/src/utils/ext_password.c
index 5615bd72a..cbf92de8c 100644
--- a/src/utils/ext_password.c
+++ b/src/utils/ext_password.c
@@ -20,6 +20,9 @@ static const struct ext_password_backend *backends[] = {
 #ifdef CONFIG_EXT_PASSWORD_TEST
 	&ext_password_test,
 #endif /* CONFIG_EXT_PASSWORD_TEST */
+#ifdef CONFIG_EXT_PASSWORD_FILE
+	&ext_password_file,
+#endif /* CONFIG_EXT_PASSWORD_FILE */
 	NULL
 };
 
diff --git a/src/utils/ext_password_file.c b/src/utils/ext_password_file.c
new file mode 100644
index 000000000..664e17ef5
--- /dev/null
+++ b/src/utils/ext_password_file.c
@@ -0,0 +1,133 @@
+/*
+ * External backend for file-backed passwords
+ * Copyright (c) 2021, Patrick Steinhardt <ps at pks.im>
+ *
+ * This software may be distributed under the terms of the BSD license.
+ * See README for more details.
+ */
+
+#include "includes.h"
+
+#include "utils/config.h"
+#include "common.h"
+#include "ext_password_i.h"
+
+
+/**
+ * Data structure for the file-backed password backend.
+ */
+struct ext_password_file_data {
+	char *path; /* path of the password file */
+};
+
+
+/**
+ * ext_password_file_init - Initialize file-backed password backend
+ * @params: Parameters passed by the user.
+ * Returns: Pointer to the initialized backend.
+ *
+ * This function initializes a new file-backed password backend. The user is
+ * expected to initialize this backend with the parameters being the path of
+ * the file that contains the passwords.
+ */
+static void * ext_password_file_init(const char *params)
+{
+	struct ext_password_file_data *data;
+
+	if (!params) {
+		wpa_printf(MSG_ERROR, "EXT PW FILE: no path given");
+		return NULL;
+	}
+
+	data = os_zalloc(sizeof(*data));
+	if (data == NULL)
+		return NULL;
+
+	data->path = os_strdup(params);
+	if (data->path == NULL) {
+		os_free(data);
+		return NULL;
+	}
+
+	return data;
+}
+
+
+/**
+ * ext_password_file_deinit - Deinitialize file-backed password backend
+ * @param ctx: The file-backed password backend
+ *
+ * This function frees all data associated with the file-backed password
+ * backend.
+ */
+static void ext_password_file_deinit(void *ctx)
+{
+	struct ext_password_file_data *data = ctx;
+
+	str_clear_free(data->path);
+	os_free(data);
+}
+
+/**
+ * ext_password_file_get - Retrieve password from the file-backed password backend
+ * @param ctx: The file-backed password backend
+ * @param name: Name of the password to retrieve
+ * Returns: Buffer containing the password if one was found or %NULL.
+ *
+ * This function tries to find a password identified by name in the password
+ * file. The password is expected to be stored in `NAME=PASSWORD` format.
+ * Comments and empty lines in the file are ignored. Invalid lines will cause
+ * an error message, but will not cause the function to fail.
+ */
+static struct wpabuf * ext_password_file_get(void *ctx, const char *name)
+{
+	struct ext_password_file_data *data = ctx;
+	struct wpabuf *password = NULL;
+	char buf[512], *pos;
+	int line = 0;
+	FILE *f;
+
+	f = fopen(data->path, "r");
+	if (f == NULL) {
+		wpa_printf(MSG_ERROR, "EXT PW FILE: could not open file '%s': %s",
+			   data->path, strerror(errno));
+		return NULL;
+	}
+
+	wpa_printf(MSG_DEBUG, "EXT PW FILE: get(%s)", name);
+
+	while (wpa_config_get_line(buf, sizeof(buf), f, &line, &pos)) {
+		char *sep = os_strchr(pos, '=');
+		if (!sep) {
+			wpa_printf(MSG_ERROR, "Invalid password line %d.", line);
+			continue;
+		}
+
+		if (!sep[1]) {
+			wpa_printf(MSG_ERROR, "No password for line %d.", line);
+			continue;
+
+		}
+
+		if (os_strncmp(name, pos, sep - pos))
+			continue;
+
+		password = wpabuf_alloc_copy(sep + 1, os_strlen(sep + 1));
+		goto done;
+	}
+
+	wpa_printf(MSG_ERROR, "Password for '%s' was not found.", name);
+
+done:
+	forced_memzero(buf, sizeof(buf));
+	fclose(f);
+	return password;
+}
+
+
+const struct ext_password_backend ext_password_file = {
+	.name = "file",
+	.init = ext_password_file_init,
+	.deinit = ext_password_file_deinit,
+	.get = ext_password_file_get,
+};
diff --git a/src/utils/ext_password_i.h b/src/utils/ext_password_i.h
index 948eaf542..872ccd195 100644
--- a/src/utils/ext_password_i.h
+++ b/src/utils/ext_password_i.h
@@ -26,4 +26,8 @@ struct wpabuf * ext_password_alloc(size_t len);
 extern const struct ext_password_backend ext_password_test;
 #endif /* CONFIG_EXT_PASSWORD_TEST */
 
+#ifdef CONFIG_EXT_PASSWORD_FILE
+extern const struct ext_password_backend ext_password_file;
+#endif /* CONFIG_EXT_PASSWORD_FILE */
+
 #endif /* EXT_PASSWORD_I_H */
diff --git a/wpa_supplicant/Android.mk b/wpa_supplicant/Android.mk
index 7a79fd5d2..adaf69c6c 100644
--- a/wpa_supplicant/Android.mk
+++ b/wpa_supplicant/Android.mk
@@ -1617,6 +1617,12 @@ L_CFLAGS += -DCONFIG_EXT_PASSWORD_TEST
 NEED_EXT_PASSWORD=y
 endif
 
+ifdef CONFIG_EXT_PASSWORD_FILE
+OBJS += src/utils/ext_password_file.c
+L_CFLAGS += -DCONFIG_EXT_PASSWORD_FILE
+NEED_EXT_PASSWORD=y
+endif
+
 ifdef NEED_EXT_PASSWORD
 OBJS += src/utils/ext_password.c
 L_CFLAGS += -DCONFIG_EXT_PASSWORD
diff --git a/wpa_supplicant/Makefile b/wpa_supplicant/Makefile
index 6a92aaace..a59003ef2 100644
--- a/wpa_supplicant/Makefile
+++ b/wpa_supplicant/Makefile
@@ -1752,6 +1752,12 @@ CFLAGS += -DCONFIG_EXT_PASSWORD_TEST
 NEED_EXT_PASSWORD=y
 endif
 
+ifdef CONFIG_EXT_PASSWORD_FILE
+OBJS += ../src/utils/ext_password_file.o
+CFLAGS += -DCONFIG_EXT_PASSWORD_FILE
+NEED_EXT_PASSWORD=y
+endif
+
 ifdef NEED_EXT_PASSWORD
 OBJS += ../src/utils/ext_password.o
 CFLAGS += -DCONFIG_EXT_PASSWORD
diff --git a/wpa_supplicant/defconfig b/wpa_supplicant/defconfig
index aaf64280f..708a82385 100644
--- a/wpa_supplicant/defconfig
+++ b/wpa_supplicant/defconfig
@@ -530,6 +530,8 @@ CONFIG_WIFI_DISPLAY=y
 #
 # External password backend for testing purposes (developer use)
 #CONFIG_EXT_PASSWORD_TEST=y
+# File-based backend to read passwords from an external file.
+#CONFIG_EXT_PASSWORD_FILE=y
 
 # Enable Fast Session Transfer (FST)
 #CONFIG_FST=y
diff --git a/wpa_supplicant/wpa_supplicant.conf b/wpa_supplicant/wpa_supplicant.conf
index 9d5de8591..77f363e00 100644
--- a/wpa_supplicant/wpa_supplicant.conf
+++ b/wpa_supplicant/wpa_supplicant.conf
@@ -366,7 +366,14 @@ fast_reauth=1
 
 # Password (and passphrase, etc.) backend for external storage
 # format: <backend name>[:<optional backend parameters>]
+# Test backend which stores passwords in memory. Should only be used for
+# development purposes.
 #ext_password_backend=test:pw1=password|pw2=testing
+# File-based backend which reads passwords from a file. The parameter
+# identifies the file to read passwords from. The password file follows the
+# format of wpa_supplicant.conf and accepts simple `key=passphrase` formatted
+# passwords.
+#ext_password_backend=file:/path/to/passwords.conf
 
 
 # Disable P2P functionality
-- 
2.30.1

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/hostap/attachments/20210214/61be17d1/attachment.sig>

From j at w1.fi  Sun Feb 14 11:43:41 2021
From: j at w1.fi (Jouni Malinen)
Date: Sun, 14 Feb 2021 18:43:41 +0200
Subject: [PATCH v3 0/3] Add FILS discovery support
In-Reply-To: <20201215020428.27901-1-alokad@codeaurora.org>
References: <20201215020428.27901-1-alokad@codeaurora.org>
Message-ID: <20210214164341.GA425725@w1.fi>

On Mon, Dec 14, 2020 at 06:04:25PM -0800, Aloka Dixit wrote:
> This patchset adds FILS discovery support with some 6GHz specific details.
> 
> v3: Fixed NSS value calculation in FILS capability.
> 
> Aloka Dixit (3):
>   6G: Define FILS discovery frame elements
>   AP: Add FILS discovery support
>   nl80211: Add FILS discovery support

Thanks, applied with cleanup and fixes. In particular, the FILS
Discovery Information field generation would not have worked correctly
on big endian CPUs and the suite selector indication in FD RSN Info did
not look correct for multiple cases.

-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Sun Feb 14 17:55:15 2021
From: j at w1.fi (Jouni Malinen)
Date: Mon, 15 Feb 2021 00:55:15 +0200
Subject: [PATCH v2 0/2] Unsolicited broadcast probe resp support
In-Reply-To: <010101747b0df18e-e2d2d07f-8de3-4e39-b555-e4e836ee38e6-000000@us-west-2.amazonses.com>
References: <010101747b0df18e-e2d2d07f-8de3-4e39-b555-e4e836ee38e6-000000@us-west-2.amazonses.com>
Message-ID: <20210214225515.GA1763959@w1.fi>

On Fri, Sep 11, 2020 at 02:45:45AM +0000, Aloka Dixit wrote:
> This patch adds support for unsolicited broadcast probe response
> transmission, used for in-band discovery in 6GHz, as mentioned in
> IEEE P802.11ax/D6.0 26.17.2.3.2, AP behavior for fast passive scanning.
> 
> v2: New extended feature flag. Minor cleanup.
> 
> Aloka Dixit (2):
>   AP: Unsolicited broadcast probe resp support
>   nl80211: Unsolicited bcast probe resp support

Thanks, applied with some cleanup.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Mon Feb 15 17:49:40 2021
From: j at w1.fi (Jouni Malinen)
Date: Tue, 16 Feb 2021 00:49:40 +0200
Subject: [PATCH] Update sgml to generate reproducible manpages
In-Reply-To: <20200904140455.15487-1-hukeping@huawei.com>
References: <20200904140455.15487-1-hukeping@huawei.com>
Message-ID: <20210215224940.GA1271127@w1.fi>

On Fri, Sep 04, 2020 at 10:04:55PM +0800, Hu Keping wrote:
> Prior to this patch, we failed to recreate bit-by-bit identical
> copies of wpa_supplicant because it doesn't generate reproducible manpages.
> 
> Since the latest version(0.6.14-3 or new) of docbook-utils have already
> support getting the date from sgml file [1], it is possible to make some
> progress on the "reproducible builds" effort [2].
> 
> [1]: https://sources.debian.org/patches/docbook-utils/0.6.14-3
> [2]: https://reproducible-builds.org

Thanks, applied.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Mon Feb 15 17:51:27 2021
From: j at w1.fi (Jouni Malinen)
Date: Tue, 16 Feb 2021 00:51:27 +0200
Subject: [PATCH v2 0/2] File-backed external password store
In-Reply-To: <cover.1613300948.git.ps@pks.im>
References: <cover.1613300948.git.ps@pks.im>
Message-ID: <20210215225127.GB1271127@w1.fi>

On Sun, Feb 14, 2021 at 12:16:24PM +0100, Patrick Steinhardt wrote:
> Patrick Steinhardt (2):
>   wpa_supplicant: Move `wpa_config_get_line()` into utils
>   ext_password: Implement new file-based backend

Thanks, applied.

-- 
Jouni Malinen                                            PGP id EFC895FA


From raphael.melotte at mind.be  Tue Feb 16 03:55:55 2021
From: raphael.melotte at mind.be (=?UTF-8?B?UmFwaGHDq2wgTcOpbG90dGU=?=)
Date: Tue, 16 Feb 2021 09:55:55 +0100
Subject: [PATCH] wpa_supplicant: multi_ap: only enable 4addr mode if not
 already enabled
In-Reply-To: <20210213225622.GA879085@w1.fi>
References: <20210208172823.11536-1-raphael.melotte@mind.be>
 <20210213225622.GA879085@w1.fi>
Message-ID: <01c7215f-1919-92ba-00ae-3882a8cb8b86@mind.be>


On 2/13/21 11:56 PM, Jouni Malinen wrote:
> On Mon, Feb 08, 2021 at 06:28:23PM +0100, Rapha?l M?lotte wrote:
>> If 4addr mode is already enabled, the call to enable it a second time
>> may fail. If this happens when roaming, it leads to deauthentication.
> 
> Based on the discussion, I addressed this issue differently by ignoring
> the nl80211 command failure when trying to enable the 4addr mode in case
> it is already enabled.
>   

I confirm the issue which lead me to send this patch is fixed with 
'58bbbb5981440da508164cbd423ca5dd7c1b98d8'.

I was wondering if it was possible to use a bridge in the tests to reproduce the 
original issue with hwsim, but now I see that the test is already there :-)

Thanks!


From andrei.otcheretianski at intel.com  Tue Feb 16 08:23:56 2021
From: andrei.otcheretianski at intel.com (Andrei Otcheretianski)
Date: Tue, 16 Feb 2021 15:23:56 +0200
Subject: [PATCH] wpa_supplicant: Fix potential memleak
Message-ID: <20210216132357.4588-1-andrei.otcheretianski@intel.com>

Fix a memory leak on error path.

Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski at intel.com>
---
 wpa_supplicant/interworking.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/wpa_supplicant/interworking.c b/wpa_supplicant/interworking.c
index 1ff142a8d4..5db473cf73 100644
--- a/wpa_supplicant/interworking.c
+++ b/wpa_supplicant/interworking.c
@@ -2793,6 +2793,7 @@ int anqp_send_req(struct wpa_supplicant *wpa_s, const u8 *dst, int freq,
 			wpa_printf(MSG_WARNING,
 				   "ANQP: Cannot send MBO query to unknown BSS "
 				   MACSTR, MAC2STR(dst));
+			wpabuf_free(extra_buf);
 			return -1;
 		}
 
-- 
2.28.0



From andrei.otcheretianski at intel.com  Tue Feb 16 08:23:57 2021
From: andrei.otcheretianski at intel.com (Andrei Otcheretianski)
Date: Tue, 16 Feb 2021 15:23:57 +0200
Subject: [PATCH] PASN: Correctly set RSNXE bits
In-Reply-To: <20210216132357.4588-1-andrei.otcheretianski@intel.com>
References: <20210216132357.4588-1-andrei.otcheretianski@intel.com>
Message-ID: <20210216132357.4588-2-andrei.otcheretianski@intel.com>

From: Ilan Peer <ilan.peer at intel.com>

As the bit positions were used to set the bits instead
of using shift operations.
In addition the capability bits should not be shifted
as the shifting is handled later.

Signed-off-by: Ilan Peer <ilan.peer at intel.com>
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski at intel.com>
---
 src/ap/ieee802_11_shared.c       | 6 +++---
 wpa_supplicant/pasn_supplicant.c | 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/ap/ieee802_11_shared.c b/src/ap/ieee802_11_shared.c
index 045310594b..a429b5dd48 100644
--- a/src/ap/ieee802_11_shared.c
+++ b/src/ap/ieee802_11_shared.c
@@ -1122,11 +1122,11 @@ u8 * hostapd_eid_rsnxe(struct hostapd_data *hapd, u8 *eid, size_t len)
 	}
 
 	if (hapd->iface->drv_flags2 & WPA_DRIVER_FLAGS2_SEC_LTF)
-		capab |= BIT(WLAN_RSNX_CAPAB_SECURE_LTF - 8);
+		capab |= BIT(WLAN_RSNX_CAPAB_SECURE_LTF);
 	if (hapd->iface->drv_flags2 & WPA_DRIVER_FLAGS2_SEC_RTT)
-		capab |= BIT(WLAN_RSNX_CAPAB_SECURE_RTT - 8);
+		capab |= BIT(WLAN_RSNX_CAPAB_SECURE_RTT);
 	if (hapd->iface->drv_flags2 & WPA_DRIVER_FLAGS2_PROT_RANGE_NEG)
-		capab |= BIT(WLAN_RSNX_CAPAB_PROT_RANGE_NEG - 8);
+		capab |= BIT(WLAN_RSNX_CAPAB_PROT_RANGE_NEG);
 
 	flen = (capab & 0xff00) ? 2 : 1;
 	if (len < 2 + flen || !capab)
diff --git a/wpa_supplicant/pasn_supplicant.c b/wpa_supplicant/pasn_supplicant.c
index 736a6c7d6f..4f5ac589b9 100644
--- a/wpa_supplicant/pasn_supplicant.c
+++ b/wpa_supplicant/pasn_supplicant.c
@@ -689,11 +689,11 @@ static struct wpabuf * wpas_pasn_build_auth_1(struct wpa_supplicant *wpa_s)
 	/* TODO: How to handle protected TWT and SAE H2E? */
 	capab = 0;
 	if (wpa_s->drv_flags2 & WPA_DRIVER_FLAGS2_SEC_LTF)
-		capab |= WLAN_RSNX_CAPAB_SECURE_LTF;
+		capab |= BIT(WLAN_RSNX_CAPAB_SECURE_LTF);
 	if (wpa_s->drv_flags2 & WPA_DRIVER_FLAGS2_SEC_RTT)
-		capab |= WLAN_RSNX_CAPAB_SECURE_RTT;
+		capab |= BIT(WLAN_RSNX_CAPAB_SECURE_RTT);
 	if (wpa_s->drv_flags2 & WPA_DRIVER_FLAGS2_PROT_RANGE_NEG)
-		capab |= WLAN_RSNX_CAPAB_PROT_RANGE_NEG;
+		capab |= BIT(WLAN_RSNX_CAPAB_PROT_RANGE_NEG);
 	wpa_pasn_add_rsnxe(buf, capab);
 
 	ret = pasn_auth_frame_hash(pasn->akmp, pasn->cipher,
-- 
2.28.0



From andrei.otcheretianski at intel.com  Tue Feb 16 08:45:07 2021
From: andrei.otcheretianski at intel.com (Andrei Otcheretianski)
Date: Tue, 16 Feb 2021 15:45:07 +0200
Subject: [PATCH] tests: Replace deprecated thread isAlive function
Message-ID: <20210216134507.14765-1-andrei.otcheretianski@intel.com>

The isAlive() function is deprecated in newer versions of Python
so replace it with the is_alive() instead.

Signed-off-by: Oren Givon <oren.givon at intel.com>
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski at intel.com>
---
 tests/hwsim/remotehost.py | 10 +++++-----
 tests/remote/rutils.py    |  8 ++++----
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/tests/hwsim/remotehost.py b/tests/hwsim/remotehost.py
index 9df3d80752..0799b951f2 100644
--- a/tests/hwsim/remotehost.py
+++ b/tests/hwsim/remotehost.py
@@ -127,24 +127,24 @@ class Host():
 
         pid_file = t.name + ".pid"
 
-        if t.isAlive():
+        if t.is_alive():
             cmd = ["kill `cat " + pid_file + "`"]
             self.execute(cmd)
 
         # try again
         self.thread_wait(t, 5)
-        if t.isAlive():
+        if t.is_alive():
             cmd = ["kill `cat " + pid_file + "`"]
             self.execute(cmd)
 
         # try with -9
         self.thread_wait(t, 5)
-        if t.isAlive():
+        if t.is_alive():
             cmd = ["kill -9 `cat " + pid_file + "`"]
             self.execute(cmd)
 
         self.thread_wait(t, 5)
-        if t.isAlive():
+        if t.is_alive():
             raise Exception("thread still alive")
 
         self.execute(["rm", pid_file])
@@ -158,7 +158,7 @@ class Host():
             wait_str = str(wait) + "s"
 
         logger.debug(self.name + " thread_wait(" + wait_str + "): ")
-        if t.isAlive():
+        if t.is_alive():
             t.join(wait)
 
     def pending(self, s, timeout=0):
diff --git a/tests/remote/rutils.py b/tests/remote/rutils.py
index 0585480a2b..6902991124 100644
--- a/tests/remote/rutils.py
+++ b/tests/remote/rutils.py
@@ -347,7 +347,7 @@ def ping_run(host, ip, result, ifname=None, addr_type="ipv4", deadline="5", qos=
 
 def ping_wait(host, thread, timeout=None):
     host.thread_wait(thread, timeout)
-    if thread.isAlive():
+    if thread.is_alive():
         raise Exception("ping thread still alive")
 
 def flush_arp_cache(host):
@@ -504,16 +504,16 @@ def iperf_run(server, client, server_ip, client_res, server_res,
 
 def iperf_wait(server, client, server_thread, client_thread, timeout=None, iperf="iperf"):
     client.thread_wait(client_thread, timeout)
-    if client_thread.isAlive():
+    if client_thread.is_alive():
         raise Exception("iperf client thread still alive")
 
     server.thread_wait(server_thread, 5)
-    if server_thread.isAlive():
+    if server_thread.is_alive():
         server.execute(["killall", "-s", "INT", iperf])
         time.sleep(1)
 
     server.thread_wait(server_thread, 5)
-    if server_thread.isAlive():
+    if server_thread.is_alive():
         raise Exception("iperf server thread still alive")
 
     return
-- 
2.28.0



From alokad at codeaurora.org  Tue Feb 16 13:10:18 2021
From: alokad at codeaurora.org (Aloka Dixit)
Date: Tue, 16 Feb 2021 10:10:18 -0800
Subject: [PATCH v3 0/3] Add FILS discovery support
In-Reply-To: <20210214164341.GA425725@w1.fi>
References: <20201215020428.27901-1-alokad@codeaurora.org>
 <20210214164341.GA425725@w1.fi>
Message-ID: <487992cb81250ce96ada1cdb56a30999@codeaurora.org>

On 2021-02-14 08:43, Jouni Malinen wrote:
> On Mon, Dec 14, 2020 at 06:04:25PM -0800, Aloka Dixit wrote:
>> This patchset adds FILS discovery support with some 6GHz specific 
>> details.
>> 
>> v3: Fixed NSS value calculation in FILS capability.
>> 
>> Aloka Dixit (3):
>>   6G: Define FILS discovery frame elements
>>   AP: Add FILS discovery support
>>   nl80211: Add FILS discovery support
> 
> Thanks, applied with cleanup and fixes. In particular, the FILS
> Discovery Information field generation would not have worked correctly
> on big endian CPUs and the suite selector indication in FD RSN Info did
> not look correct for multiple cases.

I had used bit manipulation on existing RSN IE without
checking for the actual security types. The way you
added does look better. Thanks.


From mcroce at linux.microsoft.com  Tue Feb 16 18:53:05 2021
From: mcroce at linux.microsoft.com (Matteo Croce)
Date: Wed, 17 Feb 2021 00:53:05 +0100
Subject: Build error after radiotap update
Message-ID: <20210217004916.7693510b@linux.microsoft.com>

Hi,

After e6ac26943 ("radiotap: Update radiotap parser")
I get this build error:

# make
/usr/bin/ld: build/hostapd/src/drivers/driver_nl80211_monitor.o:src/utils/radiotap.h:42: multiple definition of `__packed'; build/hostapd/src/drivers/driver_nl80211.o:src/utils/radiotap.h:42: first defined here
/usr/bin/ld: build/hostapd/src/utils/radiotap.o:hostapd/../src/utils/radiotap.h:42: multiple definition of `__packed'; build/hostapd/src/drivers/driver_nl80211.o:src/utils/radiotap.h:42: first defined here
collect2: error: ld returned 1 exit status
make: *** [Makefile:1281: hostapd] Error 1

I tried to replace __packed with __attribute__ ((__packed__)) and
although it compiles, I have the following warning:

../src/utils/radiotap.c: In function ?ieee80211_radiotap_iterator_init?:
../src/utils/radiotap.c:114:27: warning: taking address of packed member of ?struct ieee80211_radiotap_header? may result in an unaligned pointer value [-Waddress-of-packed-member]
  114 |  iterator->_next_bitmap = &radiotap_header->it_present;
      |                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~

My compiler is: gcc version 10.2.1 20210110 (Debian 10.2.1-6)

Regards,
-- 
per aspera ad upstream


From andrei.otcheretianski at intel.com  Wed Feb 17 05:14:32 2021
From: andrei.otcheretianski at intel.com (Andrei Otcheretianski)
Date: Wed, 17 Feb 2021 12:14:32 +0200
Subject: [PATCH v2 1/2] nl80211: Unconditionally clear nl_msg
In-Reply-To: <SJ0PR11MB4941B7B5141CB028291278B1F58D9@SJ0PR11MB4941.namprd11.prod.outlook.com>
References: <SJ0PR11MB4941B7B5141CB028291278B1F58D9@SJ0PR11MB4941.namprd11.prod.outlook.com>
Message-ID: <20210217101433.14673-1-andrei.otcheretianski@intel.com>

Previously nl80211_nlmsg_clear() would be called under a special condition
when valid_handler is NULL and valid_data is -1.
Such API is not very convenient as it forces the handler to be NULL.
Change the send_and_recv function to always clear the nl_msg, which will
simplify all this logic.

Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski at intel.com>
---
 src/drivers/driver_nl80211.c | 15 +++++++--------
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/src/drivers/driver_nl80211.c b/src/drivers/driver_nl80211.c
index 80d2b4a400..6fb085446f 100644
--- a/src/drivers/driver_nl80211.c
+++ b/src/drivers/driver_nl80211.c
@@ -467,8 +467,8 @@ static int send_and_recv(struct nl80211_global *global,
 	}
  out:
 	nl_cb_put(cb);
-	if (!valid_handler && valid_data == (void *) -1)
-		nl80211_nlmsg_clear(msg);
+	/* Always clear the message as it can potentially contain keys */
+	nl80211_nlmsg_clear(msg);
 	nlmsg_free(msg);
 	return err;
 }
@@ -3164,7 +3164,7 @@ static int issue_key_mgmt_set_key(struct wpa_driver_nl80211_data *drv,
 		nlmsg_free(msg);
 		return -1;
 	}
-	ret = send_and_recv_msgs(drv, msg, NULL, (void *) -1, NULL, NULL);
+	ret = send_and_recv_msgs(drv, msg, NULL, NULL, NULL, NULL);
 	if (ret) {
 		wpa_printf(MSG_DEBUG,
 			   "nl80211: Key management set key failed: ret=%d (%s)",
@@ -3204,7 +3204,7 @@ static int nl80211_set_pmk(struct wpa_driver_nl80211_data *drv,
 		return -ENOBUFS;
 	}
 
-	ret = send_and_recv_msgs(drv, msg, NULL, (void *) -1, NULL, NULL);
+	ret = send_and_recv_msgs(drv, msg, NULL, NULL, NULL, NULL);
 	if (ret) {
 		wpa_printf(MSG_DEBUG, "nl80211: Set PMK failed: ret=%d (%s)",
 			   ret, strerror(-ret));
@@ -3370,8 +3370,7 @@ static int wpa_driver_nl80211_set_key(struct i802_bss *bss,
 			goto fail;
 	}
 
-	ret = send_and_recv_msgs(drv, msg, NULL, key ? (void *) -1 : NULL,
-				 NULL, NULL);
+	ret = send_and_recv_msgs(drv, msg, NULL, NULL, NULL, NULL);
 	if ((ret == -ENOENT || ret == -ENOLINK) && alg == WPA_ALG_NONE)
 		ret = 0;
 	if (ret)
@@ -8710,7 +8709,7 @@ static int nl80211_pmkid(struct i802_bss *bss, int cmd,
 		return -ENOBUFS;
 	}
 
-	return send_and_recv_msgs(bss->drv, msg, NULL, (void *) -1, NULL, NULL);
+	return send_and_recv_msgs(bss->drv, msg, NULL, NULL, NULL, NULL);
 }
 
 
@@ -8980,7 +8979,7 @@ static void nl80211_set_rekey_info(void *priv, const u8 *kek, size_t kek_len,
 
 	nla_nest_end(msg, replay_nested);
 
-	ret = send_and_recv_msgs(drv, msg, NULL, (void *) -1, NULL, NULL);
+	ret = send_and_recv_msgs(drv, msg, NULL, NULL, NULL, NULL);
 	if (ret == -EOPNOTSUPP) {
 		wpa_printf(MSG_DEBUG,
 			   "nl80211: Driver does not support rekey offload");
-- 
2.28.0



From andrei.otcheretianski at intel.com  Wed Feb 17 05:14:33 2021
From: andrei.otcheretianski at intel.com (Andrei Otcheretianski)
Date: Wed, 17 Feb 2021 12:14:33 +0200
Subject: [PATCH v2 2/2] nl80211: use the process_bss_event for the nl_connect
 handler
In-Reply-To: <SJ0PR11MB4941B7B5141CB028291278B1F58D9@SJ0PR11MB4941.namprd11.prod.outlook.com>
References: <SJ0PR11MB4941B7B5141CB028291278B1F58D9@SJ0PR11MB4941.namprd11.prod.outlook.com>
Message-ID: <20210217101433.14673-2-andrei.otcheretianski@intel.com>

From: Avraham Stern <avraham.stern at intel.com>

The nl_connect is initialized with the process_bss_event() handler.
However, it is used several times with the default valid handler.
As a result, if a message that is only valid for the
process_bss_event() is received while the default handler is used, it
will be dropped.

This has been observed in a case where during the 4 way handshake, a
beacon is received on the AP side, which triggers a beacon update,
just before receiving the next EAPOL.
When send_and_recv_msgs_owner() is called for sending the
NL80211_CMD_SET_BEACON command, the NL80211_CMD_CONTROL_PORT_FRAME
event is already pending.
As a result, it is received with the default handler, which drops it.
Since the EAPOL frame is dropped, the connection attempt fails.

Fix it by using the process_bss_event() handler when the nl_connect
handler is used.

Signed-off-by: Avraham Stern <avraham.stern at intel.com>
---
 src/drivers/driver_nl80211.c      | 68 ++++++++++++++++---------------
 src/drivers/driver_nl80211.h      |  2 +-
 src/drivers/driver_nl80211_scan.c |  2 +-
 3 files changed, 38 insertions(+), 34 deletions(-)

diff --git a/src/drivers/driver_nl80211.c b/src/drivers/driver_nl80211.c
index 6fb085446f..d8a911a6a4 100644
--- a/src/drivers/driver_nl80211.c
+++ b/src/drivers/driver_nl80211.c
@@ -530,6 +530,21 @@ static int send_and_recv_msgs_owner(struct wpa_driver_nl80211_data *drv,
 }
 
 
+static int
+send_and_recv_msgs_connect_handle(struct wpa_driver_nl80211_data *drv,
+				  struct nl_msg *msg, struct i802_bss *bss)
+{
+	struct nl_sock *nl_connect = get_connect_handle(bss);
+
+	if (nl_connect)
+		return send_and_recv_msgs_owner(drv, msg, nl_connect, 1,
+						process_bss_event, bss, NULL,
+						NULL);
+	else
+		return send_and_recv_msgs(drv, msg, NULL, NULL, NULL, NULL);
+}
+
+
 struct nl_sock * get_connect_handle(struct i802_bss *bss)
 {
 	if ((bss->drv->capa.flags2 & WPA_DRIVER_FLAGS2_CONTROL_PORT_RX) ||
@@ -3541,10 +3556,11 @@ static int nl80211_set_conn_keys(struct wpa_driver_associate_params *params,
 int wpa_driver_nl80211_mlme(struct wpa_driver_nl80211_data *drv,
 			    const u8 *addr, int cmd, u16 reason_code,
 			    int local_state_change,
-			    struct nl_sock *nl_connect)
+			    struct i802_bss *bss)
 {
 	int ret;
 	struct nl_msg *msg;
+	struct nl_sock *nl_connect = get_connect_handle(bss);
 
 	if (!(msg = nl80211_drv_msg(drv, 0, cmd)) ||
 	    nla_put_u16(msg, NL80211_ATTR_REASON_CODE, reason_code) ||
@@ -3556,8 +3572,8 @@ int wpa_driver_nl80211_mlme(struct wpa_driver_nl80211_data *drv,
 	}
 
 	if (nl_connect)
-		ret = send_and_recv(drv->global, nl_connect, msg, NULL, NULL,
-				    NULL, NULL);
+		ret = send_and_recv(drv->global, nl_connect, msg,
+				    process_bss_event, bss, NULL, NULL);
 	else
 		ret = send_and_recv_msgs(drv, msg, NULL, NULL, NULL, NULL);
 	if (ret) {
@@ -3571,7 +3587,7 @@ int wpa_driver_nl80211_mlme(struct wpa_driver_nl80211_data *drv,
 
 static int wpa_driver_nl80211_disconnect(struct wpa_driver_nl80211_data *drv,
 					 u16 reason_code,
-					 struct nl_sock *nl_connect)
+					 struct i802_bss *bss)
 {
 	int ret;
 	int drv_associated = drv->associated;
@@ -3580,7 +3596,7 @@ static int wpa_driver_nl80211_disconnect(struct wpa_driver_nl80211_data *drv,
 	nl80211_mark_disconnected(drv);
 	/* Disconnect command doesn't need BSSID - it uses cached value */
 	ret = wpa_driver_nl80211_mlme(drv, NULL, NL80211_CMD_DISCONNECT,
-				      reason_code, 0, nl_connect);
+				      reason_code, 0, bss);
 	/*
 	 * For locally generated disconnect, supplicant already generates a
 	 * DEAUTH event, so ignore the event from NL80211.
@@ -3603,14 +3619,13 @@ static int wpa_driver_nl80211_deauthenticate(struct i802_bss *bss,
 		return nl80211_leave_ibss(drv, 1);
 	}
 	if (!(drv->capa.flags & WPA_DRIVER_FLAGS_SME)) {
-		return wpa_driver_nl80211_disconnect(drv, reason_code,
-						     get_connect_handle(bss));
+		return wpa_driver_nl80211_disconnect(drv, reason_code, bss);
 	}
 	wpa_printf(MSG_DEBUG, "%s(addr=" MACSTR " reason_code=%d)",
 		   __func__, MAC2STR(addr), reason_code);
 	nl80211_mark_disconnected(drv);
 	ret = wpa_driver_nl80211_mlme(drv, addr, NL80211_CMD_DEAUTHENTICATE,
-				      reason_code, 0, get_connect_handle(bss));
+				      reason_code, 0, bss);
 	/*
 	 * For locally generated deauthenticate, supplicant already generates a
 	 * DEAUTH event, so ignore the event from NL80211.
@@ -4759,8 +4774,7 @@ static int wpa_driver_nl80211_set_ap(void *priv,
 		goto fail;
 #endif /* CONFIG_FILS */
 
-	ret = send_and_recv_msgs_owner(drv, msg, get_connect_handle(bss), 1,
-				       NULL, NULL, NULL, NULL);
+	ret = send_and_recv_msgs_connect_handle(drv, msg, bss);
 	if (ret) {
 		wpa_printf(MSG_DEBUG, "nl80211: Beacon set failed: %d (%s)",
 			   ret, strerror(-ret));
@@ -5814,9 +5828,7 @@ static int nl80211_leave_ibss(struct wpa_driver_nl80211_data *drv,
 	int ret;
 
 	msg = nl80211_drv_msg(drv, 0, NL80211_CMD_LEAVE_IBSS);
-	ret = send_and_recv_msgs_owner(drv, msg,
-				       get_connect_handle(drv->first_bss), 1,
-				       NULL, NULL, NULL, NULL);
+	ret = send_and_recv_msgs_connect_handle(drv, msg, drv->first_bss);
 	if (ret) {
 		wpa_printf(MSG_DEBUG, "nl80211: Leave IBSS failed: ret=%d "
 			   "(%s)", ret, strerror(-ret));
@@ -5948,9 +5960,7 @@ retry:
 	if (ret < 0)
 		goto fail;
 
-	ret = send_and_recv_msgs_owner(drv, msg,
-				       get_connect_handle(drv->first_bss), 1,
-				       NULL, NULL, NULL, NULL);
+	ret = send_and_recv_msgs_connect_handle(drv, msg, drv->first_bss);
 	msg = NULL;
 	if (ret) {
 		wpa_printf(MSG_DEBUG, "nl80211: Join IBSS failed: ret=%d (%s)",
@@ -6286,7 +6296,7 @@ static int nl80211_connect_common(struct wpa_driver_nl80211_data *drv,
 static int wpa_driver_nl80211_try_connect(
 	struct wpa_driver_nl80211_data *drv,
 	struct wpa_driver_associate_params *params,
-	struct nl_sock *nl_connect)
+	struct i802_bss *bss)
 {
 	struct nl_msg *msg;
 	enum nl80211_auth_type type;
@@ -6358,8 +6368,7 @@ skip_auth_type:
 	if (ret)
 		goto fail;
 
-	ret = send_and_recv_msgs_owner(drv, msg, nl_connect, 1, NULL,
-				       (void *) -1, NULL, NULL);
+	ret = send_and_recv_msgs_connect_handle(drv, msg, bss);
 	msg = NULL;
 	if (ret) {
 		wpa_printf(MSG_DEBUG, "nl80211: MLME connect failed: ret=%d "
@@ -6383,7 +6392,7 @@ fail:
 static int wpa_driver_nl80211_connect(
 	struct wpa_driver_nl80211_data *drv,
 	struct wpa_driver_associate_params *params,
-	struct nl_sock *nl_connect)
+	struct i802_bss *bss)
 {
 	int ret;
 
@@ -6393,7 +6402,7 @@ static int wpa_driver_nl80211_connect(
 	else
 		os_memset(drv->auth_attempt_bssid, 0, ETH_ALEN);
 
-	ret = wpa_driver_nl80211_try_connect(drv, params, nl_connect);
+	ret = wpa_driver_nl80211_try_connect(drv, params, bss);
 	if (ret == -EALREADY) {
 		/*
 		 * cfg80211 does not currently accept new connections if
@@ -6404,9 +6413,9 @@ static int wpa_driver_nl80211_connect(
 			   "disconnecting before reassociation "
 			   "attempt");
 		if (wpa_driver_nl80211_disconnect(
-			    drv, WLAN_REASON_PREV_AUTH_NOT_VALID, nl_connect))
+			    drv, WLAN_REASON_PREV_AUTH_NOT_VALID, bss))
 			return -1;
-		ret = wpa_driver_nl80211_try_connect(drv, params, nl_connect);
+		ret = wpa_driver_nl80211_try_connect(drv, params, bss);
 	}
 	return ret;
 }
@@ -6440,8 +6449,7 @@ static int wpa_driver_nl80211_associate(
 		else
 			bss->use_nl_connect = 0;
 
-		return wpa_driver_nl80211_connect(drv, params,
-						  get_connect_handle(bss));
+		return wpa_driver_nl80211_connect(drv, params, bss);
 	}
 
 	nl80211_mark_disconnected(drv);
@@ -6476,9 +6484,7 @@ static int wpa_driver_nl80211_associate(
 			goto fail;
 	}
 
-	ret = send_and_recv_msgs_owner(drv, msg,
-				       get_connect_handle(drv->first_bss), 1,
-				       NULL, NULL, NULL, NULL);
+	ret = send_and_recv_msgs_connect_handle(drv, msg, drv->first_bss);
 	msg = NULL;
 	if (ret) {
 		wpa_dbg(drv->ctx, MSG_DEBUG,
@@ -10461,8 +10467,7 @@ static int nl80211_join_mesh(struct i802_bss *bss,
 	if (nl80211_put_mesh_config(msg, &params->conf) < 0)
 		goto fail;
 
-	ret = send_and_recv_msgs_owner(drv, msg, get_connect_handle(bss), 1,
-				       NULL, NULL, NULL, NULL);
+	ret = send_and_recv_msgs_connect_handle(drv, msg, bss);
 	msg = NULL;
 	if (ret) {
 		wpa_printf(MSG_DEBUG, "nl80211: mesh join failed: ret=%d (%s)",
@@ -10519,8 +10524,7 @@ static int wpa_driver_nl80211_leave_mesh(void *priv)
 
 	wpa_printf(MSG_DEBUG, "nl80211: mesh leave (ifindex=%d)", drv->ifindex);
 	msg = nl80211_drv_msg(drv, 0, NL80211_CMD_LEAVE_MESH);
-	ret = send_and_recv_msgs_owner(drv, msg, get_connect_handle(bss), 0,
-				       NULL, NULL, NULL, NULL);
+	ret = send_and_recv_msgs_connect_handle(drv, msg, bss);
 	if (ret) {
 		wpa_printf(MSG_DEBUG, "nl80211: mesh leave failed: ret=%d (%s)",
 			   ret, strerror(-ret));
diff --git a/src/drivers/driver_nl80211.h b/src/drivers/driver_nl80211.h
index 940d82c87b..7b0caa2782 100644
--- a/src/drivers/driver_nl80211.h
+++ b/src/drivers/driver_nl80211.h
@@ -272,7 +272,7 @@ int wpa_driver_nl80211_set_mode(struct i802_bss *bss,
 int wpa_driver_nl80211_mlme(struct wpa_driver_nl80211_data *drv,
 			    const u8 *addr, int cmd, u16 reason_code,
 			    int local_state_change,
-			    struct nl_sock *nl_connect);
+			    struct i802_bss *bss);
 
 int nl80211_create_monitor_interface(struct wpa_driver_nl80211_data *drv);
 void nl80211_remove_monitor_interface(struct wpa_driver_nl80211_data *drv);
diff --git a/src/drivers/driver_nl80211_scan.c b/src/drivers/driver_nl80211_scan.c
index 233175d19b..1316084805 100644
--- a/src/drivers/driver_nl80211_scan.c
+++ b/src/drivers/driver_nl80211_scan.c
@@ -870,7 +870,7 @@ static void clear_state_mismatch(struct wpa_driver_nl80211_data *drv,
 		wpa_driver_nl80211_mlme(drv, addr,
 					NL80211_CMD_DEAUTHENTICATE,
 					WLAN_REASON_PREV_AUTH_NOT_VALID, 1,
-					get_connect_handle(drv->first_bss));
+					drv->first_bss);
 	}
 }
 
-- 
2.28.0



From anusha at meter.com  Wed Feb 17 17:32:55 2021
From: anusha at meter.com (Anusha Datar)
Date: Wed, 17 Feb 2021 17:32:55 -0500
Subject: [PATCH 0/3] Modify RADIUS message length validation
Message-ID: <20210217223258.10801-1-anusha@meter.com>

This set of patches creates an explicit parameter for the RADIUS
message length, modify that parameter to match the value in RFC2865,
and then modify radius_client to check for message truncation to
check whether or not the message is actually too long. These steps
are necessary to prepare for modifying the buffer limits.

Anusha Datar (3):
  Create RADIUS_MAX_MSG_LEN param in radius header
  Set RADIUS message length to reflect RFC2865
  Check for message truncation in radius client

 src/radius/radius.h        |  3 +++
 src/radius/radius_client.c | 15 ++++++++++++---
 src/radius/radius_server.c |  5 -----
 3 files changed, 15 insertions(+), 8 deletions(-)

-- 
2.25.1



From anusha at meter.com  Wed Feb 17 17:32:56 2021
From: anusha at meter.com (Anusha Datar)
Date: Wed, 17 Feb 2021 17:32:56 -0500
Subject: [PATCH 1/3] Create RADIUS_MAX_MSG_LEN param in radius header
In-Reply-To: <20210217223258.10801-1-anusha@meter.com>
References: <20210217223258.10801-1-anusha@meter.com>
Message-ID: <20210217223258.10801-2-anusha@meter.com>

The radius client currently uses a hardcoded value of 3000 for the
maximum length of a radius message, and the radius server currently
defines a constant value for the maximum length of the radius message
within its source. The client and the server should use the same
maximum length value, so this change creates a shared parameter
RADIUS_MAX_MSG_LEN within the header file radius.h and modifies
both the client and the server to use that parameter instead of
a locally set value.

Signed-off-by: Anusha Datar <anusha at meter.com>
Reviewed-by: Steve deRosier <derosier at cal-sierra.com>
Reviewed-by: Julian Squires <julian at cipht.net>
---
 src/radius/radius.h        | 2 ++
 src/radius/radius_client.c | 2 +-
 src/radius/radius_server.c | 5 -----
 3 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/src/radius/radius.h b/src/radius/radius.h
index 630c0f9d0..e22868817 100644
--- a/src/radius/radius.h
+++ b/src/radius/radius.h
@@ -225,6 +225,8 @@ struct radius_msg;
 /* Default size to be allocated for attribute array */
 #define RADIUS_DEFAULT_ATTR_COUNT 16
 
+/* Maximum message length for incoming RADIUS messages */
+#define RADIUS_MAX_MSG_LEN 3000
 
 /* MAC address ASCII format for IEEE 802.1X use
  * (draft-congdon-radius-8021x-20.txt) */
diff --git a/src/radius/radius_client.c b/src/radius/radius_client.c
index 2b7a604ed..7484d61b8 100644
--- a/src/radius/radius_client.c
+++ b/src/radius/radius_client.c
@@ -816,7 +816,7 @@ static void radius_client_receive(int sock, void *eloop_ctx, void *sock_ctx)
 	struct hostapd_radius_servers *conf = radius->conf;
 	RadiusType msg_type = (RadiusType) sock_ctx;
 	int len, roundtrip;
-	unsigned char buf[3000];
+	unsigned char buf[RADIUS_MAX_MSG_LEN + 1];
 	struct radius_msg *msg;
 	struct radius_hdr *hdr;
 	struct radius_rx_handler *handlers;
diff --git a/src/radius/radius_server.c b/src/radius/radius_server.c
index 971fe91b1..e02c21540 100644
--- a/src/radius/radius_server.c
+++ b/src/radius/radius_server.c
@@ -35,11 +35,6 @@
  */
 #define RADIUS_MAX_SESSION 1000
 
-/**
- * RADIUS_MAX_MSG_LEN - Maximum message length for incoming RADIUS messages
- */
-#define RADIUS_MAX_MSG_LEN 3000
-
 static const struct eapol_callbacks radius_server_eapol_cb;
 
 struct radius_client;
-- 
2.25.1



From anusha at meter.com  Wed Feb 17 17:32:57 2021
From: anusha at meter.com (Anusha Datar)
Date: Wed, 17 Feb 2021 17:32:57 -0500
Subject: [PATCH 2/3] Set RADIUS message length to reflect RFC2865
In-Reply-To: <20210217223258.10801-1-anusha@meter.com>
References: <20210217223258.10801-1-anusha@meter.com>
Message-ID: <20210217223258.10801-3-anusha@meter.com>

The current RADIUS server message maximum length limits the length of
each RADIUS message to 3000 bytes. As specified in RFC 2865 section 3
("Packet Format"), the RADIUS standard's maximum message size is 4096
bytes, so this change increases the RADIUS server's maximum message
size from 3000 to 4096 to match the standard.

Signed-off-by: Anusha Datar <anusha at meter.com>
Reviewed-by: Steve deRosier <derosier at cal-sierra.com>
Reviewed-by: Julian Squires <julian at cipht.net>
---
 src/radius/radius.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/radius/radius.h b/src/radius/radius.h
index e22868817..59a12d029 100644
--- a/src/radius/radius.h
+++ b/src/radius/radius.h
@@ -225,8 +225,9 @@ struct radius_msg;
 /* Default size to be allocated for attribute array */
 #define RADIUS_DEFAULT_ATTR_COUNT 16
 
-/* Maximum message length for incoming RADIUS messages */
-#define RADIUS_MAX_MSG_LEN 3000
+/* Maximum message length for incoming RADIUS messages, as stated in RFC 2865 
+ * Section 3 ("Packet Format").*/
+#define RADIUS_MAX_MSG_LEN 4096
 
 /* MAC address ASCII format for IEEE 802.1X use
  * (draft-congdon-radius-8021x-20.txt) */
-- 
2.25.1



From anusha at meter.com  Wed Feb 17 17:32:58 2021
From: anusha at meter.com (Anusha Datar)
Date: Wed, 17 Feb 2021 17:32:58 -0500
Subject: [PATCH 3/3] Check for message truncation in radius client
In-Reply-To: <20210217223258.10801-1-anusha@meter.com>
References: <20210217223258.10801-1-anusha@meter.com>
Message-ID: <20210217223258.10801-4-anusha@meter.com>

The radius client currently determines if a radius message is longer
than the supported maximum length by checking whether the size of the
received buffer and the length of the buffer (as returned by recv()) is
equal. This method fails to detect if the buffer has actually been
truncated. This change modifies the radius_client to instead use the
recvmsg() call and then check the message header flags to determine
whether or not the received message has been truncated and drop the
message if that is the case.

Signed-off-by: Anusha Datar <anusha at meter.com>
Reviewed-by: Steve deRosier <derosier at cal-sierra.com>
Reviewed-by: Julian Squires <julian at cipht.net>
---
 src/radius/radius_client.c | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/src/radius/radius_client.c b/src/radius/radius_client.c
index 7484d61b8..ad02a998d 100644
--- a/src/radius/radius_client.c
+++ b/src/radius/radius_client.c
@@ -816,7 +816,9 @@ static void radius_client_receive(int sock, void *eloop_ctx, void *sock_ctx)
 	struct hostapd_radius_servers *conf = radius->conf;
 	RadiusType msg_type = (RadiusType) sock_ctx;
 	int len, roundtrip;
-	unsigned char buf[RADIUS_MAX_MSG_LEN + 1];
+	unsigned char buf[RADIUS_MAX_MSG_LEN];
+	struct msghdr msghdr = {0};
+	struct iovec iov;
 	struct radius_msg *msg;
 	struct radius_hdr *hdr;
 	struct radius_rx_handler *handlers;
@@ -836,15 +838,22 @@ static void radius_client_receive(int sock, void *eloop_ctx, void *sock_ctx)
 		rconf = conf->auth_server;
 	}
 
-	len = recv(sock, buf, sizeof(buf), MSG_DONTWAIT);
+	iov.iov_base = buf;
+	iov.iov_len = RADIUS_MAX_MSG_LEN;
+	msghdr.msg_iov = &iov;
+	msghdr.msg_iovlen = 1;
+	msghdr.msg_flags = 0;
+	len = recvmsg(sock, &msghdr, MSG_DONTWAIT);
 	if (len < 0) {
 		wpa_printf(MSG_INFO, "recv[RADIUS]: %s", strerror(errno));
 		return;
 	}
+
 	hostapd_logger(radius->ctx, NULL, HOSTAPD_MODULE_RADIUS,
 		       HOSTAPD_LEVEL_DEBUG, "Received %d bytes from RADIUS "
 		       "server", len);
-	if (len == sizeof(buf)) {
+
+	if (msghdr.msg_flags & MSG_TRUNC) {
 		wpa_printf(MSG_INFO, "RADIUS: Possibly too long UDP frame for our buffer - dropping it");
 		return;
 	}
-- 
2.25.1



From bgalvani at redhat.com  Fri Feb 19 09:50:04 2021
From: bgalvani at redhat.com (Beniamino Galvani)
Date: Fri, 19 Feb 2021 15:50:04 +0100
Subject: [PATCH] dbus: Export SAE capability
Message-ID: <20210219145004.2130700-1-bgalvani@redhat.com>

Export a new 'sae' capability to indicate that wpa_supplicant was
built with SAE support.

Signed-off-by: Beniamino Galvani <bgalvani at redhat.com>
---
 wpa_supplicant/dbus/dbus_new_handlers.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/wpa_supplicant/dbus/dbus_new_handlers.c b/wpa_supplicant/dbus/dbus_new_handlers.c
index 7d20f2123..3a13180b0 100644
--- a/wpa_supplicant/dbus/dbus_new_handlers.c
+++ b/wpa_supplicant/dbus/dbus_new_handlers.c
@@ -1013,7 +1013,7 @@ dbus_bool_t wpas_dbus_getter_global_capabilities(
 	const struct wpa_dbus_property_desc *property_desc,
 	DBusMessageIter *iter, DBusError *error, void *user_data)
 {
-	const char *capabilities[13];
+	const char *capabilities[14];
 	size_t num_items = 0;
 	struct wpa_global *global = user_data;
 	struct wpa_supplicant *wpa_s;
@@ -1061,6 +1061,9 @@ dbus_bool_t wpas_dbus_getter_global_capabilities(
 #ifdef CONFIG_SHA384
 	capabilities[num_items++] = "sha384";
 #endif /* CONFIG_SHA384 */
+#ifdef CONFIG_SAE
+	capabilities[num_items++] = "sae";
+#endif /* CONFIG_SAE */
 #ifdef CONFIG_OWE
 	capabilities[num_items++] = "owe";
 #endif /* CONFIG_OWE */
-- 
2.26.2



From j at w1.fi  Fri Feb 19 17:07:24 2021
From: j at w1.fi (Jouni Malinen)
Date: Sat, 20 Feb 2021 00:07:24 +0200
Subject: [PATCH] dbus: Export SAE capability
In-Reply-To: <20210219145004.2130700-1-bgalvani@redhat.com>
References: <20210219145004.2130700-1-bgalvani@redhat.com>
Message-ID: <20210219220724.GA97575@w1.fi>

On Fri, Feb 19, 2021 at 03:50:04PM +0100, Beniamino Galvani wrote:
> Export a new 'sae' capability to indicate that wpa_supplicant was
> built with SAE support.

What would this be used for and why would the more complete SAE
capability indication in wpas_dbus_getter_capabilities() not be better
option for that use case? I would have expected it to be more valuable
to know whether SAE can be used with a specific interface than whether
wpa_supplicant build includes SAE support especially if that support
cannot be used in practice.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Fri Feb 19 17:42:10 2021
From: j at w1.fi (Jouni Malinen)
Date: Sat, 20 Feb 2021 00:42:10 +0200
Subject: [PATCH v2 2/2] nl80211: use the process_bss_event for the
 nl_connect handler
In-Reply-To: <20210217101433.14673-2-andrei.otcheretianski@intel.com>
References: <SJ0PR11MB4941B7B5141CB028291278B1F58D9@SJ0PR11MB4941.namprd11.prod.outlook.com>
 <20210217101433.14673-2-andrei.otcheretianski@intel.com>
Message-ID: <20210219224210.GB97575@w1.fi>

On Wed, Feb 17, 2021 at 12:14:33PM +0200, Andrei Otcheretianski wrote:
> diff --git a/src/drivers/driver_nl80211.c b/src/drivers/driver_nl80211.c
> +static int
> +send_and_recv_msgs_connect_handle(struct wpa_driver_nl80211_data *drv,
> +				  struct nl_msg *msg, struct i802_bss *bss)
> +{
> +	struct nl_sock *nl_connect = get_connect_handle(bss);
> +
> +	if (nl_connect)
> +		return send_and_recv_msgs_owner(drv, msg, nl_connect, 1,
> +						process_bss_event, bss, NULL,
> +						NULL);

So this has set_owner hardcoded to 1 which matches most modified
callers, but...

> @@ -10519,8 +10524,7 @@ static int wpa_driver_nl80211_leave_mesh(void *priv)
>  
>  	wpa_printf(MSG_DEBUG, "nl80211: mesh leave (ifindex=%d)", drv->ifindex);
>  	msg = nl80211_drv_msg(drv, 0, NL80211_CMD_LEAVE_MESH);
> -	ret = send_and_recv_msgs_owner(drv, msg, get_connect_handle(bss), 0,
> -				       NULL, NULL, NULL, NULL);
> +	ret = send_and_recv_msgs_connect_handle(drv, msg, bss);

This one here uses set_owner == 0.. Is it really correct to replace that
with 1?

-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Fri Feb 19 18:51:40 2021
From: j at w1.fi (Jouni Malinen)
Date: Sat, 20 Feb 2021 01:51:40 +0200
Subject: [PATCH] wpa_supplicant: Fix potential memleak
In-Reply-To: <20210216132357.4588-1-andrei.otcheretianski@intel.com>
References: <20210216132357.4588-1-andrei.otcheretianski@intel.com>
Message-ID: <20210219235140.GA909999@w1.fi>

On Tue, Feb 16, 2021 at 03:23:56PM +0200, Andrei Otcheretianski wrote:
> Fix a memory leak on error path.

Thanks, applied.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Fri Feb 19 18:51:57 2021
From: j at w1.fi (Jouni Malinen)
Date: Sat, 20 Feb 2021 01:51:57 +0200
Subject: [PATCH] PASN: Correctly set RSNXE bits
In-Reply-To: <20210216132357.4588-2-andrei.otcheretianski@intel.com>
References: <20210216132357.4588-1-andrei.otcheretianski@intel.com>
 <20210216132357.4588-2-andrei.otcheretianski@intel.com>
Message-ID: <20210219235157.GB909999@w1.fi>

On Tue, Feb 16, 2021 at 03:23:57PM +0200, Andrei Otcheretianski wrote:
> As the bit positions were used to set the bits instead
> of using shift operations.
> In addition the capability bits should not be shifted
> as the shifting is handled later.

Thanks, applied.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Fri Feb 19 18:52:16 2021
From: j at w1.fi (Jouni Malinen)
Date: Sat, 20 Feb 2021 01:52:16 +0200
Subject: [PATCH] tests: Replace deprecated thread isAlive function
In-Reply-To: <20210216134507.14765-1-andrei.otcheretianski@intel.com>
References: <20210216134507.14765-1-andrei.otcheretianski@intel.com>
Message-ID: <20210219235216.GC909999@w1.fi>

On Tue, Feb 16, 2021 at 03:45:07PM +0200, Andrei Otcheretianski wrote:
> The isAlive() function is deprecated in newer versions of Python
> so replace it with the is_alive() instead.

Thanks, applied.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Fri Feb 19 18:52:49 2021
From: j at w1.fi (Jouni Malinen)
Date: Sat, 20 Feb 2021 01:52:49 +0200
Subject: [PATCH v2 1/2] nl80211: Unconditionally clear nl_msg
In-Reply-To: <20210217101433.14673-1-andrei.otcheretianski@intel.com>
References: <SJ0PR11MB4941B7B5141CB028291278B1F58D9@SJ0PR11MB4941.namprd11.prod.outlook.com>
 <20210217101433.14673-1-andrei.otcheretianski@intel.com>
Message-ID: <20210219235249.GD909999@w1.fi>

On Wed, Feb 17, 2021 at 12:14:32PM +0200, Andrei Otcheretianski wrote:
> Previously nl80211_nlmsg_clear() would be called under a special condition
> when valid_handler is NULL and valid_data is -1.
> Such API is not very convenient as it forces the handler to be NULL.
> Change the send_and_recv function to always clear the nl_msg, which will
> simplify all this logic.

Thanks, applied patch 1/2 with one missed caller cleanup added.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Fri Feb 19 18:53:07 2021
From: j at w1.fi (Jouni Malinen)
Date: Sat, 20 Feb 2021 01:53:07 +0200
Subject: [PATCH 0/3] Modify RADIUS message length validation
In-Reply-To: <20210217223258.10801-1-anusha@meter.com>
References: <20210217223258.10801-1-anusha@meter.com>
Message-ID: <20210219235307.GE909999@w1.fi>

On Wed, Feb 17, 2021 at 05:32:55PM -0500, Anusha Datar wrote:
> This set of patches creates an explicit parameter for the RADIUS
> message length, modify that parameter to match the value in RFC2865,
> and then modify radius_client to check for message truncation to
> check whether or not the message is actually too long. These steps
> are necessary to prepare for modifying the buffer limits.
> 
> Anusha Datar (3):
>   Create RADIUS_MAX_MSG_LEN param in radius header
>   Set RADIUS message length to reflect RFC2865
>   Check for message truncation in radius client

Thanks, applied.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Sat Feb 20 09:26:42 2021
From: j at w1.fi (Jouni Malinen)
Date: Sat, 20 Feb 2021 16:26:42 +0200
Subject: [PATCH v2] PEAP peer: allow autheap for EAP-TLS phase2 support
In-Reply-To: <20201016083101.2300-1-alex@digriz.org.uk>
References: <20201016083101.2300-1-alex@digriz.org.uk>
Message-ID: <20210220142642.GA449838@w1.fi>

On Fri, Oct 16, 2020 at 09:31:03AM +0100, Alexander Clouter wrote:
> PEAP supports using EAP-TLS as the inner method (often referred to as
> PEAP-TLS or PEAP-EAP-TLS in the literature). This patch exposes the hooks
> that enable this to be configured and used by wpa_supplicant/eapol_test.

I still do not understand why this would be needed. EAP-TLS as an inner
method for PEAP has been supported for years with following:

    eap=PEAP
    phase2="auth=TLS"
    ca_cert="ca-for-outer-peap.pem"
    identity="User"
    ca_cert2="ca-for-inner-eap-tls.pem"
    client_cert2="user-cert-for-inner-eap-tls.pem"
    private_key2="user-private-key-for-inner-eap-tls.pem"

Sure, this is different compared to the EAP-TTLS special case, but the
special case is on the EAP-TTLS side (both EAP and non-EAP inner
methods) and not on PEAP (only EAP inner methods).

-- 
Jouni Malinen                                            PGP id EFC895FA


From alex at digriz.org.uk  Sat Feb 20 10:22:01 2021
From: alex at digriz.org.uk (Alexander Clouter)
Date: Sat, 20 Feb 2021 15:22:01 +0000
Subject: [PATCH v2] PEAP peer: allow autheap for EAP-TLS phase2 support
In-Reply-To: <20210220142642.GA449838@w1.fi>
References: <20201016083101.2300-1-alex@digriz.org.uk>
 <20210220142642.GA449838@w1.fi>
Message-ID: <29b4c5bd-1683-4837-bc9a-0cf3af16f741@www.fastmail.com>

Hello,

On Sat, 20 Feb 2021, at 14:26, Jouni Malinen wrote:
> 
> I still do not understand why this would be needed. EAP-TLS as an inner
> method for PEAP has been supported for years with following:
> 
>     eap=PEAP
>     phase2="auth=TLS"
>     [snipped]
> 
> Sure, this is different compared to the EAP-TTLS special case, but the
> special case is on the EAP-TTLS side (both EAP and non-EAP inner
> methods) and not on PEAP (only EAP inner methods).

Thank you for showing me this, I can confirm it works perfectly for me, now I am surprised I missed this.

Please drop this patch from consideration.

Kind Regards

-- 
Alexander Clouter


From j at w1.fi  Sat Feb 20 11:25:02 2021
From: j at w1.fi (Jouni Malinen)
Date: Sat, 20 Feb 2021 18:25:02 +0200
Subject: [PATCH v3 0/2] EAP-{TTLS,PEAP} support (draft) for TLS 1.3
In-Reply-To: <20201016084935.22901-1-alex@digriz.org.uk>
References: <20201016084935.22901-1-alex@digriz.org.uk>
Message-ID: <20210220162502.GA864806@w1.fi>

On Fri, Oct 16, 2020 at 09:49:34AM +0100, Alexander Clouter wrote:
> Support TLS 1.3 for EAP-{TTLS,PEAP} as described in
> draft-ietf-emu-tls-eap-types and tested against FreeRADIUS[1].
> 
> [1] https://github.com/FreeRADIUS/freeradius-server/pull/3517

> Alexander Clouter (2):
>   EAP-TTLS/PEAP peer: fix failure when using session tickets under TLS 1.3
>   EAP peer/server: support for draft-ietf-emu-tls-eap-types-00

Thanks, applied with some cleanup. In particular, I split patch 2/2 into
smaller commits to make it easier to understand what is being changed. I
also replaced the references to the draft-ietf-emu-eap-tls13
draft to use the revision -13 explicitly instead of the latest version
since it looks like the Commitment Message implementation does not
really match what is there now in -14 that came out after these patches
were posted.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From alex at digriz.org.uk  Sat Feb 20 12:03:04 2021
From: alex at digriz.org.uk (Alexander Clouter)
Date: Sat, 20 Feb 2021 17:03:04 +0000
Subject: [PATCH v3 0/2] EAP-{TTLS,PEAP} support (draft) for TLS 1.3
In-Reply-To: <20210220162502.GA864806@w1.fi>
References: <20201016084935.22901-1-alex@digriz.org.uk>
 <20210220162502.GA864806@w1.fi>
Message-ID: <3591c461-9366-4cb9-84f8-f02ca1b3f6cf@www.fastmail.com>

Hello,

On Sat, 20 Feb 2021, at 16:25, Jouni Malinen wrote:
> On Fri, Oct 16, 2020 at 09:49:34AM +0100, Alexander Clouter wrote:
> > Support TLS 1.3 for EAP-{TTLS,PEAP} as described in
> > draft-ietf-emu-tls-eap-types and tested against FreeRADIUS[1].
> > 
> > [1] https://github.com/FreeRADIUS/freeradius-server/pull/3517
> 
> > Alexander Clouter (2):
> >   EAP-TTLS/PEAP peer: fix failure when using session tickets under TLS 1.3
> >   EAP peer/server: support for draft-ietf-emu-tls-eap-types-00
> 
> Thanks, applied with some cleanup. In particular, I split patch 2/2 into
> smaller commits to make it easier to understand what is being changed.

Thank you for this in particular where you put your time into fixing them up.

> I also replaced the references to the draft-ietf-emu-eap-tls13
> draft to use the revision -13 explicitly instead of the latest version
> since it looks like the Commitment Message implementation does not
> really match what is there now in -14 that came out after these patches
> were posted.

There is a lively debate underway on the emu mailing list on what to do here and no doubt soon I will need to update hostap to track further changes.

My understanding is that though replacing the commitment message (revision-13) with a SSL close_notify (revision-14) works for EAP-TLS, it makes things a little fruity for TTLS/PEAP especially around session resumption and how to signal types of errors (unknown CA, etc).

Time will tell, but I do plan to provide further patches once the dust settles to hostap; maybe like FreeRADIUS currently has where a configuration toggle to flip between these different signalling methods is offered. 

Regards

-- 
Alexander Clouter


From j at w1.fi  Sun Feb 21 07:11:06 2021
From: j at w1.fi (Jouni Malinen)
Date: Sun, 21 Feb 2021 14:11:06 +0200
Subject: Build error after radiotap update
In-Reply-To: <20210217004916.7693510b@linux.microsoft.com>
References: <20210217004916.7693510b@linux.microsoft.com>
Message-ID: <20210221121106.GA427780@w1.fi>

On Wed, Feb 17, 2021 at 12:53:05AM +0100, Matteo Croce wrote:
> After e6ac26943 ("radiotap: Update radiotap parser")
> I get this build error:

> /usr/bin/ld: build/hostapd/src/drivers/driver_nl80211_monitor.o:src/utils/radiotap.h:42: multiple definition of `__packed'; build/hostapd/src/drivers/driver_nl80211.o:src/utils/radiotap.h:42: first defined here

> I tried to replace __packed with __attribute__ ((__packed__)) and
> although it compiles, I have the following warning:
> 
> ../src/utils/radiotap.c: In function ?ieee80211_radiotap_iterator_init?:
> ../src/utils/radiotap.c:114:27: warning: taking address of packed member of ?struct ieee80211_radiotap_header? may result in an unaligned pointer value [-Waddress-of-packed-member]
>   114 |  iterator->_next_bitmap = &radiotap_header->it_present;

Interestingly, I did not see either of these in any of my normal build
setups.. Anyway, this is now fixed here:
https://w1.fi/cgit/hostap/commit/?id=10502ad59f918072057139a315e4cec84e17629f

-- 
Jouni Malinen                                            PGP id EFC895FA


From bgalvani at redhat.com  Mon Feb 22 05:43:31 2021
From: bgalvani at redhat.com (Beniamino Galvani)
Date: Mon, 22 Feb 2021 11:43:31 +0100
Subject: [PATCH] dbus: Export SAE capability
In-Reply-To: <20210219220724.GA97575@w1.fi>
References: <20210219145004.2130700-1-bgalvani@redhat.com>
 <20210219220724.GA97575@w1.fi>
Message-ID: <20210222104331.GA2195596@tp>

On Sat, Feb 20, 2021 at 12:07:24AM +0200, Jouni Malinen wrote:
> On Fri, Feb 19, 2021 at 03:50:04PM +0100, Beniamino Galvani wrote:
> > Export a new 'sae' capability to indicate that wpa_supplicant was
> > built with SAE support.
> 
> What would this be used for and why would the more complete SAE
> capability indication in wpas_dbus_getter_capabilities() not be better
> option for that use case? I would have expected it to be more valuable
> to know whether SAE can be used with a specific interface than whether
> wpa_supplicant build includes SAE support especially if that support
> cannot be used in practice.

You are right, please ignore my patch.

Beniamino
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/hostap/attachments/20210222/8523e3ec/attachment.sig>

From matthewmwang at chromium.org  Mon Feb 22 19:49:25 2021
From: matthewmwang at chromium.org (Matthew Wang)
Date: Mon, 22 Feb 2021 16:49:25 -0800
Subject: [PATCH] Reject auths during explicit roam requests
Message-ID: <20210223004925.342911-1-matthewmwang@chromium.org>

The roam D-Bus and wpa_cli commands flip the reassociate bit before
calling wpa_supplicant_connect. wpa_supplicant connect eventually aborts
ongoing scans, which causes scan results to be reported. Since the
reassociate bit is set, this will trigger a connection attempt based on
the aborted scan's scan results and cancel the initial connetion
request. This often causes wpa_supplicant to reassociate to the same AP
it is currently associated to.

Add a roam_in_progress flag to indicate that we're currently attempting
to roam via D-Bus so that we don't initate another connection attempt.

Signed-off-by: Matthew Wang <matthewmwang at chromium.org>
---
 wpa_supplicant/ctrl_iface.c             | 9 +++++++++
 wpa_supplicant/dbus/dbus_new_handlers.c | 9 +++++++++
 wpa_supplicant/sme.c                    | 7 +++++++
 wpa_supplicant/wpa_supplicant_i.h       | 1 +
 4 files changed, 26 insertions(+)

diff --git a/wpa_supplicant/ctrl_iface.c b/wpa_supplicant/ctrl_iface.c
index 0d4c2bc8f0b..c89be5d4482 100644
--- a/wpa_supplicant/ctrl_iface.c
+++ b/wpa_supplicant/ctrl_iface.c
@@ -5686,6 +5686,15 @@ static int wpa_supplicant_ctrl_iface_roam(struct wpa_supplicant *wpa_s,
 	wpa_s->reassociate = 1;
 	wpa_supplicant_connect(wpa_s, bss, ssid);
 
+	/*
+	 * Indicate that an explicitly requested roam is in progress so scan
+	 * results that come in before the 'sme-connect' radio work gets
+	 * executed do not override the original connection attempt.
+	 */
+	if (radio_work_pending(wpa_s, "sme-connect")) {
+		wpa_s->roam_in_progress = 1;
+	}
+
 	return 0;
 #endif /* CONFIG_NO_SCAN_PROCESSING */
 }
diff --git a/wpa_supplicant/dbus/dbus_new_handlers.c b/wpa_supplicant/dbus/dbus_new_handlers.c
index 7d20f2123a8..5ace9bd396d 100644
--- a/wpa_supplicant/dbus/dbus_new_handlers.c
+++ b/wpa_supplicant/dbus/dbus_new_handlers.c
@@ -2005,6 +2005,15 @@ DBusMessage * wpas_dbus_handler_roam(DBusMessage *message,
 	wpa_s->reassociate = 1;
 	wpa_supplicant_connect(wpa_s, bss, ssid);
 
+	/*
+	 * Indicate that an explicitly requested roam is in progress so scan
+	 * results that come in before the 'sme-connect' radio work gets
+	 * executed do not override the original connection attempt.
+	 */
+	if (radio_work_pending(wpa_s, "sme-connect")) {
+		wpa_s->roam_in_progress = 1;
+	}
+
 	return NULL;
 #endif /* CONFIG_NO_SCAN_PROCESSING */
 }
diff --git a/wpa_supplicant/sme.c b/wpa_supplicant/sme.c
index c6cef5b1447..4fd0c5e104f 100644
--- a/wpa_supplicant/sme.c
+++ b/wpa_supplicant/sme.c
@@ -941,6 +941,8 @@ static void sme_auth_start_cb(struct wpa_radio_work *work, int deinit)
 	struct wpa_connect_work *cwork = work->ctx;
 	struct wpa_supplicant *wpa_s = work->wpa_s;
 
+	wpa_s->roam_in_progress = 0;
+
 	if (deinit) {
 		if (work->started)
 			wpa_s->connect_work = NULL;
@@ -981,6 +983,11 @@ void sme_authenticate(struct wpa_supplicant *wpa_s,
 		return;
 	}
 
+	if (wpa_s->roam_in_progress) {
+		wpa_dbg(wpa_s, MSG_DEBUG,
+			"SME: Reject sme_authenticate() in favor of explicit roam request");
+		return;
+	}
 	if (radio_work_pending(wpa_s, "sme-connect")) {
 		/*
 		 * The previous sme-connect work might no longer be valid due to
diff --git a/wpa_supplicant/wpa_supplicant_i.h b/wpa_supplicant/wpa_supplicant_i.h
index 7d14b627d89..d15b5c6a4d1 100644
--- a/wpa_supplicant/wpa_supplicant_i.h
+++ b/wpa_supplicant/wpa_supplicant_i.h
@@ -621,6 +621,7 @@ struct wpa_supplicant {
 	u8 pending_bssid[ETH_ALEN]; /* If wpa_state == WPA_ASSOCIATING, this
 				     * field contains the target BSSID. */
 	int reassociate; /* reassociation requested */
+	int roam_in_progress; /* roam in progress */
 	unsigned int reassoc_same_bss:1; /* reassociating to the same BSS */
 	unsigned int reassoc_same_ess:1; /* reassociating to the same ESS */
 	int disconnected; /* all connections disabled; i.e., do no reassociate
-- 
2.30.0.617.g56c4b15f3c-goog



From andrei.otcheretianski at intel.com  Tue Feb 23 05:47:57 2021
From: andrei.otcheretianski at intel.com (Otcheretianski, Andrei)
Date: Tue, 23 Feb 2021 10:47:57 +0000
Subject: [PATCH v2 2/2] nl80211: use the process_bss_event for the
 nl_connect handler
In-Reply-To: <20210219224210.GB97575@w1.fi>
References: <SJ0PR11MB4941B7B5141CB028291278B1F58D9@SJ0PR11MB4941.namprd11.prod.outlook.com>
 <20210217101433.14673-2-andrei.otcheretianski@intel.com>
 <20210219224210.GB97575@w1.fi>
Message-ID: <SJ0PR11MB4941AE9A504A7F39486D697CF5809@SJ0PR11MB4941.namprd11.prod.outlook.com>

> On Wed, Feb 17, 2021 at 12:14:33PM +0200, Andrei Otcheretianski wrote:
> > diff --git a/src/drivers/driver_nl80211.c
> > b/src/drivers/driver_nl80211.c
> > +static int
> > +send_and_recv_msgs_connect_handle(struct wpa_driver_nl80211_data
> *drv,
> > +				  struct nl_msg *msg, struct i802_bss *bss) {
> > +	struct nl_sock *nl_connect = get_connect_handle(bss);
> > +
> > +	if (nl_connect)
> > +		return send_and_recv_msgs_owner(drv, msg, nl_connect, 1,
> > +						process_bss_event, bss,
> NULL,
> > +						NULL);
> 
> So this has set_owner hardcoded to 1 which matches most modified callers,
> but...
> 
> > @@ -10519,8 +10524,7 @@ static int
> wpa_driver_nl80211_leave_mesh(void
> > *priv)
> >
> >  	wpa_printf(MSG_DEBUG, "nl80211: mesh leave (ifindex=%d)", drv-
> >ifindex);
> >  	msg = nl80211_drv_msg(drv, 0, NL80211_CMD_LEAVE_MESH);
> > -	ret = send_and_recv_msgs_owner(drv, msg,
> get_connect_handle(bss), 0,
> > -				       NULL, NULL, NULL, NULL);
> > +	ret = send_and_recv_msgs_connect_handle(drv, msg, bss);
> 
> This one here uses set_owner == 0.. Is it really correct to replace that with 1?

After looking at nl80211 code, looks that these attributes are ignored for leave_mesh().. So I guess this should be ok.

Andrei
> 
> --
> Jouni Malinen                                            PGP id EFC895FA


From peter.malo at streamunlimited.com  Thu Feb 25 11:12:43 2021
From: peter.malo at streamunlimited.com (Peter Malo)
Date: Thu, 25 Feb 2021 17:12:43 +0100
Subject: Contribution
Message-ID: <9fa02715-f058-d71a-26df-c6007109bfee@streamunlimited.com>

Dear sir/madam,

I'm attaching a format-patch which extends the dbus interface.
I added sending some info about temporary disabling of ssid.

Best Regards,
Peter Malo

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-dbus-Add-SsidTempDisabled-signal.patch
Type: text/x-patch
Size: 5959 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/hostap/attachments/20210225/30d004b3/attachment.bin>

From peter.malo at streamunlimited.com  Thu Feb 25 11:38:46 2021
From: peter.malo at streamunlimited.com (Peter Malo)
Date: Thu, 25 Feb 2021 17:38:46 +0100
Subject: [PATCH] dbus: Add SsidTempDisabled signal
Message-ID: <acb6d3d2-47fa-2a66-d5a3-55458af38e97@streamunlimited.com>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-dbus-Add-SsidTempDisabled-signal.patch
Type: text/x-patch
Size: 5959 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/hostap/attachments/20210225/90fca63c/attachment.bin>

From orrmazor at gmail.com  Thu Feb 25 09:06:17 2021
From: orrmazor at gmail.com (Orr Mazor)
Date: Thu, 25 Feb 2021 16:06:17 +0200
Subject: [PATCH] Add an option to set secondary channel in hostapd conf
Message-ID: <20210225140617.18220-1-orr.mazor@tandemg.com>

Usefull in case we want to specify the secondary channel
or in case we want to be on 20mghz with 40mghz capabilities.

It is possible in chan_switch to set secondary channel,
however it was not possible to do so when hostapd start.
This commit adds this option.

Signed-off-by: Orr Mazor <orr.mazor at tandemg.com>
---
 hostapd/config_file.c | 9 +++++++--
 hostapd/hostapd.conf  | 8 ++++++++
 src/ap/ap_config.h    | 1 +
 3 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/hostapd/config_file.c b/hostapd/config_file.c
index 64704fb3d..4079fa5d5 100644
--- a/hostapd/config_file.c
+++ b/hostapd/config_file.c
@@ -1067,11 +1067,13 @@ static int hostapd_config_ht_capab(struct hostapd_config *conf,
 		conf->ht_capab |= HT_CAP_INFO_LDPC_CODING_CAP;
 	if (os_strstr(capab, "[HT40-]")) {
 		conf->ht_capab |= HT_CAP_INFO_SUPP_CHANNEL_WIDTH_SET;
-		conf->secondary_channel = -1;
+		if (!conf->secondary_channel_set)
+			conf->secondary_channel = -1;
 	}
 	if (os_strstr(capab, "[HT40+]")) {
 		conf->ht_capab |= HT_CAP_INFO_SUPP_CHANNEL_WIDTH_SET;
-		conf->secondary_channel = 1;
+		if (!conf->secondary_channel_set)
+			conf->secondary_channel = 1;
 	}
 	if (os_strstr(capab, "[HT40+]") && os_strstr(capab, "[HT40-]")) {
 		conf->ht_capab |= HT_CAP_INFO_SUPP_CHANNEL_WIDTH_SET;
@@ -3447,6 +3449,9 @@ static int hostapd_config_fill(struct hostapd_config *conf,
 				   line);
 			return 1;
 		}
+	} else if (os_strcmp(buf, "secondary_channel") == 0) {
+		conf->secondary_channel = atoi(pos);
+		conf->secondary_channel_set = 1;
 	} else if (os_strcmp(buf, "require_ht") == 0) {
 		conf->require_ht = atoi(pos);
 	} else if (os_strcmp(buf, "obss_interval") == 0) {
diff --git a/hostapd/hostapd.conf b/hostapd/hostapd.conf
index a3d28efed..769a06356 100644
--- a/hostapd/hostapd.conf
+++ b/hostapd/hostapd.conf
@@ -625,6 +625,14 @@ wmm_ac_vo_acm=0
 # Require stations to support HT PHY (reject association if they do not)
 #require_ht=1
 
+# secondary_channel: Set secondary channel offset manually
+# can be set to 1, 0 or -1
+# 1 - means the secondary channel will be 20mghz above primary channel
+# 0 - means the secondary channel is same as primary channel
+# -1 - means the secondary channel will be 20mghz below primary channel
+# (if not set here will be set automatically)
+#secondary_channel=0
+
 # If set non-zero, require stations to perform scans of overlapping
 # channels to test for stations which would be affected by 40 MHz traffic.
 # This parameter sets the interval in seconds between these scans. Setting this
diff --git a/src/ap/ap_config.h b/src/ap/ap_config.h
index 88200c688..6fa26a5a9 100644
--- a/src/ap/ap_config.h
+++ b/src/ap/ap_config.h
@@ -995,6 +995,7 @@ struct hostapd_config {
 	u16 ht_capab;
 	int ieee80211n;
 	int secondary_channel;
+	unsigned int secondary_channel_set:1;
 	int no_pri_sec_switch;
 	int require_ht;
 	int obss_interval;
-- 
2.17.1



From j at w1.fi  Thu Feb 25 14:03:03 2021
From: j at w1.fi (Jouni Malinen)
Date: Thu, 25 Feb 2021 21:03:03 +0200
Subject: wpa_supplicant P2P provision discovery processing vulnerability
Message-ID: <20210225190303.GA474115@w1.fi>

Published: February 25, 2021
Latest version available from: https://w1.fi/security/2021-1/


Vulnerability

A vulnerability was discovered in how wpa_supplicant processes P2P
(Wi-Fi Direct) provision discovery requests. Under a corner case
condition, an invalid Provision Discovery Request frame could end up
reaching a state where the oldest peer entry needs to be removed. With
a suitably constructed invalid frame, this could result in use
(read+write) of freed memory. This can result in an attacker within
radio range of the device running P2P discovery being able to cause
unexpected behavior, including termination of the wpa_supplicant process
and potentially code execution.


Vulnerable versions/configurations

wpa_supplicant v1.0-v2.9 with CONFIG_P2P build option enabled

An attacker (or a system controlled by the attacker) needs to be within
radio range of the vulnerable system to send a set of suitably
constructed management frames that trigger the corner case to be reached
in the management of the P2P peer table.


Possible mitigation steps

- Merge the following commit to wpa_supplicant and rebuild it:

  P2P: Fix a corner case in peer addition based on PD Request
  
  This patch is available from https://w1.fi/security/2021-1/
  
- Update to wpa_supplicant v2.10 or newer, once available

- Disable P2P (control interface command "P2P_SET disabled 1" or
  "p2p_disabled=1" in (each, if multiple interfaces used) wpa_supplicant
  configuration file)

- Disable P2P from the build (remove CONFIG_P2P=y)

-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Fri Feb 26 16:08:15 2021
From: j at w1.fi (Jouni Malinen)
Date: Fri, 26 Feb 2021 23:08:15 +0200
Subject: [PATCH] dbus: Add SsidTempDisabled signal
In-Reply-To: <acb6d3d2-47fa-2a66-d5a3-55458af38e97@streamunlimited.com>
References: <acb6d3d2-47fa-2a66-d5a3-55458af38e97@streamunlimited.com>
Message-ID: <20210226210815.GA508088@w1.fi>

On Thu, Feb 25, 2021 at 05:38:46PM +0100, Peter Malo wrote:
> diff --git a/doc/dbus.doxygen b/doc/dbus.doxygen
> +      <li>
> +	<h3>SsidTempDisabled ( s : ssid, u : auth_failures, s : reason )</h3>
> +	<p>Information about SSID being temporarily disabled.</p>
> +	<h4>Arguments</h4>
> +	<dl>
> +	  <dt>s : ssid</dt>
> +	  <dd>SSID of the network that has been temp disabled.</dd>
> +	  <dt>u : auth_failures</dt>
> +	  <dd>Number of authentication failures</dd>
> +	  <dt>s : reason</dt>
> +	  <dd>Reason for the disabling of the network e.g., "WRONG_KEY"</dd>
> +	</dl>
> +      </li>

This looks a bit strange.. Why would a D-Bus signal include the SSID?
Shouldn't this instead be identifying the network object that is being
temporarily disabled?

If there is a signal notifying that a network got temporarily disabled,
shouldn't there be a signal to notify that such temporarily disablement
was removed?

-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Fri Feb 26 16:16:20 2021
From: j at w1.fi (Jouni Malinen)
Date: Fri, 26 Feb 2021 23:16:20 +0200
Subject: [PATCH] Add an option to set secondary channel in hostapd conf
In-Reply-To: <20210225140617.18220-1-orr.mazor@tandemg.com>
References: <20210225140617.18220-1-orr.mazor@tandemg.com>
Message-ID: <20210226211620.GB508088@w1.fi>

On Thu, Feb 25, 2021 at 04:06:17PM +0200, Orr Mazor wrote:
> Usefull in case we want to specify the secondary channel
> or in case we want to be on 20mghz with 40mghz capabilities.
> 
> It is possible in chan_switch to set secondary channel,
> however it was not possible to do so when hostapd start.
> This commit adds this option.

Can you please clarify how this proposed new parameter differs from the
existing ht_capab=[HT40+], ht_capab=[HT40-], and ht_capab=[HT40+][HT40-]
options?

Please also note that the IEEE 802.11 standard has mandatory
requirements for 40 MHz co-existence on when the primary and secondary
channels have to be switched and I'm unlikely to accept changes
that would allow the user to bypass those requirements.

-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Fri Feb 26 16:25:30 2021
From: j at w1.fi (Jouni Malinen)
Date: Fri, 26 Feb 2021 23:25:30 +0200
Subject: [PATCH] Reject auths during explicit roam requests
In-Reply-To: <20210223004925.342911-1-matthewmwang@chromium.org>
References: <20210223004925.342911-1-matthewmwang@chromium.org>
Message-ID: <20210226212530.GC508088@w1.fi>

On Mon, Feb 22, 2021 at 04:49:25PM -0800, Matthew Wang wrote:
> The roam D-Bus and wpa_cli commands flip the reassociate bit before
> calling wpa_supplicant_connect. wpa_supplicant connect eventually aborts
> ongoing scans, which causes scan results to be reported. Since the
> reassociate bit is set, this will trigger a connection attempt based on
> the aborted scan's scan results and cancel the initial connetion
> request. This often causes wpa_supplicant to reassociate to the same AP
> it is currently associated to.
> 
> Add a roam_in_progress flag to indicate that we're currently attempting
> to roam via D-Bus so that we don't initate another connection attempt.

> diff --git a/wpa_supplicant/ctrl_iface.c b/wpa_supplicant/ctrl_iface.c
> @@ -5686,6 +5686,15 @@ static int wpa_supplicant_ctrl_iface_roam(struct wpa_supplicant *wpa_s,
> +	/*
> +	 * Indicate that an explicitly requested roam is in progress so scan
> +	 * results that come in before the 'sme-connect' radio work gets
> +	 * executed do not override the original connection attempt.
> +	 */
> +	if (radio_work_pending(wpa_s, "sme-connect")) {
> +		wpa_s->roam_in_progress = 1;
> +	}

Is this limited to "sme-connect" on purpose or should "connect" be
included as well? I understand the only user of wpa_s->roam_in_progress
in this patch is in sme.c, but is that really the only issue that this
tries to address or could the same issue with ignoring an explicit roam
request apply to drivers that use internal SME instead of the
wpa_supplicant/sme.c implementation with split authentication and
association steps?

> diff --git a/wpa_supplicant/sme.c b/wpa_supplicant/sme.c
> index c6cef5b1447..4fd0c5e104f 100644
> --- a/wpa_supplicant/sme.c
> +++ b/wpa_supplicant/sme.c
> @@ -941,6 +941,8 @@ static void sme_auth_start_cb(struct wpa_radio_work *work, int deinit)
>  	struct wpa_connect_work *cwork = work->ctx;
>  	struct wpa_supplicant *wpa_s = work->wpa_s;
>  
> +	wpa_s->roam_in_progress = 0;

This is now the only place where this new variable is reset to 0. Is
that sufficient? What if the roam attempt fails for some reason before
being able to reach the authentication step? Could this flag be
forgotten in place and could that cause issues for the future completely
unrelated connection attempt?

> @@ -981,6 +983,11 @@ void sme_authenticate(struct wpa_supplicant *wpa_s,
>  		return;
>  	}
>  
> +	if (wpa_s->roam_in_progress) {
> +		wpa_dbg(wpa_s, MSG_DEBUG,
> +			"SME: Reject sme_authenticate() in favor of explicit roam request");
> +		return;
> +	}

I.e., how would this recover from sme_auth_start_cb() not getting called
after the last roam request?

> diff --git a/wpa_supplicant/wpa_supplicant_i.h b/wpa_supplicant/wpa_supplicant_i.h
> +	int roam_in_progress; /* roam in progress */

The preferred type for new boolean variables is to use the C99 boolean
type through bool val = true/false.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Fri Feb 26 17:08:55 2021
From: j at w1.fi (Jouni Malinen)
Date: Sat, 27 Feb 2021 00:08:55 +0200
Subject: [PATCH 2/4] convert internal frequencies to KHz
In-Reply-To: <20200618061534.29646-3-thomas@adapt-ip.com>
References: <20200618061534.29646-1-thomas@adapt-ip.com>
 <20200618061534.29646-3-thomas@adapt-ip.com>
Message-ID: <20210226220855.GA508738@w1.fi>

On Wed, Jun 17, 2020 at 11:15:32PM -0700, Thomas Pedersen wrote:
> In preparation for supporting (S1G) channels centered on
> non-integer MHz, such as 902.5Mhz, convert nearly all
> internal frequency representations into units of KHz.

This is a huge patch and very likely to cause conflicts with any other
pending work.. That's one of the reasons why I did not really want to
even consider this while there was quite a few pending patches in the
queue. That situation is now better, so I can at least consider. Still,
it would be nice if this patch could be split into smaller pieces that
would go through interfaces in steps rather than everything at once.

> A conversion must be done when:
> 
> - parsing existing API, ie. control interface, dbus, etc.
> - parsing config files
> - sending driver commands
> - receiving driver events

That sounds reasonable.

> When the user input is a string, we parse the input as a
> MHz float, then convert to KHz. This will existing
> commands to work on S1G channels unchanged.

But I don't really want to see floating point types for frequencies.
Integers in kHz with helper functions for parsing might be OK, but
ideally, I would not see even a single float or atof() in this patch..

> When generating events and log messages, we exploit the
> "%g" format specifier which will drop the "." and
> trailing zeroes if the input does not have a fractional
> component. Similar to parsing user input this lets us
> expose fractional MHz frequencies without disturbing
> existing users.

Needing floating point numbers for printing out integer values looks
undesired.. I guess "freq=902.5" might be more convenient to see in many
places instead of something like freq_khz=902500, though.. Anyway,
generating that with "%u.%u" or "%u.%03u" for 902.500 might be simpler.

> While dbus, driver_bsd, driver_atheros, driver_hostap,
> driver_privsep, driver_wext, etc. have been converted
> based on 'git grep freq ...', they have received no
> testing :(. Suggestions, extra review, or help testing
> these are welcome.

This is one of the major issues here. Alternative approach would be to
introduce new frequency-in-kHz variables for the places that really need
this while leaving the existing -in-MHz variants available to avoid
regressions.

And on the editorial front, I'd prefer correct spelling of the SI
unit/prefix (kHz) instead of that Kelvin Herz thingie used here in most
places.. ;-)

> This commit should introduce no functional change.

Maybe so, but this is going to hugely inconvenient to review and show to
be correct.

-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Sat Feb 27 04:43:12 2021
From: j at w1.fi (Jouni Malinen)
Date: Sat, 27 Feb 2021 11:43:12 +0200
Subject: [PATCH] hostapd: Support SO_BINDTODEVICE for radius client.
In-Reply-To: <6c67751b-d0d8-bb76-9b88-a443d763c88e@gmail.com>
References: <20200513204812.28542-1-greearb@candelatech.com>
 <6c67751b-d0d8-bb76-9b88-a443d763c88e@gmail.com>
Message-ID: <20210227094312.GA408140@w1.fi>

On Fri, Jun 12, 2020 at 01:08:32PM +0200, Andreas Tobler wrote:
> thanks for this patch. We applied it locally and with some modifications we
> got it to work.
> 
> The most important modification for us was to move the 'force disconnect
> part', the one which follows after the client-addr bind, before we do the
> SO_BINDTODEVICE.
> If we do a connect with the disconnect_addr which has a sin_family
> AF_UNSPEC, we loose the SO_BINDTODEVICE on the socket.
> This is the reason we moved it right before we bind the device.
> 
> The second modification is the usage of setsockopt(). Your's was not wrong
> but irritating while reading the first time. We just use the devicename and
> its length for the 4th and 5th argument instead of the irfeq.
> 
> Attached the updated patch with our modifications.

Thanks, applied with fixes and cleanup.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Sat Feb 27 10:48:04 2021
From: j at w1.fi (Jouni Malinen)
Date: Sat, 27 Feb 2021 17:48:04 +0200
Subject: [PATCH] hostapd: Add ACS support for broadcom device
In-Reply-To: <59ffe473aef1756a2ed567e046a3f2ad@mail.gmail.com>
References: <59ffe473aef1756a2ed567e046a3f2ad@mail.gmail.com>
Message-ID: <20210227154804.GA822866@w1.fi>

On Sat, Jun 13, 2020 at 09:03:03AM +0800, Xinrui Sun wrote:
> BRCM vendor command used to trigger ACS scan. After ACS finished,
> DHD driver will send results by event BRCM_VENDOR_EVENT_ACS.

Thanks, applied with some cleanup.

-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Sat Feb 27 11:19:11 2021
From: j at w1.fi (Jouni Malinen)
Date: Sat, 27 Feb 2021 18:19:11 +0200
Subject: [RFC AP: ACS: select primary channel for 5G-band based on
 interference factor
In-Reply-To: <1603715517413.92611@itmh.ru>
References: <1603715517413.92611@itmh.ru>
Message-ID: <20210227161911.GA832750@w1.fi>

On Mon, Oct 26, 2020 at 12:31:59PM +0000, ?????? ?????? ????????????? wrote:
> Make ACS algorithm select the best channel within a bandwidth as primary
> channel instead of just picking the first one.
> 
> The reason i had to add acs_adjust_sec_chan is because even if i use VHT80
> ieee80211n_allowed_ht40_channel_pair -> allowed_ht40_channel_pair
> check fails and i get fallback to 20 MHz.

Can you please share hostapd debug logs for a case with and without this
patch highlighting why this is needed?

> diff --git a/src/ap/acs.c b/src/ap/acs.c
> +static void acs_adjust_sec_chan(struct hostapd_config *conf)
> +{
> +	const int ht40_plus_channels[] = { 36, 44, 52, 60, 100, 108, 116, 124, 132, 140,
> +								149, 157, 165, 184, 192 };
> +	int i, sec_chan = -1;
> +
> +	for (i = 0; i < ARRAY_SIZE(ht40_plus_channels); i++) {
> +		if (conf->channel == ht40_plus_channels[i]) {
> +		    sec_chan = 1;
> +		    break;
> +		}
> +	}
> +
> +	conf->secondary_channel = sec_chan;
>  }

So this function would force conf->secondary_channel to be != 0.

> @@ -961,8 +985,10 @@ static void acs_study(struct hostapd_iface *iface)
> -	if (iface->conf->ieee80211ac || iface->conf->ieee80211ax)
> +	if (iface->conf->ieee80211ac || iface->conf->ieee80211ax) {
>  		acs_adjust_center_freq(iface);
> +		acs_adjust_sec_chan(iface->conf);
> +	}

And it would be called unconditionally for VHT and HE.. Is that really
correct? What if the configuration is requesting 20 MHz channel
bandwidth to be used?

-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Sat Feb 27 13:01:36 2021
From: j at w1.fi (Jouni Malinen)
Date: Sat, 27 Feb 2021 20:01:36 +0200
Subject: [PATCH] p2p: pick 5g channel from more possible channels
In-Reply-To: <CALoVRkM57QVkEvrFNzDw=H4QGh4qhTa_atBGuKpt-4FF+PJdkQ@mail.gmail.com>
References: <CALoVRkM57QVkEvrFNzDw=H4QGh4qhTa_atBGuKpt-4FF+PJdkQ@mail.gmail.com>
Message-ID: <20210227180136.GA1632323@w1.fi>

On Mon, Oct 12, 2020 at 10:23:40AM +0800, Jimmy Chen wrote:
> There are more possible available channels for 5GHz currently.
> Especially in EU region, the operating class 115 channels are
> no longer available, but SRD channels (the operating class 124)
> are available.

Thanks, applied with some cleanup.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From markov.mikhail at itmh.ru  Sat Feb 27 13:41:31 2021
From: markov.mikhail at itmh.ru (=?koi8-r?B?7cHSy8/XIO3JyMHJzCDhzMXL08HOxNLP18ne?=)
Date: Sat, 27 Feb 2021 18:41:31 +0000
Subject: [RFC AP: ACS: select primary channel for 5G-band based on
 interference factor
In-Reply-To: <20210227161911.GA832750@w1.fi>
References: <1603715517413.92611@itmh.ru>,<20210227161911.GA832750@w1.fi>
Message-ID: <1614451291262.32484@itmh.ru>

>Can you please share hostapd debug logs for a case with and without this
>patch highlighting why this is needed?
With https://pastebin.com/WVeeBiDD
Without https://pastebin.com/VLZhJf3S
Both times VHT80 requested.

>And it would be called unconditionally for VHT and HE.. Is that really
>correct? What if the configuration is requesting 20 MHz channel
>bandwidth to be used?
I can not say for sure how would it work for HE, but if i use HT20 it
works correctly. Here is `iw dev' output:
phy#3
	Interface wlan1
		ifindex 12
		wdev 0x300000002
		addr 7a:f0:82:62:19:11
		ssid xxx
		type AP
		channel 40 (5200 MHz), width: 20 MHz, center1: 5200 MHz
		txpower 20.00 dBm
		multicast TXQ:
			qsz-byt	qsz-pkt	flows	drops	marks	...
			0	0	0	0	0

I do realize that setting "conf->secondary_channel to be != 0" could be
not the best decision, but `allowed_ht40_channel_pair' check messes
everything. That's why i tried to RFC.

From j at w1.fi  Sun Feb 28 04:22:31 2021
From: j at w1.fi (Jouni Malinen)
Date: Sun, 28 Feb 2021 11:22:31 +0200
Subject: [PATCH 2/6] Rewrite roaming logic
In-Reply-To: <CABRiz0rF-LF6rkQGOpxz4h84MhEvffbKujC_YGjm9EQ+1J7__g@mail.gmail.com>
References: <20200602001018.83640-1-matthewmwang@chromium.org>
 <20200602001018.83640-2-matthewmwang@chromium.org>
 <20200619152927.GA26140@w1.fi>
 <CABRiz0rOiQMDmBpci5HrC=Nz-3zAs_Hhc6WbFXtknp=BiTUmpw@mail.gmail.com>
 <CABRiz0rF-LF6rkQGOpxz4h84MhEvffbKujC_YGjm9EQ+1J7__g@mail.gmail.com>
Message-ID: <20210228092231.GA10281@w1.fi>

On Tue, Jun 23, 2020 at 02:41:19PM -0700, Matthew Wang wrote:
> Thanks for the response. I ran the prefer_ht20_during_roam test and it
> looks like it expects a roam from a non-HT AP at -30 dBm with 54 Mbps
> est_tpt to an HT AP at -30 dBm with 65 Mbps est_tpt. I'm not too clear
> on all the phy layer details of HT, but in my opinion, roaming from an
> AP at such a strong signal level (-30 dBm) needs a fairly strong
> justification, and a 20% increase (54 -> 65) in estimated throughput
> is not that strong. That being said, if there are benefits to moving
> from non-HT to HT that aren't captured in the {signal, est_tpt} pair,
> then I'd advocate for using a flag that behaves similarly to the
> to_{2,5}ghz flags, which adjusts the roaming difficulty up/down 2 dBm
> depending on the direction of the roam. We can assign some value for
> {to,from}_ht flags that subtracts from or adds to the roaming
> difficulty depending on how valuable HT vs non-HT is. Does this make
> sense?

That behavior is not limited to so high signal strength value. Same
happens with all other values and the impact is much more severe in some
cases. For example, with both APs at -86 dBm non-HT AP gets 2 Mbps
est_tpt and HT AP gets 8.666 Mbps. Still, roaming is prevented ("Skip
roam - too small difference in signal level (0 < 4)"). In other words,
even that min_diff -= 2 style adjustment that is given for to_5ghz would
not help here. In fact, it looks like this patch would make it
impossible to roam to an AP that shows better throughput estimate
(regardless of how large a difference) on the same band unless there is
also at least 4 dB increase in the signal level when cur_level < -85.
That does not look reasonable.

And yes, HT does come with possibility of using A-MPDU and A-MSDU
aggregation which can result in significant improvement in throughput
and airtime efficiency and that is in addition to the estimated
throughput values from TX rates. So it might indeed make sense to
add/subtract difficulty for roaming, but still, the main issue I see
here is in that behavior that seems to completely prevent roaming unless
signal level increases significantly regardless of other factors.

-- 
Jouni Malinen                                            PGP id EFC895FA


From nikolas at gnu.org  Sun Feb 28 23:19:26 2021
From: nikolas at gnu.org (Nikolas Nyby)
Date: Sun, 28 Feb 2021 23:19:26 -0500
Subject: [PATCH] Update old link to ACS wiki documentation
Message-ID: <20210301041926.539327-1-nikolas@gnu.org>

The old links here were broken.

Signed-off-by: Nikolas Nyby <nikolas at gnu.org>
---
 hostapd/defconfig    | 2 +-
 hostapd/hostapd.conf | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/hostapd/defconfig b/hostapd/defconfig
index cbdd2a55c..666447e4a 100644
--- a/hostapd/defconfig
+++ b/hostapd/defconfig
@@ -346,7 +346,7 @@ CONFIG_IPV6=y
 # * ath10k
 #
 # For more details refer to:
-# http://wireless.kernel.org/en/users/Documentation/acs
+# https://wireless.wiki.kernel.org/en/users/documentation/acs
 #
 #CONFIG_ACS=y
 
diff --git a/hostapd/hostapd.conf b/hostapd/hostapd.conf
index 8958abd16..842639649 100644
--- a/hostapd/hostapd.conf
+++ b/hostapd/hostapd.conf
@@ -171,7 +171,7 @@ channel=1
 #op_class=131
 
 # ACS tuning - Automatic Channel Selection
-# See: http://wireless.kernel.org/en/users/Documentation/acs
+# See: https://wireless.wiki.kernel.org/en/users/documentation/acs
 #
 # You can customize the ACS survey algorithm with following variables:
 #
-- 
2.25.1



