linux returns EAGAIN for closed ocserv interfaces

[Nikos Mavrogiannopoulos]

On Fri, 2014-09-19 at 22:13 +0200, Niels Peen wrote:
> > On 19 Sep 2014, at 21:41, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> 
> > Is anything related in the ocserv logs about this client? Does his
> > device exist? Any other kernel related messages that could help?
> 
> Sep 18 22:13:47 fanupiri ocserv[4444]: sec-mod: auth init for user ‘XXX' (group: '') from ‘1.1.1.1'
> Sep 18 22:13:54 fanupiri ocserv[4442]: main: 1.1.1.1:51466 main-misc.c:414: command socket closed
> Sep 18 22:13:55 fanupiri ocserv[4442]: main: 1.1.1.1:51467 main-misc.c:414: command socket closed
> Sep 18 22:13:56 fanupiri ocserv[4442]: main: 1.1.1.1:51468 assigned IPv4 to ‘XXX': 10.255.232.69
> Sep 18 22:13:56 fanupiri ocserv[4442]: main: 1.1.1.1:51468 assigning tun device tun_oc9
> Sep 18 22:13:56 fanupiri ocserv[4442]: main: 1.1.1.1:51468 user ‘XXX' of group '[unknown]' authenticated (using cookie)
> Sep 18 22:13:57 fanupiri ocserv[4442]: main: 1.1.1.1:51465 main-misc.c:414: command socket closed
> Sep 18 22:13:57 fanupiri ocserv[4442]: main: 1.1.1.1:51465 main-misc.c:414: command socket closed
> Sep 18 22:26:12 fanupiri ocserv[4442]: main: 1.1.1.1:51468 main-misc.c:414: command socket closed
> 
> Output from strongswan and ntpd suggests that the tun_oc9 device is taken down:
> 
> Sep 18 22:26:12 fanupiri charon: 12[KNL] interface tun_oc9 deactivated  
> Sep 18 22:26:12 fanupiri charon: 07[KNL] interface tun_oc9 deleted
> Sep 18 22:26:14 fanupiri ntpd[13026]: Deleting interface #130 tun_oc9, 10.255.232.68#123, interface stats: received=0, sent=0, dropped=0, active_time=737 secs
> 
> And ocserv re-uses it for a different user later:
> Sep 18 23:58:56 fanupiri ocserv[4442]: main: 2.2.2.2:47417 assigning tun device tun_oc9

So as far as I understand the situation here is a client disconnecting,
ocserv dropping the tun device, and a message dnsmasq had on its queue
for that client enters an infinite loop with the kernel returning EAGAIN
for that send. The key to the answer is where in the kernel network
stack that EAGAIN comes from. 

A question about the other vpn server that you use. Does it open a new
tun device for each client? If not that may also give some hint on the
issue.

> Occasionally I see this, but with multiple users online at any time I can’t identify who causes it. I also see it when the problem does not occur. (Off-topic: perhaps ocserv could log the originating IP.)
> Sep 18 22:14:13 fanupiri ocserv[4442]: main: could not determine the owner of received UDP packet

The message just before that one should clarify the reason. I've now
made it more verbose.

regards,
Nikos