On Sat, 2014-11-15 at 12:26 +0100, Nikos Mavrogiannopoulos wrote: > > clients behind these nat types will have no issue as long as the nat > keeps the UDP association. If it is lost there is nothing in the > received packets that could allow ocserv to reassociate the session > with the correct server. Er, don't they have the session-id in the ClientHello? And the server *provides* the session-id, so it could make it something which helps with finding the correct server. On Sat, 2014-11-15 at 12:45 +0100, Nikos Mavrogiannopoulos wrote: > David could openconnect reconnect the TLS channel only but continue > sending on the old DTLS channel? That is what is seems to be happening > here. Yes. See your own commit http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/14d807f5 It'll automatically reconnect DTLS after any CSTP reconnect, but *only* if DTLS doesn't have its own rehandshake timer/mechanism set up. And that's probably the right thing to do. If there's been packet loss and the TCP connection is stalled, DTLS could be running just fine and the user might not even have *noticed*. We can reconnect the CSTP without even a momentary blip in actual *traffic* over DTLS. If the CSTP gives us a new session-id, though, we probably *should* reconnect DTLS. I think we're careful not to change our DTLS-Master-Secret on reconnect, aren't we? -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5745 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20141115/46edcd3d/attachment-0001.bin>
