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

Because I saw commit https://github.com/LibreELEC/LibreELEC.tv/pull/7703 today going IWD to v2.4 I also compiled that and dropt it into LE11.01 official.

My observation on RPi4 were 97% successful connects. They also seem to be faster, judged by the length of the starting RSS-feed-text.

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" we have the information that he got an IP with chewitts-test-image. Nice

@mylarguten: life will be easier when people are polite (see your posting RE: invalid wifi key )

but for the sake, here you go: https://chewitt.libreelec.tv/testing/LibreE…4-11.0.1.img.gz

chewitt: I want to know whether this makes him happy

Greetings,

I wanted to upload a quite big log with pastebinit. The log is 38.5 M in size and pastebinit gives me no URL. I could guess there is a size limit? Grabbing an stutter issue with a special IPTV stream made the log so big. How can I serve this log?

Post

RE: invalid wifi key

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.

chewitt

March 26, 2023 at 5:16 PM

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

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.

Quote from chewitt

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.

Quote from frakkin64

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

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:

diff -r iwd-2.3/src/station.c iwd-master/src/station.c
371,372c371,372
<         pos += snprintf(path + pos, sizeof(path) - pos, "%02x",
<                                 ssid[i]);
---
>         pos += snprintf(path + pos, sizeof(path) - pos, "%02hhx",
>                     ssid[i]);
2301c2301
<     if ((hs->mde[4] & 1))
---
>     if ((hs->mde[4] & 1)) {
2304,2305c2304,2311
<     else
<         ft_authenticate(netdev_get_ifindex(station->netdev), bss);
---
>         goto done;
>     }
> 
>     if (station->connected_bss->frequency == bss->frequency) {
>         ft_authenticate_onchannel(netdev_get_ifindex(station->netdev),
>                         bss);
>         goto done;
>     }
2306a2313,2315
>     ft_authenticate(netdev_get_ifindex(station->netdev), bss);
> 
> done:

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

Your WiFi on a RPi4 is working with LE11.0.1 ? Do you use internal or external WiFi? And without any information people can look into a glass bowl People here need your logs ...

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.

Quote from frakkin64

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.

Quote from frakkin64

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

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?!

Quote from chewitt

An image for RPi4 with two additional patches from the connman list for someone to test. I have low expectations that either patch will resolve anything, but for the sake of a 30-second rebuild: https://chewitt.libreelec.tv/testing/LibreE….arm-11.0.1.tar

Are your two patches correlated with what I could study on https://lore.kernel.org/connman/202301…[email protected]/T/ ??