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:
>> 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.
I found a test case for this. Modify your local openconnect tree as
follows, then just start pinging over the ocserv connection:
-- 8< --
diff --git a/cstp.c b/cstp.c
index 0980095..7e5e9e0 100644
--- a/cstp.c
+++ b/cstp.c
@@ -879,6 +879,9 @@ int cstp_mainloop(struct openconnect_info
*vpninfo, int *timeout)
goto handle_outgoing;
}
+ if (time(NULL) % 20 == 0)
+ goto do_reconnect;
+
switch (keepalive_action(&vpninfo->ssl_times, timeout)) {
case KA_REKEY:
do_rekey:
-- 8< --
FWIW, I'm building openconnect against OpenSSL on this machine, and
the DTLS traffic dies immediately on the first CSTP reconnect.
I will include this fix in V9 of my patch series:
https://github.com/cernekee/openconnect/commit/7ea4fd2efae8515695ffb235df09d973fbf7a029
