Connection timeout ignores configured context timeout about dtls HOT 6 CLOSED

@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.