[GIT PULL V4] JNI bindings for libopenconnect

[Kevin Cernekee]

On Mon, Nov 4, 2013 at 7:38 AM, Nikos Mavrogiannopoulos
<n.mavrogiannopoulos at gmail.com> wrote:
> On Sun, Nov 3, 2013 at 9:22 PM, Kevin Cernekee <cernekee at gmail.com> wrote:
>
>> The modified ics-openvpn Android app has been tested on ARMv7, x86, and
>> MIPS devices.  It is able to connect to ocserv and ping through the VPN on
>> all architectures.
>
> Thanks for the app it is really useful.
>
>> I sometimes see intermittent errors logged on the ocserv side:
>>     ocserv[25459]: [main] DTLS record version: 1.0
>>     ocserv[25459]: [main] DTLS hello version: 220.94
>>     ocserv[25459]: [main] unexpected DTLS content type: 23
>>     ocserv[25459]: [main] could not determine the owner of received UDP packet
>
> Do you have an idea of when this is received? Is it after a client has
> terminated? In ocserv the main process receives the first DTLS packet
> (client hello) and forwards it to the relevant process (in a complex
> process - as connecting on UDP cannot be handled as nicely as TCP).
> The error that you see means that the main process received a DTLS
> packet that isn't a client hello (23 is application data), which was
> probably intended to be delivered to a worker process.
>
> 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.

I also saw another issue:

ocserv[4080]: [192.168.0.10]:42559 have not received TCP DPD for long (906 secs)
ocserv[4080]: [192.168.0.10]:42559 TCP MSS is 1435
ocserv[4080]: [192.168.0.10]:42559 received 32 byte(s) (TLS)
ocserv[4080]: [192.168.0.10]:42559 received BYE packet; exiting
ocserv[3003]: [192.168.0.10]:42559 command socket closed

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):

diff --git a/src/worker-vpn.c b/src/worker-vpn.c
index d4edd5f..290b177 100644
--- a/src/worker-vpn.c
+++ b/src/worker-vpn.c
@@ -745,8 +745,7 @@ int max, e, ret;
        }
        if (now-ws->last_msg_tcp > DPD_TRIES*ws->config->dpd) {
                oclog(ws, LOG_ERR, "have not received TCP DPD for long
(%d secs)", (int)(now-ws->last_msg_tcp));
-               ws->buffer[0] = AC_PKT_DPD_OUT;
-               tls_send(ws->session, ws->buffer, 1);
+               tls_send(ws->session, "STF\x01\x00\x00\x03\x00", 8);

                if (now-ws->last_msg_tcp > DPD_MAX_TRIES*ws->config->dpd) {
                        oclog(ws, LOG_ERR, "have not received TCP DPD
for very long; tearing down connection");


Also, cstp_mainloop() in libopenconnect can rely on stale or
uninitialized data if cstp_read() returns a malformed (short) packet.
In this case it only received "\x03" from ocserv, but it erroneously
displayed buf[1..7] left over from a previous read, obfuscating the
source of the problem.