linux returns EAGAIN for closed ocserv interfaces

[Nikos Mavrogiannopoulos]

On Fri, 2014-09-19 at 18:57 +0200, Thomas Veerman wrote:
> Nikos Mavrogiannopoulos schreef op 2014-09-19 17:14:
> > On Fri, Sep 19, 2014 at 5:07 PM, Nikos Mavrogiannopoulos
> > <n.mavrogiannopoulos at gmail.com> wrote:
> >>>> Are these discussions public? Does that change solve the issue? Is 
> >>>> the
> >>>> loop on dnsmasq on tun or udp socket?
> >>> The problem has not re-occured since, but I won't be able to say 
> >>> with confidence until some more
> >>> time has passed.
> >> If that solves the issue, we'd better wrap all close calls in 
> >> ocserv's
> >> main thread.
> > 
> > Having read:
> > http://lwn.net/Articles/576478/
> > https://lkml.org/lkml/2002/7/17/165
> > 
> > it gets more confusing. As I understand close shouldn't have been
> > interrupted in linux.
> 
> Interesting. I'm totally in favor of close(2) having a policy of never 
> failing except for EBADF, but that's not what the man page says (Ubuntu 
> 14.04.1). However, the close(2) wrapper was not the main goal of the 
> patch. I was looking for a potential reason why tun devices weren't 
> properly closed and came across the handle_script_exit function that 
> contains the comment:
>         /* we close the lease tun fd both on success and failure.
>           * The parent doesn't need to keep the tunfd, and if it does,
>           * it causes issues to client.
>           */
> And then proceeds to close the tun fd only if proc->tun_lease.name 
> doesn't contain an empty string. The patch removes that condition. 

Hmm, tun_lease.name should always have a name when the device is opened.
The name is returned by the TUNSETIFF ioctl(), which I suppose if
succeed it should return a valid name. I'll add a check there to be
sure, but whether tun devices always have name can be seen at syslog
(assigning tun device ...).

> I 
> added the close(2) wrapper as an extra measure, but I now realize that's 
> unnecessary (on Linux at least).

Here it gets interesting.

> On Fri, Sep 19, 2014 at 2:54 PM, Niels Peen <niels at peen.ch> wrote:
> 10.255.232.69 is a client of ocserv that disconnected prior to dnsmasq
> returning the result. Removing ocserv from the server (but letting
> people connect with other VPN methods) prevents the problem from
> occurring. 

Is anything related in the ocserv logs about this client? Does his
device exist? Any other kernel related messages that could help?

regards,
Nikos