Posts by chewitt

Intel chipsets are all supported via the same "iwlwifi" driver which is enabled in our kernels. I have no knowledge of the individual chipsets because we rarely see issues reported against them, and when things just work we don't learn about them.

In all three logs "wlan0" is probed and appears to be present, and in the USB logs I also see wlan1 (and confusingly, wlan2) and those are then associating successfully to the network. I don't see any attempts from the wlan0 interface (the Broadcom card) to associate to a network.

Note that ConnMan stores SSID/pass data against a specific card, so even if you have connected successfully on wlan1/2 and then remove the USB card, it will not auto-connect to the network using wlan0. You would need to specifically connect without the USB device connected and (re)enter the passphrase. I'm wondering if you've done that?

That said, I'm also just realising that wlan0 is using the 'wl' driver:

Aug 06 08:25:54 LibreELEC kernel: wl: loading out-of-tree module taints kernel.

This driver is vendor/out-of-tree and has been unmaintained by Broadcom for more than a decade. It has been dropped from LE13 as it no longer compiles and I wouldn't be even slightly surprised if (even when it did compile) it didn't work properly on modern kernels due to long-term bit-rot. Some wl using cards are also supported by 'b43' which although in-kernel, is equally unmaintained for about a decade, and for that reason we haven't enabled it in LE13 kernels after dropping wl. TL/DR; even if this did work on LE12 it will have a short lifespan.

For that reason I'd recommend you get an alternative PCIe card. Look for something with an Intel chip as those are generally well maintained and with the drivers/firmware upstream.

It fails on some add-on packages too. This PR resolves the issue https://github.com/LibreELEC/LibreELEC.tv/pull/10314

Quote from emelsky

However if I reboot LibreELEC without other connection (either wired or USB WiFi) then Broadcom card disappears.

Please run "journalctl | paste" and share the URL generated for three states:

a) Boot with Ethernet connected, USB wifi disconnected

b) Boot with USB wifi connected, Ethernet disconnected

c) Boot with neither USB or Ethernet connected (then wait 60 secs, connect Ethernet to pastebin the log)

config R8169                                                                              
        tristate "Realtek 8169/8168/8101/8125 ethernet support"                           
        depends on PCI                                                                    
        select FW_LOADER                                                                  
        select CRC32                                                                      
        select PHYLIB                                                                     
        select REALTEK_PHY                                                                
        help                                                                              
          Say Y here if you have a Realtek Ethernet adapter belonging to                  
          the following families:                                                         
          RTL8169 Gigabit Ethernet                                                        
          RTL8168 Gigabit Ethernet                                                        
          RTL8101 Fast Ethernet                                                           
          RTL8125 2.5GBit Ethernet

From Linux 6.16 kernel Kconfig options ^ .. the RTL8125 chip is supported by the r8169 driver so 'all' kernels (not some) are using that driver with that chip.

You will need to describe in more detail (and provide system logs) detailing the actual problem. NB: blacklisting r8169 will disable part of the ethernet stack, but not all of it. You will still see the Realtek PHY being probed and detected.

Sudden power loss denies the OS (and services running) the opportunity to shut-down gracefully/cleanly so my uneducated guess is that some kind of session/state data is not cleared and it's presence during boot results in something like ConnMan not seeing that a new connection is required; as it believes one already exists or something of that nature.

The way to investigate that kind of wild-ass theory s starting ConnMan in debug mode (add 'debugging' to boot params in cmdline.txt) and with persistent logging enabled from the settings add-on, as ConnMan debug output is quite verbose and the default system log size will result in log rotation before you've had a chance to login and look.

