Comments (6)
@jkralik was right! It is an issue with the default configuration of the go-coap dtls server. By default the coap.ListenAndServeDTLS
function creates a new server with this configuration.
To create a server and pass options that are different than default, users should create their own version of coap.ListenAndServeDTLS
that passes those options in the dtls.NewServer
call. For example, I implemented my own listenAndServeDTLSTimeout
:
func listenAndServeDTLSTimeout(network string, addr string, config *piondtls.Config, handler mux.Handler, timeout time.Duration) (err error) {
l, err := net.NewDTLSListener(network, addr, config)
if err != nil {
return err
}
defer func() {
if errC := l.Close(); errC != nil && err == nil {
err = errC
}
}()
s := dtls.NewServer(options.WithMux(handler), options.WithInactivityMonitor(timeout, func(cc *udpClient.Conn) { _ = cc.Close() }))
return s.Serve(l)
}
When I pass a timeout of time.Minute*5
to this function, my server functions and does not close the connection on my client device. Hopefully this helps anyone else that wants to configure their CoAP and DTLS server differently.
from dtls.
Can you reproduce this issue without go-coap in the mix? I'm not sure what else coap.ListenAndServeDTLS
may be doing. You should be able to adapt https://github.com/pion/dtls/blob/master/examples/listen/psk/main.go pretty easily to test this.
from dtls.
Based on what I see, you use coap.ListenAndServeDTLS
, which by default has an InactivityMonitor that closes the connection after 16 seconds.
https://github.com/plgd-dev/go-coap/blob/7f5072879e76a6312fed75c45de17279fe14a7eb/dtls/server/config.go#L30
So could you try create DTLS server similar as in the test with greater timeout? https://github.com/plgd-dev/go-coap/blob/7f5072879e76a6312fed75c45de17279fe14a7eb/dtls/server_test.go#L208 ?
from dtls.
@daenney I am currently trying that, however I can't get the example you mentioned to actually open and serve on my port (5684). It's probably an issue on my end and I'll try to resolve it.
@jkralik Thanks for the suggestion. I did look into that earlier and found that increasing the InactivityMonitor timeout to 5 minutes did not extend the connection length. My client still had to reconnect and do a full handshake for every transmission on a one minute interval.
from dtls.
To clarify, I manually changed the 16 second timeout to a 5 minute one in the default server instantiation by modifying the go coap package. I did not try to create a server as the test does. I can try manually configuring the server instead.
from dtls.
@daenney I got the example to work! I am testing on an EC2 instance and had to change to example to serve on the instance's internal address instead of localhost.
The example DTLS listener does not close the connection like the go-coap one does. So this does appear to be a go-coap issue. Looks like I was barking up the wrong tree, under the flawed assumption that pion dtls was managing the "connection".
Thank you for the suggestions for sanity checking @daenney, and thanks for the suggestion in go-coap, @jkralik. I will keep searching for a fix on the coap side of things and report back in case anyone else eventually has this issue.
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
- 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.