On Fri, 2014-04-18 at 11:15 -0700, Kevin Cernekee wrote: > On Fri, Apr 18, 2014 at 1:51 AM, Nikos Mavrogiannopoulos > <n.mavrogiannopoulos at gmail.com> wrote: > > That means that the session (TCP/TLS) has timed out, but the phone > > continues sending DTLS UDP packets and expecting the server to reply. > > There is not much the server can do, as the session's credentials no > > longer exist. What you could do is try to play with the various > > timeout values in the server's configuration and see which one fits > > your mobile better. In that case let us know. > > FWIW, Cisco notes that DPD is used by their software to figure out > when to fall back from DTLS to TLS: > http://www.cisco.com/c/en/us/td/docs/security/asa/asa84/configuration/guide/asa_84_cli_config/vpn_anyconnect.html#wp1090425 > Setting a more aggressive DPD interval could help the client determine > that it needs to reconnect. The downside is that DPD packets sent > from the gateway will often cause wakeups on a sleeping mobile device, > affecting battery life. I'm afraid that there is something not nice there. The server shouldn't have disassociated the UDP session from that process, not unless the client changed its port, or it's some issue of the linux kernel (the udp fd passing we do to the appropriate process is pretty undocumented). I'd hope it is the former, but even in that case I don't see an easy solution. Maybe just disable UDP/DTLS for these clients, or force the DPD to less than 1.50 mins. regards, Nikos
