After DTLS handshake by PSK. server send WRITE request on /0/1 using TLV, the package of CoAP is incomplete. about leshan HOT 23 CLOSED

Here the capture done with leshan-client-demo lightly modified to use TLV like your device.

The modification in LeshanClientDemo:

        // Configure Registration Engine
        DefaultRegistrationEngineFactory engineFactory = new DefaultRegistrationEngineFactory();
        if (cli.main.comPeriodInSec != null)
            engineFactory.setCommunicationPeriod(cli.main.comPeriodInSec * 1000);
        engineFactory.setReconnectOnUpdate(cli.dtls.reconnectOnUpdate);
        engineFactory.setResumeOnConnect(!cli.dtls.forceFullhandshake);
        engineFactory.setQueueMode(cli.main.queueMode);
+       engineFactory.setPreferredContentFormat(ContentFormat.TLV);

the command line :

java -jar leshan-client-demo.jar -b -i iot_app_100 -n rw001 -p 713073559dead664a293238a651054f77ca91e97ba301898c2fa059e8bf14db9 -u coaps://leshan.eclipseprojects.io:5784 -c TLS_PSK_WITH_AES_128_CCM_8

The Capture :
capture_with_leshan_client_demo.zip

from leshan.

I tried to decrypt the wireshark capture without success. I don't know exactly why...

I tried to simulate you device with same endpoint name same credentials, same ciphersuite, same prefered content format with leshan-client-demo and I able to decode the wireshark capture I created on my side.

I see nothing wrong at server side. TLV seems well formed and decoded by leshan-client-demo and wireshark without issue.

At first sight, I rather bet on a problem at your client side.

from leshan.

hello sbernard
thanks for your help Could you pls help upload your test Wireshark log, we want to make a compared to find the different.

in our Wireshark, there is no finish package from client and server, and transfer the application data, whether we can estimate the handshake is failed？

BRS

from leshan.

I will try to do that next week.

from leshan.

OK，I will closed ticket #1547，thanks！
if the procedure is OK，

we received the UDP socket package length is incomplete, so after ssl decode, the result also incomplete. do you have some way to record the server log if our client connects the bootstrap server, we can compare the origin data that server sends.

and we parse the buffer to ASCII, it is incomplete. "coap://leshan.eclipse"
200 -> È
0 -> (空字符)
37 -> %
99 -> c
111 -> o
97 -> a
112 -> p
58 -> :
47 -> /
47 -> /
108 -> l
101 -> e
115 -> s
104 -> h
97 -> a
110 -> n
46 -> .
101 -> e
99 -> c
108 -> l
105 -> i
112 -> p
115 -> s
101 -> e

from leshan.

You can easily run a leshan-server-demo on a machine you can control and so do the traffic/logs capture on your own.

See : https://github.com/eclipse-leshan/leshan#test-leshan-demos-locally

from leshan.

Hi sbernard
yes, we try before but the failed because of the Information security in our network.
1.Did the server split packet when the CoAP package is larger. Are there any markers to confirm it from server package.
2.last time you try in your client is ok. If possible, could you please support your Wireshark log for compared, thanks.

the PSK now modify below:
rw001
iot_app_100
713073559dead664a293238a651054f77ca91e97ba301898c2fa059e8bf14db9

BRS

from leshan.

I strongly advice to :

1.Did the server split packet when the CoAP package is larger. Are there any markers to confirm it from server package.

It could when depending on blockwise configuration but in that particular case I don't think so.

1. run your server locally at (or at least as locally is possible)

2.last time you try in your client is ok.

When I tired, I was using leshan-client-demo with same endpoint/credentials. So this succeed with client-demo, not with your client.

from leshan.

If possible, could you please support your Wireshark log for compared, thanks.

I will do it as I found time but I again I rather bet on an issue at "your" client side...
What are you using as DTLS and CoAP stack ?

from leshan.

Hi sbernard
yes, we use DTLS and CoAP, it is very kind of you, thanks a lot.
at the same time, we also confirm the CoAP split packet in spec.

BRS

from leshan.

we use DTLS and CoAP

I was not clear the question was : "which library exactly are you using at client side for DTLS and CoAP ?"

at the same time, we also confirm the CoAP split packet in spec.

I know there is several way to split CoAP payload in several CoAP packet defined different CoAP RFC. 😅
I just said that in this particular case, I don't think it is used (at least not at the server initiative)

from leshan.

Just took over the problem, I am not really sure. may be openssl and wakaama.😅

