oscserv error: "could not determine the owner of received UDP packet"

[David Woodhouse]

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>