CoAP Reset Message on Observation Notification #719

wumpel · 2018-08-16T07:55:41Z

Hello,

LWM2M client is connected to the Leshan LWM2M server (Leshan-1.0.0-M8/CF-2.0.0-M11)
through the mobile network (4G) using plain connection (no DTLS).
Clients lifetime is set to 10mins.
Server starts an observation on a sensor value resource.
Client notifies periodically (every hour) current sensor value.
It seems that after some devices inactivity time, the mobile network changes the source port (by the same IP address) which leads to "UDP matching error" and following RST response message to the clients observation notification response.

Leshan-1.0.0-M8
Californium-2.0.0-M11

Please see for more information attached log snippet:

=> registration

17:55:37.867 [CoapServer#1] DEBUG c.n.server.log.CoapMessageTracer - [CoAP] receive CoAP request from the addr: /89.204.137.15:22590
17:55:37.906 [CoapServer#1] DEBUG c.n.server.log.CoapMessageTracer - [CoAP] send CoAP response to the addr: /89.204.137.15:22590
17:55:37.908 [CoapServer#1] TRACE o.e.californium.core.coap.Message - Message completed ACK-2.01 MID= 11, Token=[51a9e16e16330b00], OptionSet={"Location-Path":["rd","qh8Mp8wNiW"]}, no payload

17:55:37.936 [CoapServer#1] DEBUG c.n.server.service.EventController - registration json {"endpoint":"NODE-02","registrationId":"qh8Mp8wNiW","registrationDate":"2018-08-15T17:55:37+02:00","lastUpdate":"2018-08-15T17:55:37+02:00","address":"89.204.137.15:22590","smsNumber":"null","lwM2mVersion":"1.0","lifetime":600,"bindingMode":"U","rootPath":"/","objectLinks":[{"url":"/","attributes":{"rt":"oma.lwm2m"}},{"url":"/1/0","attributes":{}},{"url":"/2/0","attributes":{}},{"url":"/2/1","attributes":{}},{"url":"/2/2","attributes":{}},{"url":"/2/3","attributes":{}},{"url":"/2/4","attributes":{}},{"url":"/2/5","attributes":{}},{"url":"/2/6","attributes":{}},{"url":"/2/7","attributes":{}},{"url":"/3/0","attributes":{}},{"url":"/4/0","attributes":{}},{"url":"/5/0","attributes":{}},{"url":"/6/0","attributes":{}},{"url":"/7/0","attributes":{}},{"url":"/3322/0","attributes":{}}],"additionalRegistrationAttributes":{}}

=> start observation

17:55:38.008 [CoapServer#1] DEBUG o.e.c.c.n.stack.ReliabilityLayer - Exchange[L6] prepare retransmission for CON-GET MID= -1, Token=null, OptionSet={"Observe":0, "Uri-Path":["3322","0","5700"]}, no payload
17:55:38.009 [CoapServer#1] DEBUG o.e.c.core.network.BaseMatcher - registering observe request CON-GET MID= -1, Token=null, OptionSet={"Observe":0, "Uri-Path":["3322","0","5700"]}, no payload
17:55:38.011 [CoapServer#1] DEBUG o.e.c.c.n.InMemoryMessageExchangeStore - Exchange[L6] added with generated mid KeyMID[20435, [59cc890f]:22590], CON-GET MID=20435, Token=[11fe6117d0b6dc38], OptionSet={"Observe":0, "Uri-Path":["3322","0","5700"]}, no payload
17:55:38.011 [CoapServer#1] DEBUG o.e.c.c.n.InMemoryMessageExchangeStore - Exchange[L6] added with token Token=[11fe6117d0b6dc38], CON-GET MID=20435, Token=[11fe6117d0b6dc38], OptionSet={"Observe":0, "Uri-Path":["3322","0","5700"]}, no payload
17:55:38.012 [CoapServer#1] DEBUG o.e.c.core.network.UdpMatcher - tracking open request [MID: 20435, Token: Token=[11fe6117d0b6dc38]]
17:55:38.012 [CoapServer#1] DEBUG c.n.server.log.CoapMessageTracer - [CoAP] send CoAP request to the addr: /89.204.137.15:22590
17:55:38.012 [CoapServer#1] DEBUG c.n.server.service.EventController - node: NODE-02 CoAP: {"timestamp":1534348538012,"incoming":false,"type":"CON","code":"GET","mId":20435,"token":"[11fe6117d0b6dc38]","options":"Uri-Path: "3322", "0", "5700" - Observe: 0","payload":null}
17:55:38.150 [CoapServer#1] DEBUG c.n.server.log.CoapMessageTracer - [CoAP] receive CoAP empty message from the addr: /89.204.137.15:22590
17:55:38.151 [CoapServer#1] DEBUG c.n.server.service.EventController - node: NODE-02 CoAP: {"timestamp":1534348538151,"incoming":true,"type":"ACK","code":null,"mId":11,"token":"[]","options":null,"payload":null}
17:55:38.151 [CoapServer#1] DEBUG o.e.c.core.network.UdpMatcher - ignoring unmatchable empty message from UDP(89.204.137.15): ACK MID= 11
17:55:38.375 [CoapServer#1] DEBUG c.n.server.log.CoapMessageTracer - [CoAP] receive CoAP response from the addr: /89.204.137.15:22590
17:55:38.376 [CoapServer#1] DEBUG c.n.server.service.EventController - node: NODE-02 CoAP: {"timestamp":1534348538376,"incoming":true,"type":"ACK","code":"2.05","mId":20435,"token":"[11fe6117d0b6dc38]","options":"Content-Format: "application/vnd.oma.lwm2m+tlv" - Observe: 0","payload":"Hex:e4164446756b9a"}
17:55:38.376 [CoapServer#1] TRACE o.e.c.core.network.UdpMatcher - received response ACK-2.05 MID=20435, Token=[11fe6117d0b6dc38], OptionSet={"Observe":0, "Content-Format":"application/vnd.oma.lwm2m+tlv"}, e4 16 44 46 75 6b 9a
17:55:38.377 [CoapServer#1] DEBUG o.e.c.c.n.InMemoryMessageExchangeStore - removing Exchange[L6] for MID KeyMID[20435, [59cc890f]:22590]
17:55:38.377 [CoapServer#1] DEBUG o.e.c.core.network.UdpMatcher - closed open request [KeyMID[20435, [59cc890f]:22590]]
17:55:38.377 [CoapServer#1] TRACE o.e.c.core.network.Exchange - Exchange[L6, complete]!

=> periodic registration update (every 10 mins), pease nore, the port has been changed

18:05:28.906 [CoapServer#1] DEBUG c.n.server.log.CoapMessageTracer - [CoAP] receive CoAP request from the addr: /89.204.137.15:30583
18:05:28.917 [CoapServer#1] DEBUG o.e.c.c.n.stack.ReliabilityLayer - Exchange[R9] send response null-2.04 MID= -1, Token=null, OptionSet={}, no payload, failed transmissions: 0
18:05:28.917 [CoapServer#1] TRACE o.e.c.c.n.stack.ReliabilityLayer - Exchange[R9] switched response message type from null to ACK (request was CON)
18:05:28.920 [CoapServer#1] DEBUG o.e.c.core.network.Exchange - Remote Exchange[R9, complete] completed ACK-2.04 MID= 12, Token=[51a9e16e16330c00], OptionSet={}, no payload!
18:05:28.921 [CoapServer#1] DEBUG c.n.server.log.CoapMessageTracer - [CoAP] send CoAP response to the addr: /89.204.137.15:30583
18:05:28.923 [CoapServer#1] TRACE o.e.californium.core.coap.Message - Message completed ACK-2.04 MID= 12, Token=[51a9e16e16330c00], OptionSet={}, no payload
18:05:29.153 [CoapServer#1] DEBUG c.n.server.log.CoapMessageTracer - [CoAP] receive CoAP empty message from the addr: /89.204.137.15:30583
18:05:29.153 [CoapServer#1] DEBUG o.e.c.core.network.UdpMatcher - ignoring unmatchable empty message from UDP(89.204.137.15): ACK MID= 12

=> reset observation notification

18:12:27.706 [CoapServer#1] DEBUG c.n.server.log.CoapMessageTracer - [CoAP] receive CoAP response from the addr: /89.204.137.15:6207
18:12:27.707 [CoapServer#1] TRACE o.e.c.core.network.UdpMatcher - received response NON-2.05 MID=20436, Token=[11fe6117d0b6dc38], OptionSet={"Observe":1, "Content-Format":"application/vnd.oma.lwm2m+tlv"}, e4 16 44 46 75 68 cd
18:12:27.707 [CoapServer#1] DEBUG o.e.c.core.network.BaseMatcher - re-created exchange from original observe request: CON-GET MID=20435, Token=[11fe6117d0b6dc38], OptionSet={"Observe":0, "Uri-Path":["3322","0","5700"]}, no payload
18:12:27.707 [CoapServer#1] INFO o.e.c.core.network.UdpMatcher - ignoring potentially forged response for token Token=[11fe6117d0b6dc38] with non-matching endpoint context
18:12:27.707 [CoapServer#1] DEBUG o.e.c.core.network.CoapEndpoint - rejecting unmatchable response from UDP(89.204.137.15)
18:12:27.707 [CoapServer#1] DEBUG c.n.server.log.CoapMessageTracer - [CoAP] send CoAP empty message to the addr: /89.204.137.15:6207

BR's
-wumpel

boaks · 2018-08-16T08:30:51Z

Observe request:
/89.204.137.15:22590

Notify:
/89.204.137.15:6207

This violates RFC7252,
https://tools.ietf.org/html/rfc7252#section-5.3.2

The source endpoint of the response MUST be the same as the destination endpoint of the original request.

The endpoint is defined by the ip-address and port. If the port is changed, the endpoint is changed, and so the "notify response" doesn't longer match the observer request.

There have been man discussion about that on the OMA issue page.
https://github.com/OpenMobileAlliance/OMA_LwM2M_for_Developers/issues
Some of them are even closed. There are several proposals to overcome that, and californium offers therefore a EndpointContextMatcher.

Depending on your security requirements, you should select (or even implement), a roper matcher.
The default is RFC7252 compliant behaviour (RESPONSE_MATCHING=STRICT in Californium.properties). If you don't have any security requirements (that's very important, because this configuration defines the behaviour and especially for plain coap, it makes the system very vulnerable), you may change that to "RELAXED"

I'm not sure, where leshan setup the EndpointContextMatcher, if californiums EndpointContextMatcherFactory is used, just edit the value of the response matching to relaxed in the used "Californium.properties" file.

RESPONSE_MATCHING=RELAXED

At least for first tests, this should help. If it's really a solution, depends, as mentioned above, from your security requirements.

sbernard31 · 2018-08-16T09:49:25Z

In Leshan we are using the default EndpointContextMatcher of californium for plain CoAP, so as Achim explained, the strict one. Address/port MUST NOT changed.

To avoid this check, you can use the RELAXED mode . In Leshan you can, just change the CoAP config :

coapConfig = LeshanServerBuilder.createDefaultNetworkConfig();
coapConfig.setString(Keys.RESPONSE_MATCHING, "RELAXED");
builder.setCoapConfig(coapConfig);

Or with leshan-server-demo, just change the value in Californium.properties.

But I agree with @boaks, this is a pretty unsecured configuration and for me, this should mainly be used for tests purpose.

If you want to implements you own EndpointContextMatcher in Leshan, you can use `

builder.setEndpointFactory(new EndpointFactory() {

            @Override
            public CoapEndpoint createUnsecuredEndpoint(InetSocketAddress localAddress, NetworkConfig coapConfig,
                    ObservationStore store) {
                CoapEndpoint.CoapEndpointBuilder endpointBuilder = new CoapEndpoint.CoapEndpointBuilder();
                endpointBuilder.setInetSocketAddress(localAddress);
                endpointBuilder.setNetworkConfig(coapConfig);
                endpointBuilder.setObservationStore(store);
                endpointBuilder.setEndpointContextMatcher(new CustomContextMatcher());
                return endpointBuilder.build();
            }

            // ...
        });

Anyway, If you want a more production ready solution, you should use DTLS and so you will not faced this issue in Leshan as we are using a custom EndpointContextMatcher which are checking only DTLS Identity and not address/port.

wumpel · 2018-08-16T10:27:26Z

Thanks guys for your explanation and suggestions!

The actually purpose of this server is the general evaluation of the LWM2M client running on embedded HW, connected through the mobile network, slipping very long time and reporting periodically sensor values. Therefore, a simple plain CoAP connection was chosen. For sure, for production environment, the DTLS connection should be implemented (client unique PSK), but for now it isn't the scope of the tests.
Setting RESPONSE_MATCHING=RELAXED in Californium.properties do the job well, observation responses are now accepted and proceeded on the server.
We could close the issue, thanks again!

wumpel closed this as completed Aug 16, 2018

boaks mentioned this issue Oct 23, 2018

How to set Notification to support ACK-CON #772

Closed

boaks mentioned this issue Nov 25, 2018

Does the Californium project only support ACK messages? #807

Closed

developez mentioned this issue Aug 11, 2020

Create Memory Registration Store with new clean default period it has no effect eclipse-leshan/leshan#872

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

CoAP Reset Message on Observation Notification #719

CoAP Reset Message on Observation Notification #719

wumpel commented Aug 16, 2018

boaks commented Aug 16, 2018

sbernard31 commented Aug 16, 2018

wumpel commented Aug 16, 2018

CoAP Reset Message on Observation Notification #719

CoAP Reset Message on Observation Notification #719

Comments

wumpel commented Aug 16, 2018

boaks commented Aug 16, 2018

sbernard31 commented Aug 16, 2018

wumpel commented Aug 16, 2018