Hi, Simon.
Maybe you can change the demo server again to the more update version, so that on my side I can run the scenario, when I fail to connect, and collect logs and
debug this situation?
Thank you,
Mark
From: Simon Bernard [mailto:contact@xxxxxxxxxxxxxxx]
Sent: Wednesday, November 25, 2020 12:34 PM
To: Mark Lugovskoy <mark.lugovskoy-ext@xxxxxxx>; Kraus Achim (IOC/PAP-HU) <Achim.Kraus@xxxxxxxx>; leshan developer discussions <leshan-dev@xxxxxxxxxxx>; Thomas LE ROUX <thomas.leroux@xxxxxxxx>
Subject: Re: AW: [leshan-dev] A question regarding Leshan demo web site
Yes, the specification is clear about the client side. I think your device does not respect it.
At server side this is less clear and maybe for our server which supports only DTLS 1.2 we don't do the right thing too. (we are waiting for IETF answer)
Le 24/11/2020 à 15:47, Mark Lugovskoy a écrit :
Hi, Simon.
Sorry, I didn’t receive any e-mail from you since Yesterday.
What about my client? Do you still say there’s a problem with it also?
Thank you,
Mark
Hi,
I was just writing an email to you to ask if you didn't missed my previous request in my previous mail.
In my previous mail I said that I changed the code and ask you to retest to be sure this is really this VERSION field value which makes your device unhappy.
Thx Mark for testing, It seems that this is confirmed now.
Let's see if we get an answer on the mailing list :
https://mailarchive.ietf.org/arch/msg/tls/rQ3El3ROKTN0rpzhRpJCaKOrUyU/ and then we will decide what we should do.
Simon
Le 24/11/2020 à 15:34, Mark Lugovskoy a écrit :
Hi,
I now tried again and managed to connect to the demo server.
Did you make some change there?
Thank you,
Mark
Hi together,
I wrote to the ietf-tls-list, see
https://mailarchive.ietf.org/arch/msg/tls/rQ3El3ROKTN0rpzhRpJCaKOrUyU/
Let’s see, if we get answers.
And if that version is really the issue for the device.
Mit freundlichen Grüßen / Best regards
Achim Kraus
Bosch IoT Hub - Product Area IoT Platform (IOC/PAP-HU)
Bosch.IO GmbH | Stuttgarter Straße 130 | 71332 Waiblingen |
GERMANY | www.bosch.io
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber, Dr. Aleksandar Mitrovic, Yvonne Reckling
Openssl 1.1.1 uses 1.0, mbedtls uses 1.2 for that HelloVerifyRequest.
This could match with my understanding. (But I agree RFC is written in a confusing way)
If it’s possible, I would also feel more comfortable, if you setup the sandbox with 1.2 and verify, that the client
is really blocked by that, and something different.
I pushed temporary commit in master to be able to deploy it on the sandbox. This should be available in few minutes.
Mark, maybe you could retest in 20/30 minutes to ensure that this is really this VERSION field value which makes your device unhappy
Le 23/11/2020 à 17:35, Kraus Achim (IOC/PAP-HU) a écrit :
Hi Simon,
First results:
Openssl 1.1.1 uses 1.0, mbedtls uses 1.2 for that HelloVerifyRequest.
Both clients works with 1.2 or 1.0
From your previous mail:
The server MUST use the same
version number in the HelloVerifyRequest that it would use when
sending a ServerHello.
That’s interesting … and doesn’t fit. So I will write to the ietf-tls-list.
Mit freundlichen Grüßen / Best regards
Achim Kraus
Bosch IoT Hub - Product Area IoT Platform (IOC/PAP-HU)
Bosch.IO GmbH | Stuttgarter Straße 130 | 71332 Waiblingen |
GERMANY | www.bosch.io
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber, Dr. Aleksandar Mitrovic, Yvonne Reckling
As you are here Achim, I will not open a dedicated issue in californium.
Let discuss about it here.
My first point : I'm not sure this is a good idea to change default behavior in a minor version release. In this particular case we could maybe considered this as a bug fix (But I'm not sure of this as this is just a SHOULD and not a MUST).
My second point : About the RFC, it says :
1. TLS 1.2 server implementations SHOULD use DTLS
2. version 1.0 regardless of the version of TLS that is expected to be
3. negotiated. DTLS 1.2 and 1.0 clients MUST use the version solely to
4. indicate packet formatting (which is the same in both DTLS 1.2 and
5. 1.0) and not as part of version negotiation. In particular, DTLS 1.2
6. clients MUST NOT assume that because the server uses version 1.0 in
7. the HelloVerifyRequest that the server is not DTLS 1.2 or that it
8. will eventually negotiate DTLS 1.0 rather than DTLS 1.2.
9. The server MUST use the same
10. version number in the HelloVerifyRequest that it would use when
11. sending a ServerHello.
So I'm not sure to understand this correctly ? Does it means that a DTLS 1.2 server SHOULD use 1.2 version in hello_verfiy_request ? Using 1.0 version is only for server which
support 1.0 to 1.2 ?
(I suppose you have another understanding else you didn't implement this ? or maybe you just missed the second sentence ?)
Mark,
no matter how this discussion will end, your device seems to not respect this part of the RFC :
In particular, DTLS 1.2
clients MUST NOT assume that because the server uses version 1.0 in
the HelloVerifyRequest that the server is not DTLS 1.2 or that it
will eventually negotiate DTLS 1.0 rather than DTLS 1.2.
So you should report this.
Simon
Le 23/11/2020 à 16:48, Kraus Achim (IOC/PAP-HU) a écrit :
Hi together,
there is a DtlsConfiguration.Builder.setProtocolVersionForHelloVerifyRequests.
That may help out.
It’s always not too easy, to fix something according a RFC, if some implementations are used to behave different ;-).
Mit freundlichen Grüßen / Best regards
Achim Kraus
Bosch IoT Hub - Product Area IoT Platform (IOC/PAP-HU)
Bosch.IO GmbH | Stuttgarter Straße 130 | 71332 Waiblingen |
GERMANY | www.bosch.io
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber, Dr. Aleksandar Mitrovic, Yvonne Reckling
I bet this could be because of :
https://github.com/eclipse/californium/pull/1397
See :
https://tools.ietf.org/html/rfc6347#section-4.2.1
The default VERSION value changes which change default behavior, but this changes follow a RFC recommendation so I'm not sure if this will(or even should) be changed back ? (My guess is probably not)
This is possible to change it using the API, see :
https://github.com/eclipse/californium/pull/1397/files#diff-3c57eeacb63a45e50c11737e09d3e166367773a093f2cb216e3ece81f2477597R1606 (but this will probably not changed on the sandbox)
Le 23/11/2020 à 16:17, Simon Bernard a écrit :
We succeed to get a capture. I joined it.
Your device sounds to not answer to HELLO_VERIFY_REQUEST from the server.
I guess there is some changes about this at Californium side. I will open a ticket to discuss about this. Please do not hesitate to join the discussion.
Le 23/11/2020 à 15:36, Simon Bernard a écrit :
Hi,
You can eventually run leshan-server-demo locally and so run wireshark at server side.
Or Eventually, I can try to do a capture at server side. (as there is not so much traffic) I'm currently running a tcpdump on the sandbox. If you make your device communicate now I can see the exchange.
(This will maybe be complicated to synchronize ourself, I will let the tcpdump capturing for the next hour but I will stop it before the end of the day)
Simon
Le 23/11/2020 à 15:00, Mark Lugovskoy a écrit :
Hi,
I tried to connect using this sequence of commands from GSM modem:
AT#LWM2MINJKEYS=0,1,"mark123456","mark123456","0987654321"
AT#LWM2MSTS=0,999,"coaps://leshan.eclipseprojects.io:5784",1
at#reboot
AT#LWM2MENA=1
With this sequence, I managed to connect until Thursday after noon. In the evening I already couldn’t connect.
I pretty much use my GSM modem as black box, so I can’t provide much more details. I also don’t have Wireshark.
I’ll try to find more information that you asked.
Thank you,
Mark
From: Thomas LE ROUX [mailto:thomas.leroux@xxxxxxxx]
Sent: Monday, November 23, 2020 3:33 PM
To: leshan developer discussions <leshan-dev@xxxxxxxxxxx>
Cc: Mark Lugovskoy <mark.lugovskoy-ext@xxxxxxx>
Subject: Re: [leshan-dev] A question regarding Leshan demo web site
There must be something wrong with either your computer's networking options, the sequence of command you used, registration to the server (wrong key, or a device with the same
identity is registered with a wrong key. You can check this out at
https://leshan.eclipseprojects.io/#/security) or something else.
Hi,
Is there some problem with this server?
It should not. But you maybe found a bug ?
Thursday I integrated in master (and so applied on Leshan sandbox) some commits about integration of the new Californium version, there is maybe a regression with this. (Californium itself or my modifications)
This could help if you provide more context. (which client used ? DTLS or not ?, if DTLS, rpk psk or x509 ? providing wireshark capture or log could help too)
If you prefer you can use github issue ? (Mailing list is fine too)
Simon
Le 23/11/2020 à 13:17, Mark Lugovskoy a écrit :
Hi,
Last week I connected with my device successfully to the demo LESHAN server:
https://leshan.eclipseprojects.io/#/clients.
But since Thursday I can’t connect to it, with the same sequence of commands that I used before.
Is there some problem with this server?
Thank you,
Mark
_______________________________________________
leshan-dev mailing list
leshan-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/leshan-dev
_______________________________________________
leshan-dev mailing list
leshan-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/leshan-dev
_______________________________________________
leshan-dev mailing list
leshan-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/leshan-dev
_______________________________________________
leshan-dev mailing list
leshan-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/leshan-dev
|