receive UDP on nRF9160-dk SLM application

[AndMar8]

Hi,

I want to receive UPD message on my nRF9160-DK.

I can send UDP messages from my Nordic device to a server and from that messages I get the public IP address of my module. But when I try to receive messages, I don't receive anything.  

I use the serial LTE modem application.

I see the following links to send messages:

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/applications/serial_lte_modem/doc/TCPIP_AT_commands.html#udp-receive-data-xrecvfrom

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/applications/serial_lte_modem/doc/slm_description.html

First try:

AT#XSOCKET=1,2,0

#XSOCKET: 1, 2, 0, 17

OK

AT#XSENDTO="x.x.x.x",20080,1,"Test UDP"

#XSENDTO: 8

OK

AT#XSOCKET=0

#XSOCKET: 0, closed

OK

AT#XSOCKET=1,2,1

#XSOCKET: 1, 2, 1, 17

OK

AT#XBIND=3442

OK

AT#XRECVFROM

and after this I get: "Error: 'AT#XRECVFROM' timed out"  and I cannot send AT command to LTE Link Monitor.

-------------------------------------------------------------------------

Second try:

AT#XSOCKET=1,2,0

#XSOCKET: 1, 2, 0, 17

OK

AT#XSENDTO="x.x.x.x",20080,1,"Test UDP"

#XSENDTO: 8

OK

AT#XSOCKET=0

#XSOCKET: 0, closed

OK

AT#XSOCKET=1,2,1

#XSOCKET: 1, 2, 1, 17

OK

AT#UDPRECVFROM="x.x.x.x",3442

+CME: 0

Here I don't know how to solve this error.


-------------------------------------------------------------------------

Third try:

I set the UDP proxy to use the command AT#XUDPSVR;
So in "Configure nRF Connect SDK Project" I select "Stateful connection-oriented UDP client/server <SLM_UDP_PROXY>"

AT#XUDPCLI=1,"x.x.x.x",20080

#XUDPCLI: 1 connected

OK

%CESQ: 32,1,19,2

%CESQ: 29,1,24,3

AT#XUDPSEND=1,"Test UDP"

#XUDPSEND: 8

OK

AT#XUDPCLI=0

#XUDPCLI: disconnected

OK

AT#XUDPSVR=1,3442 or AT#XUDPSVR=2,3442

#XUDPSVR: 1 started

OK

Here it seems to work but I don't receive anything and retrying I get sometimes: "Error: 'AT#XUDPSVR=1,3442 ' timed out"

I try using the IP that I get in the receiving messages and also with the IP that I get with the command "AT+CGDCONT?"

I try also using the example script "client_udp.py" but nothing.

I try many times with all possible combinations.

What can I do? The nRF9160-DK receives messages but doesn't print them on the LTE Link Monitor or I'm using wrong AT command? Is there an error in the client code? Is the IP that I use the error? Is it possible that my server doesn't know how to reach my APN even if I specify the correct public IP address?

Please, help me to receive a simple "hello".
Thank you in advance.

Best regards

[Didrik Rokhaug]

Hi,

You should not close the socket after sending data, for so to open a new socket that you listen on.

Instead, you should listen on the same socket that you sent data from.

Also, be aware that due to Christmas vacations, response times might be slower than normal.

Best regards,

Didrik

[AndMar8]

Hi,
Thanks for the answer.
I tried without closing the socket but the recvfrom returns always this error: "Error: 'AT#XRECVFROM ' timed out" and always from here I can't send AT command through the LTE Link Monitor.
In the following I put the command used:

First try:

AT#XSOCKET=1,2,1
#XSOCKET: 1, 2, 1, 17
OK

AT#XBIND=3442
OK

AT#XSENDTO="x.x.x.x",20080,1,"Test UDP"
#XSENDTO: 8
OK

AT#XRECVFROM (here stops)

-----------------------------------------------------------

Second try:

AT#XSOCKET=1,2,0
#XSOCKET: 1, 2, 0, 17
OK

