Bug 96381 - TUN/TAP user API regression in 3.19, non-bloking read returns 0 when no data is available rather than EAGAIN
Summary: TUN/TAP user API regression in 3.19, non-bloking read returns 0 when no data ...
Status: NEW
Alias: None
Product: Networking
Classification: Unclassified
Component: Other (show other bugs)
Hardware: All Linux
: P1 high
Assignee: Stephen Hemminger
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-04-09 09:25 UTC by Ambroz Bizjak
Modified: 2019-02-26 23:19 UTC (History)
2 users (show)

See Also:
Kernel Version: 3.19.3
Tree: Mainline
Regression: No


Attachments

Description Ambroz Bizjak 2015-04-09 09:25:41 UTC
With kernel 3.19, a read() from a TUN/TAP file descriptor in non-blocking mode will return 0 when no data is available, rather than fail with EAGAIN. This breaks certain applications which will interpret the 0 return value as a zero-length packet and happily go on reading more packets.

Here's relevant parts of my application showing the change of behavior and how the application locks up with kernel 3.19.

-- strace with 3.18 --
open("/dev/net/tun", O_RDWR)            = 5
ioctl(5, TUNSETIFF, 0x7ffe24f1e620)     = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 6
ioctl(6, SIOCGIFMTU, {ifr_name="tun4", ifr_mtu=1500}) = 0
close(6)                                = 0
fcntl(5, F_SETFL, O_RDONLY|O_NONBLOCK)  = 0
epoll_ctl(3, EPOLL_CTL_ADD, 5, {0, {u32=6509592, u64=6509592}}) = 0
read(5, 0xac8010, 1500)                 = -1 EAGAIN (Resource temporarily unavailable)
epoll_ctl(3, EPOLL_CTL_MOD, 5, {EPOLLIN, {u32=6509592, u64=6509592}}) = 0

-- strace with 3.19 --
open("/dev/net/tun", O_RDWR)            = 5
ioctl(5, TUNSETIFF, 0x7ffea2f4d970)     = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 6
ioctl(6, SIOCGIFMTU, {ifr_name="tun4", ifr_mtu=1500}) = 0
close(6)                                = 0
fcntl(5, F_SETFL, O_RDONLY|O_NONBLOCK)  = 0
epoll_ctl(3, EPOLL_CTL_ADD, 5, {0, {u32=6509592, u64=6509592}}) = 0
read(5, "", 1500)                       = 0
read(5, "", 1500)                       = 0
read(5, "", 1500)                       = 0
read(5, "", 1500)                       = 0
read(5, "", 1500)                       = 0
...
Comment 1 Stéphane Charette 2015-04-25 07:03:43 UTC
Think I ran into this.  Using Boost ASIO to do async reads from TAP fd.  Now that I've upgraded to Ubuntu 15.04 (kernel 3.19.0-15), the application behaves differently where ASIO returns immediately with EOF error when attempting to read from the TAP fd.
Comment 2 Stéphane Charette 2019-02-26 23:19:02 UTC
Anyone know if this was ever fixed?

Note You need to log in before you can comment on or make changes to this bug.