getting wrong endpointname msisdnice[msisdn] instead of the expected urn:imei-msisdn:<imei>-<phonenumber>

[sd00819204]

Hi Team,

Issue details:

In few devices during the bootstrap and registration process. It seems that the server is receiving an incorrect endpoint name, specifically msisdnice[msisdn] instead of the expected urn:imei-msisdn:<imei>-<phonenumber>
From our application side, we are sending the correct IMEI+MSISDN, so this discrepancy we are getting.

We need your assistance identifying the specific files and functions within the mbedtls and coap layers where we can print the buffer and check where this value urn:imei-msisdn: is corrupted, which is coming from the application layer.

Your quick support is highly appreciable

[zhuang-hy]

已收到，我会尽快回复！

[Kucmasz]

Hi!
My first wild guess is that the <phonenumber> string is not NULL-terminated and additional bytes from adhering memory region are copied until the '\0' is found, which happens to have such layout: not null-terminated phonenumber,"ice",null-terminated msisdn. Endpoint name is taken from anjay_configuration_t::endpoint_name and you can print it right before passing that to anjay_new(). Can you confirm whether it is the case?
Endpoint
Regards,
Tomasz

[sd00819204]

Hi @Kucmasz ,

Thanks for your quick response.

our bootstrap steps are successful. we are sending correct urn:imei-msisdn:3556610997xxxxx-512201xxxx
but while sending registration message from device to server urn:imei-msisdn string getting messed up . Sometime we are getting only msisdn number or sometime only imei number

we are using client initiated bootstrap. can you please let us know where this buffer corruption is happing while sending the registration message.

Please help us to resolve or pin point the issue.

Thanks for the support.

[sd00819204]

Hi @Kucmasz,

As you suggested we printed anjay_configuration_t::endpoint_name before anjay_new and got the incorrect string msisdnice[msisdn], So we traced and found

demo.c
1501    char **ptr = (char **)malloc(ROW * sizeof(char *));
1502    memset(ptr,'\0', ROW * sizeof(char *));
1503    for (int i=0; i<ROW; i++) {
1504        ptr[i] = (char *)malloc(COL * sizeof(char));
1505         memset(ptr[i],'\0',sizeof(ptr[i]));
1506    }
1507    saved_argv = ptr;

So at 1505 we memset with '\0', and we found the endpoint_name is now printing correctly i.e. urn:imei-msisdn:3556610997xxxxx-512201xxxx in the syslog.

but at /persist/DMClient-persistance.dat doesn't have the correct value it has the same garbage value

Also please refer to #74 (comment)

[Kucmasz]

Hi,
Are you able to capture a pcap file containing the bootstrap information being sent to the device? I'd love to take a look at what exactly is in the message.
The information received may be conveyed through many layers and software components, so I'd start with checking the Bootstrap messages payload.
Regards

[sd00819204]

Hi @Kucmasz,

Thanks for your ultimate help,

Yes we can able to capture the pcap log, and also we can see the sequence flow

Nov 19 11:25:31.416 mdm9607 user.notice lwm2m: 2024-11-19 11:25:31.415990 DEBUG [anjay] [/data/hgtf47/BlueBank/FulcrumVariants/repo_bsp/MDM9607.LE.2.0_BB/apps_proc/fulcrum/anjay-1.9.1-source/src/interface/bootstrap_core.c:797]: scheduling Client Initiated Bootstrap
 
Nov 19 11:25:31.418 mdm9607 user.err lwm2m: 2024-11-19 11:25:31.418705 INFO [anjay] [/data/hgtf47/BlueBank/FulcrumVariants/repo_bsp/MDM9607.LE.2.0_BB/apps_proc/fulcrum/anjay-1.9.1-source/src/interface/bootstrap_core.c:658]: TechM: send_request_bootstrap()
 
Nov 19 11:25:31.487 mdm9607 user.err lwm2m: 2024-11-19 11:25:31.487334 INFO [anjay] [/data/hgtf47/BlueBank/FulcrumVariants/repo_bsp/MDM9607.LE.2.0_BB/apps_proc/fulcrum/anjay-1.9.1-source/src/interface/bootstrap_core.c:689]: LWM2M: Bootstrap Request sent
 
Nov 19 11:25:31.701 mdm9607 user.notice lwm2m: 2024-11-19 11:25:31.701244 DEBUG [anjay] [/data/hgtf47/BlueBank/FulcrumVariants/repo_bsp/MDM9607.LE.2.0_BB/apps_proc/fulcrum/anjay-1.9.1-source/src/anjay_core.c:523]: LWM2M: MsgResult: Bootstrap Finish
 
Nov 19 11:26:37.304 mdm9607 user.err lwm2m: 2024-11-19 11:26:37.304881 INFO [anjay] [/data/hgtf47/BlueBank/FulcrumVariants/repo_bsp/MDM9607.LE.2.0_BB/apps_proc/fulcrum/anjay-1.9.1-source/src/servers/connection_info.c:713]: connected to gvzwcdp.vzw.motive.com:5684 from
 
Nov 19 11:27:07.427 mdm9607 user.err lwm2m: 2024-11-19 11:27:07.426988 INFO [anjay] [/data/hgtf47/BlueBank/FulcrumVariants/repo_bsp/MDM9607.LE.2.0_BB/apps_proc/fulcrum/anjay-1.9.1-source/src/interface/register.c:224]: Register sent
 
Nov 19 11:27:07.427 mdm9607 user.err lwm2m: 2024-11-19 11:27:07.427189 INFO [anjay] [/data/hgtf47/BlueBank/FulcrumVariants/repo_bsp/MDM9607.LE.2.0_BB/apps_proc/fulcrum/anjay-1.9.1-source/src/interface/register.c:259]: registration successful, location = /rd/QUabTg9eB6

Below is the pcap log, but we are unable to decrypt it.

tcpdump.zip

But we can see the correct bootstrap urn while bootstrapping in dtls msg

but while registering we are now able to see the only imei number as we did memset at #74 (comment) instead of msisdnice[msisdn]. Correct me if i am wrong, we should get here the value urn:imei-msisdn:<imei>-<phonenumber> see below screenshot:

Please help us on this.

[Kucmasz]

Generally the endpoint name is set by the application and expected to be null-terminated, endpoint name is client-wide and does not change for different management and bootstrap servers, so if printing it before anjay_new() shows trailing garbage value, I'd suspect the string assigned as anjay_configuration_t::endpoint_name to be either not null-terminated or even modified during the app runs.
Values similar to endpoint name in Bootstrapping is probably DTLS Identity, which is mandated by specification to be somehow linked with endpoint name and in most (testing) cases is basically equal.
But just now I noticed that you mention demo.c, the demo app for desktop, so is it the case? are you setting the endpoint name with ./output/bin/demo -e x -u <bs_uri> -b command and then it's not equal to x?

[sd00819204]

Hi @Kucmasz

the demo app for desktop

No, The demo.c we have modified to get it work with linux wireless device

so if printing it before anjay_new() shows trailing garbage value, I'd suspect the string assigned as anjay_configuration_t::endpoint_name to be either not null-terminated or even modified during the app runs.

please look into #74 (comment) after memset we are not getting garbage value before anjay_configuration_t::endpoint_name now

we have linked the pcap log already but is there a way to give the decryption key through mail ?