uConsole 4G (SIM7600): why you have to restart ModemManager after enabling the modem, and a patch that fixes it

uConsole
, , ,
1

If you use the 4G module and your routine is uconsole-4g-cm4 enable, then sleep, then sudo systemctl restart ModemManager, or if NetworkManager sometimes refuses to connect with

Connection requested IPv4 but IPv4 is unsupported by the modem

or

Connection requested both IPv4 and IPv6 but dual-stack addressing is unsupported by the modem

this post explains the cause and gives a fix.

Setup: uConsole CM4, SIM7600G-H in 9001 mode (USB 1e0e:9001, PPP on ttyUSB2), Debian 13 (Trixie), ModemManager 1.24.0, NetworkManager 1.52.1.

Cause

After power-on, the modem appears on USB well before it has finished initializing its SIM. ModemManager probes it about 10 s later. During initialization ModemManager asks the modem which PDP types it supports (AT+CGDCONT=?), and if the modem isn’t ready yet, it answers ERROR:

[ttyUSB2/at] --> 'AT+CGDCONT=?'
[ttyUSB2/at] <-- 'ERROR'
[ttyUSB2/at] <-- '+CPIN: READY'     (half a second later)
[ttyUSB2/at] <-- 'SMS DONE'
[ttyUSB2/at] <-- 'PB DONE'

ModemManager logs that error only at debug level and never repeats the query. The modem then looks fine (enabled, registered, attached), but its “supported IP families” stay empty. NetworkManager therefore rejects every connection attempt until ModemManager is restarted, which is why the restart trick works. Whether you hit it depends on how fast the modem boots, so it can come and go “by itself”.

Check whether this is your problem:

mmcli -m any --output-keyvalue | grep supported-ip-families

-- means you are affected. A working modem shows ipv4 / ipv6 / ipv4v6.

Fix

A small ModemManager patch makes it retry the query every 2 s for up to 30 s. I tested it with an automated A/B test, 20 modem power-cycles per build, on the same device and SIM:

Build Modem initialized Connected
stock ModemManager 1.24.0 4/20 4/20
patched 20/20 19/20*

* The one failure was caused by the test script itself, not by ModemManager.

With the patched build, uconsole-4g-cm4 enable is enough and NetworkManager connects on its own. No ModemManager restart, no sleep.

The patch, a Debian rebuild recipe, the test script and an improved enable script (it still restarts ModemManager in the rarer sim-missing / unknown-capabilities cases the patch does not cover) are here:

Notes:

  • You have to rebuild the modemmanager package yourself and put it on hold (apt-mark hold), so security updates for it then need re-patching by hand.
  • If you use IPv4 only, also set ipv6.method disabled on the NetworkManager GSM connection.
  • I plan to report this upstream to ModemManager, so that a proper fix ends up in the package.

Other things that can make the modem fail

These are not fixed by the patch:

  • Low battery. The modem’s current peaks while transmitting can reset the internal USB hub. The modem and the keyboard drop off USB (usb usb1-port1: disabled by hub (EMI?)), sometimes until a reboot. Use a charger or a well-charged battery.
  • Weak signal / small antenna. This means higher transmit power, Network timeout errors and modem resets.

Disclosure

I gave these problems to Claude (Anthropic’s AI assistant, in Claude Code) as tasks. The analysis, the patches and the scripts were written by Claude. I tested them on my uConsole. Tested on one device only, so read before you apply anything as root.

Related threads

2

The timing explanation makes sense: the PDP-type query going out before the SIM is ready would leave supported-ip-families unset, and that matches the NetworkManager errors you quoted. The mmcli check is a useful way to confirm it, since an empty value is easy to spot. One thing I’d want to know is whether the retry patch ever delays normal modem detection on units that initialize quickly, and whether you’ve seen it hold up across reboots rather than just power-cycles. Your A/B numbers should make that clear.

3

Thanks. On both points:

Fast-initializing modems: the retry only kicks in when AT+CGDCONT=? returns an error. If the modem answers the first time, the code path is the same as stock and nothing is delayed. In the A/B test the time from power-on to an initialized modem was 27–31 s for both builds. 11 of the 20 patched cycles needed one retry (2 s), and that didn’t change the total noticeably, because the rest of the init takes longer anyway.

Reboots vs. power-cycles: the automated test only power-cycled the modem (via GPIO, without rebooting the CM4). I also rebooted a few times with the patched build. After each reboot uconsole-4g-cm4 enable was enough and NM connected without needing a restart. After a reboot the modem starts powered off and enable turns it on, so MM sees the same sequence as in the test. That’s a handful of reboots, not 20, so more reports from other units are welcome.

Upstream: I’ve reported it to ModemManager now: Making sure you're not a bot!
The problem itself isn’t new. The SIM7600 answering too early while it boots is already in #725. Empty supported IP families (“IPv4 is unsupported by the modem”) came up on modemmanager-devel in 2024 and in #705. Here on the forum, people have used the “restart ModemManager after enable” workaround for years. As far as I can tell, nobody had tracked it down to the one failed AT+CGDCONT=? query, and no fix has gone in so far.

4

I used the delay script, just because cpi had a tread about using the modem when the uconsole first released and talked about boot time. Also works well to use scripts because the AIO had a lora module boot time too… One of the things you deal with when using the ext port. Awesome for the community to contribute to the larger world though!