Fedora Account System
Red Hat Associate
Red Hat Customer
I would like to see vtun in EPEL 7. Would you add it, or would you like assistance in packaging it for EPEL 7? I haven't looked at the package yet; are there known issues blocking it, or is it just a case of you don't use EPEL 7?
Never came up before :) I did a mock build against epel-7 and nothing obvious broke, so I requested an epel7 branch via the package database. Stay tuned...
vtun-3.0.4-1.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-414e87e78e
vtun-3.0.4-1.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-414e87e78e
I installed this from testing, and did find a couple of issues: - One packaging issue: the package includes a subdirectory in /var/lock, but that's on the /run tmpfs now, so needs to have an entry in /usr/lib/tmpfiles.d - One bug (may be a bug in vtund?): when I enable encryption on a session, the vtund server segfaults in OpenSSL: [79424.644636] vtund[27482]: segfault at 0 ip 00007fc14cda41ca sp 00007fff8b5b1c10 error 4 in libcrypto.so.1.0.1e[7fc14ccba000+1c0000]
fixed the tmpfiles.d issue, will upload new test build soon. Re. openssl: what version of openssl-libs ships on el7? I have 1.0.2k on F24 (where vtun works fine encrypted) and 1.1.0f on F26 (where I haven't tried it yet).
vtun-3.0.4-2.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-5e53642508
vtun-3.0.4-2.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-5e35833214
vtun-3.0.4-2.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-5e35833214
vtun-3.0.4-2.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-5e53642508
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle. Changing version to '27'.
vtun-3.0.4-2.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.
vtun-3.0.4-2.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.
Please note that encryption in vtun-3.0.4-2 is completely broken. Encryption context is initialized into a temporary variable (pctx_enc) so actual context is always null. #0 EVP_EncryptUpdate (ctx=0x0, out=out@entry=0x7f036e71a700 "", outl=outl@entry=0x7ffd7ab092ac, in=in@entry=0x7f036e71bb00 "E", inl=88) at evp_enc.c:377 #1 0x00007f036cf50ecc in encrypt_buf (len=84, in=<optimized out>, out=0x7ffd7ab093d8) at lfd_encrypt.c:328 #2 0x00007f036cf4f816 in lfd_run_down (out=0x7ffd7ab093d8, in=<optimized out>, len=<optimized out>) at linkfd.c:115 #3 lfd_linker () at linkfd.c:341 #4 linkfd (host=host@entry=0x7f036e719390) at linkfd.c:427 #5 0x00007f036cf4d871 in tunnel (host=host@entry=0x7f036e719390) at tunnel.c:227 #6 0x00007f036cf4b66e in connection (sock=sock@entry=4) at server.c:99 #7 0x00007f036cf4b940 in listener () at server.c:166 #8 server (sock=sock@entry=0) at server.c:196 #9 0x00007f036cf48318 in main (argc=3, argv=0x7ffd7ab09c38, env=0x7ffd7ab09c58) at main.c:234
Is there an upstream patch I should apply in advance of a future 3.0.5 release ? If not, would you mind reporting this to the upstream project mailing list at https://sourceforge.net/projects/vtun/lists/vtun-devel ?
The bug is caused by vtun-openssl.patch from this package so I believe upstream fix is not required.
Since EPEL7 is still using openssl 1.0, so vtun-3.0.4-4 is no longer applying that patch (required only for openssl 1.1 in >= F26) for the EPEL7 build. See bug 1487003
just a quick follow-up: the openssl out-of-tree patch I used to build against openssl1.1 never worked properly, and segfaulted when one attempted to use it. Instead, I'm building against compat-openssl1.0 and will leave it to upstream to fix openssl1.1 compatibility.
vtun-3.0.4-5.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-4853fd2ed8
vtun-3.0.4-5.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-019aa5febe
vtun-3.0.4-5.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-fd12483a2d
vtun-3.0.4-5.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-019aa5febe
vtun-3.0.4-5.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-4853fd2ed8
vtun-3.0.4-5.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.
vtun-3.0.4-5.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.
vtun-3.0.4-5.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.
Title: Not possible to establish a WORKING connecting from a vtun-client to a vtun-server. Hardware All Summary: To establish a connecting from a vtun-Client to a vtun-Server succeeds 'principially' -- But as soon as I configure either Side (client / server) e.g. by "ifconfig tap0 10.235.24.1/24 up", the connection is broken and at the other side I get the error: "Input/output error (5)". Details: * In the configuration for the client and the server I use 'tap0' and I have "up { }". * The client is (e.g.) "10.235.1.189/24". * The server is (e.g.) "router". * I start the server by "vtund -s -n" * I start the client by "vtund -n test router" * At the client side I get the following messages: " vtund[18277]: VTun client ver 3.X 02/20/2026 started vtund[18277]: Connecting to router vtund[18277]: Remote Server sends <Te> vtund[18277]: Session test[router] opened" * At the server side I get the following messages: " vtund[30528]: VTUN server ver 3.X 02/20/2026 (stand) vtund[18536]: Session test[10.235.1.189:33057] opened" * If I try configure the tap0 on the client side by (e.g.) "ifconfig tap0 10.235.24.1/24 up": * At the client side I get the following messages: " vtund[18277]: Connection closed by other side vtund[18277]: Session test[router] closed vtund[18277]: Exit" * At the server side I get the following messages: " vtund[18536]: Input/output error (5) vtund[18536]: Session test closed" * If I try configure the tap0 on the server side by (e.g.) "ifconfig tap0 10.235.24.2/24 up": * At the client side I get the following messages: " vtund[18277]: Input/output error (5) vtund[18277]: Session test[router] closed vtund[18277]: Exit * At the server side I get the following messages: " vtund[18277]: Connection closed by other side vtund[18536]: Session test closed" Expected Results: * I start the server by "vtund -s -n" * I start the client by "vtund -n test router" * At the client side I get the following messages: " vtund[18277]: VTun client ver 3.X 02/20/2026 started vtund[18277]: Connecting to router vtund[18277]: Remote Server sends <Te> vtund[18277]: Session test[router] opened" * At the server side I get the following messages: " vtund[30528]: VTUN server ver 3.X 02/20/2026 (stand) vtund[18536]: Session test[10.235.1.189:33057] opened" * If I try configure the tap0 on the client side by (e.g.) "ifconfig tap0 10.235.24.1/24 up": * At the client side I get no further messages. * At the server side I get no further messages. * If I try configure the tap0 on the server side by (e.g.) "ifconfig tap0 10.235.24.2/24 up": * At the client side I get no further messages. * At the server side I get no further messages. * By "ifconfig tap0" on the client side I get: " tap0 Link encap:Ethernet HWaddr 46:BC:1F:99:71:15 inet addr:10.235.24.1 Bcast:10.235.24.255 Mask:255.255.255.0 [...]" * By "ifconfig tap0" on the server side I get: " tap0 Link encap:Ethernet HWaddr 62:00:58:FE:1D:20 inet addr:10.235.24.2 Bcast:10.235.24.255 Mask:255.255.255.0 [...]" * I have a working tunnel. * On the client side, I succeed with "ping 10.235.24.2". * On the server side, I succeed with "ping 10.235.24.1". On a kernel-2.4 "vtund" works as expected. Severity Medium Proposed solution: The Patch "patch.txt"; it fixes the connection termination (EIO) of "vtund" on modern Linux kernels (e.g. 5.x) Summary: This patch addresses a regression where "vtund" terminates the connection immediately after the virtual interface (TAP/TUN) is created but before it is administratively configured. Problem Description: On legacy kernels (e.g., 2.4), writing to a /dev/net/tun file descriptor was permitted even if the corresponding network interface was not yet UP. Modern Linux kernels (e.g. 5.x) have a stricter state management. If the kernel or the remote peer sends initial packets (e.g., IPv6 DAD, IGMP) while the local interface is still initializing, the write() system call returns EIO (Errno 5). Currently, "vtund" treats EIO as a fatal error and closes the session, leading to a race condition during tunnel startup. Technical Solution: The patch introduces a "latch mechanism" using SIOCGIFFLAGS via a temporary control socket: 1. It checks the operational status of the interface (IFF_UP and IFF_RUNNING). 2. During the initial phase (before the interface is confirmed UP), EIO errors are caught and ignored to allow the interface to "settle". 3. Once the interface is confirmed UP for the first time, the error handling reverts to standard behavior (strict error checking) to ensure operational reliability. Impact: This fix restores compatibility with modern Linux distributions where "vtund" was previously unstable or non-functional. patch.txt: diff --git a/driver.h b/driver.h index 6b0a9ba..7341343 100644 --- a/driver.h +++ b/driver.h @@ -33,6 +33,7 @@ extern int (*dev_read)(int fd, char *buf, int len); extern int (*proto_write)(int fd, char *buf, int len); extern int (*proto_read)(int fd, char *buf); +int is_interface_running(char *dev); int tun_open(char *dev); int tun_close(int fd, char *dev); int tun_write(int fd, char *buf, int len); diff --git a/linkfd.c b/linkfd.c index 67f251a..dd59c34 100644 --- a/linkfd.c +++ b/linkfd.c @@ -225,6 +225,9 @@ static int lfd_linker(void) fd_set fdset; int maxfd, idle = 0, tmplen; + lfd_host->was_interface_running = 0; + lfd_host->ignore_error = 0; + if( !(buf = lfd_alloc(VTUN_FRAME_SIZE + VTUN_FRAME_OVERHEAD)) ){ vtun_syslog(LOG_ERR,"Can't allocate buffer for the linker"); return 0; @@ -317,12 +320,27 @@ static int lfd_linker(void) lfd_host->stat.comp_in += len; if( (len=lfd_run_up(len,buf,&out)) == -1 ) break; - if( len && dev_write(fd2,out,len) < 0 ){ - if( errno != EAGAIN && errno != EINTR ) - break; - else - continue; - } + + if( !lfd_host->was_interface_running ){ + int res = is_interface_running(lfd_host->sopt.dev); + if( -1 == res ) + break; /* error! */ + if( res ) + { + lfd_host->ignore_error = 0; + lfd_host->was_interface_running = 1; + } else { + lfd_host->ignore_error = 1; + } + } + + if( len && dev_write(fd2,out,len) < 0 ){ + if( errno != EAGAIN && errno != EINTR ) { + if(!lfd_host->ignore_error || EIO != errno) + break; + } else + continue; + } lfd_host->stat.byte_in += len; } diff --git a/linux/tun_dev.c b/linux/tun_dev.c index 0e4e18f..0d82585 100644 --- a/linux/tun_dev.c +++ b/linux/tun_dev.c @@ -37,6 +37,34 @@ #include "vtun.h" #include "lib.h" +/** + * is_interface_running - check, if the network interface is running + * @dev: name of the network interface + * Returns: + * * %true(1), if the interface is up/running, + * * %false(0), if the interface is not up/running, + * * -1 on failure; the errno may be checked. + */ +int +is_interface_running(char *dev) { + struct ifreq ifr; + + int sock = socket(AF_INET, SOCK_DGRAM, 0); + if(0 > sock) + return -1; + + memset(&ifr, 0, sizeof(ifr)); + strncpy(ifr.ifr_name, dev, IFNAMSIZ); + + if(0 > ioctl(sock, SIOCGIFFLAGS, &ifr)) { + close(sock); + return -1; + } + + close(sock); + return 0 != (ifr.ifr_flags & (IFF_RUNNING | IFF_UP)); +} + /* * Allocate TUN device, returns opened fd. * Stores dev name in the first arg(must be large enough). diff --git a/vtun.h b/vtun.h index 08f5c60..fd6d1b7 100644 --- a/vtun.h +++ b/vtun.h @@ -114,8 +114,11 @@ struct vtun_host { struct vtun_addr src_addr; struct vtun_stat stat; - struct vtun_sopt sopt; + + /* Flags to handle the EIO-error before interface is UP. */ + int ignore_error; + int was_interface_running; }; extern llist host_list;