Posts by ajbathe

    When you follow the link and some other klicks u can see under

    [le12] iwd: update to 2.4 by heitbaum · Pull Request #7703 · LibreELEC/LibreELEC.tv
    ver 2.4: Fix issue with FT-over-Air and same channel operation. Fix issue with AP mode and missing support for GTK. Fix issue with AP mode and channel switch…
    github.com

    that iwd has a new revision 2.4. Then u can test this software part. I did that with my Raspberry Pi 4 (RPi4) and did 101 tests (101x times I swithed the computer off and on) and 97% of these runs were good, only 4 were bad (means no autoconnect). No autoconnect means you got an IP but not the wifi interface really up.

    Till today, nobody nows why this is like it is. And because my system starts some news feed at the bottom, I can judge how fast the connections get etablished. Is the text short, did it take a longtime for connecting the WiFi-interface, is the text longer (it had more time to print) the time to bring up the interface was shorter, so the news feed "printer" could print more letters. Means the connection was built up faster.

    What you don't know, that I don't do that manually, there is some mechanism were you can tell the machine, reboot after being 30 secs up and then reboot yourself. I count the loops and say what the computer tested by itself when I was doing something else.

    That was now the long version of what that means.


    The second answer I would say: As long as your hardware will function, maybe 15 years, maybe 5 mins. Nobody knows that. When your system has an RTC (Real Time Clock) your clock will run with quite a good time till the battery is empty, otherwise you could have 15 years just your personal but wrong time and date.

    Aehmm, I forgot to say Welcome back ^^

    Please connect once manually:

    System -> LibreELEC -> Network Wireless Networks has to be active

    -> Connections -> Your WiFi -> Connect

    If kodi restarts, just do it again. Than I guess you will be happy a little bit. There is still an autoconnect issue... So you might try it more than once.

    If you have entered your working passphrase, just reboot sometimes and report whether you got a working connection.

    Added: Hmmm, besides the fact of seeing an "insulted liverwurst" :D we have the information that he got an IP with chewitts-test-image. Nice :)

    People with WiFi problems under LE11.0 are welcome to try a key test image. Please report whether this version fixes or improves your WiFi-problem.

    Here is the log of a boot with successful autoconnect of Linux version 6.1.19 (chewitt@toolbox) (aarch64-none-elf-gcc-12.2.0 (GCC) 12.2.0, GNU ld (GNU Binutils) 2.39) #1 SMP Sun Mar 26 10:51:02 UTC 2023

    http://ix.io/4rUs

    The log by boot given in #55 had

    Code
    Mar 26 19:08:47 raspi connmand[743]: ../plugins/iwd.c:cm_network_connect_cb() /net/connman/iwd/0/3/4c696e75782d4e6574776f726b_psk connect failed: net.connman.iwd.Failed

    here in the working case we don't see that.

    Added:

    And of course, I wanted to know how many times an autoconnect will be successfull with your version: The result: 76 boots were ok, 25 not. Pattern: http://ix.io/4rVg

    no info means no connect - just a simple shell script via crond for counting.

    Conclusion: I don't know the changes of connman source from 11.0.1 official to the version #53, I used the RPi4 LE11.0 official versions and only replaced IWD with the currently master version. I don't know how meaningful a comparision with my numbers are, but 12/13 with LE11.01 compared with 25 is a double.

    And my main question now is: Why does it function > 75% in both test scenarios and the rest not? And my last suggestion: I read many complains of that problem here, it seems to exist quite a longer time. What about announcing the test images more on the top.I think it is a little bit "lost" here in one single thread.

    Here are two test images for RPi4 and Generic (GBM) that contain connman/iwd with latest patches/changes (HEAD):

    https://chewitt.libreelec.tv/testing/LibreE….arm-11.0.1.tar

    https://chewitt.libreelec.tv/testing/LibreE…6_64-11.0.1.tar

    If others can confirm things are resolved we'll get the changes submitted and merged.

    Thanx for the very fast build;

    some autoconnects, some not, I grabbed that scenario: failure in GUI (no autoconnect), but was able to manually connect by entering the passphrase - so no invalid key :) - then connect - around 5 boots, 2x passphrase requests, 3 okay.

    Your log chewitt53-test-no-autoconnect.log -> http://ix.io/4rTi

    I guess you compiled iwd master like me? But is it wise to change more than one software part when tracking a bug (I mean connman here). Just my thought... I only replaced iwd and checked that with different LE versions.

    There is some difference in the iwds

    # ldd /usr/lib/iwd <- your version #53

    /usr/lib/libarmmem-v7l.so => /usr/lib/libarmmem-v7l.so (0xf7ce0000)

    libc.so.6 => /usr/lib/libc.so.6 (0xf7b70000)

    /lib/ld-linux-armhf.so.3 => /usr/lib/ld-linux-armhf.so.3 (0xf7d09000)

    ldd /storage/bin/iwd <- on OSMC compiled version

    /usr/lib/libarmmem-v7l.so => /usr/lib/libarmmem-v7l.so (0xf7d00000)

    libdl.so.2 => /usr/lib/libdl.so.2 (0xf7cd0000)

    libc.so.6 => /usr/lib/libc.so.6 (0xf7b60000)

    /lib/ld-linux-armhf.so.3 => /usr/lib/ld-linux-armhf.so.3 (0xf7d30000)

    Could be this relevant? Your LE version doesn't use libdl.so.2

    So, here is my final contribution of today:

    I did some tests with iwd-master and LE11.0.1 official. 101 boots showed 88 good ones with autoconnection working. 13 were not-connected, I don't know why.

    Who wants to see the pattern, here you go: http://ix.io/4rSS

    But manually I was able to reconnect. Would guess, this looks like some timing problem, but not sure.

    I created two logs again:

    journalctl-iwd-master-connect.log -> http://ix.io/4rSN

    journalctl-iwd-master-noconnect.log -> http://ix.io/4rSO

    Because of the info from frakkin64, I also switched debugging on with "options brcmfmac debug=0x00100006 feature_disable=0x82000" for the brcmfmac kernel driver - but I guess this is not the case here. I don't use WPA3 (SAE) and only FWSUP gets disabled.

    Who wants to glance at that:

    brcmfmac.connected -> http://ix.io/4rSW

    brcmfmac.not-connected -> http://ix.io/4rSX

    Now I have to wait for some developer reactions. I am quite happy, but not perfectly ;) The 101 cases had to be 101 good ones. Have a nice day.

    Added: Ups, I saw the new test-image of chewitt (see #53 above) after writing this. My information here is not correlated. I will test that too.

    ajbathe You can give this a shot, I do have devices on 6.1.19 with brcmfmac and haven't noticed any issues, but it may be specific to features your using that I am not, or perhaps wpa_supplicant didn't support offloading by default. It's just interesting they single out brcmfmac.

    https://iwd.wiki.kernel.org/offloading

    Code
    cat > /storage/.config/modprobe.d/brcmfmac_disable_fw_offload.conf << 'EOF'
    options brcmfmac feature_disable=0x82000
    EOF

    Thanx for that new info for me - I will look into that when my RPi4 machine is done with some stress test.

    Good news: I haven't seen any invalid-key or operation failed messages with iwd-master, but in some rare cases - this is the bad news - autoconnect is not working 100%.

    I want to know, how many of 100 boots see the WiFi network device - I do this via cronjob, waiting 60 secs, reboot and count the cases, where wlan adapter is up or not ... I would say less than 10% but I will report that here when the test done.

    > or perhaps wpa_supplicant didn't support offloading by default.

    wpa_supplicant is not onboard anymore, or what did you mean by mention that?

    Okay, that's not my scenario, what would be your guess? But wait, I have two networks on one FritzBox 7390. This would be helpful to not compile many iwd-versions step by step upwards from version 2.3

    could this be the reason?

    wireless/iwd.git - Wireless daemon for Linux

    or

    wireless/iwd.git - Wireless daemon for Linux

    some changes since 02.02.2023 fixes my issue:

    wireless/iwd.git - Wireless daemon for Linux

    But this is my hottest canditate:

    "ft: Introduce ft_authenticate_onchannel

    Currently when we try FT-over-Air, the Authenticate frame is always sent via offchannel infrastructure We request the driver to go offchannel, then send the Authenticate frame. This works fine as long as the target AP is on a different channel. On some networks some (or all) APs might actually be located on the same channel. In this case going offchannel will result in some drivers not actually sending the Authenticate frame until after the offchannel operation completes. Work around this by introducing a new ft_authenticate variant that will not request an offchannel operation first."

    wireless/iwd.git - Wireless daemon for Linux

    ajbathe
    March 25, 2023 at 8:48 PM

    Is somebody able to crosscompile an iwd for RPi4 from the actual master of https://git.kernel.org/pub/scm/network/wireless/iwd.git ? My next idea is to replace /usr/lib/iwd with that version for LE11.0.1

    Added: Not necessary anymore! I think I found the bug - compare source from LE-iwd with the master version - somewhere here sits it: diff from 2.3 and master: http://ix.io/4rR9

    Because of "station.c:station_connect_cb() 3, result: 2" I would assume here is it:

    What I did: I flashed the last OSMC on another SD-card, installed all packages which I needed to compile the master version I mentioned above. I put this iwd into /storage/bin and told systemd to use that version (-> drop-in with ExecStart=/storage/bin/iwd -d). I rebootet and it worked. I downgraded from chewitt to LE11.01 official. It worked! I downgraded again to LE11.0 and it works too!!

    Dear LE-devs, please replace the iwd with the master-version above. And give that test-release to some many people here who have this kind of wifi-problems.

    The small problem with no autoconnect when Wired-LAN is on first is - I guess IMHO - connman related because iwd only cares for Wifi, am I wrong in this thinking?

    prove: http://ix.io/4rPG <- LibreELEC (official): 11.0.0

    And now I can make some friends happy who need WiFi because they bought 10 meters of some Wifi cable :D

    And another small problem could be: When wired LAN comes first, WiFi won't get fired up. By observations from today with chewitts version had Wifi-only - I fear that we have to look at that too. But who uses WiFi and LAN together?! ME NOT - /joke off - Otherwise I would not have been able to do my todays contribution. Have a nice weekend.

    It's possible all of the reported invalid key situations are in fact the same problem

    I think you are right, it's not only RPi4 related.


    BTW, If you have paired connman & iwd debug logs that would probably be useful to the mailing lists exhibiting good/bad at the same time.

    see the full journalctl versions :)

    http://ix.io/4rMQ & http://ix.io/4rMR - I already thought that iwd log could not be meaningful enough


    and looking at https://lore.kernel.org/connman/ you will see that the devs are aware of the wifi-problematic

    My attention was triggered by

    Code
    Patches for the AutoConnect bug I hit in the iwd plugin 2023-01-16  7:52 UTC  (7+ messages)

    chewitt

    > I have low expectations that either patch will resolve anything ...

    I here disagree, your version shows the right way, could you please build another for the sake version with the patches from directly above? I will test that too. When I'm hopefully not wrong, they are not integrated?!