from leshan.

if it is no use block-wise, what else could be causing only half the data, now parse short package is ok, but set DM server address package is just half of the data, and PSK can decode the half data, so we want to reference the pass Wireshark log.

short package response ok, long package response 400

from leshan.

if it is no use block-wise, what else could be causing only half the data

"Let us be well assured of the Matter of Fact, before we trouble our selves with enquiring into the Cause"

If you are able to decode your wireshark capture you could ealisy see if there is block transfer OR not. (I'm not able to do that with your capture as explained at : #1543 (comment)

If you can not do that you can also try to bootstrap you device with exactly same config instead you don't use DTLS at Bootstrap server side and so you will see packet in clear and so easily see if blockwise is used.

from leshan.

Hi sbernard
we compared between our Wireshark, and you capture for us. and we found in our client connect Leshan server, Leshan server response the same packet was sent twice. every package from handshake to application data.
two package identifiction is same, pls refer the screenshot below:
our tcpdumpfile:
tcpdump1129.zip

frame47:

frame48:

from leshan.

Hi sbernard，
it's weird that we cannot decode the package in our device.
any way you can filtration the package that IP of us？

BRS

from leshan.

1. I said before when I tried to reproduce your use case. All works as expected to me.
2. For some reasons I can explain, I'm not able to decrypt your capture while I can do it with mine (which use exactly same credentials/cipher) => so there is something strange with your way to capture OR you network OR something else ?
3. With current information I can do nothing.
4. If you think there is something wrong in DTLS library we are using you can try to open a bug at : https://github.com/eclipse-californium/californium/issues (but I would be surprised if that was the issue)

So, I advice you to make your tests step by step :

1. Do not use DTLS, run a leshan-bsserver-demo on a machine you control and test with leshan-client-demo (make sure you can do capture at client and server side),
2. Then same test with your device instead of leshan-client-demo,
3. Then use DTLS , with leshan-client-demo,
4. Then use DTLS with your device.

from leshan.

Hi sbernard
we tried connecting with Leshan server without DTLS by our device, it is the same that every package from server was sent twice. This phenomenon should have nothing to do with DTLS.
we want to build server at local not permission by Information security.
UDP.zip
now the problem looks like a bug in the server？
Could you pls help to confirm leshan bootstrap server online version can record any log if we support the ip address？

thanks！

BRS

from leshan.

now the problem looks like a bug in the server？

As this only happen in your environment, I didn't bet this is a bug at server side...

Run server locally and capture at server side and maybe you will see packet only once.

we want to build server at local not permission by Information security.

I do not understand.

Could you pls help to confirm leshan bootstrap server online version can record any log if we support the ip address？

I do not understand.

from leshan.

Hi sbernard
as you said now we download leshan-bsserver-demo.jar and run in windows, but always display:
[ERROR] cannot start server endpoint [/113.108.96.XXX:5683]
we use command :java -jar leshan-bsserver-demo.jar -lh 113.108.96.xxx -lp 5683

anything wrong in windows of running leshan-bsserver-demo.jar

did the package fit for windows？

from leshan.

I didn't test it recently (I haven't windows machine) but :

1. this is pure java so theoretically this should work
2. I know that by the past some user succeed to launch it.

[ERROR] cannot start server endpoint [/113.108.96.XXX:5683]

This is the only logs you get ?
Eventually you can try to launch it with -v, -vv or -vvv to get more log.

from leshan.

log as below:
Have you ever encountered this problem？

