[GIT PULL V4] JNI bindings for libopenconnect

[Kevin Cernekee]

On Tue, Dec 10, 2013 at 8:18 AM, Nikos Mavrogiannopoulos
<n.mavrogiannopoulos at gmail.com> wrote:
> On Tue, Dec 10, 2013 at 4:44 PM, Kevin Cernekee <cernekee at gmail.com> wrote:
>
>> 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.
>
> I cannot reproduce that. Could you try with the latest git? I want to
> check what is the reason that the initial IP wasn't used.

This requires two concurrent sessions under the same username.  I see
this behavior using the ocserv head of tree (rev 791d77632):

1) First session starts; the IPv4 address is based on a hash of the
username so it is typically the same number every time.

2) Second session starts; the IP is randomly chosen because
get_ipv4_lease() picks the IP via gnutls_rnd() if its first choice,
based on the username hash, was taken:

    ocserv[18952]: [192.168.0.10]:32780 cannot assign remote IP
[192.168.1.191]:0 to 'test'; it is in use.
    ocserv[18952]: [192.168.0.10]:32780 selected IP for 'test':
[192.168.1.130]:0
    ocserv[18952]: [192.168.0.10]:32780 assigned IPv4 to 'test':
[192.168.1.131]:0

3) kill -9 <second_openconnect_pid>

4) handle_commands() gets 0 from recvmsg(), returns ERR_WORKER_TERMINATED.

5) remove_proc() is called, printing "command socket closed" in the
log and removing our entry (including leases) from clist.

6) openconnect reconnects with the same cookie.

7) ocserv can't find any trace of our existing leases in clist, and so
get_ipv4_lease() is called again to generate a new random number.


The hash mentioned in step #1 will effectively mask this problem if
there is only one active connection under each username.

Obviously openconnect won't complain about IP changes if I'm invoking
it manually with --cookie, but it will complain if the CSTP connection
drops (e.g. TCP reset), it auto-reconnects 10 seconds later, and then
it gets a different IP.