Comments (2)
We think we have the same problem as this. In our case the server is pion/dtls and the client is an embedded device communicating over cellular (e.g. NB-IoT). The client occasionally seems to miss the server's Hello Verify Request message and retransmits its Client Hello (with sequence number 0). The server ignores this as duplicate packet (see logs below) and doesn't send a new Hello Verify Request. Attached the Wireshark captures. (In this case I'm not sure whether the replay should stop this packet or whether the handshake should continue with a new server Hello Verify Request after the client hello on no. 12.) Hope this helps analysing this issue.
Server log retransmissions
dtls TRACE: 15:04:51.828203 handshaker.go:166: [handshake:server] Flight 0: Preparing
dtls TRACE: 15:04:51.828276 handshaker.go:166: [handshake:server] Flight 0: Sending
dtls TRACE: 15:04:51.828302 handshaker.go:166: [handshake:server] Flight 0: Waiting
dtls TRACE: 15:04:51.828408 handshaker.go:282: [handshake:server] Flight 0 -> Flight 2
dtls TRACE: 15:04:51.828424 handshaker.go:166: [handshake:server] Flight 2: Preparing
dtls TRACE: 15:04:51.828436 handshaker.go:166: [handshake:server] Flight 2: Sending
dtls TRACE: 15:04:51.828447 conn.go:387: [handshake:server] -> HelloVerifyRequest (epoch: 0, seq: 0)
dtls TRACE: 15:04:51.828496 handshaker.go:166: [handshake:server] Flight 2: Waiting
dtls TRACE: 15:04:52.829430 handshaker.go:166: [handshake:server] Flight 2: Waiting
dtls TRACE: 15:04:53.830491 handshaker.go:166: [handshake:server] Flight 2: Waiting
dtls TRACE: 15:04:54.831180 handshaker.go:166: [handshake:server] Flight 2: Waiting
dtls TRACE: 15:04:55.832146 handshaker.go:166: [handshake:server] Flight 2: Waiting
dtls TRACE: 15:04:56.833152 handshaker.go:166: [handshake:server] Flight 2: Waiting
dtls DEBUG: 15:04:57.449185 conn.go:674: discarded duplicated packet (epoch: 0, seq: 0)
dtls TRACE: 15:04:57.833916 handshaker.go:166: [handshake:server] Flight 2: Waiting
dtls TRACE: 15:04:58.834248 handshaker.go:166: [handshake:server] Flight 2: Waiting
dtls TRACE: 15:04:59.834361 handshaker.go:166: [handshake:server] Flight 2: Waiting
dtls TRACE: 15:05:00.834596 handshaker.go:166: [handshake:server] Flight 2: Waiting
dtls TRACE: 15:05:01.835640 handshaker.go:166: [handshake:server] Flight 2: Waiting
dtls TRACE: 15:05:02.836381 handshaker.go:166: [handshake:server] Flight 2: Waiting
dtls TRACE: 15:05:03.837412 handshaker.go:166: [handshake:server] Flight 2: Waiting
dtls TRACE: 15:05:04.837987 handshaker.go:166: [handshake:server] Flight 2: Waiting
dtls TRACE: 15:05:05.838382 handshaker.go:166: [handshake:server] Flight 2: Waiting
dtls TRACE: 15:05:06.838829 handshaker.go:166: [handshake:server] Flight 2: Waiting
dtls TRACE: 15:05:07.840758 handshaker.go:166: [handshake:server] Flight 2: Waiting
dtls TRACE: 15:05:08.840882 handshaker.go:166: [handshake:server] Flight 2: Waiting
dtls TRACE: 15:05:09.841116 handshaker.go:166: [handshake:server] Flight 2: Waiting
dtls TRACE: 15:05:10.842098 handshaker.go:166: [handshake:server] Flight 2: Waiting
dtls TRACE: 15:05:11.846328 handshaker.go:166: [handshake:server] Flight 2: Waiting
dtls TRACE: 15:05:12.850823 handshaker.go:166: [handshake:server] Flight 2: Waiting
dtls DEBUG: 15:05:13.529103 conn.go:674: discarded duplicated packet (epoch: 0, seq: 0)
dtls TRACE: 15:05:13.851419 handshaker.go:166: [handshake:server] Flight 2: Waiting
dtls TRACE: 15:05:14.852340 handshaker.go:166: [handshake:server] Flight 2: Waiting
dtls TRACE: 15:05:15.853112 handshaker.go:166: [handshake:server] Flight 2: Waiting
dtls TRACE: 15:05:16.853419 handshaker.go:166: [handshake:server] Flight 2: Waiting
dtls TRACE: 15:05:17.854099 handshaker.go:166: [handshake:server] Flight 2: Waiting
dtls TRACE: 15:05:18.855161 handshaker.go:166: [handshake:server] Flight 2: Waiting
dtls TRACE: 15:05:19.856138 handshaker.go:166: [handshake:server] Flight 2: Waiting
dtls TRACE: 15:05:20.857056 handshaker.go:166: [handshake:server] Flight 2: Waiting
2023/01/31 15:05:21.828226 dtls-listener.go:47: dtls: cannot accept connection: cannot accept connection: handshake error: context deadline exceeded
Server log normal connection
dtls TRACE: 14:54:47.469307 conn.go:387: [handshake:server] -> ServerHello (epoch: 0, seq: 1)
dtls TRACE: 14:54:47.469319 conn.go:387: [handshake:server] -> ServerHelloDone (epoch: 0, seq: 2)
dtls TRACE: 14:54:47.469374 handshaker.go:166: [handshake:server] Flight 4: Waiting
dtls DEBUG: 14:54:47.583354 conn.go:737: CipherSuite not initialized, queuing packet
dtls DEBUG: 14:54:47.583430 conn.go:660: received packet of next epoch, queuing packet
2023/01/31 14:54:47.593816 psk-authenticator.go:22: HTTP request (identityHint: ODY3Nzg3MDUwMjU2MTI2, duration: 10.283515ms)
dtls TRACE: 14:54:47.593977 conn.go:743: server: <- ChangeCipherSpec (epoch: 1)
dtls TRACE: 14:54:47.594044 handshaker.go:282: [handshake:server] Flight 4 -> Flight 6
dtls TRACE: 14:54:47.594065 handshaker.go:166: [handshake:server] Flight 6: Preparing
dtls TRACE: 14:54:47.594130 handshaker.go:234: [handshake:server] -> changeCipherSpec (epoch: 1)
dtls TRACE: 14:54:47.594147 handshaker.go:166: [handshake:server] Flight 6: Sending
dtls TRACE: 14:54:47.594163 conn.go:387: [handshake:server] -> Finished (epoch: 1, seq: 3)
dtls TRACE: 14:54:47.594245 handshaker.go:166: [handshake:server] Flight 6: Finished
dtls TRACE: 14:54:47.594270 conn.go:216: Handshake Completed
2023/01/31 14:54:49.840175 handler.go:30: Identity hint: ODY3Nzg3MDUwMjU2MTI2
2023/01/31 14:54:49.840231 handler.go:33: Incoming POST request from 80.187.98.113:21504
2023/01/31 14:54:49.840241 handler.go:42: Remote address '80.187.98.113' at port 21504
2023/01/31 14:54:49.840254 handler.go:79: Convert octet-stream data to CBOR (queries: [format=cbor])
2023/01/31 14:54:49.861455 http.go:110: HTTP response (duration: 21.085935ms code: 202, content-type: text/plain; charset=utf-8, length: 1)
2023/01/31 14:54:49.861507 handler.go:120: Received HTTP response on POST /iot
2023/01/31 14:54:49.861520 handler.go:128: Code: 202, Body: 30
from dtls.
My problem may also be related to this issue.
According to RFC6347 section 4.2.8,
In cases where a server believes it has an existing association on a given host/port quartet and it receives an epoch=0 ClientHello, it SHOULD proceed with a new handshake but MUST NOT destroy the existing association until the client has demonstrated reachability either by completing a cookie exchange or by completing a complete handshake including delivering a verifiable Finished message.
However, it appears that the server does not respond to ClientHello with existing parameters.
These are log screenshots on the client.
The server is built with PionDTLS, the client is not.
(client=10.254.0.162, server=100.66.1.41)
ClientHello (10.254.0.162:49157 -> 100.66.1.41:23088)
No.34: ClientHello (10.254.0.162:49157 -> 100.66.1.41:23088)
No.38: HelloVerifyRequest
ClientHello with existing parameters (10.254.0.162:49157 -> 100.66.1.41:23088): **problem phase**
No.72-: ClientHello with existing parameters (10.254.0.162:49157 -> 100.66.1.41:23088; ignored)
ClientHello with new parameters (10.254.0.162:49160 -> 100.66.1.41:23088)
No.176: ClientHello with new parameters (10.254.0.162:49160 -> 100.66.1.41:23088; client port is changed)
No.181: HelloVerifyRequest
from dtls.
Related Issues (20)
- not close udp conn when dtls handshake failed?
- Add Config.VerifyConnection callback
- noise feature? HOT 2
- Port old fuzzing code to Go's new fuzzing tools
- Connection timeout ignores configured context timeout HOT 6
- Allow supplying external crypto.Signer for TLS signature HOT 4
- OpenSSL E2E Tests are broken in Go 1.20 HOT 1
- Completed Handshake process without any certificate sent by the client HOT 5
- when connecting new listener, bind:already in use error occurs HOT 2
- about pmtu and message too long error
- BadCertificate error on Linux arm64 HOT 5
- Failures in e2e tests can cause GitHub workflows to run for maximum duration HOT 1
- Flaky `TestNetTest/PingPong` HOT 1
- Support `net.PacketConn` in DTLS `Listener`
- Flaky OpenSSL e2e test HOT 1
- Please export some connection state variables HOT 1
- Flight3 does not respect Config.EllipticCurves
- nil pointer dereference in State.UnmarshalBinary
- When the DTLS server receives a large packet, there is an error: packet length and declared length do not match HOT 1
- Transport Error HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dtls.