2023-11-30 17:19:08,599 InMemoryMessageExchangeStore [DEBUG] [Bootstrap Server-coap://113.108.96.XXX:5683] using TokenProvider org.eclipse.californium.core.network.RandomTokenGenerator
2023-11-30 17:19:08,613 ban                       [INFO] Started.
2023-11-30 17:19:08,614 CoapEndpoint              [INFO] [Bootstrap Server-coap://113.108.96.XXX:5683] CoapEndpoint uses udp context
2023-11-30 17:19:08,627 BlockwiseLayer            [INFO] [Bootstrap Server-coap://113.108.96.XXX:5683] BlockwiseLayer uses MAX_MESSAGE_SIZE=1024, PREFERRED_BLOCK_SIZE=512, BLOCKWISE_STATUS_LIFETIME=300000, MAX_RESOURCE_BODY_SIZE=8192, BLOCKWISE_STRICT_BLOCK2_OPTION=false
2023-11-30 17:19:08,632 ReliabilityLayer          [TRACE] Max. leisure for multicast server=5000ms
2023-11-30 17:19:08,632 ReliabilityLayer          [TRACE] ReliabilityLayer uses ACK_TIMEOUT=2000ms, MAX_ACK_TIMEOUT=60000ms, ACK_RANDOM_FACTOR=1.5, and ACK_TIMEOUT_SCALE=2.0 as default
2023-11-30 17:19:08,685 CertPathUtil              [DEBUG] certificate: CN=localhost, O=Internet Widgits Pty Ltd, ST=Some-State, C=AU, no extkeyusage!
2023-11-30 17:19:08,686 CertPathUtil              [DEBUG] certificate: CN=localhost, O=Internet Widgits Pty Ltd, ST=Some-State, C=AU, no extkeyusage!
2023-11-30 17:19:08,707 InMemoryReadWriteLockConnectionStore [INFO] Created new InMemoryConnectionStore [capacity: 150000, connection expiration threshold: 1800s]
2023-11-30 17:19:08,710 RandomTokenGenerator      [INFO] using tokens of 8 bytes in length
2023-11-30 17:19:08,710 InMemoryMessageExchangeStore [DEBUG] [Bootstrap Server-coaps://0.0.0.0:5684] using TokenProvider org.eclipse.californium.core.network.RandomTokenGenerator
2023-11-30 17:19:08,711 CoapEndpoint              [INFO] [Bootstrap Server-coaps://0.0.0.0:5684] CoapEndpoint uses lwm2m correlation
2023-11-30 17:19:08,711 BlockwiseLayer            [INFO] [Bootstrap Server-coaps://0.0.0.0:5684] BlockwiseLayer uses MAX_MESSAGE_SIZE=1024, PREFERRED_BLOCK_SIZE=512, BLOCKWISE_STATUS_LIFETIME=300000, MAX_RESOURCE_BODY_SIZE=8192, BLOCKWISE_STRICT_BLOCK2_OPTION=false
2023-11-30 17:19:08,712 ReliabilityLayer          [TRACE] Max. leisure for multicast server=5000ms
2023-11-30 17:19:08,712 ReliabilityLayer          [TRACE] ReliabilityLayer uses ACK_TIMEOUT=2000ms, MAX_ACK_TIMEOUT=60000ms, ACK_RANDOM_FACTOR=1.5, and ACK_TIMEOUT_SCALE=2.0 as default
2023-11-30 17:19:08,913 CoapServer                [INFO] Starting server
2023-11-30 17:19:08,916 ExecutorsUtil             [TRACE] create special thread pool of 8 threads
2023-11-30 17:19:08,917 ExecutorsUtil             [TRACE] create thread pool of 7 threads
2023-11-30 17:19:08,918 ExecutorsUtil             [DEBUG] remove on cancel: true, split: true, log-diff: 10000
2023-11-30 17:19:08,918 ExecutorsUtil             [TRACE] warmup ...
2023-11-30 17:19:08,918 ExecutorsUtil             [TRACE] warmup ...
2023-11-30 17:19:08,919 ExecutorsUtil             [TRACE] warmup ...
2023-11-30 17:19:08,919 CoapEndpoint              [DEBUG] [Bootstrap Server-coap://113.108.96.XXX:5683] Starting endpoint at coap://113.108.96.XXX:5683
2023-11-30 17:19:08,919 ExecutorsUtil             [TRACE] warmup ...
2023-11-30 17:19:08,922 InMemoryMessageExchangeStore [DEBUG] [Bootstrap Server-coap://113.108.96.XXX:5683] no MessageIdProvider set, using default org.eclipse.californium.core.network.InMemoryMessageIdProvider
2023-11-30 17:19:08,927 CoapEndpoint              [DEBUG] [Bootstrap Server-coap://113.108.96.XXX:5683] Endpoint at coap://113.108.96XXX:5683 is already stopped
2023-11-30 17:19:08,927 CoapServer                [ERROR] cannot start server endpoint [/113.108.96.XXX:5683]

from leshan.

Just to be sure what is the XXX in 113.108.96.XXX:5683 ? (do you just modified log to hide your real IP ?)

Reading CoapServer.start() code we should see the exception which cause that in log ... :

https://github.com/eclipse-californium/californium/blob/1751069a9ef7cb8a49ce3c27da8d6f3549c96b27/californium-core/src/main/java/org/eclipse/californium/core/CoapServer.java#L328-L335

Have you ever encountered this problem？

I never see that kind of log without corresponding exception stack-trace ...

from leshan.