GL-X3000 gl_ble_daemon crashlooping (+other weirdness)

Technical Support for Routers 4G LTE, 5G NR, USB modems
1

MY GL-X3000 has been acting up in a couple of hard to pin down ways. Sometimes the lights all turn off and slowly come back on but there's nothing I can correlate it to clearly in the system logs and crash log is empty. However, today I had a WiFi dropout and it seems the cellular modem also crashed at the same time as the 5G was reconnecting when I was able to access the UI again.

The corresponding errors in the log are these:

Mon Jan 27 19:11:44 2025 daemon.notice netifd: modem_0001_4 (12495): udhcpc: sending discover
Mon Jan 27 19:11:46 2025 daemon.err usbmuxd[12895]: [19:11:46.945][3] usbmuxd v1.1.1 starting up
Mon Jan 27 19:11:46 2025 daemon.err usbmuxd[12895]: [19:11:46.948][3] Using libusb 1.0.24
Mon Jan 27 19:11:46 2025 daemon.err usbmuxd[12895]: [19:11:46.951][3] Initialization complete
Mon Jan 27 19:11:46 2025 daemon.err usbmuxd[12895]: [19:11:46.952][3] Enabled exit on SIGUSR1 if no devices are attached. Start a new instance with "--exit" to trigger.
Mon Jan 27 19:11:47 2025 daemon.notice netifd: modem_0001_4 (12495): udhcpc: received SIGTERM
Mon Jan 27 19:11:47 2025 daemon.notice netifd: modem_0001_4 (12495): udhcpc: entering released state
Mon Jan 27 19:11:47 2025 daemon.notice netifd: modem_0001_4 (12495): Command failed: Permission denied
Mon Jan 27 19:11:47 2025 daemon.notice netifd: Interface 'modem_0001_4' is now down
Mon Jan 27 19:11:47 2025 daemon.notice netifd: Network alias '' link is down
Mon Jan 27 19:11:47 2025 daemon.notice netifd: Interface 'modem_0001_4' has link connectivity loss
Mon Jan 27 19:11:47 2025 daemon.notice netifd: Interface 'modem_0001_4' is disabled
Mon Jan 27 19:11:47 2025 user.notice firewall: Reloading firewall due to ifdown of modem_0001 ()
Mon Jan 27 19:11:47 2025 kern.info kernel: [   57.468233] net rmnet_mhi0: link_state 0x1 -> 0x0
Mon Jan 27 19:11:47 2025 daemon.notice netifd: Network device 'rmnet_mhi0' link is down
Mon Jan 27 19:11:47 2025 daemon.notice netifd: modem_0001 (11467): [01-27_19:11:35:331] requestGetSIMStatus SIMStatus: SIM_READY
Mon Jan 27 19:11:47 2025 daemon.notice netifd: modem_0001 (11467): [01-27_19:11:35:335] requestGetProfile[1] ORANGE///0/IPV6
Mon Jan 27 19:11:47 2025 daemon.notice netifd: modem_0001 (11467): [01-27_19:11:35:335] requestSetProfile[1] web.vodafone.de///0/IPV4V6
Mon Jan 27 19:11:47 2025 daemon.notice netifd: modem_0001 (11467): [01-27_19:11:35:357] requestRegistrationState2 MCC: 262, MNC: 2, PS: Detached, DataCap: UNKNOW
Mon Jan 27 19:11:47 2025 daemon.notice netifd: modem_0001 (11467): [01-27_19:11:35:360] requestRegistrationState2 MCC: 262, MNC: 2, PS: Detached, DataCap: UNKNOW
Mon Jan 27 19:11:47 2025 daemon.notice netifd: modem_0001 (11467): [01-27_19:11:35:363] requestQueryDataCall IPv4ConnectionStatus: DISCONNECTED
Mon Jan 27 19:11:47 2025 daemon.notice netifd: modem_0001 (11467): [01-27_19:11:35:367] requestQueryDataCall IPv6ConnectionStatus: DISCONNECTED
Mon Jan 27 19:11:47 2025 daemon.notice netifd: modem_0001 (11467): [01-27_19:11:46:114] requestRegistrationState2 MCC: 0, MNC: 0, PS: Detached, DataCap: UNKNOW
Mon Jan 27 19:11:47 2025 daemon.notice netifd: modem_0001 (11467): [01-27_19:11:46:238] requestRegistrationState2 MCC: 262, MNC: 2, PS: Detached, DataCap: UNKNOW
Mon Jan 27 19:11:47 2025 daemon.notice netifd: modem_0001 (11467): [01-27_19:11:46:241] requestRegistrationState2 MCC: 262, MNC: 2, PS: Detached, DataCap: UNKNOW
Mon Jan 27 19:11:47 2025 daemon.notice netifd: modem_0001 (11467): [01-27_19:11:46:904] requestRegistrationState2 MCC: 262, MNC: 2, PS: Detached, DataCap: UNKNOW
Mon Jan 27 19:11:47 2025 daemon.notice netifd: modem_0001 (11467): [01-27_19:11:47:525] QmiWwanThread exit
Mon Jan 27 19:11:47 2025 daemon.notice netifd: modem_0001 (11467): [01-27_19:11:47:525] qmi_main exit
Mon Jan 27 19:11:47 2025 daemon.notice netifd: Interface 'modem_0001' is now down
Mon Jan 27 19:11:47 2025 user.notice kmwan: config json str={ "op": 3, "data": { "cells": [ "modem_0001" ] } }
Mon Jan 27 19:11:47 2025 kern.debug kernel: [   57.917874] kmwan: Delete node:modem_0001
Mon Jan 27 19:11:48 2025 daemon.err usbmuxd[12895]: [19:11:48.772][3] Caught signal 15, exiting
Mon Jan 27 19:11:48 2025 daemon.err usbmuxd[12895]: [19:11:48.772][3] usbmuxd shutting down
Mon Jan 27 19:11:48 2025 daemon.err usbmuxd[12895]: [19:11:48.873][3] Shutdown complete
Mon Jan 27 19:11:49 2025 daemon.err gl_ble_daemon: (ble_manage.c:52) gl_ble_init failed: 1
Mon Jan 27 19:11:49 2025 daemon.err gl_ble_daemon: (main.c:50) ble initial fail!
Mon Jan 27 19:11:56 2025 daemon.err gl_ble_daemon: (ble_manage.c:52) gl_ble_init failed: 1
Mon Jan 27 19:11:56 2025 daemon.err gl_ble_daemon: (main.c:50) ble initial fail!
Mon Jan 27 19:11:57 2025 daemon.notice netifd: Interface 'modem_0001' is setting up now
Mon Jan 27 19:12:01 2025 daemon.notice netifd: modem_0001 (13721): Failed to parse message data
Mon Jan 27 19:12:01 2025 daemon.info gl-repeater[3473]: (repeater.lua:1215) ntp been valid
Mon Jan 27 19:12:03 2025 daemon.err gl_ble_daemon: (ble_manage.c:52) gl_ble_init failed: 1
Mon Jan 27 19:12:03 2025 daemon.err gl_ble_daemon: (main.c:50) ble initial fail!
Mon Jan 27 19:12:03 2025 daemon.info procd: Instance gl-ble-daemon::gl_ble_daemon s in a crash loop 6 crashes, 2 seconds since last crash

