Dealing with RESPONSE_MATCHING parameter on device (reverse engineering)

[developez]

Question

Scenario:

1 device that connects under LWM2M protocol
1 back running leshan library (we have got the code)
1 back running with unknow software and unknow code

Behaviour:

We running leshan server with this parameter:

	networkConfig.setString(NetworkConfig.Keys.RESPONSE_MATCHING,"STRICT");

When the device does the registration process then we observe the /19/0/0 endpoint. When we touch the device, this sends a message to the server that is observed by the /19/0/0 observation, is this action we send a command to the device with this code:

this.server.getObservationService().addListener(this.observationListener);

private final ObservationListener observationListener = new ObservationListener() {

        @Override
        public void onResponse(Observation observation, Registration registration, ObserveResponse response) {      	

            var open_command= ...;       	

            WriteResponse write_response = this.ref_server.send(registration, new WriteRequest(19,1,0, open_command));
            if(write_response != null)
            {
                 ....

       }

All this works OK, but at 2-3 minutes when device is not touched, if you touch the device again, the device make the registration process again and the observation to the /19/0/0 needs to be done again to send commands because the previous observation is obsolete.

The log says this when the device connects again with the server after 2-3 minutes without interaction:

DEBUG BaseMatcher - re-created exchange from original observe request: CON-GET    MID= 6508, Token=41EFA768DDCD1227, OptionSet={"Observe":0, "Uri-Path":["19","0","0"]}, no payload
DEBUG UdpMatcher$4 - ignoring potentially forged response for token KeyToken[41EFA768DDCD1227] with non-matching endpoint context

(and then, the device does the de-registration and registration process again, and the, we need to reobservate the /19/0/0.

In other hand, if we use the parameter RELAXED:

	networkConfig.setString(NetworkConfig.Keys.RESPONSE_MATCHING,"RELAXED");

The re-registration process is not done, but the sent command (ref_server.send) never achieves the device (the port of the device changed).

We dont know if the device uses DTLS, we think that we need to put the corrects parameters at the time to launch the leshan server. We have got another backend with unknow code that works without this re-registration or re-observation issues.

[sbernard31]

Which version of Leshan are you using ?

Take a look at https://github.com/eclipse-leshan/leshan/wiki/LWM2M-Devices-with-Dynamic-IP

Note that since 2.0.0-M11 there is this bug #1421 which should be fixed by #1463

If this is still not clear with documentation above, do not hesitate to ask questions.

[sbernard31]

We dont know if the device uses DTLS

It probably doesn't because for DTLS NetworkConfig.Keys.RESPONSE_MATCHING should not change the Leshan behavior.

WriteResponse write_response = this.ref_server.send(registration, new WriteRequest(19,1,0, open_command));

I see you are using sync API, for production it's strongly recommended to use te async API.

[sbernard31]

Let me know if we can close the issue.

[developez]

This totally solved the issue, I used 1.1.0 version with "setUpdateRegistrationOnNotification(true);".

But now we have got another problem.

We compiled a jar in our project, this jar in Windows works good (5683 in the firewall), but when we run that jar in Linux, with the 5683 port opened on UFW, the connection cannot be finished. The devices can achieve to the server but the server cannot send packets to the devices, the packets never acheive the device.

Any experience about this?

[sbernard31]

Not really, but reading you I understand this is more network config issue.
Maybe playing with tcpdump/wireshark to search where the packet is lost could help to diagnostic.

This totally solved the issue, I used 1.1.0 version with "setUpdateRegistrationOnNotification(true);".

2 remarks :

• setUpdateRegistrationOnNotification is out of specification so I strongly advice to rather fix the device behavior which should send an Update before to send notification.
• 1.1.0 is affected by security issue, at this momment you should use at least 1.4.2 (see : https://github.com/eclipse-leshan/leshan/security/policy#versions-security-state )

[developez]

About the problem of the UDP packets between Windows and Linux using wireshark we see this diferences:

LINUX

WINDOWS

In Linux the devices never get the response that sends the backend.

[sbernard31]

This is a difference at IP layer, I don't think this could be related to your issue.

In Linux the devices never get the response that sends the backend.

But did you see the packet for your response when you use tcpdump on your server ?
If you see the packet, then the issue could be anywhere between your device and you server. and so I can not really help you.

[sbernard31]

Should we close this issue ?

[sbernard31]

I close it but feel free to reopen if needed.