Mudi 7 (GL-E5800) connects successfully, receives IP and default route, then immediately disconnects again

Router
1

Hi everyone,

I’m experiencing a problem with my GL.iNet Mudi 7 (GL-E5800) which seems to be different from the already known idle reconnect issue.

Device

  • GL.iNet Mudi 7 (GL-E5800)

  • Firmware: 4.8.5

  • OpenWrt 23.05.4

  • Cellular package updated to the official test package provided by Cathy:

    • gl-sdk4-cellular git-2026.156.24582-f1aa5a0-1

  • kmwan:

    • kmod-gl-sdk4-kmwan 5.15+git-2026.131.42937-4216576-1

SIM

I’m using a Yesim eSIM.

The problem occurs while roaming on Vodafone Italy, but I have also seen similar behaviour in France.

The APN is:

plus

Roaming is enabled.

What happens

The modem successfully registers on the network.

AT commands show the modem is attached to Vodafone IT.

During connection the router briefly becomes fully operational.

ifstatus modem_cpu shows:

  • up: true

  • rmnet interface present

  • IPv4 address assigned

  • default route installed

Example:

"up": true,

"l3_device": "rmnet_data0",

"ipv4-address": [

{

"address": "10.xxx.xxx.xxx",

"mask": 30

}

],

"route": [

{

"target": "0.0.0.0",

"mask": 0,

"nexthop": "10.xxx.xxx.xxx"

}

]

Only a few seconds later the interface disappears again and the web UI returns to Connecting…

Log behaviour

The logs repeatedly show something similar to:

ACTION=ifup

INTERFACE=modem_cpu

...

kmwan: Delete node: modem_cpu

...

ACTION=ifdown

INTERFACE=modem_cpu

So the modem successfully connects first, then the interface is immediately brought down again.

Why I think this is different from the known reconnect issue

I already installed the official test package for the idle reconnect bug.

That package appears to fix the original problem where the modem never reconnects after a carrier disconnect.

However, my issue is different:

  • the modem does connect

  • it does receive an IP address

  • it does install a default route

  • then it disconnects again within a few seconds.

This does not look like a failed PDP activation or APN problem.

Additional observations

  • ifstatus modem_cpu briefly shows up: true.

  • The assigned IPv4 address and default route are visible.

  • Uptime is typically still 0 when the interface disappears.

  • The web UI never stays connected for more than a few seconds.

Questions

  1. Has anyone seen this behaviour before?

  2. Could this be an interaction between the updated gl-sdk4-cellular package and the older kmwan package?

  3. Are there any debug logs I can collect that would help identify why modem_cpu is immediately brought down after a successful connection?

I’m happy to provide additional logs or run any debug commands if needed.

Thanks!

1 Like
3

Hello, could you please help to get the cellular debug log for analysis:

  1. log in to the ssh terminal, enter the following command:
    Cellular_debug.sh 1
  2. wait for about 3 minutes, enter the following ssh command to stop the debug process:
    Cellular_debug.sh 0
  3. export the /tmp/cellular_manager.log and share it with us.

Thank you.

4

modemlog.txt (5.6 KB)

was only allowed to add one link

5

Thanks for your quick response.

I have attached both requested log files:

  • cellular_manager.log
  • modemlog.txt (captured with watch ifstatus modem_cpu)

One important note regarding the timestamps:

The Mudi's system clock was not synchronized while these logs were recorded, so the timestamps in the logs are incorrect.

The logs show dates around July 26/27, but they were actually captured on July 28 at approximately 10:45 CEST (UTC+2).

I hope this helps with correlating the events.

Please let me know if you need any additional debug logs or if there are specific commands you would like me to run.

cellular_manager.txt (2.4 MB)

7

Based on the current device logs, the cellular data session appears to have been disconnected by the carrier shortly after the connection was established, causing the network to drop immediately.

At this stage, we suspect this may be related to the carrier network or the SIM card status. Additional modem logs are required for further confirmation.

Could you please assist with the following:

  1. Share the device to GoodCloud and send me the device login password via private message, so we can access it remotely for further troubleshooting.
  2. Insert a USB drive into the device, so we can collect modem logs for deeper analysis.

Thank you for your cooperation.

8

Not being able to provide the requested log right now, I contacted yesim support.

It seems I ran into a fair usage policy being put on my esim. Support was seemingly able to reset the FUP as the Mudi was able to connect right after I powered it on.

I have been producing 92GB of traffic between the 17th and 26th of July, when the SIM stopped working without any notice.

My learning, check with the SIM provider first before running into a debugging rabbit hole.

Thanks for your support anyways and sorry for suspecting the Mudi being at fault here.

Kind Regards, Eike

1 Like