Closed bdantas closed 1 year ago
I suspect the issue is that iw detects this particular AP but the new iwd does not detect it. If that's the case, the problem may have to do with how ARWCVisitor broadcasts its ssid rather than with the fact that it is an open network. But it's just a guess. I'm stuck at this point.
Hi. Could you try to reproduce the bug in original iwd(that one that needs dbus)? That would help me understand whether the bug affects only eiwd or it is generic bug that worth fixing/debugging in upstream iwd.
Hi, illiliti. I was able to reproduce the bug in the original iwd. Something about my workplace causes iwd to not be able to detect any networks at all.
Here is me running the original iwd on my laptop when I'm at home, where everything works perfectly:
$ tce-load -i ./iwd.tcz
iwd.tcz: OK
$ sudo /usr/local/etc/init.d/dbus start
starting dbus daemon...
$ sudo iwd &
No Diffie-Hellman support found, WPS will not be available
The following options are missing in the kernel:
CONFIG_KEY_DH_OPERATIONS
Wireless daemon version 2.0
station: Network configuration is disabled.
Wiphy: 0, Name: phy0
Permanent Address: 00:16:eb:99:80:18
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-15
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-15
VHT Capabilities:
Short GI for 80Mhz
Max RX MCS: 0-9 for NSS: 2
Max TX MCS: 0-9 for NSS: 2
Ciphers: BIP-CMAC-128 CCMP-128 TKIP
Supported iftypes: ad-hoc station ap p2p-client p2p-go p2p-device
$ sudo iwctl station wlan0 get-networks
Available networks
--------------------------------------------------------------------------------
Network name Security Signal
--------------------------------------------------------------------------------
bibliotheca_alexandrina psk ****
AndroidAP-bd open ****
donkey psk ****
DIRECT-A7-HP OfficeJet Pro 6970 psk ****
$ sudo iwctl station wlan0 connect donkey
Type the network passphrase for donkey psk.
Passphrase: *********
$ sudo udhcpc -S -i wlan0 >/dev/null
$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=115 time=39.405 ms
64 bytes from 8.8.8.8: seq=1 ttl=115 time=21.158 ms
64 bytes from 8.8.8.8: seq=2 ttl=115 time=21.211 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 21.158/27.258/39.405 ms
At work, things break down at the sudo iwctl station wlan0 get-networks
step--it says "No networks available", which is not true. I work at a big company where there are many wireless networks. Maybe too many--iwd seems to get overwhelmed and doesn't even detect the open network being generated by my phone (AndroidAP-bd), which is sitting right next to my laptop.
Can you help me troubleshoot this or are upstream issues outside your purview?
P.S. I also tried running sudo iwctl station wlan0 scan
prior to sudo iwctl station wlan0 get-networks
but it makes no difference. In fact, sudo iwctl station wlan0 scan
just seems to hang and never returns.
For the time being, I am using iw to scan and _wpasupplicant to authenticate. iw's scans work well regardless of the number of APs around.
If you said it was working before then I guess some commit between 1.20 and 2.0 regressed your setup. You could try to debug it yourself using git bisect
. It will help you to find commit that caused regression. Afterwards you need to directly report your finding to upstream either via IRC^1 or mailing list^2.
One more nuance: if you failed to find regression in iwd, try to bisect(between 0.53 and 0.54) ell^1. It is used by iwd as a low-level library, therefore the bug might be there as well.
In any event, contact upstream and they will help you(they will suggest better fix than I would after all).
Sounds like a plan. Thank you for your help and direction.
Let's keep it open until the bug is resolved.
After much pain and suffering testing both iwd and ell commits, I figured out that the regression was in iwd (ell is innocent) between iwd 1.29 (last good release) and iwd 1.30 (first bad release). I did a git bisect which says:
dfcba7c83c60f1a99ecf6f1424e97bf89fcab38e is the first bad commit
commit dfcba7c83c60f1a99ecf6f1424e97bf89fcab38e
Author: James Prestwood <prestwoj@gmail.com>
Date: Thu Aug 4 11:51:06 2022 -0700
wiphy: track GET_REG ID
Keep track of the GET_REG call so it can be canceled if the wiphy
goes down.
src/wiphy.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
I'll let the iwd developers know.
This issue was fixed upstream with this commit: https://git.kernel.org/pub/scm/network/wireless/iwd.git/commit/?id=ea93e74a0650f5f0355919184c265ae747e52a37
illiliti, thanks again for your guidance and for maintaining eiwd!
I am on Tiny Core Linux x86_64 with kernel version 5.15.10. eiwd version 1.20-1 was working perfectly. Yesterday I upgraded to eiwd version 2.0-1 and noticed strange behavior: I can authenticate with all APs that have a password, but only some open APs. Unfortunately, the open AP at my work place is the one that I cannot authenticate with.
Here is the result of an AP scan using
sudo iw dev wlan0 scan flush
. It includes an open AP that works fine (AndroidAP-bd) and also shows the open AP that I am having trouble authenticating with (ARWCVisitor): https://pastebin.com/WWqcGxMfI am trying to authenticate like this:
Can you please help me figure out how to authenticate with ARWCVisitor when using eiwd 2.0-1?