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
next prev parent 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