Californium DTLS failed to handshake #1668
Comments
|
Hi,
I try to donwload your captures but :
Please provide more clean captures 🙏 Using same ID/PSK for bootstrap server and dm server is OK for test but not really a good idea in production. |
|
Hi Leshan Gatekeepers,
2 "Which client are you using?" I am using the lesion-demo-client code provided.
Regards, Henry |
|
Hi Leshan Gatekeepers, Here is my Wireshark file. Regards, Henry PS. I used the same file but apply filter like coap port 5683 and coaps port 5684. |
|
Just to let you know, it is not recommended to use 2.0.0-M6 for security reason. As you said, the source address IP of HELLO_VERIFY_REQUEST seems not good.
I doubt this will solve the issue. Just to be sure, I tested with a leshan-client-demo 1.5.0 on Leshan sandbox and it works as expected : |
|
Hi Leshan Gatekeepers, I am not sure why you keep on saying that I am using the lesion-2.0.0-M16 (M16 sixteen not M6 six). I believe that the problem may be happening at the registration update not at the bootstrap. The client performs the bootstrap operation correctly but when the client performs registration update the DTLS fails to function because the bootstrap server interferes with the DTLS in shaking, please refer to the PDF document for the setup and Wireshark trace to see the DTLS failure. bs.local=192.168.68.57 Bootstrap operation works fine After successfully bootstrap the client will perform registration update. That is when the DTLS operation fails I will capture the Wireshark on the client for you. Regards, Henry |
|
And here I the trace for the 1.5.0 failed after bootstrap as well. |
Very sorry about that I don't know why I read M6 instead of M16 ... 🙇♀️
Probably a detail, but the device will probably do a
I read the PDF document twice. I also read the capture several time and I understand the problem is the source address of HELLO_VERIFY_PACKET. Your client logs are expected looking at wireshark capture. So again, with current information, I see nothing which makes me think this is not a network (configuration?) issue. Did you try to use Leshan sandbox ? |
|
Hi Leshan Gatekeepers, The reason that I deploy the Bootstrap Application to run on one server and the Device Management Application to run on another server because I think in production we will deploy Leshan this way. The Bootstrap Application is used to authenticate the device. The Device Management Application is used to authorise the device. I dont think it is because of the network issue as the Bootstrap operation works fine: However, when the Device performs the Registration Update I believe that the issue is likely at the Californium layer. This is because the Californium does not have information about the Device Management. It seems that the Califormum does not have to logic to support any communication to the Device Management. It can communicate to the Bootstrap Application but the Device Management Application. And no I have not tried your sandbox yet: All my setup is done using Jetbrains IntelliJ for both Leshan-2.0.0-M16 and Leshan-1.5.0. Regards, Henry |
If the Did you configure two network interfaces on the same host? |
|
Hi Leshan Gatekeepers, If both the DTLS/Bootstrap and DTLS/Registration Update fail to work, then it is the network issue. But here the DTLS/Bootstrap works and DTLS/Registration Update fail. Network is an issue...Ummm I think it is the DTLS and Bootstrap/Device Management IP addresses logic may be the issue and which layer handle the swapping of the Bootstrap and Device Management IP addresses...You would know more than me. My Bootstrap operation works fine at the DTLS handshake and Bootstrap.If it is the network issue then the DTLS handshake MUST fail at the Bootstrap operation. 6431 12.156966 192.168.68.51 192.168.68.57 DTLSv1.2 119 Client Hello After the Bootstrap operation the Device will perform Registration Update, here the DTLS handshake fails. 6527 17.289198 192.168.68.51 192.168.68.58 DTLS 119 Client Hello Regards, Henry |
I may have missed it, but I can't see the answer to that question. The handshake fails, because the |
Just a detail but this is not a registration
This is not true... As boaks says :
So looking at received packet, we can say that at application level (Leshan/Californium/Scandium) all works as expected... Also, it fails only in your environment. I was not able to reproduce and Leshan is largely used and nobody reports that kind of issue... (having bootstap server and DM server on different host is a very common use case) So please stop repeat : "it works on bootstrap and not on register, so this is not a network issue"... boaks (Californium/Scandium main contributor) and me (Leshan main contributor) explain a lot why we think this is not a good argument and why there is strong hint this is a network issue.
I don't know what you are talking about ? you mean at client side ? The issue is not a client side as it sends packet to the right address ... I don't get your point... If you want to move forward on this :
|
|
Hi Gatekeepers,
All is kind of working on separate hosts making the development environment for both Bootstrap Application and Device Management Application slightly more complex. As for the so-called network issue. I don't know enough about it until I can debug down to the Californium to see what really happen there. You are the Gatekeepers and/or Leshan Gods live and breath every seconds. I have my solution and we can close the issue. I move to implement the Leshan Client Demo to the Android and test out all the features like Bootstrap/Register/Register Update (my apology on this confusion) to see how Leshan Device Management handle IP Address changes together with Queue to work. Thank for all your helping on solving the issue. Regards, Henry Nguyễn |
If you want to run that on the same host, you may be better off using different ports (different service => different port). If two interfaces are configure, there may be more issues with that. java -jar target/cf-plugtest-server-3.13.jar --interfaces-pattern "192.168.68.57"
java -jar target/cf-plugtest-server-3.13.jar --interfaces-pattern "192.168.68.58" You will not be able to register successful, but you will see, if the dtls handshake works reliable. |
I agree with that. Demo can easily be launch with different port :
To get all arguments : |
Question
Here is my test setup for two scenarios:
I did test for both release versions:
1.5.0 and 2.0.0-M16
And the sam result happened on both releases.
May you help if configuration to DTLS so that the BS server will not interfere with the Registration Update.
I am looking forward to hear from and Thank for your help in advanced. Henry Nguyen
BS Server (bootstrap) run on bs.local=192..68.68.57/wp=8080/lp=5683/slp=5684
BS is configured to support Id=IOTS-01 PSK=1A2B3C4D and coaps://bs.local:5684/coaps://dm.local:5684
DM server (Device Management runs on dm.local=192.168.68.58/lp=5683/slp=5684
DM is configured to support Id=IOTS-01 PSK=1A2B3C4D
DTLS for bootstrap works
DTLS for registration update failed. It the Client IOTS-01 send Client Hello but the BS sends Hello Verify to IOTS-01. The Client IOTS-01 expects the DM to send the Hello Verify.
BS Server (bootstrap) run on bs.local=192..68.68.57/wp=8080/lp=5683/slp=5684
BS is configured to support Id=IOTS-01 PSK=1A2B3C4D and coaps://bs.local:6684/coaps://dm.local:6684
DM server (Device Management runs on bs.local=192.168.68.57/wp=9080/lp=6683/slp=6684
DM is configured to support Id=IOTS-01 PSK=1A2B3C4D
DTLS for bootstrap works
DTLS for registration update works. It the Client IOTS-01 send Client Hello and the DM sends Hello Verify to IOTS-01.
LeshanPoCSetup.pdf
captureinpcapngaa.zip
captureinpcapngab.zip
captureinpcapngac.zip
The text was updated successfully, but these errors were encountered: