Wireless Daemon for Linux
 help / color / mirror / Atom feed
From: James Prestwood <prestwoj@gmail.com>
To: Mauro Condarelli <mc5686@mclink.it>, iwd@lists.linux.dev
Subject: Re: Setup help request
Date: Tue, 2 Jan 2024 05:01:39 -0800	[thread overview]
Message-ID: <b3c259af-ee4f-488c-ad81-a734302fc6d6@gmail.com> (raw)
In-Reply-To: <f477c1f4-4585-4b76-95a6-d0d31532e401@mclink.it>

[-- Attachment #1: Type: text/plain, Size: 8428 bytes --]

Hi Mauro,

On 1/1/24 4:34 PM, Mauro Condarelli wrote:
> Hi James,
> Thanks for the fast reply.
>
> Comments inline below.
>
> On 1/2/24 00:03, James Prestwood wrote:
>> Hi Mauro,
>>
>> On 1/1/24 11:26 AM, Mauro Condarelli wrote:
>>> Hi,
>>> I just installed `IWD version 2.3` on a small MiniPC (Beelink, if it 
>>> matters) sporting a
>>> `Intel Corporation Wireless 3165 (rev 81)` PCI Wireless adapter.
>>> O.S. is a fairly up-to-date "Debian GNU/Linux 12 (bookworm)"
>>> Installation was done via standard Debian package (`apt install iwd`)
>>> I am trying to use it as Access Point (infrastructure).
>>> I have in my config:
>>> ---------------------------------
>>> root@lxd:~# cat /etc/iwd/main.conf
>>> [General]
>>> EnableNetworkConfiguration=true
>>> #AddressRandomization=network
>>> #RoamThreshold=-70
>>> #RoamThreshold5G=-76
>>> [Network]
>>> #NameResolvingService=resolvconf
>>> #
>>> #EnableIPv6=true
>>> ---------------------------------
>>> root@lxd:~# cat /var/lib/iwd/ap/beelink.ap
>>> [Security]
>>> Passphrase=****************
>>>
>>> [IPv4]
>>> Address=192.168.250.1
>>> Gateway=192.168.250.1
>>> Netmask=255.255.255.0
>>> DNSList=8.8.8.8
>>> LeaseTime=3600
>>> IPRange=192.168.250.200,192.168.250.209
>>> root@lxd:~#
>>> ---------------------------------
>>>
>>> I am testing manually so I did:
>>>
>>> ---------------------------------
>>> root@lxd:/etc/systemd/network# /usr/libexec/iwd -d >/tmp/iwd.log 2>&1 &
>>> [1] 112842
>>> root@lxd:/etc/systemd/network# iwctl
>>> NetworkConfigurationEnabled: enabled
>>> StateDirectory: /var/lib/iwd
>>> Version: 2.3
>>> [iwd]# device list
>>> Devices                                   *
>>> -------------------------------------------------------------------------------- 
>>>
>>>   Name                  Address               Powered Adapter Mode
>>> -------------------------------------------------------------------------------- 
>>>
>>>   wlan0                 84:c5:a6:4c:ff:31     on phy0 ap
>>>
>>> [iwd]# device wlan0 set-property Mode ap
>>> [iwd]# ap wlan0 start-profile beelink
>>> [iwd]# ap wlan0 show
>>>                              Access Point Interface
>>> -------------------------------------------------------------------------------- 
>>>
>>>   Settable  Property              Value
>>> -------------------------------------------------------------------------------- 
>>>
>>>             Started               yes
>>>             Name                  beelink
>>>             Scanning              no
>>>             Frequency             2437
>>>             PairwiseCiphers
>>>             GroupCipher           CCMP-128
>>> [iwd]#
>>>
>>> [iwd]#
>>>
>>> root@lxd:/etc/systemd/network#
>>> ---------------------------------
>>>
>>> Sometimes I can see a "beelink" SSID with Fritz sniffer app
>>> or even from my desktop, but I was never able to connect.
>>
>> In the logs you see "Frame didn't validate as MMPDU". This means 
>> there was a malformed packet, or at least IWD thinks it was 
>> malformed. Could you get an iwmon capture while IWD is running and 
>> you attempt to connect with a client device? Also, have you tried 
>> connecting with several client devices (laptop, phone, etc)? That 
>> would tell us if its a specific client sending a bad frame, or a bug 
>> processing the frame. More info on how to do that here:
>>
>> https://iwd.wiki.kernel.org/debugging
>>
>> Note the capture will contain your devices MAC/SSID/PSK so if your 
>> worried about privacy you can send it just to me, or use a dummy 
>> passphrase just for the test, up to you.
> I used the following script to reproducibly start IWD and friends:
> ---------------------------------
> root@lxd:~# cat ./start_iwd.sh
> #!/bin/bash
>
> /usr/libexec/iwd -d >/tmp/iwd.log 2>&1 &
> IWD_PID=$!
>
> sleep 5
> iwctl device list
> iwctl device wlan0 set-property Mode ap
> iwctl ap wlan0 start-profile beelink
> iwctl ap wlan0 show
>
> iwmon --write /tmp/iwmon.pcap >/tmp/iwmon.log 2>&1 &
> IWMON_PID=$!
>
> mc
>
> kill $IWMON_PID
> kill $IWD_PID
> ---------------------------------
>
> While shell was active I:
> - opened Fritz! `WLAN` app
>   - it took ~30s to see a `beelink` network apparently spanning 
> several channels
> - tried to connect from my desktop
>   - it did see a `beelink` AP a long time (>2m) after `WLAN` app saw it.
>   - it tried several times to connect.
>   - it never succeeded.
>   - it didn't even ask for a passphrase.
> - tried to connect using my Android Phone (the ssame running `WLAN`.
>   - it never saw a `beelink` AP to attempt connection.
>
> I attach all logs I took.
> I changed password to "temp-password" so it can be shared as needed.

I think there is more going on but for starters it appears whatever app 
your using to scan is sending an invalid probe request frame. This 
causes IWD to ignore it which seems like the reason you cant even see 
the AP in the scans. I've attached a patch you can test, but I'm not 
sure this is something we can really upstream since its out of spec. The 
concerning IE is Extended capabilities, this is something IWD actually 
uses and parses, so the fact there is a duplicate and each one is 
different makes it impossible to know which one we should use. The probe 
request is including multiple entries for "Extended Capabilities" and 
"FILS Request Parameters (tag 258)". With the patch applied, and some 
other modifications to iwmon you can see two entries for these IEs:

                     Extended Capabilities: len 10
                         Capability: bit  2: Extended channel switching
                         Capability: bit 17: WNM-Sleep mode
                         Capability: bit 19: BSS transition
                         Capability: bit 25: SSID list
                         Capability: bit 46: WNM- Notification
                         Capability: bit 62: Opmode Notification
                         04 00 0a 02 00 40 00 40 80 
01                    .....@.@..
                     Tag 258: len 2
                         00 
12                                            ..
                     Extended Capabilities: len 10
                         Capability: bit 17: WNM-Sleep mode
                         Capability: bit 19: BSS transition
                         Capability: bit 25: SSID list
                         Capability: bit 46: WNM- Notification
                         00 00 0a 02 00 40 00 00 00 
01                    .....@....
                     Tag 258: len 2
                         00 ff

If this patch doesn't resolve the issue could you re-run the test and 
start iwmon at the very beginning, prior to starting IWD?

>
>>
>>>
>>> I attach logs I am unable to interpret.
>>>
>>> Any hint about what to check/change would be very welcome as
>>> I'm completely out of my depth here.
>>>
>>> Target would be to have (if at all possible, of course) a dual band 
>>> (2.4G/5G)
>>> bridged Access Point.
>>
>> Just a side note here, for a dual band access point you will actually 
>> need two separate adapters.
> Is this an IWD limitation or is it general?
> This adapter seems to have two independent radio channels.
> In `WLAN` app I see the `beelink` AP only in the 2.4GHz band.

This isn't IWD specific. If the card only has a single radio (phy) its 
limited to utilizing a single channel at a time. So you won't be able to 
simultaneously use 2.4 and 5GHz. Some modern cards do have multiple 
physical adapters within a single package, but they aren't generally 
what you find in consumer grade hardware. You would see two "Whiphy 
phyX" entries in "iw list" if this was the case for you.

Thanks,

James

>
>>
>>>
>>> Many Thanks in Advance.
>>> Mauro
>
> Thanks
> Mauro

[-- Attachment #2: 0001-TESTING-add-extended-capabilities-FILS-request-to-du.patch --]
[-- Type: text/x-patch, Size: 874 bytes --]

From 503a502931dcc737430a252186b84787e8a720e1 Mon Sep 17 00:00:00 2001
From: James Prestwood <prestwoj@gmail.com>
Date: Tue, 2 Jan 2024 04:50:21 -0800
Subject: [PATCH] TESTING: add extended capabilities/FILS request to duplicate
 IEs

---
 src/mpdu.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/mpdu.c b/src/mpdu.c
index 9d0409d2..dbb52c0b 100644
--- a/src/mpdu.c
+++ b/src/mpdu.c
@@ -393,7 +393,9 @@ static bool validate_mgmt_ies(const uint8_t *ies, size_t ies_len,
 				tag != IE_TYPE_MULTIPLE_BSSID &&
 				tag != IE_TYPE_NEIGHBOR_REPORT &&
 				tag != IE_TYPE_QUIET_CHANNEL &&
-				tag != IE_TYPE_FILS_HLP_CONTAINER) {
+				tag != IE_TYPE_FILS_HLP_CONTAINER &&
+				tag != IE_TYPE_EXTENDED_CAPABILITIES &&
+				tag != IE_TYPE_FILS_REQUEST_PARAMETERS) {
 			struct ie_tlv_iter clone;
 
 			memcpy(&clone, &iter, sizeof(clone));
-- 
2.34.1


  reply	other threads:[~2024-01-02 13:01 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-01 19:26 Setup help request Mauro Condarelli
2024-01-01 23:03 ` James Prestwood
2024-01-02  0:34   ` Mauro Condarelli
2024-01-02 13:01     ` James Prestwood [this message]
2024-01-02 14:07       ` Mauro Condarelli
2024-01-02 14:40         ` James Prestwood
2024-01-02 17:10           ` Denis Kenzior
2024-01-02 15:11         ` Mauro Condarelli
2024-01-02 15:36           ` James Prestwood
2024-01-02 17:09             ` Mauro Condarelli
2024-01-02 17:30               ` James Prestwood
2024-01-02 17:45                 ` Mauro Condarelli
2024-01-02 19:52                   ` James Prestwood
2024-01-02 20:30                     ` Mauro Condarelli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b3c259af-ee4f-488c-ad81-a734302fc6d6@gmail.com \
    --to=prestwoj@gmail.com \
    --cc=iwd@lists.linux.dev \
    --cc=mc5686@mclink.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox