XBee 3 Global LTE Cat 1 TCP server accepts handshake but closes before acknowledging first Modbus/TCP request

We are seeing a second failure pattern with the same XBee 3 Global LTE Cat 1 configuration:

  • Firmware 11521
  • Transparent TCP Server on port 502
  • Modbus TCP client on Windows
  • XBee TS = 7.5 seconds
  • Cellular private network / VPN

A new TCP connection is established successfully, but the XBee closes it before accepting the first Modbus request payload.

Representative packet sequence:

Application -> XBee: SYN
XBee -> Application: SYN, ACK
Application -> XBee: ACK
Application -> XBee: Modbus/TCP request, 12 bytes of TCP payload

XBee -> Application: FIN, ACK, Ack=1
Application -> XBee: ACK
XBee -> Application: RST

The important detail is that the XBee’s FIN acknowledges only the TCP handshake (Ack=1). It does not acknowledge the Modbus payload; if it had accepted the 12-byte request, the acknowledgement would advance to Ack=13.

So the TCP listener accepts the connection, but the application-side connection appears to close before the first Modbus request is accepted. The FIN can occur almost immediately after the request, much faster than the configured 7.5-second TS timeout.

After receiving the FIN, the Windows TCP stack correctly ACKs it. We are updating our client so that a received FIN/EOF/RST immediately retires the socket and schedules a fresh connection after a cooldown; it will not continue to spend Modbus retry attempts on that closed socket.

Questions:

  1. Under what XBee Transparent TCP Server conditions can a newly accepted connection be closed before the first serial/TCP payload is acknowledged?
  2. Could this indicate a stale or partially cleaned-up prior TCP session after a carrier/network path change?
  3. Does the XBee have a documented timing requirement between a prior socket closing and accepting/sending data on a new inbound connection?
  4. Are there firmware fixes after 11521 relevant to this behavior?

EDIT:
We have verified on the remote modbus server device is functional, but it receives no new Modbus requests from the LTE module during this state. In the PCAP, the XBee accepts the TCP handshake but does not acknowledge the first 12-byte Modbus/TCP payload (Ack=1, not Ack=13), then FIN/RSTs the connection. This indicates the request is not being delivered through the XBee Transparent TCP-to-UART path; it is not reaching the attached controller.

EDIT:
We reset the LTE module (airplane mode + powercycling) and all the devices configured this way connected and became operating normally. So what is the mechanism in the XBee that causes this issue?

Please submit a support case for this issue.