AT#XSENDTO="x.x.x.x",20080,1,"Test UDP"
#XSENDTO: 8
OK

AT#XRECVFROM (here stops)

I have to change something in the project file?

I closed socket in previous tries because I thought that I have to set the socket in client mode (AT#XSOCKET=1,2,0) to send messages and in server mode (AT#XSOCKET=1,2,1) to receive messages.

Best regards

 

[Achim Kraus]

Usually, neither the local ip-address your nRF9160 nor the local port you use will be visible at the server. The mobile provider mostly use a NAT, which exchanges that address and port. And because of that NAT, you must respond "in time". I would try to start with less than 30s. 

[Didrik Rokhaug]

AndMar8 said:

I didn't find CONFIG_SLM_LOG_LEVEL=y so I guess you mean CONFIG_SLM_LOG_LEVEL_DBG=y (I hope it's correct).

 Yes, sorry. That was a typo on my part.

I also forgot to mention that you have to comment out the CONFIG_SLM_LOG_LEVEL_INF=y line (or replace it with *_DBG=y).

I have also done some more tests myself, and it doesn't seem like the recvfrom call actually gets registered in the modem trace unless it returns some data.

So the 2nd point in my last comment doesn't seem to be an actual problem, just another indication that the device never receives the response.

 

AndMar8 said:

is there an at command to get the IP address of my nRF9160?

 AT+CGDCONT?

But, it is worth noting what Achim Kraus says about NAT.

[Didrik Rokhaug]

Hi AndMar8,

Could you try the following sequence of commands (with the same server and port)?

AT+CEREG=5
AT+CSCON=1
AT+CFUN=1
// Wait for the nRF9160 to be connected (CEREG 1 or 5)
AT#XSOCKET=1,2,0
AT#XSENDTO="84.215.43.232",56227,1,"<some text here>"
AT#XRECVFROM

You should then end up with a log similar to this (if you have enabled debug logging):

Fullscreen slm_udp_working.txt Download

