Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[wakaama-dev] Content-Format Wakaama Issue

Dear all,

 

I have a Wakaama Client issue which impacts my Leshan Server.

 

When retrieving a simple resource such as /1/0/1 or /1/0/2 from the Client it works ok and I can decode packets with Content-Format [0] (“plain/text”) from the Server.

 

When retrieving entire instance of an object, or particular resources such as /3/0/6 or /3/0/7, the final format I see in “lwm2m_data_serialize” in my Wakaama Client is TLV “11542” (pls see logs below).

However, from the CoAP debug logs, I can see a “Content-Format” set to “22” in “coap_serialize_message” which is sent back to and decoded by Leshan Server.

 

The issue is that with leshan M15 it gives error, whereas with leshan M11 I still receive a 22 (image/jpeg) but it does not block and correctly decode the packet.

 

Now, noticing that “11542 % 256” actually returns “22”, my guess is that it could be a casting problem to an 8bit integer.

 

Thanks a lot for any help.

Kind Regards,

Riccardo.

 

-Done parsing-------

size: 1, formatP: 0

Final format: 0

-Serializing MID 30151 to 0x10003688, Token (len 5) B3 F7 AF D1 DA-

-Serializing options at 0x10003691-

Content-Format [0]

OPTION 12 (delta 12, len 0)

WRITTEN 0 B opt header

-Done serializing at 0x10003692----

-Done 12 B (header len 11, payload len 1)-

Dump [0x65 45 75 C7  B3 F7 AF D1]

41 bytes received from [XXX.XXX.XXX.XXX]:5684

decrypt_verify(): found 12 bytes cleartext

Token (len 1) [0xEB00000000000000]

OPTION 11 (delta 11, len 1): Uri-Path [1]

OPTION 11 (delta 0, len 1): Uri-Path [0]

OPTION 17 (delta 6, len 2): Accept [0]

 

-Done parsing-------

size: 7, formatP: 0

Final format: 11542

-Serializing MID 30152 to 0x10003e78, Token (len 1) EB-

-Serializing options at 0x10003e7d-

Content-Format [22]

OPTION 12 (delta 12, len 1)

WRITTEN 0 B opt header

-Done serializing at 0x10003e7f----

-Done 31 B (header len 8, payload len 23)-

Dump [0x61 45 75 C8  EB C1 16 FF]

44 bytes received from [XXX.XXX.XXX.XXX]:5684

decrypt_verify(): found 15 bytes cleartext

Token (len 4) [0x42D02C3200000000]

OPTION 11 (delta 11, len 1): Uri-Path [1]

OPTION 11 (delta 0, len 1): Uri-Path [0]

OPTION 17 (delta 6, len 2): Accept [0]

 

 

From: Riccardo Pozza [mailto:riccardo.pozza@xxxxxxxxx]
Sent: 19 January 2017 15:50
To: 'leshan developer discussions' <leshan-dev@xxxxxxxxxxx>
Subject: RE: [leshan-dev] Leshan Issue with Content-Format following update to M15

 

Hi Simon,

 

The Wakaama is fresh of update as of 13Jan as well and I double checked and it contains the REG_ATTR_CONTENT_JSON “11543”, plus there is LWM2M_CONTENT_TLV=11542 and LWM2M_CONTENT_JSON=11543 in liblwm2m.h under lwm2m_media_type_t.

 

In all the objects, everytime lwm2m_data_new(X) is called, (i.e. when the server is asking the full object or when I ask AVAILABLE_POWER_SOURCES in the Device Obj) in Wakaama, there seems to be an issue with a format response.

 

I double checked and every (*formatP ) in lwm2m_data_serialize at the beginning is 0 (hopefully this is the right place to check).

 

Thanks and Kind Regards,

Riccardo.

 

 

From: leshan-dev-bounces@xxxxxxxxxxx [mailto:leshan-dev-bounces@xxxxxxxxxxx] On Behalf Of Simon Bernard
Sent: 19 January 2017 15:34
To: leshan developer discussions <
leshan-dev@xxxxxxxxxxx>
Subject: Re: [leshan-dev] Leshan Issue with Content-Format following update to M15

 

Did you check if you have a version of wakaama which contains this commit : https://github.com/eclipse/wakaama/commit/e04e6208c0ced4d5f0b805e278d38264f69cbcf1

