Searching for a position in the Security Object /0

[pstolarz]

I've observed the following issue while testing awa_clientd.
The bootstrap server and OMA server (leshan) are launched on a single host on different ports as follows:

ps@ps-vm-deb2:~/oma-test$ awa-client-get /0
LWM2MSecurity[/0/0]:
    LWM2MServerURI[/0/0/0]: coap://localhost:15685
    BootstrapServer[/0/0/1]: True
    SecurityMode[/0/0/2]: 0
    PublicKeyorIDentity[/0/0/3]: Opaque (0):
    ServerPublicKeyorIDentity[/0/0/4]: Opaque (0):
    SecretKey[/0/0/5]: Opaque (0):
    SMSBindingKeyParameters[/0/0/7]: Opaque (0):
    SMSBindingSecretKeys[/0/0/8]: Opaque (0):
    ShortServerID[/0/0/10]: 0
    ClientHoldOffTime[/0/0/11]: 0
LWM2MSecurity[/0/1]:
    LWM2MServerURI[/0/1/0]: coap://127.0.0.1:5683
    BootstrapServer[/0/1/1]: False
    SecurityMode[/0/1/2]: 3
    PublicKeyorIDentity[/0/1/3]: Opaque (11):5B 50 75 62 6C 69 63 4B 65 79 5D
    ServerPublicKeyorIDentity[/0/1/4]: Opaque (0):
    SecretKey[/0/1/5]: Opaque (11):5B 53 65 63 72 65 74 4B 65 79 5D
    ShortServerID[/0/1/10]: 1
    ClientHoldOffTime[/0/1/11]: 30

after bootstraping & registration process I see the following logs for requests from the OMA server:

 [DEBUG] [coap_abstraction_erbium.c:249] Coap PUT for /1001/0/0
 [DEBUG] [lwm2m_client_core.c:1893] BOOTSTRAP WRITE: /1001/0/0
 [DEBUG] [lwm2m_client_core.c:163] Deserialise resource 1001/0/0:
 [DEBUG] [lwm2m_observers.c:209] All attributes checked out for server 0, Will notify change to /1001/0/0 when possible.
 [DEBUG] [coap_abstraction_erbium.c:265] Coap Response code 204
 [DEBUG] [lwm2m_xml_interface.c:76] Send 317 bytes on IPC

BOOTSTRAP WRITE seemed suspicious for me since the bootstraping process was already finished and the source of requests was OMA server only (BS server was even killed).

After some investigation I've found the problem in core\src\client\lwm2m_client_core.c while looking for a position in the Security Object (representing a server endpoint):

static LWM2MSecurityInfo * GetSecurityInfoForAddress(Lwm2mContextType * context, AddressType * address)
{
    LWM2MSecurityInfo * info = NULL;
    struct ListHead * current;
    ListForEach(current, Lwm2mCore_GetSecurityObjectList(context))
    {
        LWM2MSecurityInfo * securityInfo = ListEntry(current, LWM2MSecurityInfo, list);
        if (Lwm2mCore_CompareAddresses(address, &securityInfo->address) == 0)
        {
            info = securityInfo;
            break;
        }
    }
    return info;
}

Lwm2mCore_CompareAddresses() uses only an IP4/6 address while searching for a position. Port is completly ignored. E.g. for the Linux implementation we have:

int Lwm2mCore_CompareAddresses(AddressType * addr1, AddressType * addr2)
{
    if (addr1->Addr.Sa.sa_family != addr2->Addr.Sa.sa_family)
    {
        return -1;
    }

    switch (addr1->Addr.Sa.sa_family)
    {
        case AF_INET:
            return memcmp(&addr1->Addr.Sin.sin_addr.s_addr, &addr2->Addr.Sin.sin_addr, sizeof(addr2->Addr.Sin.sin_addr));
        case AF_INET6:
            return memcmp(&addr1->Addr.Sin6.sin6_addr, &addr2->Addr.Sin6.sin6_addr, sizeof(addr2->Addr.Sin6.sin6_addr));
        default:
            Lwm2m_Error("Unsupported address family: %d\n", addr1->Addr.Sa.sa_family);
            break;
    }

    return -1;
}

This causes the servers installed on the same host as indistinguishable (as occurred in my case - the OMA server was identified as BS server).

Investigating further the issue I've found that in the client's device management handler DeviceManagmentEndpointHandler() in lwm2m_client_core.c the AddressType * addr arg contains (probably?) garbage data in the port field (that is addr->Addr.Sin.sin_port for the Linux abstraction) but I didn't have time to investigate what was a root-cause of this.

[delmet]

Thanks for the detailed summary of problem.

I think ports were not garbage just in network byte order.

I have pushed in a fix which seem to work from by own testing as pre-change I was also getting "BOOTSTRAP WRITE: ". but now works but note resource needs to exist first before doing PUT.

[pstolarz]

Looking good, thanks for the quick fix. Impressive as usually.

What I taken as the garbage was in fact a port of a local client connecting locally via UDP every time using different local port. I was hurry I didn't check carefully. Sorry.

[delmet]

No worries @pstolarz .

Thank you, for helping us improve Awa.