*** Booting Zephyr OS build v2.4.0-ncs1  ***
Ready
[00:00:00.231,994] <inf> app: Serial LTE Modem
[00:00:00.232,177] <dbg> at_host: TX
52 65 61 64 79 0d 0a                             |Ready..          
[00:00:00.232,177] <dbg> at_host.slm_at_host_init: at_host init done
at+cereg=5
OK
[00:00:06.317,932] <dbg> at_host: RX
61 74 2b 63 65 72 65 67  3d 35                   |at+cereg =5      
[00:00:06.318,450] <dbg> at_host.uart_callback: RX_DISABLED
[00:00:06.328,948] <dbg> at_host: TX
[00:00:06.329,010] <dbg> at_host: TX
4f 4b 0d 0a                                      |OK..             
at+cscon=1
OK
[00:00:09.456,085] <dbg> at_host: RX
61 74 2b 63 73 63 6f 6e  3d 31                   |at+cscon =1      
[00:00:09.456,604] <dbg> at_host.uart_callback: RX_DISABLED
[00:00:09.466,735] <dbg> at_host: TX
[00:00:09.466,796] <dbg> at_host: TX
4f 4b 0d 0a                                      |OK..             
at+cfun=1
OK
[00:00:12.772,094] <dbg> at_host: RX
61 74 2b 63 66 75 6e 3d  31                      |at+cfun= 1       
[00:00:12.772,613] <dbg> at_host.uart_callback: RX_DISABLED
[00:00:12.844,238] <dbg> at_host: TX
[00:00:12.844,299] <dbg> at_host: TX
4f 4b 0d 0a                                      |OK..             
+CEREG: 2,"76C1","014A3901",7,0,0,"11100000","11100000"
+CSCON: 1
[00:00:14.167,694] <dbg> at_host: TX
2b 43 45 52 45 47 3a 20  32 2c 22 37 36 43 31 22 |+CEREG:  2,"76C1"
2c 22 30 31 34 41 33 39  30 31 22 2c 37 2c 30 2c |,"014A39 01",7,0,
30 2c 22 31 31 31 30 30  30 30 30 22 2c 22 31 31 |0,"11100 000","11
31 30 30 30 30 30 22 0d  0a                      |100000". .       
[00:00:14.195,556] <dbg> at_host: TX
2b 43 53 43 4f 4e 3a 20  31 0d 0a                |+CSCON:  1..     
+CEREG: 5,"76C1","014A3901",7,,,"00000010","00000110"
[00:00:16.082,397] <dbg> at_host: TX
2b 43 45 52 45 47 3a 20  35 2c 22 37 36 43 31 22 |+CEREG:  5,"76C1"
2c 22 30 31 34 41 33 39  30 31 22 2c 37 2c 2c 2c |,"014A39 01",7,,,
22 30 30 30 30 30 30 31  30 22 2c 22 30 30 30 30 |"0000001 0","0000
30 31 31 30 22 0d 0a                             |0110"..          
at+cgdcont?
+CGDCONT: 0,"IP","ibasis.iot","10.160.177.45",0,0
OK
[00:00:18.583,740] <dbg> at_host: RX
61 74 2b 63 67 64 63 6f  6e 74 3f                |at+cgdco nt?     
[00:00:18.584,259] <dbg> at_host.uart_callback: RX_DISABLED
[00:00:18.595,428] <dbg> at_host: TX
2b 43 47 44 43 4f 4e 54  3a 20 30 2c 22 49 50 22 |+CGDCONT : 0,"IP"
2c 22 69 62 61 73 69 73  2e 69 6f 74 22 2c 22 31 |,"ibasis .iot","1
30 2e 31 36 30 2e 31 37  37 2e 34 35 22 2c 30 2c |0.160.17 7.45",0,
30 0d 0a                                         |0..              
[00:00:18.599,945] <dbg> at_host: TX
4f 4b 0d 0a                                      |OK..             
at#xsocket=1,2,0
#XSOCKET: 1, 2, 0, 17
OK
[00:00:24.831,848] <dbg> at_host: RX
61 74 23 78 73 6f 63 6b  65 74 3d 31 2c 32 2c 30 |at#xsock et=1,2,0
[00:00:24.832,366] <dbg> at_host.uart_callback: RX_DISABLED
[00:00:24.842,163] <dbg> at_host: TX
23 58 53 4f 43 4b 45 54  3a 20 31 2c 20 32 2c 20 |#XSOCKET : 1, 2, 
30 2c 20 31 37 0d 0a                             |0, 17..          
[00:00:24.842,163] <dbg> tcpip.do_socket_open: Socket opened
[00:00:24.844,238] <dbg> at_host: TX
4f 4b 0d 0a                                      |OK..             
+CSCON: 0
[00:00:27.609,008] <dbg> at_host: TX
2b 43 53 43 4f 4e 3a 20  30 0d 0a                |+CSCON:  0..     
at#xsendto="84.215.43.232",56227,1,"didrik port test"
#XSENDTO: 16
OK
+CSCON: 1
[00:00:30.552,490] <dbg> at_host: RX
61 74 23 78 73 65 6e 64  74 6f 3d 22 38 34 2e 32 |at#xsend to="84.2
31 35 2e 34 33 2e 32 33  32 22 2c 35 36 32 32 37 |15.43.23 2",56227
2c 31 2c 22 64 69 64 72  69 6b 20 70 6f 72 74 20 |,1,"didr ik port 
74 65 73 74 22                                   |test"            
[00:00:30.552,825] <dbg> tcpip.parse_host_by_ipv4: IPv4 Address 84.215.43.232
[00:00:30.552,856] <dbg> tcpip.do_udp_init: UDP initialized
[00:00:30.553,009] <dbg> at_host.uart_callback: RX_DISABLED
[00:00:30.561,676] <dbg> at_host: TX
23 58 53 45 4e 44 54 4f  3a 20 31 36 0d 0a       |#XSENDTO : 16..  
[00:00:30.561,706] <dbg> tcpip.do_sendto: UDP sent
[00:00:30.580,383] <dbg> at_host: TX
4f 4b 0d 0a                                      |OK..             
[00:00:30.665,832] <dbg> at_host: TX
2b 43 53 43 4f 4e 3a 20  31 0d 0a                |+CSCON:  1..     
at#xrecvfrom
didrik port test
#XRECVFROM: 1, 16
OK
[00:00:40.058,105] <dbg> at_host: RX
61 74 23 78 72 65 63 76  66 72 6f 6d             |at#xrecv from    
[00:00:40.058,410] <dbg> at_host: TX
64 69 64 72 69 6b 20 70  6f 72 74 20 74 65 73 74 |didrik p ort test
[00:00:40.058,624] <dbg> at_host.uart_callback: RX_DISABLED
[00:00:40.059,875] <dbg> at_host: TX
0d 0a 23 58 52 45 43 56  46 52 4f 4d 3a 20 31 2c |..#XRECV FROM: 1,
20 31 36 0d 0a                                   | 16..            
[00:00:40.059,875] <dbg> tcpip.do_recvfrom: UDP received
[00:00:40.061,798] <dbg> at_host: TX
4f 4b 0d 0a                                      |OK..             
+CSCON: 0
[00:00:42.356,109] <dbg> at_host: TX
2b 43 53 43 4f 4e 3a 20  30 0d 0a                |+CSCON:  0..     

