* Setup help request
@ 2024-01-01 19:26 Mauro Condarelli
2024-01-01 23:03 ` James Prestwood
0 siblings, 1 reply; 14+ messages in thread
From: Mauro Condarelli @ 2024-01-01 19:26 UTC (permalink / raw)
To: iwd
[-- Attachment #1: Type: text/plain, Size: 2879 bytes --]
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.
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.
Many Thanks in Advance.
Mauro
[-- Attachment #2: iwd.log --]
[-- Type: text/x-log, Size: 11972 bytes --]
Wireless daemon version 2.3
src/main.c:main() Using configuration directory /etc/iwd
Loaded configuration from /etc/iwd/main.conf
src/storage.c:storage_create_dirs() Using state directory /var/lib/iwd
src/main.c:nl80211_appeared() Found nl80211 interface
src/module.c:iwd_modules_init()
src/wsc.c:wsc_init()
src/eap.c:__eap_method_enable()
src/eap-wsc.c:eap_wsc_init()
src/eap-md5.c:eap_md5_init()
src/eap-tls.c:eap_tls_init()
src/eap-ttls.c:eap_ttls_init()
src/eap-mschapv2.c:eap_mschapv2_init()
src/eap-sim.c:eap_sim_init()
src/eap-aka.c:eap_aka_prime_init()
src/eap-aka.c:eap_aka_init()
src/eap-peap.c:eap_peap_init()
src/eap-gtc.c:eap_gtc_init()
src/eap-pwd.c:eap_pwd_init()
src/manager.c:manager_wiphy_dump_callback() New wiphy phy0 added (0)
src/manager.c:manager_wiphy_dump_done()
src/manager.c:manager_filtered_wiphy_dump_done()
Wiphy: 0, Name: phy0
Permanent Address: 84:c5:a6:4c:ff:31
2.4Ghz Band:
Bitrates (non-HT):
1.0 Mbps
2.0 Mbps
5.5 Mbps
11.0 Mbps
6.0 Mbps
9.0 Mbps
12.0 Mbps
18.0 Mbps
24.0 Mbps
36.0 Mbps
48.0 Mbps
54.0 Mbps
HT Capabilities:
HT40
Short GI for 20Mhz
Short GI for 40Mhz
HT RX MCS indexes:
0-7
HT TX MCS differ, max NSS: 2
5Ghz Band:
Bitrates (non-HT):
6.0 Mbps
9.0 Mbps
12.0 Mbps
18.0 Mbps
24.0 Mbps
36.0 Mbps
48.0 Mbps
54.0 Mbps
HT Capabilities:
HT40
Short GI for 20Mhz
Short GI for 40Mhz
HT RX MCS indexes:
0-7
HT TX MCS differ, max NSS: 2
VHT Capabilities:
Short GI for 80Mhz
Max RX MCS: 0-9 for NSS: 1
Max TX MCS: 0-9 for NSS: 1
Ciphers: BIP-CMAC-128 CCMP-128 TKIP
Supported iftypes: ad-hoc station ap p2p-client p2p-go p2p-device
src/manager.c:manager_interface_dump_done()
src/manager.c:manager_create_interfaces() creating wlan0
src/manager.c:manager_create_interfaces() creating wlan0-p2p
src/wiphy.c:wiphy_update_reg_domain() New reg domain country code for phy0 is 00
src/manager.c:manager_config_notify() Notification of command New Interface(7)
src/netdev.c:netdev_link_notify() event 16 on ifindex 23
src/manager.c:manager_new_station_interface_cb()
src/netdev.c:netdev_create_from_genl() Created interface wlan0[23 e]
src/manager.c:manager_config_notify() Notification of command New Interface(7)
src/manager.c:manager_new_p2p_interface_cb()
src/p2p.c:p2p_device_update_from_genl() Created P2P device f
src/netdev.c:netdev_link_notify() event 16 on ifindex 23
src/wiphy.c:wiphy_reg_notify() Notification of command Wiphy Reg Change(113)
src/wiphy.c:wiphy_update_reg_domain() New reg domain country code for phy0 is XX
src/netdev.c:netdev_set_4addr() netdev: 23 use_4addr: 0
src/netdev.c:netdev_initial_up_cb() Interface 23 initialized
src/netconfig.c:netconfig_new() Creating netconfig for interface: 23
src/station.c:station_enter_state() Old State: disconnected, new state: autoconnect_quick
src/station.c:station_quick_scan_trigger() regdom is updating, delaying quick scan
src/rrm.c:rrm_add_frame_watches()
src/netdev.c:netdev_link_notify() event 16 on ifindex 23
src/station.c:station_enter_state() Old State: autoconnect_quick, new state: autoconnect_full
src/scan.c:scan_periodic_start() Starting periodic scan for wdev e
src/wiphy.c:wiphy_radio_work_insert() Inserting work item 1
src/wiphy.c:wiphy_radio_work_next() Starting work item 1
src/manager.c:manager_config_notify() Notification of command Set Interface(6)
src/scan.c:scan_notify() Scan notification Trigger Scan(33)
src/scan.c:scan_request_triggered() Passive scan triggered for wdev e
src/scan.c:scan_periodic_triggered() Periodic scan triggered for wdev e
src/netdev.c:netdev_link_notify() event 16 on ifindex 23
src/wiphy.c:wiphy_reg_notify() Notification of command Wiphy Reg Change(113)
src/wiphy.c:wiphy_update_reg_domain() New reg domain country code for phy0 is IT
src/scan.c:scan_notify() Scan notification New Scan Results(34)
src/netdev.c:netdev_link_notify() event 16 on ifindex 23
src/scan.c:get_scan_callback() get_scan_callback
src/scan.c:scan_parse_bss_information_elements() Load: 8/255
src/scan.c:get_scan_callback() get_scan_callback
src/scan.c:get_scan_callback() get_scan_callback
src/scan.c:get_scan_done() get_scan_done
src/scan.c:scan_periodic_rearm() Arming periodic scan timer: 10
src/station.c:station_add_seen_bss() Processing BSS '8e:fd:73:bc:fc:a6' with SSID: , freq: 5260, rank: 2955, strength: -3500, data_rate: 433.3
src/station.c:station_add_seen_bss() BSS has hidden SSID
src/station.c:station_add_seen_bss() Processing BSS '8e:fd:73:bc:fc:a4' with SSID: TIM-12904656, freq: 5260, rank: 2955, strength: -3500, data_rate: 433.3
src/station.c:station_add_seen_bss() Added new Network "TIM-12904656" security psk
src/station.c:station_add_seen_bss() Processing BSS '92:fd:73:bc:fc:a5' with SSID: TIM-12904656, freq: 2417, rank: 591, strength: -1700, data_rate: 72.2
src/station.c:station_autoconnect_start()
src/station.c:station_autoconnect_next() autoconnect: Trying SSID: TIM-12904656
src/station.c:station_autoconnect_next() autoconnect: '8e:fd:73:bc:fc:a4' freq: 5260, rank: 2955, strength: -3500
src/station.c:station_autoconnect_next() autoconnect: network_autoconnect: No such file or directory (-2)
src/wiphy.c:wiphy_radio_work_done() Work item 1 done
src/scan.c:get_scan_callback() get_scan_callback
src/scan.c:scan_parse_bss_information_elements() Load: 8/255
src/scan.c:get_scan_callback() get_scan_callback
src/scan.c:get_scan_callback() get_scan_callback
src/scan.c:get_scan_done() get_scan_done
src/scan.c:scan_periodic_rearm() Arming periodic scan timer: 10
src/station.c:station_add_seen_bss() Processing BSS '8e:fd:73:bc:fc:a6' with SSID: , freq: 5260, rank: 2955, strength: -3500, data_rate: 433.3
src/station.c:station_add_seen_bss() BSS has hidden SSID
src/station.c:station_add_seen_bss() Processing BSS '8e:fd:73:bc:fc:a4' with SSID: TIM-12904656, freq: 5260, rank: 2955, strength: -3500, data_rate: 433.3
src/station.c:station_add_seen_bss() Processing BSS '92:fd:73:bc:fc:a5' with SSID: TIM-12904656, freq: 2417, rank: 591, strength: -1700, data_rate: 72.2
src/station.c:station_autoconnect_start()
src/station.c:station_autoconnect_next() autoconnect: Trying SSID: TIM-12904656
src/station.c:station_autoconnect_next() autoconnect: '8e:fd:73:bc:fc:a4' freq: 5260, rank: 2955, strength: -3500
src/station.c:station_autoconnect_next() autoconnect: network_autoconnect: No such file or directory (-2)
src/scan.c:scan_periodic_timeout() e
src/wiphy.c:wiphy_radio_work_insert() Inserting work item 2
src/wiphy.c:wiphy_radio_work_next() Starting work item 2
src/scan.c:scan_notify() Scan notification Trigger Scan(33)
src/scan.c:scan_request_triggered() Passive scan triggered for wdev e
src/scan.c:scan_periodic_triggered() Periodic scan triggered for wdev e
src/scan.c:scan_notify() Scan notification New Scan Results(34)
src/netdev.c:netdev_link_notify() event 16 on ifindex 23
src/scan.c:get_scan_callback() get_scan_callback
src/scan.c:scan_parse_bss_information_elements() Load: 7/255
src/scan.c:get_scan_callback() get_scan_callback
src/scan.c:get_scan_callback() get_scan_callback
src/scan.c:get_scan_done() get_scan_done
src/scan.c:scan_periodic_rearm() Arming periodic scan timer: 20
src/station.c:station_add_seen_bss() Processing BSS '8e:fd:73:bc:fc:a6' with SSID: , freq: 5260, rank: 2955, strength: -3200, data_rate: 433.3
src/station.c:station_add_seen_bss() BSS has hidden SSID
src/station.c:station_add_seen_bss() Processing BSS '8e:fd:73:bc:fc:a4' with SSID: TIM-12904656, freq: 5260, rank: 2955, strength: -3200, data_rate: 433.3
src/station.c:station_add_seen_bss() Processing BSS '92:fd:73:bc:fc:a5' with SSID: TIM-12904656, freq: 2417, rank: 591, strength: -2400, data_rate: 72.2
src/station.c:station_autoconnect_start()
src/station.c:station_autoconnect_next() autoconnect: Trying SSID: TIM-12904656
src/station.c:station_autoconnect_next() autoconnect: '8e:fd:73:bc:fc:a4' freq: 5260, rank: 2955, strength: -3200
src/station.c:station_autoconnect_next() autoconnect: network_autoconnect: No such file or directory (-2)
src/wiphy.c:wiphy_radio_work_done() Work item 2 done
src/agent.c:agent_register() agent register called
src/agent.c:agent_register() agent :1.47 path /agent/112875
src/scan.c:scan_periodic_timeout() e
src/wiphy.c:wiphy_radio_work_insert() Inserting work item 3
src/wiphy.c:wiphy_radio_work_next() Starting work item 3
src/scan.c:scan_notify() Scan notification Trigger Scan(33)
src/scan.c:scan_request_triggered() Passive scan triggered for wdev e
src/scan.c:scan_periodic_triggered() Periodic scan triggered for wdev e
src/scan.c:scan_notify() Scan notification New Scan Results(34)
src/scan.c:get_scan_callback() get_scan_callback
src/scan.c:scan_parse_bss_information_elements() Load: 8/255
src/scan.c:get_scan_callback() get_scan_callback
src/scan.c:get_scan_callback() get_scan_callback
src/scan.c:get_scan_done() get_scan_done
src/scan.c:scan_periodic_rearm() Arming periodic scan timer: 40
src/station.c:station_add_seen_bss() Processing BSS '8e:fd:73:bc:fc:a6' with SSID: , freq: 5260, rank: 2955, strength: -3500, data_rate: 433.3
src/station.c:station_add_seen_bss() BSS has hidden SSID
src/station.c:station_add_seen_bss() Processing BSS '8e:fd:73:bc:fc:a4' with SSID: TIM-12904656, freq: 5260, rank: 2955, strength: -3500, data_rate: 433.3
src/station.c:station_add_seen_bss() Processing BSS '92:fd:73:bc:fc:a5' with SSID: TIM-12904656, freq: 2417, rank: 591, strength: -1700, data_rate: 72.2
src/station.c:station_autoconnect_start()
src/station.c:station_autoconnect_next() autoconnect: Trying SSID: TIM-12904656
src/station.c:station_autoconnect_next() autoconnect: '8e:fd:73:bc:fc:a4' freq: 5260, rank: 2955, strength: -3500
src/station.c:station_autoconnect_next() autoconnect: network_autoconnect: No such file or directory (-2)
src/wiphy.c:wiphy_radio_work_done() Work item 3 done
src/netdev.c:netdev_link_notify() event 16 on ifindex 23
src/netdev.c:netdev_link_notify() event 16 on ifindex 23
src/station.c:station_free()
src/netconfig.c:netconfig_destroy()
src/scan.c:scan_periodic_stop() Stopping periodic scan for wdev e
src/station.c:station_roam_state_clear() 23
src/netdev.c:netdev_set_interface_event() Interface type changed from station to ap
src/manager.c:manager_config_notify() Notification of command Set Interface(6)
src/netdev.c:netdev_link_notify() event 16 on ifindex 23
src/wiphy.c:wiphy_reg_notify() Notification of command Wiphy Reg Change(113)
src/wiphy.c:wiphy_update_reg_domain() New reg domain country code for phy0 is XX
src/ap.c:ap_validate_band_channel() AP using frequency 2437 and channel width 40MHz
src/netdev.c:netdev_link_notify() event 16 on ifindex 23
src/netdev.c:netdev_link_notify() event 16 on ifindex 23
src/netdev.c:netdev_link_notify() event 16 on ifindex 23
Frame didn't validate as MMPDU
src/netdev.c:netdev_unicast_notify() Unicast notification Frame(59)
Frame didn't validate as MMPDU
src/agent.c:agent_disconnect() agent :1.47 disconnected
src/agent.c:agent_free() agent free 0x5573bef1e6d0
Terminate
src/netdev.c:netdev_free() Freeing netdev wlan0[23]
src/device.c:device_free()
Removing scan context for wdev e
src/scan.c:scan_context_free() sc: 0x5573bef16be0
src/netdev.c:netdev_link_notify() event 16 on ifindex 23
src/netdev.c:netdev_mlme_notify() MLME notification Stop AP(16)
src/module.c:iwd_modules_exit()
src/eap.c:__eap_method_disable()
src/eap-wsc.c:eap_wsc_exit()
src/eap-md5.c:eap_md5_exit()
src/eap-tls.c:eap_tls_exit()
src/eap-ttls.c:eap_ttls_exit()
src/eap-mschapv2.c:eap_mschapv2_exit()
src/eap-sim.c:eap_sim_exit()
src/eap-aka.c:eap_aka_prime_exit()
src/eap-aka.c:eap_aka_exit()
src/eap-peap.c:eap_peap_exit()
src/eap-gtc.c:eap_gtc_exit()
src/eap-pwd.c:eap_pwd_exit()
src/dpp.c:dpp_exit()
src/offchannel.c:offchannel_exit()
Removing scan context for wdev f
src/scan.c:scan_context_free() sc: 0x5573bef15290
src/wsc.c:wsc_exit()
src/wiphy.c:wiphy_free() Freeing wiphy phy0[0]
D-Bus disconnected, quitting...
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Setup help request
2024-01-01 19:26 Setup help request Mauro Condarelli
@ 2024-01-01 23:03 ` James Prestwood
2024-01-02 0:34 ` Mauro Condarelli
0 siblings, 1 reply; 14+ messages in thread
From: James Prestwood @ 2024-01-01 23:03 UTC (permalink / raw)
To: Mauro Condarelli, iwd
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 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.
>
> Many Thanks in Advance.
> Mauro
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Setup help request
2024-01-01 23:03 ` James Prestwood
@ 2024-01-02 0:34 ` Mauro Condarelli
2024-01-02 13:01 ` James Prestwood
0 siblings, 1 reply; 14+ messages in thread
From: Mauro Condarelli @ 2024-01-02 0:34 UTC (permalink / raw)
To: James Prestwood, iwd
[-- Attachment #1: Type: text/plain, Size: 5253 bytes --]
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 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.
>
>>
>> Many Thanks in Advance.
>> Mauro
Thanks
Mauro
[-- Attachment #2: iw.tar.xz --]
[-- Type: application/x-xz, Size: 8544 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Setup help request
2024-01-02 0:34 ` Mauro Condarelli
@ 2024-01-02 13:01 ` James Prestwood
2024-01-02 14:07 ` Mauro Condarelli
0 siblings, 1 reply; 14+ messages in thread
From: James Prestwood @ 2024-01-02 13:01 UTC (permalink / raw)
To: Mauro Condarelli, iwd
[-- 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
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: Setup help request
2024-01-02 13:01 ` James Prestwood
@ 2024-01-02 14:07 ` Mauro Condarelli
2024-01-02 14:40 ` James Prestwood
2024-01-02 15:11 ` Mauro Condarelli
0 siblings, 2 replies; 14+ messages in thread
From: Mauro Condarelli @ 2024-01-02 14:07 UTC (permalink / raw)
To: James Prestwood, iwd
Thanks James,
comments inline below.
On 1/2/24 14:01, James Prestwood wrote:
> 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`)
>>>> ======8<----------- SNIP
>> 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'll do it ASAP, but it will take a bit of time since I'll have to compile from sources (I installed from standard Debian package).
Notice I'm not using anything "strange" for scans:
- normal Debian Sid Network Manager applet from desktop (which sees "beelink")
- normal Android phone `WiFi` Settings from phone (MIUI 12.0.3 on POCOPHONE F1, if relevant) (does *not* see "beelink")
Both are working as expected with several other Access Points.
It seems (to my limited insight) unlikely they're sending invalid probe requests.
>>>>
>>>> ======8<----------- SNIP
>>>>
Thanks
Mauro
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Setup help request
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
1 sibling, 1 reply; 14+ messages in thread
From: James Prestwood @ 2024-01-02 14:40 UTC (permalink / raw)
To: Mauro Condarelli, iwd
Hi Mauro,
On 1/2/24 6:07 AM, Mauro Condarelli wrote:
> Thanks James,
> comments inline below.
>
> On 1/2/24 14:01, James Prestwood wrote:
>> 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`)
>>>>> ======8<----------- SNIP
>>> 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'll do it ASAP, but it will take a bit of time since I'll have to
> compile from sources (I installed from standard Debian package).
>
> Notice I'm not using anything "strange" for scans:
> - normal Debian Sid Network Manager applet from desktop (which sees
> "beelink")
> - normal Android phone `WiFi` Settings from phone (MIUI 12.0.3 on
> POCOPHONE F1, if relevant) (does *not* see "beelink")
> Both are working as expected with several other Access Points.
> It seems (to my limited insight) unlikely they're sending invalid
> probe requests.
I'll need to look more at the spec to determine if this is "illegal"
(for lack of a better term) to duplicate these IEs. There are some IEs
that we allow duplicates of (which you can see in that patch). With a
simple search I cant find anything in the spec that disallows duplicates
specifically, but we have this comment in IWD:
"Tag found, make sure no duplicates present unless allowed"
Denis, any idea where that comes from off the top of your head?
Thanks,
James
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Setup help request
2024-01-02 14:07 ` Mauro Condarelli
2024-01-02 14:40 ` James Prestwood
@ 2024-01-02 15:11 ` Mauro Condarelli
2024-01-02 15:36 ` James Prestwood
1 sibling, 1 reply; 14+ messages in thread
From: Mauro Condarelli @ 2024-01-02 15:11 UTC (permalink / raw)
To: James Prestwood, iwd
[-- Attachment #1: Type: text/plain, Size: 3426 bytes --]
Thanks James,
comments inline below.
SNIP!
On 1/2/24 15:07, Mauro Condarelli wrote:
> On 1/2/24 14:01, James Prestwood wrote:
>> 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'll do it ASAP, but it will take a bit of time since I'll have to compile from sources (I installed from standard Debian package).
Done.
Only change in behavior was smartphone could see `beelink`, but not to connect to it (no password asked)
This means now my two (standard) clients behave in the same way.
I also changed my start script as follows:
-------------------------
#!/bin/bash
iwmon --write /tmp/iwmon.pcap >/tmp/iwmon.log 2>&1 &
IWMON_PID=$!
/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
mc
kill $IWMON_PID
kill $IWD_PID
cd /tmp
tar cJf iw.tar.xz iwmon.pcap iwmon.log iwd.log
-------------------------
I attach logs.
Sorry being a continued nuisance.
Mauro
[-- Attachment #2: iw.tar.xz --]
[-- Type: application/x-xz, Size: 23184 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Setup help request
2024-01-02 15:11 ` Mauro Condarelli
@ 2024-01-02 15:36 ` James Prestwood
2024-01-02 17:09 ` Mauro Condarelli
0 siblings, 1 reply; 14+ messages in thread
From: James Prestwood @ 2024-01-02 15:36 UTC (permalink / raw)
To: Mauro Condarelli, iwd
Hi Mauro,
On 1/2/24 7:11 AM, Mauro Condarelli wrote:
> Thanks James,
> comments inline below.
>
> SNIP!
>
> On 1/2/24 15:07, Mauro Condarelli wrote:
>> On 1/2/24 14:01, James Prestwood wrote:
>>> 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'll do it ASAP, but it will take a bit of time since I'll have to
>> compile from sources (I installed from standard Debian package).
> Done.
> Only change in behavior was smartphone could see `beelink`, but not to
> connect to it (no password asked)
> This means now my two (standard) clients behave in the same way.
Ok, so I'm not seeing any request to even connect from the AP side of
things. Since your clients aren't even asking for a password I suspect
it thinks there is some issue with compatibility. You could try using
hostapd with a very basic configuration and see if that works, then we
can go from there:
hw_mode=g
channel=1
ssid=testssid
wpa=1
wpa_pairwise=TKIP
wpa_passphrase=secret123
>
> I also changed my start script as follows:
> -------------------------
> #!/bin/bash
>
> iwmon --write /tmp/iwmon.pcap >/tmp/iwmon.log 2>&1 &
> IWMON_PID=$!
> /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
>
> mc
>
> kill $IWMON_PID
> kill $IWD_PID
>
> cd /tmp
> tar cJf iw.tar.xz iwmon.pcap iwmon.log iwd.log
> -------------------------
>
> I attach logs.
>
> Sorry being a continued nuisance.
No worries, its all part of the process. AP mode in IWD is still
experimental, there are obviously kinks to work out still.
> Mauro
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Setup help request
2024-01-02 15:36 ` James Prestwood
@ 2024-01-02 17:09 ` Mauro Condarelli
2024-01-02 17:30 ` James Prestwood
0 siblings, 1 reply; 14+ messages in thread
From: Mauro Condarelli @ 2024-01-02 17:09 UTC (permalink / raw)
To: James Prestwood, iwd
Thanks James,
comments inline below.
On 1/2/24 16:36, James Prestwood wrote:
> Hi Mauro,
>
> On 1/2/24 7:11 AM, Mauro Condarelli wrote:
>> SNIP!
>>
>
> Ok, so I'm not seeing any request to even connect from the AP side of things. Since your clients aren't even asking for a password I suspect it thinks there is some issue with compatibility. You could try using hostapd with a very basic configuration and see if that works, then we can go from there:
>
> hw_mode=g
> channel=1
> ssid=testssid
>
> wpa=1
> wpa_pairwise=TKIP
> wpa_passphrase=secret123
>
I had to add `interface=wlan0`, but that works... almost.
It actually asks for password, connects and then fails because there's (currently) no DHCP active (so no IP).
I think that's expected.
Behavior is the same with both clients.
Do you have any further suggestions?
TiA!
Mauro
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Setup help request
2024-01-02 14:40 ` James Prestwood
@ 2024-01-02 17:10 ` Denis Kenzior
0 siblings, 0 replies; 14+ messages in thread
From: Denis Kenzior @ 2024-01-02 17:10 UTC (permalink / raw)
To: James Prestwood, Mauro Condarelli, iwd
Hi James,
>
> I'll need to look more at the spec to determine if this is "illegal" (for lack
> of a better term) to duplicate these IEs. There are some IEs that we allow
> duplicates of (which you can see in that patch). With a simple search I cant
> find anything in the spec that disallows duplicates specifically, but we have
> this comment in IWD:
>
> "Tag found, make sure no duplicates present unless allowed"
>
> Denis, any idea where that comes from off the top of your head?
802.11 allows some IEs to be duplicated. For example, see verbiage in
802.11-2020 Section 9.3.2 dealing with Beacons:
"One or more Multiple BSSID elements are present if"...
"One or more Emergency Alert Identifier elements are present if"...
"One or more Emergency Alert Identifier elements are present if"...
"One or more Vendor Specific elements are optionally present. These..."
Regards,
-Denis
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Setup help request
2024-01-02 17:09 ` Mauro Condarelli
@ 2024-01-02 17:30 ` James Prestwood
2024-01-02 17:45 ` Mauro Condarelli
0 siblings, 1 reply; 14+ messages in thread
From: James Prestwood @ 2024-01-02 17:30 UTC (permalink / raw)
To: Mauro Condarelli, iwd
On 1/2/24 9:09 AM, Mauro Condarelli wrote:
> Thanks James,
> comments inline below.
>
>
> On 1/2/24 16:36, James Prestwood wrote:
>> Hi Mauro,
>>
>> On 1/2/24 7:11 AM, Mauro Condarelli wrote:
>>> SNIP!
>>>
>>
>> Ok, so I'm not seeing any request to even connect from the AP side of
>> things. Since your clients aren't even asking for a password I
>> suspect it thinks there is some issue with compatibility. You could
>> try using hostapd with a very basic configuration and see if that
>> works, then we can go from there:
>>
>> hw_mode=g
>> channel=1
>> ssid=testssid
>>
>> wpa=1
>> wpa_pairwise=TKIP
>> wpa_passphrase=secret123
>>
> I had to add `interface=wlan0`, but that works... almost.
>
> It actually asks for password, connects and then fails because there's
> (currently) no DHCP active (so no IP).
> I think that's expected.
> Behavior is the same with both clients.
>
> Do you have any further suggestions?
Ok perfect, at least it connected. Could you run iwmon before hostapd
and connect (same as you did with IWD), and send me those pcaps/logs.
I'll be able to compare and see what its doing differently.
>
> TiA!
> Mauro
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Setup help request
2024-01-02 17:30 ` James Prestwood
@ 2024-01-02 17:45 ` Mauro Condarelli
2024-01-02 19:52 ` James Prestwood
0 siblings, 1 reply; 14+ messages in thread
From: Mauro Condarelli @ 2024-01-02 17:45 UTC (permalink / raw)
To: James Prestwood, iwd
[-- Attachment #1: Type: text/plain, Size: 1432 bytes --]
On 1/2/24 18:30, James Prestwood wrote:
>
> On 1/2/24 9:09 AM, Mauro Condarelli wrote:
>> Thanks James,
>> comments inline below.
>>
>>
>> On 1/2/24 16:36, James Prestwood wrote:
>>> Hi Mauro,
>>>
>>> On 1/2/24 7:11 AM, Mauro Condarelli wrote:
>>>> SNIP!
>>>>
>>>
>>> Ok, so I'm not seeing any request to even connect from the AP side of things. Since your clients aren't even asking for a password I suspect it thinks there is some issue with compatibility. You could try using hostapd with a very basic configuration and see if that works, then we can go from there:
>>>
>>> hw_mode=g
>>> channel=1
>>> ssid=testssid
>>>
>>> wpa=1
>>> wpa_pairwise=TKIP
>>> wpa_passphrase=secret123
>>>
>> I had to add `interface=wlan0`, but that works... almost.
>>
>> It actually asks for password, connects and then fails because there's (currently) no DHCP active (so no IP).
>> I think that's expected.
>> Behavior is the same with both clients.
>>
>> Do you have any further suggestions?
>
> Ok perfect, at least it connected. Could you run iwmon before hostapd and connect (same as you did with IWD), and send me those pcaps/logs. I'll be able to compare and see what its doing differently.
I changed the script to:
#!/bin/bash
iwmon --write /tmp/iwmon.pcap >/tmp/iwmon.log 2>&1 &
IWMON_PID=$!
systemctl start hostapd
mc
systemctl stop hostapd
kill $IWMON_PID
cd /tmp
tar cJf iw.tar.xz iwmon.pcap iwmon.log
>
>>
>> TiA!
>> Mauro
>
[-- Attachment #2: iw.tar.xz --]
[-- Type: application/x-xz, Size: 23172 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Setup help request
2024-01-02 17:45 ` Mauro Condarelli
@ 2024-01-02 19:52 ` James Prestwood
2024-01-02 20:30 ` Mauro Condarelli
0 siblings, 1 reply; 14+ messages in thread
From: James Prestwood @ 2024-01-02 19:52 UTC (permalink / raw)
To: Mauro Condarelli, iwd
Hi Mauro,
On 1/2/24 9:45 AM, Mauro Condarelli wrote:
>
>
> On 1/2/24 18:30, James Prestwood wrote:
>>
>> On 1/2/24 9:09 AM, Mauro Condarelli wrote:
>>> Thanks James,
>>> comments inline below.
>>>
>>>
>>> On 1/2/24 16:36, James Prestwood wrote:
>>>> Hi Mauro,
>>>>
>>>> On 1/2/24 7:11 AM, Mauro Condarelli wrote:
>>>>> SNIP!
>>>>>
>>>>
>>>> Ok, so I'm not seeing any request to even connect from the AP side
>>>> of things. Since your clients aren't even asking for a password I
>>>> suspect it thinks there is some issue with compatibility. You could
>>>> try using hostapd with a very basic configuration and see if that
>>>> works, then we can go from there:
>>>>
>>>> hw_mode=g
>>>> channel=1
>>>> ssid=testssid
>>>>
>>>> wpa=1
>>>> wpa_pairwise=TKIP
>>>> wpa_passphrase=secret123
>>>>
>>> I had to add `interface=wlan0`, but that works... almost.
>>>
>>> It actually asks for password, connects and then fails because
>>> there's (currently) no DHCP active (so no IP).
>>> I think that's expected.
>>> Behavior is the same with both clients.
>>>
>>> Do you have any further suggestions?
>>
>> Ok perfect, at least it connected. Could you run iwmon before hostapd
>> and connect (same as you did with IWD), and send me those pcaps/logs.
>> I'll be able to compare and see what its doing differently.
> I changed the script to:
>
> #!/bin/bash
>
> iwmon --write /tmp/iwmon.pcap >/tmp/iwmon.log 2>&1 &
> IWMON_PID=$!
> systemctl start hostapd
>
> mc
>
> systemctl stop hostapd
> kill $IWMON_PID
>
> cd /tmp
> tar cJf iw.tar.xz iwmon.pcap iwmon.log
Thanks for doing this. I do see some slight differences between hostapd
and IWD but its difficult to know exactly what is causing the problem.
Hostapd is very old compared to IWD and has had a lot of time to get
working with every possible driver and client device. This also means
there is a lot of extra cruft that has no effect anymore. I hate to
"mimic" hostapd to a tee because it would likely add unnecessary bloat.
What client devices are you using to connect? Also, what wifi hardware
is in your beelink miniPC? maybe I have something similar I can try and
replicate the issue.
For the time being it may be easier to use hostapd for your specific
needs. As I said AP mode is experimental in IWD, and my day-to-day work
priorities aren't really with AP mode. I can poke around with it on the
side, and maybe provide patches to try out sometime in the future.
Thanks,
James
>
>
>>
>>>
>>> TiA!
>>> Mauro
>>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Setup help request
2024-01-02 19:52 ` James Prestwood
@ 2024-01-02 20:30 ` Mauro Condarelli
0 siblings, 0 replies; 14+ messages in thread
From: Mauro Condarelli @ 2024-01-02 20:30 UTC (permalink / raw)
To: James Prestwood, iwd
On 1/2/24 20:52, James Prestwood wrote:
> Hi Mauro,
>
> Thanks for doing this. I do see some slight differences between hostapd and IWD but its difficult to know exactly what is causing the problem. Hostapd is very old compared to IWD and has had a lot of time to get working with every possible driver and client device. This also means there is a lot of extra cruft that has no effect anymore. I hate to "mimic" hostapd to a tee because it would likely add unnecessary bloat. What client devices are you using to connect? Also, what wifi hardware is in your beelink miniPC? maybe I have something similar I can try and replicate the issue.
>
> For the time being it may be easier to use hostapd for your specific needs. As I said AP mode is experimental in IWD, and my day-to-day work priorities aren't really with AP mode. I can poke around with it on the side, and maybe provide patches to try out sometime in the future.
>
> Thanks,
>
> James
Thanks James.
I am using standard Debian (Sid) NetworkManager client on Linux and Android client on my smartphone for testing,
but target is to provide generic network access to whoever is in range (and allowed, of course), from family devices
to security cameras.
I am already digging into hostapd, but I always wanted to promote IWD, as much as possible, so I *will* be available
for testing if you will need it.
For reference:
- my "Beelink" has `02:00.0 Network controller: Intel Corporation Wireless 3165 (rev 81)` on PCIe.
- this miniPC is used as network frontend sporting a OPNsense VM firewall and a couple of "server containers"
on DMZ, all of this virtualized under Incus (which could add noise to the issue).
- target would be to add a bridged AP connected to interface going to my internal LAN.
Thanks for all your good work and feel free to contact directly me if you need some "independent testing".
Have a Very Happy New Year!
Mauro
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2024-01-02 20:45 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.