On Tue, 2014-01-21 at 09:37 -0800, Kevin Cernekee wrote: > To get to the point where cstp_reconnect() will block, the CSTP > connection would need to be stalled long enough to lose a couple of > DPD requests or replies (typically on the order of minutes), and then > the new TLS connection would need to time out or fail. Right, that's probably it then. A crappy network with packet loss or weird NAT misbehaviour could kill the TCP connection while the UDP is working at least *partly*, and the DPD could trigger. A reconnect may happen OK, and there's been no loss of service. > I was toying with the idea of just closing the DTLS connection any > time the CSTP connection is closed, under the assumption that the DTLS > parameters are likely to get changed upon CSTP reconnection. Would > that make sense? In my testing against Cisco servers, the DTLS parameters *weren't* changing. -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6242 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20140121/28cd9fb8/attachment.bin>
