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

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

Quote from chewitt

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

~/LibreELEC.tv $ PROJECT=Generic ARCH=x86_64 make image

...
    INSTALL    libgcrypt (target)
    INSTALL    libgpg-error (target)
...
  BUILD    qemu (host)
      TOOLCHAIN    configure (auto-detect)
...
make[1]: Entering directory '/home/rick/LibreELEC.tv/build.LibreELEC-Generic.x86_64-9.0-devel/qemu-2.12.0/.x86_64-pc-linux-gnu'
mkdir -p dtc/libfdt
mkdir -p dtc/tests
  GEN     config-host.h
  GEN     trace/generated-tcg-tracers.h
  GEN     trace/generated-helpers-wrappers.h
  GEN     trace/generated-helpers.h
  GEN     trace/generated-helpers.c
  GEN     module_block.h
  LINK    tests/qemu-iotests/socket_scm_helper
  CC      qga/qapi-generated/qga-qapi-commands.o
  CC      qemu-img.o
/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lgcrypt
/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lgpg-error
/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lgpg-error
collect2: error: ld returned 1 exit status
make[1]: *** [/home/rick/LibreELEC.tv/build.LibreELEC-Generic.x86_64-9.0-devel/qemu-2.12.0/rules.mak:121: tests/qemu-iotests/socket_scm_helper] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory '/home/rick/LibreELEC.tv/build.LibreELEC-Generic.x86_64-9.0-devel/qemu-2.12.0/.x86_64-pc-linux-gnu'
make: *** [Makefile:12: image] Error 2

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.