Version 2.60
I have one client out of about 50 that is just not holding a connection. We thought network issues, but I am able to connect to the device via SSH with no issues and not being disconnected. Also have other devices from the same network, that are fine, so no firewall issue (with assurance from the network team).
Looking into the logs, I see 3 things for this one client I am working on:
Info Connect, many Warn Messages, then Error connecting client timed out, and it just repeats.
2025/12/17 10:04:49
c.c.c.s.core.PacketHandler
INFO
CONNECT - [c1f9dbc9-0ad3-49d4-bf8e-ec7230761c41, —–][C][0] NEW Client Session
2025/12/17 10:04:49
c.c.c.s.core.PacketHandler
WARN
No client session [c1f9dbc9-0ad3-49d4-bf8e-ec7230761c41, /—–] found for packet of type PUBLISH, session has likely been disconnected
2025/12/17 10:04:59
c.c.c.s.core.AbstractConnectionListener
ERROR
[DEFAULT] Connecting client timed out (10000ms)for: [c1f9dbc9-0ad3-49d4-bf8e-ec7230761c41, /-----]
And the pattern then repeats with a different session ID. I Am at a loss as to what to look for to correct this issue with this one device.
Can you transfer a large file between the two systems? That is typically a better test to emulate an MQTT connection and data than an SSH connection.
Yes, I tested a file transfer and that was no problem.
Is there anything different about the failing client? Is it the same type as the others? Is it running the same software version?
Nothing different. Device is Raspberry PI with custom C application to publish data. I have 40 plus other Pi’s already doing this. All the software on these devices were deployed with Ansible, so they are all carbon copies of each other.
How big was the file you transferred? I would try with something fairly large - at least many 10s of Megabytes. Also, if you transfer the same file from one of the good units to the MQTT Server, does it happen in the same amount of time? Is there any logging you can look at on the client side? What does it think is happening during a connect operation? You could also try increasing the connectTimeout. See here: com.cirruslink.chariot.server - Chariot MQTT Server v2 Documentation - Confluence
From the Non Working RPI to Chariot using SCP, 1.9GB took just over 11 minutes which is what I would expect as the RPI is on Wireless.
From the Working RPI to Chariot using SCP the same file took just over 11 minutes as well…
From the log files on the Chariot side for the device failing:
| 2025/12/22 16:33:17 |
c.c.c.s.core.AbstractConnectionListener |
ERROR |
[DEFAULT] Connecting client timed out (10000ms)for: [d157b3f6-c256-4e26-a963-3562809b45a2, /10.105.22.16] |
| 2025/12/22 16:33:17 |
c.c.c.s.core.PacketHandler |
WARN |
No client session [d157b3f6-c256-4e26-a963-3562809b45a2, /10.105.22.16] found for packet of type PUBLISH, session has likely been disconnected |
| 2025/12/22 16:33:17 |
c.c.c.s.core.PacketHandler |
WARN |
No client session [d157b3f6-c256-4e26-a963-3562809b45a2, /10.105.22.16] found for packet of type PUBLISH, session has likely been disconnected |
| 2025/12/22 16:33:16 |
c.c.c.s.core.PacketHandler |
WARN |
No client session [d157b3f6-c256-4e26-a963-3562809b45a2, /10.105.22.16] found for packet of type PUBLISH, session has likely been disconnected |
| 2025/12/22 16:33:16 |
c.c.c.s.core.PacketHandler |
WARN |
No client session [d157b3f6-c256-4e26-a963-3562809b45a2, /10.105.22.16] found for packet of type PUBLISH, session has likely been disconnected |
| 2025/12/22 16:33:16 |
c.c.c.s.core.PacketHandler |
WARN |
No client session [d157b3f6-c256-4e26-a963-3562809b45a2, /10.105.22.16] found for packet of type PUBLISH, session has likely been disconnected |
=====================================
I removed a bunch in the middle
====================================
| 2025/12/22 16:33:07 |
c.c.c.s.core.PacketHandler |
WARN |
No client session [d157b3f6-c256-4e26-a963-3562809b45a2, /10.105.22.16] found for packet of type PUBLISH, session has likely been disconnected |
| 2025/12/22 16:33:07 |
c.c.c.s.core.PacketHandler |
WARN |
No client session [d157b3f6-c256-4e26-a963-3562809b45a2, /10.105.22.16] found for packet of type PUBLISH, session has likely been disconnected |
| 2025/12/22 16:33:07 |
c.c.c.s.core.PacketHandler |
WARN |
No client session [d157b3f6-c256-4e26-a963-3562809b45a2, /10.105.22.16] found for packet of type PUBLISH, session has likely been disconnected |
| 2025/12/22 16:33:07 |
c.c.c.s.core.PacketHandler |
WARN |
No client session [d157b3f6-c256-4e26-a963-3562809b45a2, /10.105.22.16] found for packet of type PUBLISH, session has likely been disconnected |
| 2025/12/22 16:33:07 |
c.c.c.s.core.PacketHandler |
WARN |
No client session [d157b3f6-c256-4e26-a963-3562809b45a2, /10.105.22.16] found for packet of type PUBLISH, session has likely been disconnected |
| 2025/12/22 16:33:07 |
c.c.c.s.core.PacketHandler |
WARN |
No client session [d157b3f6-c256-4e26-a963-3562809b45a2, /10.105.22.16] found for packet of type PUBLISH, session has likely been disconnected |
| 2025/12/22 16:33:07 |
c.c.c.s.core.PacketHandler |
INFO |
CONNECT - [d157b3f6-c256-4e26-a963-3562809b45a2, pi9eba322071e440aa, /10.105.22.16][C][1] NEW Client Session |
So the network seems like it may be ok. It might be worth checking for an active firewall that may be configured to terminate MQTT sessions. From the server side, it sees the client attempt to connect, but the session is never fully established. Is this a plain TCP MQTT, TLS MQTT, Websocket, or Secure Websocket connection? Also, is there any available logging on the client side that might give hints about what it sees happening?