Hard coded context ID of 0 in the Serial LTE Modem application (nRF SDK 2.0.0)

[Hans Jorgen Grimstad]

Hi!

I am using the Serial LTE Modem application from the nRF Connect SDK v.2.0.0

In the source code for this app, every call to: 

int util_resolve_host(int cid, const char *host, uint16_t port, int family, struct sockaddr *sa)

has a hardcoded "cid" argument with the value 0. This is a problem where a preexisting default context can't be used. It isn't possible to deactivate the default context and any new context will have a non zero id.

Creating a new context with AT+CGDCONT, activating the this context and deactivating the default with AT+CGACT will result in a single remaining context with a cid of 1.

Attempting to use AT#XSENDTO with an active context with cid=1 will result in a call to util_resolve_host with a hard coded cid=0 and the AT command will fail.

I can always hard code a different cid and recompile the application, but somehow this feels like the wrong solution to the problem

Any suggestions to how I can get around this using AT commands without having to patch the SLM source code ?

Regards

Hans Jørgen

Lab5e AS

[dejans]

Hi,

I have reported your finding internally. I'll get back to you when I get new information, possibly till the end of this week.

Best regards,
Dejan

[Hans Jorgen Grimstad]

Hi !

It seems that the same hardcoded cid is present in calls to :

void util_get_ip_addr(int cid, char *addr4, char *addr6)

Running AT#XBIND will result in:

<err> slm_sock: Get local IPv4 address failed

If I tweak the SLM source code and pass the correct cid, then AT#XBIND and AT#XRECVFROM behaves as expected.

Regards

Hans Jørgen

[dejans]

Hi Hans Jørgen,

Currently, multiple PDP contexts are supported only by ICMP echo request #XPING and socket #XSOCKET. For socket send and receive, previously mentioned socket option can be used to bind secondary PDP context.

Best regards,
Dejan

[Hans Jorgen Grimstad]

Hi !

I am not trying to use multiple PDP contexts.

I created a new one using +CGDCONT and then deactivated the default context with +CGACT. I then ended up with a single active context with a context id == 1. The non-zero id breaks any attempts to use the context to transfer data in the SLM code.

The SLM code works just fine for AT#XSENDTO and AT#XRECVFROM if the correct (non-zero) cid is transferred in the calls to util_get_ip_addr and util_resolve_host, so I don't quite understand why it isn't supported.

The source code documentation for these two functions is also clear about this:

 * @param[in] cid PDP Context ID as defined in "+CGDCONT" command (0~10).

If it's the case that only a single context with an id of 0 is permitted in this version of SLM, maybe it would have been better to:

• Explicitly include the CONFIG_PDN_DEFAULT_APN and CONFIG_PDN_DEFAULTS_OVERRIDE configs (along with maybe a comment or two) in the SLM prj.conf, since this would make it a bit more explicit (I guess that by using these I can specify my own default context that will end up with a cid == 0 ?)
• Disallow creation of PDP contexts with a non-zero id in the +CGDCONT command, since being able to create a seemingly ok PDP context that can't be used for sending data is a somewhat confusing user experience.

> For socket send and receive, previously mentioned socket option can be used to bind secondary PDP context.

Which socket option are you referring to ? 

Best Regards

Hans Jørgen

[Hans Jorgen Grimstad]

Hi !

It seems that the best solution for me was to add the following configs to the prj.conf (instead of defining the context with +CGDCONT, activating with +CGACT and then deactivating the default with +CGACT)

CONFIG_PDN=y

CONFIG_PDN_DEFAULTS_OVERRIDE=y

CONFIG_PDN_SYS_INIT=y

CONFIG_PDN_DEFAULT_APN="<our APN>"

CONFIG_PDN_DEFAULT_FAM_IPV4V6=y

 

Best Regards

Hans Jørgen Grimstad

Lab5e AS