Enabling 'tethered' wireless access point doesn't work in LibreELEC but DOES work in OpenELEC?

  • Hi,

    I recently upgraded from OpenELEC (OE) to LibreELEC (LE) because scraper addons had stopped working in OE.

    On the same hardware however, LE is unable to create a wifi tethered hotspot whereas this 'just works' on OE.

    Error from ~/.kodi/temp/kodi.log when attempting to create hotspot:

    01:01:48.837 T:140483840939776 ERROR: ## LibreELEC Addon ## connman::set_technologies ## ERROR: (DBusException('Not supported',))

    01:01:48.837 T:140483840939776 ERROR: Traceback (most recent call last):

    File "/home/chewitt/LibreELEC.82-images/build.LibreELEC-Generic.x86_64-8.2.5/LibreELEC-settings-0768930/.install_pkg/usr/share/kod

    i/addons/service.libreelec.settings/resources/lib/modules/connman.py", line 965, in set_technologie

    File "/usr/lib/python2.7/site-packages/dbus/proxies.py", line 145, in __call__

    File "/usr/lib/python2.7/site-packages/dbus/connection.py", line 651, in call_blocking

    DBusException: net.connman.Error.NotSupported: Not supported


    Any ideas?

    Thanks :)

  • Thanks Chewitt for the super prompt reply and apologies for my lag.

    Please disregard my previous message, my comparison was mistakenly based on two separate sets of hardware.

    It's either a limitation of the hardware or the Linux drivers for Broadcom that don't allow the wifi card to become a hotspot.

    Anyway, while it's a nice to have scenario it's not something that I'm willing to chase up at this time.

    What's become more pressing is getting the laptop's mouse trackpad to work in LE.

    It's an Alps trackpad, known to not work in old Linux kernels (LE uses 4.11 kernel).

    Upgrading kernels is easy but I've not been able to do it in LE as it seems to be too deeply tangled with build scripts that require the entire project to be (re-)built.

    Updated kernel to 4.18 using master checkout of http://LibreELEC.tv/projects/Generic/linux/linux.x86_64.conf, inserted it's kernel modules into the squashfs image but Syslinux oopses the kernel on boot complaining it's "Unable to mount root fs on unknown-block(1,0)".

    So I'm probably missing some important step somewhere, but may have to wait until a new version of LE is released with a current kernel before it can be used.

    Cheers :)

  • I wouldn't waste time trying to bump the kernel in an 8.2.5 image; it's not simple so easier to start with the 004 alpha release (which is stable) and work from there. Just edit projects/Generic/linux/linux.x86_64.conf and enable whatever extra kernel driver module is required before building the image (or build an image, edit the kernel, rebuild and only the kernel will be rebuilt).

    Some wireless hardware supports AP mode, but not all does. Without knowing which chip is being used it's not possible to comment.

  • Excellent! Have upgraded to 004 alpha with no problems.

    Simply upgrading to the new 004 alpha release (which uses 4.18 kernel), might be enough on it's own to get the Alps trackpad working.

    AFAICT the Alps trackpad hardware has problems in older kernels with the way it interacts with the 'i8042' controller and 'i2c-hid'.

    Fingers crossed, will be able to test later this week.

    For the wifi hardware:

    08:00.0 Network controller: Broadcom Limited BCM43224 802.11a/b/g/n (rev 01)

    en:users:drivers:brcm80211 [Linux Wireless]
    Hardware is only supported by 'brcmsmac' kernel module, which doesn't support AP mode :(

  • I wouldn't waste time trying to bump the kernel in an 8.2.5 image; it's not simple so easier to start with the 004 alpha release (which is stable) and work from there. Just edit projects/Generic/linux/linux.x86_64.conf and enable whatever extra kernel driver module is required before building the image (or build an image, edit the kernel, rebuild and only the kernel will be rebuilt).

    No dice unfortunately :(

    The notepad's Alps trackpad hardware still fails using the new 004 alpha 4.18 kernel.

    Digging deeper and it looks like the following needs to be enabled in LE's kernel to make it work:

    CONFIG_I2C_HID=m

    CONFIG_HID_ALPS=m

    CONFIG_MFD_INTEL_LPSS_ACPI=y

    CONFIG_MFD_INTEL_LPSS_PCI=y


    So I repeated the same steps of rebuilding the kernel with those options and recreating the squashfs image with kernel modules included.

    But as mentioned before the new KERNEL and SYSTEM squashfs image fail to boot with "Unable to mount root fs on unknown-block(1,0)".

    Is there some step I'm missing?

    Cheers :)

  • Well OK, if the recommended/supported way is the entire toolchain and project must be built just to upgrade the kernel, then that's fine.

    Unfortunately the image can't be built :(

    Edited once, last by shiznix (September 7, 2018 at 5:36 PM).

  • Unsure if it's some library path munging on libgcrypt's build, or if the problem lies with qemu.

    Or if the problem is that sometimes the build system uses the system GCC (7.3.0), and sometimes it uses the LE toolchain GCC (8.2.0).

    Deleting the qemu dependency gets the build moving forward again so maybe it's not really necessary but instead simply an optional dep used for testing?

    EDIT: Qemu not optional, but it's the only broken package that's stopping the image being built.

    Edited 2 times, last by shiznix (September 7, 2018 at 5:36 PM).