[GIT PULL V4] JNI bindings for libopenconnect

[Kevin Cernekee]

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.