TUN/TAP device is stuck on read

Ramon Fried ramon.fried at tandemg.com
Tue Jun 20 14:32:20 EDT 2017


> From: Ramon Fried
> Sent: Monday, June 19, 2017 5:01 PM
> To: kernelnewbies at kernelnewbies.org
> Subject: TUN/TAP device is stuck on read
    
> Hi !
> I've written a TUN device in user space and it works well.
> Sometimes however, it appears that connectivity stops. no packets are transferred.
> I manage to produce the issue only when I run iperf for a long time for testing the throughput.
> 
> Digging deeper, it looks that the application is blocked on reading from the tun device.
> I opened the verbosity of the logs in the kernel tun driver (drivers/net/tun.c) and it doesn't seem that packets arrive to it's queue.
> 
> How can I debug it further ?
> I'm new to kernel network stack, and I'm looking for a way to track the packet (for instance ping) through the stack until it reaches the queue in the tun driver.
> 
> IE.     
> 
> $ ping 10.0.0.2
> 
> I should be able to trace that ICMP packet all along the way to understand where it was dropped.
> 
> 
> BTW - 
> The network statics in ifconfig don't show any drop of packets.
> 
> Thanks A lot.

Update:
I think I found the problem, but I need some confirmation.

I'm reading and writing to the tun device (/dev/net/tun) from two threads.
It's stated in the kernel docs:
" From version 3.8, Linux supports multiqueue tuntap which can uses multiple
  file descriptors (queues) to parallelize packets sending or receiving. The
  device allocation is the same as before, and if user wants to create multiple
  queues, TUNSETIFF with the same device name must be called many times with
  IFF_MULTI_QUEUE flag."

Can this be the problem ? Is it a must to serialize the read/write to the tun file descriptor if using only one queue ?

Thanks.
Ramon

    


More information about the Kernelnewbies mailing list