Posts by GamerBene19

    Quick update: I was able to narrow the range down a bit to the (upstream) commits

    • 2ed7064934dda0766495eaaf6b26332eb63e7df8 (which is the first commit on 6.8.y that builds an LE image) issue does not appear with this commit
    • 03ff51a768fc34ebbe51ad1a60bd566fc672eb46 (which is the first commit on 6.9.y that builds an LE image) issue does appear with this commit

    I have also opened a issue in the raspberrypi linux kernel's GitHub repo: https://github.com/raspberrypi/linux/issues/7245

    So from what I was able to find out, the issue is that e8f897f4afef0031fe618a8e94127a0934896aba (which is a upstream linux commit) does not have the dts/overlay files the raspberry kernel has and that the LibreELEC build expects.

    I tried adding them, some changes to Makefiles and some files from include/... from the HEAD of 6.8.y (which builds successfully) via a patch and I god a building kernel, but when I flash the image, the disk LED flashes a few and then the Pi simply turns off (both LEDs off, no display output).

    Any advice on what would be a good way to find out which commit between 6.8.y and 6.9.y introduced my problem is appreciated.

    So I started bisecting between the two commits and need(ed) to test a merge base

    Code
    Bisecting: a merge base must be tested
    [e8f897f4afef0031fe618a8e94127a0934896aba] Linux 6.8

    Unfortunately the build for this commit fails with

    There was a similar issue in

    Rataplan626
    February 5, 2024 at 2:41 PM

    Rataplan626 do you remember what you did to solve it (to bisect successfully)?

    I'll try the different version of the rpi-kernel (rpi-6.{7,8,9,10,11}.y) next to narrow down when it breaks. Might be a few days until I report back though as I won't be home over the weekend.

    I was able to test them before leaving.
    rpi-6.7.y (which uses 6.7.12) and rpi-6.8.y (which uses 6.8.12) work, rpi-6.9.y (which uses 6.9.12) breaks.

    For the exact config I used see the commits on this branch.

    I'll try to git bisect the relevant rpi kernel commits once I get back.

    So I've bit the bullet bisected commits that touched linux kernel, drivers and LibreELEC options between 12.0.2 and 12.2.1 with
    git bisect start '--' 'distributions/LibreELEC/options' 'packages/linux-drivers/' 'packages/linux'

    According to bisect, this is the first bad commit

    This is my bisect log

    1267bd8 and 5d1274f do not build (which is also mentioned in https://github.com/LibreELEC/LibreELEC.tv/pull/10247) so i skipped them.

    014e83d also did not compile at first due to a missing call_read_iter which is referenced in out-of-kernel driver RTL8192DU and was removed in kernel version 6.10. For my bisect I simply created this patch to get it compling.

    I have also opened a issue in the driver repo in case it is helpful to someone.

    LE 13 with the kernel from 12.0.2 works too, so it seems to be a kernel/driver issue.

    I have reset packages/devel/glibc/, packages/compress/xz/, packages/linux-drivers/, packages/linux/, distributions/LibreELEC/options and projects/RPi/devices/RPi2/linux/linux.arm.conf to the version from tag 12.0.2. I have also pushed these changes onto a branch too.

    So from what I can tell the issue seems to be caused by either

    1. Changes the LE project made between 12.0.2 and 12.2.1 to the (RPi2) kernel/drivers -- e.g. via (removal) of patches

    or

    2. Changes made upstream between kernel versions 6.6.70 (which LE 12.0.2 uses) and 6.12.56 (which LE 12.2.1 uses)

    As mentioned previously in this thread, LE has disabled the out-of-tree 8192CU drivers in the past. These would have been used for my chipset in the past (and seem to still be used under RaspberryPi OS).
    But those drivers were already disabled in 12.0.2 (and in 11.x too for that matter), so I don't think it's relevant here.

    Compared to 12.0.2, 12.2.1 further disabled RTL8192DU and RTL8812AU, but I would expect that this has no effect for my dongle, as these drivers are for different chipsets (at least based on their name).

    I'm not quite sure how to continue debugging at this point, perhaps someone has a good suggestion.

    I'll try disabling RTL8192DU and RTL8812AU on 12.0.2 next, to see if disabling them somehow causes the issue (again, i don't expect it too, but you never know).

    DHCP on LibreELEC 12.0.2 with connman (2.0) and iw (6.17) versions from master works.

    I had to patch some checksums and I've also pulled in iwd (for good measure) and nftables (marked as dependency of conman in master branch) along with a newer version libnftnl (needed by nftables). If anyone is interested, my I've pushed my changes to a separate branch in my fork.

    I'll (try to) test 12.0.2 kernel/drivers on master/nightly next.

    I have opened a WiFi hotspot on my computer and have attached a Wireshark capture for both LE 12.0.2 and 13-nightly to test option 1 from above. In the image you can see a comparison of nightly (left), where DHCP is broken, and LE12.0.2 (right) where DHCP works. Notice how on the left (13-nightly) there are no data packets after the EAPOL messages (which are the WPA key exchange as far as I can tell).

    Note that I don't think reception can be an issue here as the two WiFi dongles/antennas are literally <0.5m apart on my desk.

    I think that the lack of of something like received DHCP packet xid 0x5da74051 in failing log means that either
    1. DHCP discovery never actually gets sent
    or
    2. The reply is sent but never reaches the Pi
    or
    3. The reply gets sent, but something causes it to take over 5s, always missing the timeout

    To rule out 3., I increased the DHCP discovery timeout to 30s; it still fails. The connection attempt is eventually aborted by another timeout and no LL address is configured in this case.

    I also took a packet capture on my router (which is not the AP the Pi is connecting to) of the relevant interface. I did not see any DHCP related packets going in or out while the Pi tries to connect. So I think 2. is unlikely too.

    I currently strongly suspect that the Pi has trouble actually sending out the DHCP discovery packets (aka option 1). Although I have no idea what could be causing it.

    Looking at the relevant source code of connman, the packets are sent with the sendto syscall (and notably without iw). So for now I would rule out iw aswell, which (i think) would only leave the kernel and/or the rtl8xxxu module, but that assumption might be wrong.

    I'll try to get LibreELEC 12.0.2 running with current iw and connman versions tomorrow.
    chewitt Do you know if there are other dependencies I need to consider too or if I can simply upgrade iw and connman on 12.0.2?

    I think another path forward could be git bisecting between 12.0.2 and 12.2.1, although there are ~950 commits between the two tags and I would need to rebuild the image for each bisect step. Also there might be commits in the history that do not build or break WiFi/networking in another way, so I'm not sure how viable it really is.

    I've enabled debug settings for connman with:

    Code
    LibreELEC:~ # cat /run/libreelec/debug/connman.conf
    CONNMAN_DEBUG="-d"
    CONNMAN_DHCP_DEBUG=1

    and judging from what is logged about DHCP

    and by looking through the connman code it looks like at most 6 DHCP discovery requests are sent out with a timeout of 5 seconds and if the threshold is hit an IPv4 LL address is configured.

    Edit: Under LE 12.0.2 where DHCP works it looks like this

    Make sure you set/configure the wireless regulatory domain for your country in LE settings, it can make a large difference to the radio spectrum that's usable.

    I have no access to the devices display output at the moment, but at least via SSH it looks correct

    Code
    LibreELEC:~ # iw reg get
    global
    country DE: DFS-ETSI
    	(2400 - 2483 @ 40), (N/A, 20), (N/A)
    	(5150 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW
    	(5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
    	(5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
    	(5725 - 5875 @ 80), (N/A, 13), (N/A)
    	(5945 - 6425 @ 160), (N/A, 23), (N/A), NO-OUTDOOR
    	(57000 - 66000 @ 2160), (N/A, 40), (N/A)

    and I have written down the following in my documentation of the setup steps

    so I am reasonably sure I've set it correctly.

    Hi, that could be because of the "unstable" wifi source. Maybe one of your neighbor use the same wifi channel, you did a channel analysis to see the interferences? The possible existent connman-iwd issue I think appear at reconnecting. But even without the "reconnection issue", an unstable network and continuous streaming isn't the best option. I'm just wondering... that part of the stable/unstable wifi network could be the reason that only a few users reported this issue...

    Sorry for not answering about that earlier. Yes I did look at channel utilization and signal strength of other APs. To me it looked fine.
    I just looked again, this roughly is the current situation according to iw dev wlan0 scan:

    Signal StrengthChannel
    -56 dBm1
    -90 dBm1
    -90 dBm1
    -96 dBm1
    -82 dBm6
    -94 dBm6
    -82 dBm11
    -90 dBm11
    -94 dBm6
    -82 dBm6
    -96 dBm1
    -90 dBm6
    -77 dBm5
    -76 dBm5
    -86 dBm6
    -86 dBm6
    -98 dBm10

    I am connected to the network of the first row (interestingly iw wlan0 station dump shows a better dBm value for the connected WiFi; don't know why). It might be better to switch to channel 11, but I think overall this is situation is fine considering all other dBm values of the same channel are >90

    Quick update: I have switched to the other adapter (the one with the 'proper' antenna) -- the problem still occurs.

    When connected, I see dBm values <50 (which is an improvement), but the connection still drops frequently and is really unreliable.

    I'm thinking about buying simply buying something new to 'solve' the problem. What hardware is known to have reliable WiFi with LibreELEC? Does the newer Pi's onboard WiFi work reliably?

    This out of tree driver was dropped in favour of the now maintained in kernel mainline driver. https://github.com/LibreELEC/Libr…5c5c358151e3b61

    How can I temporarily re-enable that driver? Is reverting the three commits from the PR that disabled it enough?