On Mon, Dec 9, 2013 at 11:40 PM, Nikos Mavrogiannopoulos <n.mavrogiannopoulos at gmail.com> wrote: > On Tue, Dec 10, 2013 at 1:24 AM, Kevin Cernekee <cernekee at gmail.com> wrote: > >>> Thus either you received a duplicate/delayed packet after a worker has >>> disconnected, or the UDP socket connection to a worker process was >>> lost for some reason and UDP packets are being forwarded to the main >>> process instead. >> Hmm, OK. I don't have an easy way to reproduce this, but I did see it >> again running the latest ocserv code from a few days ago. If I get a >> better log I'll post it. > > Are these errors occuring when some other even starts or stops? Sorry, not sure on the exact circumstances. >> 2013-12-08 12:31:27 LIB: Connected to HTTPS on 192.168.0.1 >> 2013-12-08 12:31:31 LIB: Got CONNECT response: HTTP/1.1 200 CONNECTED >> 2013-12-08 12:31:31 LIB: CSTP connected. DPD 440, Keepalive 32400 >> 2013-12-08 12:31:31 LIB: DTLS got write error: The specified session >> has been invalidated for some reason.. Falling back to SSL >> 2013-12-08 12:31:31 LIB: Established DTLS connection (using GnuTLS) >> 2013-12-08 12:46:37 LIB: Unknown packet 03 54 46 01 00 3c 00 00 >> 2013-12-08 12:46:37 LIB: Send BYE packet: Unknown packet received >> It looks like periodic_check() is sending out raw 1-byte DPD commands >> without the "STF\x01" magic header. I suspect you probably want to do >> something like this (compile-tested only): > > I wonder how does this worked so far. I've committed a fix, thanks. Maybe the client-side CSTP DPD catches most of the connection timeouts, and by the time the server-side DPD kicks in, the situation is already hopeless? In my case, the server-side DPD repeatedly kicks in because the client device is sleeping and largely ignoring the requests. The DPD/Keepalive messages have not been good for mobile battery life. Now I am experimenting with dropping the TCP connection, and waking+reconnecting just often enough to keep the server from invalidating the cookie. BTW, another problem I noticed: if there is a stale CSTP connection active and the client attempts to reconnect, ocserv will kill the old connection and give the client his old IP again. But if I close() the CSTP connection (killall -9 openconnect), then reconnect using the same cookie, the IP changes and this confuses openconnect.