As you can see from the log, I have verified that this server works, and I am able to communicate with it with my nRF9160DK and iBasis SIM card.

I also have some logging running on the server, so it I can confirm that it receives the packet and sends a response.

And, as always, if you could share the log and modem trace afterwards, that would be great.

[AndMar8]

Hi,

Unluckily I had already tried with the IP that I got with AT+CGDCONT? and I have the same results.

Just to let you know, I had done other test with different types of protocol of communication:

MQTT works fine: I connect the nRF9160 to a topic of a block of NODE-RED and i can receive and send messages.

TCP works fine only if I use the nRF9160 as client which has to connect to NODE-RED (as server). In this case I can send and receive message.
But if I use NODE-RED as client which has to connect to nRF9160 (as server), when I use the commands AT#XLISTEN and AT#XACCEPT, nothing happens.
I try both with the IP address of the screenshot (151.x.x.x) and with the IP address that I get with the command AT+CGDCONT? (10.x.x.x).

I think it could be for the same reason of UDP RECVFROM.

However I think that the correct IP address is 151.x.x.x and not 10.x.x.x.

I found out also that in the LTE Link monitor if I got in the Log window:

 Error: 'at#xrecvfrom' timed out 

It doesn't block the code as I thought but it's still worked. I got the same error with TCP protocol and AT#XRECV but I can receive messages, too. So fine :).

What kind of application do you use to send udp messages to nRF9160-dk? So I'll try with it, instead of NODE-RED. Probably has problem with UDP protocol.

Now I try the commands you send me! Thank you very much! 

[AndMar8]

Hi,

I have just tried and it works. I receive my same message.

The output file is shared.

So the AT command works but I don't know why my NODE-RED for udp doesn't work. Could you see the IP address that is used by your server to reply to my message?

Fullscreen udp.txt Download

