Currently, in /etc/conf.d/net there is no mean to specify whether tun/tap interface should be created using openvpn --mktun or tunctl. If both are installed, openvpn is used. It turns out that (for reasons I'm trying to investigate) the two are not interchangeable. In particular, if the tap interface is created using openvpn, then some programs that can read from tap interfaces (eg, vde) do NOT work (they receive no data). If the interface is created with tunctl, everything is fine. Reproducible: Always
(In reply to comment #0) eg, try this (on machines with openvpn installed): box1# cat /etc/conf.d/net ... tuntap_tap0="tap" config_tap0=( "10.0.0.1/24") box2# cat /etc/conf.d/net ... tuntap_tap0="tap" config_tap0=( "10.0.0.2/24") run vde_switch on both hosts: box1# vde_switch -tap tap0 box2# vde_switch -tap tap0 connect the two switches: box1# dpipe vde_plug = ssh user@box2 vde_plug now pings between 10.0.0.1 and 10.0.0.2 fail. If, otoh, openvpn is not installed and the tap interface is created with usermode-utilities (tunctl), the above setup works just fine.
baselayout-2 default to using tunctl purely because openvpn cannot apply file mode permissions to the node. The bad news is that tunctl is not available on all platforms, whereas openvpn is. So the question would have to be, what does tunctl do differently to openvpn that renders the interface not working for you? What baselayout and openvpn versions do you have installed?
(In reply to comment #2) > baselayout-2 default to using tunctl purely because openvpn cannot apply file > mode permissions to the node. The bad news is that tunctl is not available on > all platforms, whereas openvpn is. Well, letting the user (optionally) choose what he wants cannot make things worse. What I'm thinking of is something like modules_tuntap=("tunctl") or something like that (I don't have enough knowledge about initscripts to exactly tell how the option should be named, but I hope you got the idea). > So the question would have to be, what does tunctl do differently to openvpn > that renders the interface not working for you? Good question, I was just looking at openvpn sources. Comparing the codes that creates the interface, I see that openvpn calls some ioctl()s and sets some flags that tunctl does not call. The file is tun.c, and the extra openvpn lines are the following: (line 994) #if defined(IFF_ONE_QUEUE) && defined(SIOCSIFTXQLEN) ifr.ifr_flags |= IFF_ONE_QUEUE; #endif (line 1033) /* * Try making the TX send queue bigger */ #if defined(IFF_ONE_QUEUE) && defined(SIOCSIFTXQLEN) { struct ifreq netifr; int ctl_fd; if ((ctl_fd = socket (AF_INET, SOCK_DGRAM, 0)) >= 0) { CLEAR (netifr); strncpynt (netifr.ifr_name, ifr.ifr_name, IFNAMSIZ); netifr.ifr_qlen = tt->options.txqueuelen; if (ioctl (ctl_fd, SIOCSIFTXQLEN, (void *) &netifr) >= 0) { msg (D_OSBUF, "TUN/TAP TX queue length set to %d", tt->options.txqueuelen); } else { msg (M_WARN | M_ERRNO, "Note: Cannot set tx queue length on %s", ifr.ifr_name); } close (ctl_fd); } else { msg (M_WARN | M_ERRNO, "Note: Cannot open control socket on %s", ifr.ifr_name); } } #endif From my tests, the value of tt->options.txqueuelen is 0. It seems thus that the tx queue length is set to 0 for the tun/tap interface. I don't know whether this might be the cause of the problem; only, these are the only things that openvpn does and tunctl doesn't. The tests I did seem to indicate that transmission is the problem, as the interface will receive packets but not send them. > What baselayout and openvpn versions do you have installed? baselayout-1.12.9-r2, openvpn-2.0.6. Thanks for your help.
(In reply to comment #3) > Well, letting the user (optionally) choose what he wants cannot make things > worse. What I'm thinking of is something like modules_tuntap=("tunctl") or > something like that (I don't have enough knowledge about initscripts to exactly > tell how the option should be named, but I hope you got the idea). It just creates the virtual interface, the user shouldn't need to make a distinction between the two really. > From my tests, the value of tt->options.txqueuelen is 0. As yes, I fixed that myself and upstream accepted it. I think it's fixed in openvpn-2.0.7-r2. Want to try it out?
(In reply to comment #4) > It just creates the virtual interface, the user shouldn't need to make a > distinction between the two really. Yes, he shouldn't...if the outcomes of the two programs used to create the interface were the same (but see below). > > From my tests, the value of tt->options.txqueuelen is 0. > As yes, I fixed that myself and upstream accepted it. I think it's fixed in > openvpn-2.0.7-r2. Want to try it out? With pleasure. If it was just a bug and not an intentional behavior, then my original request would of course be moot. I'll try openvpn-2.0.7-r2 asap and will report back here. Thanks
(In reply to comment #5) >> I think it's fixed in openvpn-2.0.7-r2. Want to try it out? > With pleasure. If it was just a bug and not an intentional behavior, then my > original request would of course be moot. I'll try openvpn-2.0.7-r2 asap and > will report back here. 2.0.7-r2 works perfectly AFAICT. Closing the bug, thanks.
