Configurable deviations from lwm2m spec

[tuve]

Is there any way to configure/account for/manage bad behaving devices? The background is that there is devices not reporting the lwm2m version when register. This is mandatory according to the lwm2m specification, but nevertheless they don't. As I understand earlier versions of leshan allowed this and assumed the lwm2m version to be 1.0 so the problem wasn't detected, more recent versions block these devices from connecting. The question is, is there anyway configurable to allow for these devices to connect despite not follow the lwm2m specification?

[sbernard31]

I double checked and I confirm that LWM2M version in Register Request is required (in LWM2M v1.0 and v1.1)
Looking quickly at the 1.x branch, I also understand that a null version was allowed and considered as a 1.0 value.

The question is, is there anyway configurable to allow for these devices to connect despite not follow the lwm2m specification?

For now, there is not such a kind of configuration.
But I guess this should be possible to support this kind of device with some code :

Some not tested ideas :

1. Creating a custom RegisterResource and "fix" the request payload
2. Adding a MessageInterceptor which fix the request payload on receiveRequest.

The real question behind this one is : "should we handle bad device behavior ? and how should we do that ? "

"should we handle bad device behavior ?

I guess bad device behavior are part of real world and so we can not ignore it.

"how should we do that ?"

At the beginning of the project we were rather flexible with inputs but the drawbacks are :

• As Leshan is open source and provide demos, it is often used to test implementation. Being too flexible doesn't help to find issue at implementation time and so increase the number of bad behavior at production time.
• In Leshan, client and server share a lot of code but often some code are kind of input for one and output for the other (and vice versa). Meaning if we are flexible with input, we also create an API which make possible to send bad output. E.g. a RegisterRequest which accepts no Version will allow to send a Register with no Version. (In this case this is maybe a bad example as a default value could limit this but this is not always that simple).

Little by little we move to a more strict way to handle input but as we also try to provide code which is customizable (not always a success) we hope this is possible to handle bad behavior by providing some code.

Should we rather go to a Configuration way ?
I don't know, I feel this will make the code base less elegant and more difficult to maintain 🤔
But maybe there could be a way to add a kind of isolated layer dedicated to this kind of issue ? I don't know...

[sbernard31]

Tell me if fixing this by code is OK for you.
Do not hesitate to ask if my hints are not clear enough.

[tuve]

What we want to avoid is forking the code in a way requires us to basically patch every time there is an update, hence "configuration". That does not mean that solution could done in code, just that it should be fairly self containing and independent on whatever version of the leshan server is used.

To me, custom custom RegisterResource sounds like forking while MessageInterceptor seems like an independent component interacting with minimal dependencies of the rest of the leshan server. I will look into MessageInterceptor, thanks for the quick reply.

[sbernard31]

I don't know why I didn't though about it but with #1104 which should be available in master soon (at least I hope)
It should also be possible to write your own LinkParser.

I guess this is another way to workaround this.