XBee3 LTE-M/NB-IoT Listener socket closed shortly after creating listener socket

XBee & XBee Gateway XBee - Cellular
, , , ,
1

I have been testing the XBee3 LTE-M/NB-IoT with incoming TCP connections and I have been seeing some strange behaviour when using extended socket frames.

I create a socket using the Socket Create frame and then set it to listen on a certain port using the Socket Bind/Listen frame. Usually this works fine and connections can be made to the listening port. However, sometimes after sending the Socket Bind/Listen frame and getting a success response I get a Socket State frame about 4s - 4.5s later saying that the listener closed.

This happens regardless of whether or not a connection attempt was made to the listener socket in that time. Once this starts happening it happens every time I try to create a listener socket until the XBee is reset. At this point I’m not sure what causes this behaviour to start. The only information that I have for replicating it is that it seems to happen after the device has disassociated and re-associated a couple of times. (Possibly due to poor RSSI.)

In order to recover from this state a Force Reset is required. I have also tried a Network Reset but the issue persisted.

Any thoughts on why this might be happening? It would be nice not to have to be able to detect this failure mode and take corrective action.

Regards,
Donald

2

Have you checked the TM and TS commands?

Have you queried the radio to see how many ports are currently open?

3

Great post, a lot of stuff in here i did not know about

4

TM and TS are both set to their default of 5 minutes.

At the time when this behaviour is happening the only open socket (as reported by the SI command) is the listener socket that I am creating and is getting automatically closed.

I’ve done some more testing on this today and this behaviour starts happening after the modem drops off the network and reconnects. i.e. after I see a “device disassociated” and then “device associated” modem status packets. As far as I can tell by looking at the Associate LED and watching the modem status packets the modem is definitely connected to the network at the point where my listener socket keeps getting closed.

This is the output from SI after creating the socket.
0x0C
ALLOCATED
TCP
0x0000
0x0000
0.0.0.0

This is the output from SI after setting the socket to listen but before it is automatically closed.
0x0C
LISTENING
TCP
0x0100
0x0000
0.0.0.0

5

Yeah it’s definitely worth making sure you have the latest version of the user manual. I didn’t realise I had an older version until I was looking through the firmware release notes and saw all of the new features that I hadn’t seen in the copy of the manual I had.

6

In the new sockets, you can tell the device to drop the socket after the data is received or you can tell it to keep it open. Which of these functions are you using?

7

I’m not sure what you mean by the option to close to socket after the data is received. This seems to be an option for Transmit Request frames but I am using extended sockets with the Socket Create and Socket Bind/Listen frames. As far as I can tell from the user manual neither the Socket Create or Socket Bind/Listen frames have such an option.

I’ve been doing some unrelated testing with setting the bandmask manually for LTE-M and NB-IoT and the behaviour of this particular issue has changed. Now after the modem disassociates and re-associates to the network, listener sockets are no longer automatically closed as soon as they are created, they now stay open. However I am unable to connect to them when prior to the disassociation/re-association I had no trouble connecting to the listener socket that I had made.