illiliti / eiwd

iwd without dbus -- maintained fork of original dylanaraps/eiwd
GNU Lesser General Public License v2.1
46 stars 3 forks source link

latest iwd cannot find any network in congested area #4

Closed bdantas closed 1 year ago

bdantas commented 1 year ago

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/WWqcGxMf

I am trying to authenticate like this:

# touch /var/lib/iwd/ARWCVisitor.open
# iwd -i wlan0 &

Can you please help me figure out how to authenticate with ARWCVisitor when using eiwd 2.0-1?

bdantas commented 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.

illiliti commented 1 year ago

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.

bdantas commented 1 year ago

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.

bdantas commented 1 year ago

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.

illiliti commented 1 year ago

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.

illiliti commented 1 year ago

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).

bdantas commented 1 year ago

Sounds like a plan. Thank you for your help and direction.

illiliti commented 1 year ago

Let's keep it open until the bug is resolved.

bdantas commented 1 year ago

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.

bdantas commented 1 year ago

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!