I can't really make sense of the modem related errors or why the BLE MQTT service is involved at all, or why there are permission issues on modem (?) commands. I should also mention that I primarily use a wired connection via cable modem and the 5G is for failover, but when we had a cable outage due to bad weather the 5G didn't seem to work (I tested it previously with good stability and performance)

2

Which firmware do you run?

3
  • Version4.0
  • Firmware Type0701release2
  • Update Time2024-12-27 09:13:40 (UTC+00:00)

modue Version

RM520NGLAAR03A03M4G

everything says no updates available

5

You can simulate a power outage and test whether the 5G cellular network is available.

Regarding the gl-ble-daemon process, I have asked if there are problems with development.

6

Yes, I'm going to test the 5G separately to see if this is a persistent problem.

7

Update:

The information printed by the BLE daemon can be ignored, since the hardware does not have a Bluetooth module.

The MQTT service is caused by the disconnection from the WAN (like the modem), which will cause MQTT to reconnect, so it will print.

8

Interestingly the 5G connection seem to be working well now. I am re-wiring the coaxial plug and therefore failing over to 5G and it seems to be OK. Perhaps there was an issue on the Vodafone side previously.

MQTT restarting when WAN drops (which has happened a few times with the cable modem losing signal...) does make sense. Currently I don't see a strong reason to suspect an issue with the GL-X3000.