ConnMan logs are somewhat human readable .. look for errors. Feel free to pastebin them somewhere (don't upload here please).

Quote from treysis

The problem exists since at least 11

This eliminates iwd from suspicion as LE11 uses wpa_supplicant and LE12 onwards uses iwd.

So it's either something in ConnMan or perhaps the underlying brcmfmac kernel driver. I'd be thinking in the direction of ConnMan first as its responsible for managing connection state. Updating to an LE13 nightly will bump ConnMan (and the kernel driver) to the latest versions available. There no guarantee that solves anything, but it would be a local step forwards.

Quote from emelsky

Sorry I really do not know how to edit previous posts

Post editing is time-limited for normal users. After about 5-10 mins post contents are fixed. It stops spammers posting harmless comments on existing threads and then editing the post hours/days/weeks later to include URL links to whatever garbage they are being paid to promote this week.

If you don't like exposing weak services to the internet, use WireGuard to put the client device on the local network.

I'd keep it simple: add the CA to cacert.pem so the client trusts the server and then authenticate the user over WebDAV within a secure TLS session. I get that mTLS can fail things earlier in the connection sequence, but that's enough to avoid issues.

Quote from Papalapa

"[FAILED]Failed to start display.service". Could be this the reason?

I need to refine the VFD service so it doesn't start when the board/box has no VFD configured. It's harmless and can be ignored.

You will need to provide a Kodi debug log that demonstrates the problem for anyone to comment on playback issues. Esp. with mkv being a container format (we have no idea what's inside the container).

In short, no .. there has never been a LibreELEC release as we dropped i386 support back in OpenELEC days.

I don't believe mTLS is possible. Kodi supports the following TLS options via URL append:

xbmc/xbmc/addons/kodi-dev-kit/include/kodi/c-api/filesystem.h at master · xbmc/xbmc

Kodi is an award-winning free and open source home theater/media center software and entertainment hub for digital media. With its beautiful interface and…

github.com

Looking wider in the codebase I only find references to defining the CA bundle used for server cert verification. It's typically done using the SSL_CERT_FILE environment variable, although LE uses another approach (as you found in the wiki).

To use mTLS you normally provide --cert=/path/to/cert and --key=/path/to/key in the curl command and unlike the CA bundle curl/libCURL does not appear to support a client cert defined through an environment variable, so Kodi would need code changes to support those being defined, e.g. through advancedsettings.xml config.

I also didn't find any existing references to mTLS in existing Kodi issues or pull requests, or forum threads. So you'd need to make a feature request via that section of the Kodi forum.

See https://wiki.libreelec.tv/development/build-basics for some basic info on the buildsystem. Both distro's use Bluez for their BT things and ConnMan/IWD for networking. Those tools have numerous common code contributors so e.g. how things are persisted end up being very similar. There's no specific info/guides for combining capabilities. Have you thought about using the retro-game capabilities in Kodi?

Quote

ROCK 4C+ is powered by RK3399-T, which is a lower freq version of RK3399, the ram speed should be 666Mhz for stable operation.

ilmich more from Radxa ^

The remote is working via HDMI-CEC?

Quote from py9399

i have to edit config.txt to be able to use analog audio ?

Correct.

Quote from py9399

does this provide a predictable, repeatable delay ?

Probably..

Quote from py9399

if you know places where i can reach other people, i am sur i am not the first one to try this ..

I don't recall anyone doing something similar with LibreELEC before; probably because we are intentionally a 'dumb' client/playback oriented distro. I would expect to find people doing more complicated projects in the Raspberry Pi forum, or if the solution is built around Kodi, perhaps the Kodi forum.

Newer "Generic" LE images contain kernels/drivers that technically support them (sort of, it's still WIP in Linux) but Kodi currently makes no use of either so it's "not supported" for now. In the long term that might change, and it might be a good solution for use with general purpose distros that increasinly use Wayland instead of Xorg; because Wayland does not support the kind of userspace driven mode/rate change that Kodi requires for optimal playback. However, even if Kodi and Wayland do gain support I doubt LE would switch as Wayland increases the code stack (more maintenance) and VRR/Freesync requires GPU + TV/Monitor support which is not guaranteed. TL/DR; even if Kodi gains support it doesn't provide real-world benefits over our current GBM/V4L2 approach.