Posts by rdorsch

    Interesting, do I get that right that there are two drivers in staging for this USB adapter? A working one from Realtek and a non-working one from Jes Sorensen <[email protected]> ?

    Debian testing (bookworm, upcoming Debian 12) ships a working driver with kernel 6.1:

    On the Debian system FW gets indeed loaded, therefore I copied it to the libreelec system. The license of the driver is GPL on the Debian system, so I assume it is not a vendor driver (which in addition would be very surprising for me, if Debian would ship vendor drivers in its main repo).

    Output of modinfo r8188eu on the Debian system

    debian Pastezone

    In there it is reported that the driver in Debian is also from staging:

    staging: Y

    Sources of this kernel can be found here:

    Folder: 5.10.162-1 | Debian Sources

    Sources of the driver in there

    Folder: rtlwifi | Debian Sources

    Kernel config here:

    https://bokomoko.de/~rd/Debian/config-5.10.0-21-amd64

    I will update that system in the next days to Debian testing, which will come with Kernel 6.1 as well. But I would expect that wifi USB adapter still works flawless there.

    I have a rock64 box with Libreelec 11.0.1.

    I plugged in an usb Wifi adapter

    Bus 004 Device 002: ID 0bda:8179 Realtek Semiconductor Corp. RTL8188EUS 802.11n Wireless Network Adapter

    but it seems that libreelec on the Rock64 device does not recognize the stick:

    rock64:~ # iw list

    rock64:~ #

    Complete dmesg output:

    http://ix.io/4sBb


    The module seems from staging, but since I got it from pine64, I was expecting that it has at least basic Linux support:

    [ 8.281405] r8188eu: module is from the staging directory, the quality is unknown, you have been warned.

    And it is loaded, output of lsmod

    http://ix.io/4sBd

    The USB wifi adapter connects flawless on a Debian stable system on x86. I see there that firmware gets loaded:

    [428204.016092] r8188eu 1-8:1.0: firmware: direct-loading firmware rtlwifi/rtl8188eufw.bin

    I copied the FW from the Debian system to the rock64 box with libreelec 11.0.1

    rd@h370:/lib/firmware$ scp -r rtlwifi root@rock64-wlan:/storage/.config/firmware


    but this did not change anything.

    Does anybody have a suggestion what might have gone wrong?

    Thanks

    Rainer

    With

    Code
    2023-04-03 16:32:16.090 T:908      info <general>: Starting Kodi (20.1 (20.1.0) Git:20.1-Nexus). Platform: Linux ARM 32-bit
    2023-04-03 16:32:16.090 T:908      info <general>: Using Release Kodi x32
    2023-04-03 16:32:16.090 T:908      info <general>: Kodi compiled 2023-04-03 by GCC 12.2.0 for Linux ARM 32-bit version 6.1.19 (393491)
    2023-04-03 16:32:16.091 T:908      info <general>: Running on Amlogic Meson GXBB (S905) WeTek Play 2 with LibreELEC (community): nightly-20230403-bb4c561 11.0, kernel: Linux ARM 64-bit version 6.1.19

    I checked in the openwrt syslog, but did not find any entry there from the connection attempt. For successful connections, I see entries like

    Code
    Mon Apr  3 21:09:54 2023 daemon.info hostapd: wlan0: STA 78:11:dc:ed:a7:e3 IEEE 802.11: associated (aid 5)
    Mon Apr  3 21:09:54 2023 daemon.notice hostapd: wlan0: AP-STA-CONNECTED 78:11:dc:ed:a7:e3
    Mon Apr  3 21:09:54 2023 daemon.info hostapd: wlan0: STA 78:11:dc:ed:a7:e3 WPA: pairwise key handshake completed (RSN)
    Mon Apr  3 21:09:54 2023 daemon.notice hostapd: wlan0: EAPOL-4WAY-HS-COMPLETED 78:11:dc:ed:a7:e3

    on the openwrt side. I conclude that the connection process aborts very early.

    I see still the same behavior. I used the box image instead of the wetek-play2, since I still have the Android FW for reference testing on the emmc.

    The double results I cannot deterministically reproduce. I keep an eye if the double results show up again w/o manual iwd run.

    I configured the regdomain and now it seems I can at least see the wireless network.

    I managed to connect to the AP of an Android phone in tethering mode.

    I did not manage to connect to an

    OpenWrt 22.03.3 router, I get invalid key. I use this router since many years with many devices and I do not recall that I ever had an issue that a device did not want to connect.

    dmesg has quite a few entries

    ieee80211 phy0: brcmf_construct_chaninfo: Ignoring unexpected firmware channel <number>

    (not sure if that is relevant)

    http://ix.io/4swH

    Output of "iw dev wlan0 scan"

    http://ix.io/4swW

    Output of "iwlist wlan0 scanning" looks ok for me:

    and the kodi.log:

    http://ix.io/4swI


    What is very weird: Sometimes all connections show up twice, see

    PXL_20230402_194352852.jpg
    Nextcloud - a safe home for all your data
    nc.d5x.de

    Is that expected?

    Many thanks

    Rainer

    Hi,

    I have trouble getting a wifi connection with the box image on a Wetek Play 2. I don't see any wifi network at all (I do if I boot the stock (Android) firmware on the device). I connected an ethernet cable and iw list at least shows a phy. Is there something I am doing wrong?

    kodi.log:

    http://ix.io/4suB

    dmesg output:


    http://ix.io/4suC

    Any hint or advice is welcome :)

    Many thanks

    Rainer

    I run multiple VLANs for different devices (Wifi, data network, several for home automation, some of them have internet access others not). I have today my xbian box (kodi) in the Wifi VLAN and the data VLAN, i.e. there is a eth0.<vlan1> and eth0.<vlan2>.

    Many thanks, lrusak

    kmscube works without any issue, colors look ok, nothing similar to the colors when playing videos.

    I just double checked (since I upgraded to a newer libreelec build) that the orignal color issue is still there (best illustrated with the video linked in the post from classicCuboxiuser above). I do not believe that it is a performance issue, since there seems to be no dependence on the resolution of the video.

    Do you have any other ideas on either how to repro and analyse the issue with standard tools or debug it?

    Thanks

    Rainer

    Many thanks. Indeed

    fixes it (until it is resolved by upstream). Since I am not familiar with libreelec's build system, can anybody confirm that this is the right way to do this or tell what should be done differently?

    thanks

    rainer