Posts by chewitt

    The other thing I also noticed is that the /etc/resolv.conf that's updated by ConnMan includes name servers from each of the connections. I'd be curious to see if there's a way to have ConnMan only use the name server specified by WireGuard. Otherwise it's using the DNS from my local internet first before going across the VPN.

    I've noticed this but resolving it [sic] is complicated. LE does not use the internal DNS proxy in ConnMan, and ConnMan will add/remove the extra DNS servers from the WireGuard config but will not remove the initial (local network entry) at the same time. ConnMan devs are not iterested in looking into this as they regard /etc/resolv.conf as a legacy approach. LE has no plan to switch back to using the DNS proxy; in the past we found lots of bugs but the main issue was consistent user reports of "My DNS is broken" because the Kodi sysinfo screen (correctly) shows 127.0.0.1 as the DNS server and this is attributed as the source of all network issues by inexperienced users. The fix probably requires LE to move to systemd resolvd but that will be a rather invasive and political change .. won't happen overnight. NB: It's not a well-known fact, but libc will only use the first 3x DNS servers listed, even if more are in the file.

    I've experimented with the following systemd service which has some added Pre/Post calls:

    The /storage/fix_dns_leaks script looks like:

    If you only start/stop the connection at boot time via systemd this script appears to work. If you start connecting/disconnecting the connection via dbus (using the connections screen in the settings add-on) the logic is faulty somewhere and at some point you end up with no DNS servers .. I haven't had time to look into it much further due to work and other time commitments. I'd be happy if others started digging around..

    I repurpose Apple A1rport Express basestations as cheap WiFi > Ethernet bridge devices. I get better range and performance than any USB device that I've ever used and there are no drivers involved so it works on all kernel versions and any device with an Ethernet port.

    You're wrong. One setting is in the OS and our settings add-on controls that. The other is entirely within Kodi and the Kodi setting controls that. Kodi does not have code for controlling our background service (which looks like an add-on but is still external to Kodi and has no API) and while Kodi has APIs our settings add-on deliberately doesn't attempt to figure out the relationship between supported OS and GUI language. For example, Generic x86_64 hardware has different keyboard languages and layouts to Raspberry Pi which has a more limited range of supported options.

    I'm not saying it cannot be done .. but it's not a straightforward thing. So far it appears the ~70% of project staff who are not native English speakers are okay with the inconvenience of setting it in two places during setup. Unless that changes, the status quo will remain the same.

    Code
    mkdir -p /storage/.config/firmware/mrvl
    wget -O https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/plain/mrvl/sd8897_uapsta.bin /storage/.config/firmware/mrvl/sd8897_uapsta.bin
    reboot

    ^ that should get the BT device working - dmesg shows the firmware is missing in our Generic image, and since this is an SDIO module (M2 interface according to Google) there are no drivers in our current kernel. The WiFi probably needs the following kernel defconfig options enabling:

    CONFIG_MWIFIEX=m

    CONFIG_MWIFIEX_SDIO=m

    See Linux Kernel Driver DataBase: CONFIG_MWIFIEX: Marvell WiFi-Ex Driver

    ping milhouse

    We use "udevil" to mount filesystem devices dynamically instead of storing/editing static content in /etc/fstab. You can place your own udev rules in /storage/.config/udev.rules.d that will either add-to the rules (most specific rule wins) or if you name them the same as an existing embedded rules file they will overwrite/replace the same-named rules file.

    If the TP-Link requires some firmware to work let me know (it will be reported in dmesg as a failure to load something) and I'll add the firnware to the image. If it requires an out-of-tree driver, sorry but I don't have time or interest to chase down patches for realtek drivers that break with every kernel bump so all of them are disabled (and no current plans to change that).

    Restart and shutdown now wait for Kodi to gracefully shutdown instead of killing the process after 5 seconds if it hasn't existed (it never does). This avoids frequently reported issues with Kodi trashing configs which are saved at shutdown, but does drag out the shutdown process compared to older LE releases. It's known and is a general Kodi problem not anything specific to Amlogic or these images. There is a long-term plan to refactor/rework some bit of Kodi which should improve timings .. but don't hold breath.

    Hardware decode is still only partially working. H264/VP9 are now reworked and merged for Linux 5.7 and HEVC (not hardware supported on C2) will be next, but ffmpeg stateful API support and the Kodi side still need reworking. Most of the effort on that is currently focussed around Raspberry Pi but since Amlogic shares the same code paths that's not a bad thing.

    No ideas about CEC as I don't use it. I do have a patch in the codebase to disable dmesg log-spamming when CEC is not supported (as I disable it in my AVR) but this is only //commenting out the message and it doesn't/shouldn't prevent actual functionality. Check Kodi settings?