+CGEV: APNRATECTRL STAT - Not reported with pdn_event_handler_t

[Achim Kraus]

mfw 1.3.5, NCS 2.4.1

I received a

+CGEV: APNRATECTRL STAT 0,1,86307

from the modem.

I'm wondering, if that is processed by a pdn_event_handler_t.

If not, how does the application know that?

[emdi]

Hello Achim Kraus 

currently there is no support for APN rate control notifications in the PDN library.
I will check if that can be added there and open a PR for that if possible.

Regardless, the application can subscribe to any AT notifications using the AT monitor library, which will also let you parse the AT command as necessary in your application to extract all the information you want from it.

[Achim Kraus]

Thanks!

One additional comment:

Using

AT%APNRATECTRL=0,0

helps also to read that. Once the rate limit is triggered, that's indicated there. The pain is unfortunately, if the modem is switched off CFUN=0 and one CFUN=1 again, that AT cmd reports inactive rate limit, but the modem continues to fail sending the data. If the device gets rebooted, it's able to send data again.

Not sure, what the nature of that "rate limit" should be. For now I only saw that from one SIM card provider. Maybe Nordic checks, what the right behavior for switching off and on would be. I guess either the modem should then continue to send data or the modem should continue to report, that the rate limit is triggered.

[emdi]

The APN rate control state should be cleared by the modem upon CFUN=0 or in general PDN deactivation, and I think you should be able to send() successfully afterwards.

If that's not the case, which error do you receive from send() ?

[emdi]

I opened this PR to add the events to the PDN library, if you'd like to take a look.

[Achim Kraus]

> you should be able to send() successfully afterwards.

I get the same error as before, it's errno -11.

I would create a modem-trace, but if that needs to include the start, then it contains 256 messages in will get large. I will see, if I manage to get one tomorrow.

[Achim Kraus]

> I opened this PR

I will try to pick that to NCS 2.4.2. If that works, I will also test that tomorrow.

[Achim Kraus]

Here my logs:

rate limit is reached:

+CGEV: APNRATECTRL STAT 0,1,86305
I 99.884: received_from_peer 1074 bytes
I 99.884: received message (1074 bytes), starting with 'application_data', epoch 1
I 99.884: got 'application_data' epoch 1 sequence 250 (1074 bytes)
I 99.889: ** application data:
I 99.889: CoAP ACK response received. code: 2.05, token 0xb588f4cf, 1024 bytes
I 99.889: CoAP content format appl/octetstream (42)
I 99.902: -1ms/305ms: success
I 99.902: retrans: 0*250, 1*0, 2*0, 3*0, failures 0
I 99.902: rtt: 0-2s: 250, 2-4s: 0, 4-6s: 0, 6-8s: 0, 8-10s: 0
I 99.902: rtt: 10-12s: 0, 12-14s: 0, 14-16s: 0, 16-18s: 0, 18-20: 0
I 99.902: rtt: avg. 1s (250#)
I 99.903: 2023-09-13T07:51:02Z
I 99.903: Download block 249, pos 0x3e400
I 99.903: next download request
I 99.903: send 27 bytes.
W 99.903: send_to_peer failed: -1, errno 11 (No more processes)
I 99.904: APNRATECTRL STATUS: 0,0,1,86305
W 99.904: send_to_peer failed: rate limit, 86305 s
W 99.904: Failed to send CoAP request with 27 bytes via DTLS, 11 (No more processes)
I 99.905: -1ms/-1ms: failure, send
I 99.905: current failures 1.
I 99.905: Transfer canceled after 93 s.
I 99.906: 2023-09-13T07:51:02Z
I 99.906: APNRATECTRL STATUS: 0,0,1,86305
I 99.907: Modem rate limit exceeded, wait 60 s.

and after the modem was switched off and on.

W 86.211: hs_send_to_peer failed: -1, errno 11 (No more processes)
I 86.212: APNRATECTRL STATUS: 0,0,0
I 86.212: Start DTLS 1.2 handshake.
W 86.213: hs_send_to_peer failed: -1, errno 11 (No more processes)
I 86.214: APNRATECTRL STATUS: 0,0,0
I 86.214: dtls connect ...
I 86.214: APNRATECTRL STATUS: 0,0,0
I 87.215: State: connected, prevent suspend
I 87.215: DTLS hs wait 1 of 3 s
I 87.216: APNRATECTRL STATUS: 0,0,0
I 88.216: State: connected, prevent suspend
I 88.216: DTLS hs wait 2 of 3 s

And the trace.

trace-2023-09-13T07-49-20.899Z.zip