Received-SPF: pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH v3 2/2] mac80211: Allow deleting stations in ibss mode to
 reset their state
To:     Nicolas Cavallari <nicolas.cavallari@green-communications.fr>,
        Nicolas Cavallari <cavallar@lri.fr>,
        linux-wireless@vger.kernel.org
Cc:     Johannes Berg <johannes@sipsolutions.com>
References: <20200305135754.12094-1-cavallar@lri.fr>
 <20200305135754.12094-2-cavallar@lri.fr>
 <bc2934fe-ee0b-c593-e866-692487e06d4e@ncentric.com>
 <ff459a4c-9bf8-30e9-a486-86d171640e79@green-communications.fr>
From:   Koen Vandeputte <koen.vandeputte@ncentric.com>
Message-ID: <92b907d7-6ef2-e0e1-fad0-d3deca75f72b@ncentric.com>
Date:   Wed, 8 Apr 2020 17:02:17 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <ff459a4c-9bf8-30e9-a486-86d171640e79@green-communications.fr>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk


On 08.04.20 16:31, Nicolas Cavallari wrote:
> On 08/04/2020 13:56, Koen Vandeputte wrote:
>> Quick test setup overview:
>>
>> - Device mounted on top of a vessel, sailing around in windfarms.
>> - Lots of turbines are equiped with 4x 90deg sectors
>> - 802.11n HT40 2x2 custom mesh over IBSS, using Dynack
>> - As the vessel moves around,  IBSS links are continuously dropped and
>> re-added throughout the field
>> - Output of my app, fyi:  https://pastebin.com/raw/vtZSwHC9
>>
>> I've made 2 identical builds, one containing your patches and one without.
>>
>> When your patches are used:
>>
>> --> On devices with multiple radio's, all radio's went deaf within a few
>> minutes without any notice in logs.
>>
>> --> Only a reboot solved the issue but everything goes deaf again within
>> a few minutes. (after dropping/adding some links)
>>
>>
>> Any idea?
> I would highly suspect the hasty wpa_supplicant patch more than the
> kernel patches.
>
> I suppose you don't have any wpa_supplicant verbose logs ? (with the -dd
> option).
>
> I don't have physical access to any hardware given the current crisis,
> but if you could tell which kernel and wpa_supplicant version you
> applied the patch on, and whether you took the patches from the mailing
> list or from git including the cleanup patches.
>
> Also, which driver/card did you use ? I mainly tested this with ath9k
> with ar93xx.


hw used:

1) (moving)

- cns3xxx board (GW2388)

- 4x pci ar9220 (ath9k)

2)

- imx6

- 2x ar93xx (ath9k)

Sw:

OpenWrt 19.07

Kernel: 4.14.174

mac80211: 4.19.112

wpa sup: 2.9


The timeslots to play are short, so I cannot easily test manually for 
extra verbosity using wpa_sup.
Using tcpdump shows EAPOL packets being exchanged but I guess it fails 
somewhere there.
I used the kernel patches from mailinglist (V3).

If you could cook up a clean patch properly implementing the required 
bits over there, I would be happy to test it again.


Regards,

Koen