MQTT/TCP connection stuck after network loss – recovery only after keep‑alive timeout (Monarch 2, FW 8.2.1.0)

LTE-M / NB-IoT (Monarch)
1

Hello !

We observe an issue that looks like a TCP half‑open connection on a Monarch 2 modem when using MQTT.

Setup:

  • Monarch 2, firmware 8.2.1.0

  • MQTT over TCP, keep‑alive = 300 s

Reproduction:

  1. Connect the modem to the MQTT broker.

  2. Physically disconnect the antenna.
    → The modem must report +CEREG: 80 (detached / lost coverage).

  3. While the antenna is disconnected, send an MQTT downlink message.

  4. Reconnect the antenna to restore coverage.
    → Upon reconnection, we must observe +CEREG: 2 followed by a successful attachment (+CEREG: 1 or 5).
    → If +CEREG: 0 is reported, the scenario is not valid.

After the modem reattaches to the network (CEREG=1 or 5), incoming MQTT messages are not received anymore. The connection appears to remain open, but downlink traffic is blocked.
The situation only recovers after the MQTT keep‑alive timeout (300 s). At that point, communication resumes and queued messages are received in a burst, causing duplicates.

It looks like after the network interruption, the TCP socket is not correctly reset, and RX traffic only resumes once the modem initiates a new exchange.

Reducing the keep‑alive is not an option due to power consumption constraints. As a workaround, we currently force an MQTT transmission after detecting network detach/reattach, which restores communication.

Is this behavior expected or known on Monarch 2 (FW 8.2.1.0)?
Could this issue be related to LTE‑M network behavior, such as NAS signaling, context preservation, or LTE‑M specific TCP/NAT handling after coverage loss?

Thanks

image-20260421-080018
image-20260421-0800181590×830 76.1 KB

2

Hi Pascal,

Thank you for raising this to us. I will first try to reproduce it on my setup then back to you.

3

Hi, any update ? Did you manage to reproduce this issue ? Thanks

4

Hi Pascal,

1\First, sorry for my delay reply.
2\I am trying to reproduce it on my setup for this OOS scenario. And LTE modem manage to send the message once it recovery from OOS. As you can see it:

16:24:11’781.27> level >>>> msg - FEEDS - 8:24 11.680 >| EAPPS/ROUTE audit >| mpdnRouteCtxRemoveMpdnRoutes:160 Removing MPDN route (cid 1, dst port 60149, src addr 192.168.2.1, src port 8083)
16:24:11’781.52> level >>>> msg - FEEDS - 8:24 11.680 >| MQTT/SQNSMQTT SEVERE >| mosquitto_loop() failed with 7 (The connection was lost.)
16:24:11’781.58> level >>>> msg - FEEDS - 8:24 11.680 >| MQTT/SQNSMQTT WARNING >| mqtt connection was lost, reconnecting…
16:24:12’773.59> level >>>> msg - FEEDS - 8:24 12.680 >| EAPPS/ROUTE audit >| add_mpdn_route:117 Adding MPDN route (cid 1, dst port 60150, src addr 192.168.2.1, src port 8083)
16:24:12’814.97> level >>>> msg - FEEDS - 8:24 12.720 >| MQTT/SQNSMQTT WARNING >| mosquitto logger: Warning: Unable to open socket pair, outgoing publish commands may be delayed.
16:24:13’897.26> (DL EARFCN=5035 PCI=1) RRC BCCH BCH message :
48 04 20
16:24:13’930.10> (DL EARFCN=5035 PCI=1) RRC BCCH DL SCH System Information Block Type 1 message :
16:24:19’026.83> (DL EARFCN=5035 PCI=1) RRC PCCH message :
40 00 10 8c d5 e9 00
16:24:19’028.54> UL NAS Service request :
c7 1e 1e b9

3\ Is that possible we can leverage your setup to collect log for analysis. If you are okay with this, I can prepare the log tool and simple guide for this log capture thing.

5

Hello !

Thanks for your answer.

For sure, we can get the log when the issue happens. We already know how to get the log from the GM02S.

Thanks !

Pascal

6

Hi Pascal,
Noted, thank you. I assume you will need to obtain the board from the supplier’s facilities. Is that right?

7

Hello !

for this issue, we already have the board. We need to find time to make the setup and then get the log :slight_smile:

Thank you,

I come back to you ASAP !

Pascal