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

8

Hello ! We could get the logs when the issue happens :

image
image1073×404 79.1 KB

Find attached the logs :

Log_Modem_Connexion_Lost.txt (1.1 MB)

Log_Error_MQTT_Connexion_Lost.rtf (563.3 KB)

Thanks,

pascal

9

Hi Pascal,

First, thank you for the log files for analysis.
What I suspect is that the EAPPS route are changed because of LTE modem recover from OOS( network assign a new PDP content?). And MQTT client do not aware/consider that then it keep previous route rule.
It may also explain why do I not see it on my setup. As I have fixed route rule on my setup.
To confirm that, I will prepare a log recording configuration of DM light tool.
And it will require your help to catch the log for confirmation.

10

Hi Pascal,

1\Could you take attached DM light configuration file
GM02SMQTT_connection.dmrec (479 Bytes)
2\Apply configuration to SQN DM light tool prior start log recording

image
image794×631 97 KB

3\Start log recording prior the initial attach then run the test and collect DM log for us

Let me know if any clarification is required.

11

Hello ! Thanks for your help !

For sure, we will try to reproduce the issue and catch logs with your DM tool’s settings.

Pascal

12

Hi !

Sorry for the delay, we’ve had a lot of activities over the past few weeks.

We finally had time to test your procedure, but we couldn’t get any interesting logs. It seems the DM tool gets stuck during the process, and when the modem goes into deep sleep, the tool appears to stop communicating.

Do you have any idea to fix this tool limitation ?

Thanks,

Pascal

13

Hi Pascal,

Could you kindly get HW configuration with following at commands:

AT+CFUN=5
AT+SQNHWCFG?

I am asking this because UART is usually configured to WAKE up source. Then if UART is used then device will not go to sleep mode. So, that’s have a quick check on this.

14

Hi,

It’s true that the Sequans DM light tool will disconnect when the modem enters low power state.

In that case, I propose to use the AT commands below to diagnose if this is about PDN getting deactivated and activated again after reselecting a new roaming network.

Insert AT+CGEREP=2 at the modem initialization stage. This is a persistent setting. It allows to get URCs when PDN are activated and deactivated.

Below is an example, when the PDN CID#1 is deactivated by network (NW) then re-activated by the modem (ME)

[2026-07-20 09:07:00,066] INFO Uart0 > +CEREG: 1,"0005","01A2D109",7
[2026-07-20 09:07:00,067] INFO Uart0 > +CEREG: 2
[2026-07-20 09:07:00,067] INFO Uart0 > +CGEV: NW PDN DEACT 1
[2026-07-20 09:07:00,605] INFO Uart0 > +CGEV: ME PDN ACT 1
[2026-07-20 09:07:00,607] INFO Uart0 > +CEREG: 1,"0005","01A2D109",7

Also, whenever you receive the “+CGEV: NW PDN ACT” or “+CGEV: ME PDN ACT” URCs, you can trigger AT+CGCONTRDP to get the new IP context:

[2026-07-20 08:34:09,511] INFO Uart0 > +CEREG: 1,"0005","01A2D109",7
[2026-07-20 08:34:09,514] INFO Uart0 < AT+CGCONTRDP
[2026-07-20 08:34:09,627] INFO Uart0 > +CGCONTRDP: 1,5,"default.mnc001.mcc001.gprs","192.168.2.2.255.255.255.255","","192.168.200.99","","","",,,1430,,,,65535
[2026-07-20 08:34:09,628] INFO Uart0 > +CGCONTRDP: 1,5,"default.mnc001.mcc001.gprs","32.1.4.104.32.0.0.1.40.147.153.80.208.184.228.130.255.255.255.255.255.255.255.255.255.255.255.255.255.255.255.255","","32.1.72.96.72.96.0.0.0.0.0.0.0.0.136.136","","","",,,,,,,65535
[2026-07-20 08:34:09,630] INFO Uart0 > OK

Please let us know if you succeeds to gather a new error case.
Best regards,
Benoit