nRF9160 wakeup from RRC idle on incoming traffic, but data is lost

[Stephan Walter]

We are using the nRF9160 with firmware 1.3.6 to establish a DTLS connection to a server, using the Zephyr TLS stack.

The following problem occurs quite frequently: After some idle time, the modem will enter RRC idle and signal this with +CSCON: 0. If the server now sends data, the modem will wake up from RRC idle, but we don't actually receive the packet.

Such a case is documented here and in the attached files.

Packet trace on the server (server has local IP 172.18.16.75): /cfs-file/__key/communityserver-discussions-components-files/4/0284.trace0_2D00_server.pcapng

Packet #30 is an uplink packet from the nRF91 to the server. The server then tries to send data to the client (packets #31-#34). The modem wakes up for each of them, but no data is received:

10:11:11,633	+CSCON: 0
10:11:16,796	+CSCON: 1
10:11:20,263	+CSCON: 0
10:11:22,236	+CSCON: 1
10:11:25,596	+CSCON: 0
10:11:27,996	+CSCON: 1
10:11:33,560	+CSCON: 0
10:11:36,956	+CSCON: 1

At 10:11:38, packet #35 is finally received by the client and a response is sent to the server. This indicates that the connection remained active in the software stack and also in any middleware (NAT etc.).

Modem trace: /cfs-file/__key/communityserver-discussions-components-files/4/1754.trace0.bin The modem trace starts with packet #30 at 10:11:08.

We are aware that being layered on top of UDP, DTLS packets are not guaranteed to be delivered. But the packet loss is so frequent and severe that we suspect some problem in the interaction between modem and LTE-M network.

[Simon D-M]

Hi,

I can't really think of anything that could cause this except from normal UDP behavior right now... 

I asked the modem team internally to review your modem traces. We'll get back to you when they have provided a further analysis of your trace.

Best regards,

Simon

[Achim Kraus]

The modem trace shows different IP addresses than the server trace.

Are you using a VPN or something similar from the mobile provider to your server?

And in order to see, if that affects the traffic, a more complete modem trace would be helpful to see, if those addresses are changing over time.

>  This indicates that the connection remained active in the software stack and also in any middleware (NAT etc.).

Agreed, but the modem trace may be an additional indicator (from handshake to the final message exchange).

And maybe some more  details from the modem setup, e.g.

is eDRX used?

Is the UDP socket "connected" to the "server ip"?

   

[Samruddhi Jadhav]

Hi Stephan,

I am taking over this case as Simon is currently not available. We are still looking into this internally with the team and I will get back to you soon with an update once I receive further feedback on your modem trace review. Thanks for your patience.

Best Regards,

Samruddhi

[Samruddhi Jadhav]

Hi Stephan,

I have discussed internally with the team about this and have some feedback here from them. It would also be great if you could confirm what kind of sw component you are using in your app and also what type of application protocol you are using as it would be helpful to have logs from this. For example, also coap client dbg logs if you are using that. 

Best Regards,

Samruddhi

[Stephan Walter]

Hi Samruddhi,

We are using a custom protocol inside of DTLS with pre-shared keys. We use mbedTLS integrated into Zephyr, not the nRF91's TLS stack. The packets are typically rather short (1 to 200 bytes but sometimes more). The attached file trace0-server.pcapng shows the encrypted traffic. I cannot give you the key for this instance, but I could repeat the test with a different key if that would help. Is there reason to assume that the use of encryption has any influence on the behaviour we observe? I would expect not.

Time-outs and retries are done at the application level, but if several consecutive packets are lost as we see here, we run out of retry attempts.

Did the modem team give any specific information?

To answer Achim's questions: The IP address recorded on the server simply are on a private network. Apart from the NAT mechanism, I'm not aware of any peculiarities like a VPN, but I must admit I don't know the topology on the server side exactly. In this case, eDRX was not active but we do enable in in the case when GPS reception is also used.