*** Booting Zephyr OS build v2.4.0-ncs2  ***
Ready
[00:00:00.205,688] [1B][0m<inf> app: Serial LTE Modem[1B][0m
[00:00:00.205,871] [1B][0m<dbg> at_host: TX
52 65 61 64 79 0d 0a                             |Ready..          [1B][0m
[00:00:00.205,902] [1B][0m<dbg> at_host.slm_at_host_init: at_host init done[1B][0m
AT+CEREG=5
OK
[00:00:31.184,631] [1B][0m<dbg> at_host: RX
41 54 2b 43 45 52 45 47  3d 35                   |AT+CEREG =5      [1B][0m
[00:00:31.185,150] [1B][0m<dbg> at_host.uart_callback: RX_DISABLED[1B][0m
[00:00:31.194,152] [1B][0m<dbg> at_host: TX[1B][0m
[00:00:31.194,213] [1B][0m<dbg> at_host: TX
4f 4b 0d 0a                                      |OK..             [1B][0m
AT+CSCON=1
OK
[00:00:43.160,430] [1B][0m<dbg> at_host: RX
41 54 2b 43 53 43 4f 4e  3d 31                   |AT+CSCON =1      [1B][0m
[00:00:43.160,949] [1B][0m<dbg> at_host.uart_callback: RX_DISABLED[1B][0m
[00:00:43.169,372] [1B][0m<dbg> at_host: TX[1B][0m
[00:00:43.169,433] [1B][0m<dbg> at_host: TX
4f 4b 0d 0a                                      |OK..             [1B][0m
AT+CFUN=1
OK
[00:00:55.841,583] [1B][0m<dbg> at_host: RX
41 54 2b 43 46 55 4e 3d  31                      |AT+CFUN= 1       [1B][0m
[00:00:55.842,102] [1B][0m<dbg> at_host.uart_callback: RX_DISABLED[1B][0m
[00:00:55.881,561] [1B][0m<dbg> at_host: TX[1B][0m
[00:00:55.881,622] [1B][0m<dbg> at_host: TX
4f 4b 0d 0a                                      |OK..             [1B][0m
+CEREG: 2,"993A","0DC16447",9,0,0,"11100000","11100000"
+CSCON: 1
[00:00:59.546,997] [1B][0m<dbg> at_host: TX
2b 43 45 52 45 47 3a 20  32 2c 22 39 39 33 41 22 |+CEREG:  2,"993A"
2c 22 30 44 43 31 36 34  34 37 22 2c 39 2c 30 2c |,"0DC164 47",9,0,
30 2c 22 31 31 31 30 30  30 30 30 22 2c 22 31 31 |0,"11100 000","11
31 30 30 30 30 30 22 0d  0a                      |100000". .       [1B][0m
[00:00:59.907,653] [1B][0m<dbg> at_host: TX
2b 43 53 43 4f 4e 3a 20  31 0d 0a                |+CSCON:  1..     [1B][0m
+CEREG: 1,"993A","0DC16447",9,,,"00011110","00011101"
[00:01:02.925,445] [1B][0m<dbg> at_host: TX
2b 43 45 52 45 47 3a 20  31 2c 22 39 39 33 41 22 |+CEREG:  1,"993A"
2c 22 30 44 43 31 36 34  34 37 22 2c 39 2c 2c 2c |,"0DC164 47",9,,,
22 30 30 30 31 31 31 31  30 22 2c 22 30 30 30 31 |"0001111 0","0001
31 31 30 31 22 0d 0a                             |1101"..          [1B][0m
+CSCON: 0
[00:01:06.049,255] [1B][0m<dbg> at_host: TX
2b 43 53 43 4f 4e 3a 20  30 0d 0a                |+CSCON:  0..     [1B][0m
AT#XSOCKET=1,2,0
#XSOCKET: 1, 2, 0, 17
OK
[00:01:18.898,529] [1B][0m<dbg> at_host: RX
41 54 23 58 53 4f 43 4b  45 54 3d 31 2c 32 2c 30 |AT#XSOCK ET=1,2,0[1B][0m
[00:01:18.899,047] [1B][0m<dbg> at_host.uart_callback: RX_DISABLED[1B][0m
[00:01:18.907,714] [1B][0m<dbg> at_host: TX
23 58 53 4f 43 4b 45 54  3a 20 31 2c 20 32 2c 20 |#XSOCKET : 1, 2, 
30 2c 20 31 37 0d 0a                             |0, 17..          [1B][0m
[00:01:18.907,714] [1B][0m<dbg> tcpip.do_socket_open: Socket opened[1B][0m
[00:01:18.909,790] [1B][0m<dbg> at_host: TX
4f 4b 0d 0a                                      |OK..             [1B][0m
AT#XSENDTO="84.215.43.232",56227,1,"Hi, I'm AndMar8"
#XSENDTO: 15
OK
+CSCON: 1
[00:01:43.649,810] [1B][0m<dbg> at_host: RX
41 54 23 58 53 45 4e 44  54 4f 3d 22 38 34 2e 32 |AT#XSEND TO="84.2
31 35 2e 34 33 2e 32 33  32 22 2c 35 36 32 32 37 |15.43.23 2",56227
2c 31 2c 22 48 69 2c 20  49 27 6d 20 41 6e 64 4d |,1,"Hi,  I'm AndM
61 72 38 22                                      |ar8"             [1B][0m
[00:01:43.650,146] [1B][0m<dbg> tcpip.parse_host_by_ipv4: IPv4 Address 84.215.43.232[1B][0m
[00:01:43.650,177] [1B][0m<dbg> tcpip.do_udp_init: UDP initialized[1B][0m
[00:01:43.650,329] [1B][0m<dbg> at_host.uart_callback: RX_DISABLED[1B][0m
[00:01:43.659,027] [1B][0m<dbg> at_host: TX
23 58 53 45 4e 44 54 4f  3a 20 31 35 0d 0a       |#XSENDTO : 15..  [1B][0m
[00:01:43.659,027] [1B][0m<dbg> tcpip.do_sendto: UDP sent[1B][0m
[00:01:43.660,308] [1B][0m<dbg> at_host: TX
4f 4b 0d 0a                                      |OK..             [1B][0m
[00:01:44.068,756] [1B][0m<dbg> at_host: TX
2b 43 53 43 4f 4e 3a 20  31 0d 0a                |+CSCON:  1..     [1B][0m
+CSCON: 0
[00:01:47.355,255] [1B][0m<dbg> at_host: TX
2b 43 53 43 4f 4e 3a 20  30 0d 0a                |+CSCON:  0..     [1B][0m
AT#XRECVFROM
Hi, I'm AndMar8
#XRECVFROM: 1, 15
OK
[00:01:59.227,844] [1B][0m<dbg> at_host: RX
41 54 23 58 52 45 43 56  46 52 4f 4d             |AT#XRECV FROM    [1B][0m
[00:01:59.228,118] [1B][0m<dbg> at_host: TX
48 69 2c 20 49 27 6d 20  41 6e 64 4d 61 72 38    |Hi, I'm  AndMar8 [1B][0m
[00:01:59.228,363] [1B][0m<dbg> at_host.uart_callback: RX_DISABLED[1B][0m
[00:01:59.229,492] [1B][0m<dbg> at_host: TX
0d 0a 23 58 52 45 43 56  46 52 4f 4d 3a 20 31 2c |..#XRECV FROM: 1,
20 31 35 0d 0a                                   | 15..            [1B][0m
[00:01:59.229,522] [1B][0m<dbg> tcpip.do_recvfrom: UDP received[1B][0m
[00:01:59.231,384] [1B][0m<dbg> at_host: TX
4f 4b 0d 0a                                      |OK..             [1B][0m

[Didrik Rokhaug]

AndMar8 said:

What kind of application do you use to send udp messages to nRF9160-dk?

 It's a Rust application I have written myself, although at this point it is still mostly just one of the examples from the documentation. Below is a simplified version (fostly just fancy logging that is removed):

fn single_udp_echo() -> std::io::Result<()> {
    let socket = std::net::UdpSocket::bind("0.0.0.0:56227")?;

    println!("Listening on socket 56227");

    let mut buf = [0; 1024];
    
    let (amt, src) = socket.recv_from(&mut buf)?;
    println!("Received message from {:?}", src);
    
    let buf = &buf[..amt];
    debug!("{}", std::str::from_utf8(&buf).unwrap());
    
    socket.send_to(buf, &src)?;

    Ok(())
}

fn main() {
    println!("Starting UDP echo");
    
    loop {
        let udp_result = udp::single_udp_echo();
        println!("udp result: {:?}", udp_result);
    }
}

It is simply listening for a UDP message, printing it, and sending it back to the sender.

Log from the server (including my own test to check that the server was up and running), timestamps are in UTC:

[2021-03-01T13:31:10.504010113][INFO][server] Starting UDP echo
[2021-03-01T13:31:10.504231159][INFO][server::udp] Listening on socket 56227
[2021-03-01T13:32:10.600723109][DEBUG][server::udp] Received message from 62.93.143.64:44856
[2021-03-01T13:32:10.601072018][DEBUG][server::udp] didrik port test
[2021-03-01T13:32:10.601381792][WARN][server] udp result: Ok(())
[2021-03-01T13:32:10.601632681][INFO][server::udp] Listening on socket 56227
[2021-03-01T16:34:44.897245414][DEBUG][server::udp] Received message from 151.99.1.113:59409
[2021-03-01T16:34:44.897544864][DEBUG][server::udp] Hi, I'm AndMar8
[2021-03-01T16:34:44.897827920][WARN][server] udp result: Ok(())

And .pcap:

udp.pcap

It is also worth noting that the log and .pcap shows NATing both in my and iBasis' networks.

The IP address the server logs is not the same address as reported by my nRF9160, and the server's address in the .pcap is also a local address and not the one used by the devices.

 

AndMar8 said:

It doesn't block the code as I thought but it's still worked.

 Correct. That error is reported by the Link Monitor, which has a rather short timeout for AT command responses. The error message can be useful for most AT commands, as they reply immediately. However, for commands which might take some time (such as waiting for a reply from a server), the timeout can be ignored.

In conclusion, it seems the problem is with the NODE-RED server (or the server hits a limitation in the network). How fast does it reply to the UDP packets?

We have often seen NAT timeouts of ~ 1 minute, but we have also seen networks where they are significantly shorter.

[AndMar8]

Hi Didrik!

It works with my application (Node-Red). It was my trivial error.
From your pcap file I understand that I have to bind the communication to the port used by the application to receive, in order to send a reply to nRF9160-dk. I thought that (with the udp protocol) it didn't matter to specify the port from which the message came out but only the destination one.

My mistake was the following:
nRF9160-dk sends from random port, for example 59222, to my Node-Red port 20080 a message.
Reply
Node-Red has to send a reply from the same port 20080 to the port (in this case) 59222.

Firstly I used a random port to send the reply from my Node-Red.

Thank you so much for your time and your suggestion.

I have one last question.

If I send the AT command AT#XRECVFROM to my module, is there a AT command that allows to exit from RX mode without press the button reset? Or the only way is to change the timer in the code to stop the receive mode?

[Achim Kraus]

> Firstly I used a random port to send the reply from my Node-Red.

That would have worked, if no NATs would be on the route. But with NATs, such traffic is blocked. The mapping contains the port as well and so from the view of the NAT there is no route back to the modem.

> Or the only way is to change the timer in the code to stop the receive mode?

That's at least what I do, and what is done in common. Therefore the setsockopt/SO_RCVTIMEO is for. Though I patched the SLM for that, I'm not sure, how to do that with AT#XSOCKETOPT/SO_RCVTIMEO.

[Didrik Rokhaug]

AndMar8 said:

If I send the AT command AT#XRECVFROM to my module, is there a AT command that allows to exit from RX mode without press the button reset?

 No.

But, you can use the proxy service: https://devzone.nordicsemi.com/f/nordic-q-a/66288/sending-udp-using-the-serial-lte-modem-application---at-sequence/272293#272293

That will keep the SLM from locking up.

See scanrio 3 here: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/applications/serial_lte_modem/doc/slm_testing.html#udp-client

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/applications/serial_lte_modem/doc/TCPIP_AT_commands.html#udp-dtls-client-xudpcli