Problem with tun driver

Problem with tun driver

[Martín Ferrari]

(copying Eric as he seems to have been writing patches for tun to work
with netns)

Hello,

I am seeing a strange behaviour with the TUN driver when using it
inside a network name space, hope that somebody can help me...

I still couldn' t reproduce this problem outside of my program, so it
complicates things more. What I am doing is creating a tap device,
moving it into a namespace and then passing the filedescriptor to
another process which in turn starts reading from it.

From strace I see that many reads succeed (Ipv6 autoconfig and arp
requests), and at some point, read returns EBADF. I don't see the
other processes doing anything suspicious on it at the same time. From
reading the kernel sources, it seems to be failing the call to
tun_get(), but I don' t understand how that could be happening...

Any pointers?

Thanks

-- 
Martín Ferrari

Re: Problem with tun driver

[Eric W. Biederman]

Martín Ferrari <martin.ferrari@gmail.com> writes:

> (copying Eric as he seems to have been writing patches for tun to work
> with netns)
>
> Hello,
>
> I am seeing a strange behaviour with the TUN driver when using it
> inside a network name space, hope that somebody can help me...
>
> I still couldn' t reproduce this problem outside of my program, so it
> complicates things more. What I am doing is creating a tap device,
> moving it into a namespace and then passing the filedescriptor to
> another process which in turn starts reading from it.
>
> From strace I see that many reads succeed (Ipv6 autoconfig and arp
> requests), and at some point, read returns EBADF. I don't see the
> other processes doing anything suspicious on it at the same time. From
> reading the kernel sources, it seems to be failing the call to
> tun_get(), but I don' t understand how that could be happening...

Is it possible all of the processes in the network namespace you have
passed the tun dev into are dying, and thus destroying the network
namespace the tun dev is in?

It sounds like you are dealing with the network namespace death case,
or that someone is closing your filedescriptor on you.

Eric

Re: Problem with tun driver

[Eric W. Biederman]

Martín Ferrari <martin.ferrari@gmail.com> writes:

> (copying Eric as he seems to have been writing patches for tun to work
> with netns)
>
> Hello,
>
> I am seeing a strange behaviour with the TUN driver when using it
> inside a network name space, hope that somebody can help me...
>
> I still couldn' t reproduce this problem outside of my program, so it
> complicates things more. What I am doing is creating a tap device,
> moving it into a namespace and then passing the filedescriptor to
> another process which in turn starts reading from it.
>
> From strace I see that many reads succeed (Ipv6 autoconfig and arp
> requests), and at some point, read returns EBADF. I don't see the
> other processes doing anything suspicious on it at the same time. From
> reading the kernel sources, it seems to be failing the call to
> tun_get(), but I don' t understand how that could be happening...

Is it possible all of the processes in the network namespace you have
passed the tun dev into are dying, and thus destroying the network
namespace the tun dev is in?

It sounds like you are dealing with the network namespace death case,
or that someone is closing your filedescriptor on you.

Eric

Re: Problem with tun driver

[Martín Ferrari]

Hi Eric,

On Thu, Sep 16, 2010 at 15:16, Eric W. Biederman <ebiederm@xmission.com> wrote:

> Is it possible all of the processes in the network namespace you have
> passed the tun dev into are dying, and thus destroying the network
> namespace the tun dev is in?

I thought that might be the case, but no, I still have a process
there, and from that I spawn an "ip link" that shows me that the tap
device still exists and it is up.

> It sounds like you are dealing with the network namespace death case,
> or that someone is closing your filedescriptor on you.

I also checked that, but no, nobody is closing it... To make things
more strange, this happens to me only when communicating with my slave
processes by a ssh to localhost (the filedescriptor is passed using
SCM_RIGHTS), but not when I fork directly, so at this point a timing
issue seems to be the only explanation. But it still does not make
sense, as some traffic gets exchanged correctly.

Thanks for your time.
-- 
Martín Ferrari