Hi,
Since commit 7a1473683d544c41b7ab2374b21e9748c8d7d49f,
Leshan should not send CLOSE_NOTIFY on deregistration.
About the "HelloRequest", as I understand the spec this should be
used by the server to ask for a new renegotiation(also called
"rehandshake") in an existing connection.
(see https://tools.ietf.org/html/rfc5246#section-7.4.1.1 and
https://tools.ietf.org/html/rfc5246#section-7.4.1.2)
In your case, the CLOSE_NOTIFY close the DTLS connection, then the
Leshan server want to respond to the Leshan client, but as there is
no connection, the Leshan Server will initiate a new handshake for a
new connection. In this case the Leshan Server will be the Client at
DTLS meaning and so send a ClientHello. (This is not a
renegotiation)
Simon
Le 25/09/2015 17:12, Kraus Achim
(INST/ESY4) a écrit :
Hi All,
I'm not sure, if my observation is a "feature" or "bug", so I just report it (and didn't use the "bug-report"):
Setup:
Leshan Client using DTLS/PSK
Leshan Server
Both using Californium/Scandium.
When the lwm2m-client deregisters (lwm2m operation), the lwm2m-server response with a message and then closes the dtls session.
Sometimes this is executed by scandium in reverse order, because the message is sent "async via a queue" but the close is executed "sync".
If the execution is reversed, the server tries to send the response message without a DTLSSession and therefore starts a new handshake
with a "ClientHello" (see log below). But in my opinion, this is wrong. The server should send a "HelloRequest".
RFC 6347, page 23, says
"When the server desires a rehandshake, it transitions from the
FINISHED state to the PREPARING state to transmit the HelloRequest.
When the client receives a HelloRequest, it transitions from FINISHED
to PREPARING to transmit the ClientHello."
May be this doesn't clearly cover the situation above, but when the server sends a "ClientHello", the roles in the PSK
Handshake are exchanged. Therefore the server (now the handshake client) have to guess the "PSK identity" using the ip-address.
Using the "HelloRequest" will preserve the roles and therefore the handshake would run as "usual".
Mit freundlichen Grüßen / Best regards
Achim Kraus
Bosch Software Innovations GmbH
Communications (INST/ESY4)
Stuttgarter Straße 130
71332 Waiblingen
GERMANY
www.bosch-si.de
www.blog.bosch-si.com
achim.kraus@xxxxxxxxxxxx
Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B
Executives: Dr.-Ing. Rainer Kallenbach; Michael Hahn
######################################## wireshark log ###############################################################
(client sends deregister)
No. Time Source Destination Protocol Length Info
88 13.647679000 192.168.10.111 192.168.10.103 DTLSv1.2 93 Application Data
(server close)
No. Time Source Destination Protocol Length Info
89 13.692304000 192.168.10.103 192.168.10.111 DTLSv1.2 73 Encrypted Alert
(server send "Client Hello", PSK handshake roles exchanged!)
No. Time Source Destination Protocol Length Info
90 13.747024000 192.168.10.103 192.168.10.111 DTLSv1.2 147 Client Hello
No. Time Source Destination Protocol Length Info
91 13.758528000 192.168.10.111 192.168.10.103 DTLSv1.2 102 Hello Verify Request
_______________________________________________
cf-dev mailing list
cf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cf-dev
|