I just test with a version of wakaama before this commit was integrated and it partially works for me (it doesn't know the new code and choose to use old json format) :
16:28:05.160     CON-GET     2722     cc6f8a6a     Uri-Path: "1", "0" - Accept: "unknown/11542"    
16:28:05.162     ACK-2.05     2722     cc6f8a6a     Content-Format: "unknown/1543"
I also test with master and it's ok :
16:30:39.756     CON-GET     2724     37b1cb4acc64     Uri-Path: "1", "0" - Accept: "unknown/11542"    
16:30:39.758     ACK-2.05     2724     37b1cb4acc64     Content-Format: "unknown/11543"
But this is surprising that it doesn't take the accept option into account ...


Your log disturbs me because of the Content-Format: "image/jpeg"...  I looked at our code and this is Californium which handle this, see https://github.com/eclipse/californium/blob/master/californium-core/src/main/java/org/eclipse/californium/core/coap/MediaTypeRegistry.java#L41
So this means thats your client return 22 as contentFormat ? It's strange...

Le 19/01/2017 à 15:56, Riccardo Pozza a écrit :

Hi Simon

 

  Which version of Leshan did you use ?

 

>>>>>>>>>>>>Fri Jan 13 16:01 commit e11bf35657fa8e2abbd90aed2097f9058abd4897

  Which client did you use ?

 

>>>>>>>>>>>>Wakaama, I believe the problem might be there. However, it works with Leshan M11 May 11, b54557013bd269c0d17cb46e984b77c939e1aa12

  Where the log above comes from ?

>>>>>>>>>>>>>>Leshan Server Demo in client and into the Coap Messages Window.

 

Thanks and Kind Regards,

Riccardo.

 

 

From: leshan-dev-bounces@xxxxxxxxxxx [mailto:leshan-dev-bounces@xxxxxxxxxxx] On Behalf Of Simon Bernard
Sent: 19 January 2017 14:41
To: leshan developer discussions
<leshan-dev@xxxxxxxxxxx>
Subject: Re: [leshan-dev] Leshan Issue with Content-Format following update to M15

 

Hi,

  I tried to reproduce your problem and it works for me. I used the master (commit 4d1af8df3b439b2f0c763a74bd5bd75f9db5cfce) version of Leshan client and Leshan server.

  Which version of Leshan did you use  ?
  Which client did you use ?

" CON-GET Uri-Path: "1", "0" - Accept: "unknown/11542"

ACK-2.05 10916 8953 Content-Format: "image/jpeg" Hex:c10001c2010096c10200c10301c10500c10600c2075551"

  Where the log above comes from ?

Simon

Le 19/01/2017 à 15:16, Riccardo Pozza a écrit :

Hi,

I’ve just updated to latest Leshan. When I get the data of a single resource as such, it works:

 

CON-GET Uri-Path: "1", "0", "0" - Accept: "text/plain"

ACK-2.05 Content-Format: "text/plain" 1

 

However, when I try to get a full instance (or data as /3/0/6 or /3/0/7), it doesn’t work and return an acknowledgement with content format image/jpeg (?):

 

CON-GET Uri-Path: "1", "0" - Accept: "unknown/11542"

ACK-2.05 10916 8953 Content-Format: "image/jpeg" Hex:c10001c2010096c10200c10301c10500c10600c2075551


Plus, I do get:


java.lang.IllegalArgumentException: The validated object is null
    at org.eclipse.leshan.util.Validate.notNull(Validate.java:222) ~[leshan-server-demo-0.1.11-M15-SNAPSHOT-jar-with-dependencies.jar:?]
    at org.eclipse.leshan.util.Validate.notNull(Validate.java:205) ~[leshan-server-demo-0.1.11-M15-SNAPSHOT-jar-with-dependencies.jar:?]
    at org.eclipse.leshan.core.response.ReadResponse.<init>(ReadResponse.java:41) ~[leshan-server-demo-0.1.11-M15-SNAPSHOT-jar-with-dependencies.jar:?]
    at org.eclipse.leshan.server.californium.impl.LwM2mResponseBuilder.visit(LwM2mResponseBuilder.java:89) ~[leshan-server-demo-0.1.11-M15-SNAPSHOT-jar-with-dependencies.jar:?]
    at org.eclipse.leshan.core.request.ReadRequest.accept(ReadRequest.java:134) ~[leshan-server-demo-0.1.11-M15-SNAPSHOT-jar-with-dependencies.jar:?]
    at org.eclipse.leshan.server.californium.impl.CaliforniumLwM2mRequestSender$1.buildResponse(CaliforniumLwM2mRequestSender.java:102) ~[leshan-server-demo-0.1.11-M15-SNAPSHOT-jar-with-dependencies.jar:?]
    at org.eclipse.leshan.core.californium.SyncRequestObserver.onResponse(SyncRequestObserver.java:49) ~[leshan-server-demo-0.1.11-M15-SNAPSHOT-jar-with-dependencies.jar:?]
    at org.eclipse.californium.core.coap.Request.setResponse(Request.java:451) ~[leshan-server-demo-0.1.11-M15-SNAPSHOT-jar-with-dependencies.jar:?]
    at org.eclipse.californium.core.server.ServerMessageDeliverer.deliverResponse(ServerMessageDeliverer.java:169) ~[leshan-server-demo-0.1.11-M15-SNAPSHOT-jar-with-dependencies.jar:?]
    at org.eclipse.californium.core.network.stack.CoapUdpStack$StackTopAdapter.receiveResponse(CoapUdpStack.java:206) ~[leshan-server-demo-0.1.11-M15-SNAPSHOT-jar-with-dependencies.jar:?]
    at org.eclipse.californium.core.network.stack.AbstractLayer.receiveResponse(AbstractLayer.java:103) ~[leshan-server-demo-0.1.11-M15-SNAPSHOT-jar-with-dependencies.jar:?]
    at org.eclipse.californium.core.network.stack.AbstractLayer.receiveResponse(AbstractLayer.java:103) ~[leshan-server-demo-0.1.11-M15-SNAPSHOT-jar-with-dependencies.jar:?]
    at org.eclipse.californium.core.network.stack.ObserveLayer.receiveResponse(ObserveLayer.java:146) ~[leshan-server-demo-0.1.11-M15-SNAPSHOT-jar-with-dependencies.jar:?]
    at org.eclipse.californium.core.network.stack.AbstractLayer.receiveResponse(AbstractLayer.java:103) ~[leshan-server-demo-0.1.11-M15-SNAPSHOT-jar-with-dependencies.jar:?]
    at org.eclipse.californium.core.network.stack.BlockwiseLayer.receiveResponse(BlockwiseLayer.java:322) ~[leshan-server-demo-0.1.11-M15-SNAPSHOT-jar-with-dependencies.jar:?]
    at org.eclipse.californium.core.network.stack.AbstractLayer.receiveResponse(AbstractLayer.java:103) ~[leshan-server-demo-0.1.11-M15-SNAPSHOT-jar-with-dependencies.jar:?]
    at org.eclipse.californium.core.network.stack.ReliabilityLayer.receiveResponse(ReliabilityLayer.java:265) ~[leshan-server-demo-0.1.11-M15-SNAPSHOT-jar-with-dependencies.jar:?]
    at org.eclipse.californium.core.network.stack.AbstractLayer.receiveResponse(AbstractLayer.java:103) ~[leshan-server-demo-0.1.11-M15-SNAPSHOT-jar-with-dependencies.jar:?]
    at org.eclipse.californium.core.network.stack.CoapUdpStack.receiveResponse(CoapUdpStack.java:145) ~[leshan-server-demo-0.1.11-M15-SNAPSHOT-jar-with-dependencies.jar:?]
    at org.eclipse.californium.core.network.CoapEndpoint$InboxImpl.receiveResponse(CoapEndpoint.java:807) ~[leshan-server-demo-0.1.11-M15-SNAPSHOT-jar-with-dependencies.jar:?]
    at org.eclipse.californium.core.network.CoapEndpoint$InboxImpl.receiveMessage(CoapEndpoint.java:709) ~[leshan-server-demo-0.1.11-M15-SNAPSHOT-jar-with-dependencies.jar:?]
    at org.eclipse.californium.core.network.CoapEndpoint$InboxImpl.access$1000(CoapEndpoint.java:668) ~[leshan-server-demo-0.1.11-M15-SNAPSHOT-jar-with-dependencies.jar:?]
    at org.eclipse.californium.core.network.CoapEndpoint$InboxImpl$1.run(CoapEndpoint.java:682) ~[leshan-server-demo-0.1.11-M15-SNAPSHOT-jar-with-dependencies.jar:?]
    at org.eclipse.californium.core.network.CoapEndpoint$5.run(CoapEndpoint.java:858) ~[leshan-server-demo-0.1.11-M15-SNAPSHOT-jar-with-dependencies.jar:?]
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:1.8.0_111]
    at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:1.8.0_111]
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) ~[?:1.8.0_111]
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) ~[?:1.8.0_111]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) ~[?:1.8.0_111]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) ~[?:1.8.0_111]
    at java.lang.Thread.run(Thread.java:745) [?:1.8.0_111]

 

Any idea, how to fix this?

Thanks and Kind Regards,

Riccardo.




_______________________________________________
leshan-dev mailing list
leshan-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/leshan-dev

 



_______________________________________________
leshan-dev mailing list
leshan-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/leshan-dev

 


Back to the top