Package: linux-image-3.16.0-6-amd64 Version: 3.16.56-1 Before upgrading to kernel 3.16.56-1 from security.debian I had two openvpn servers running, each with "dev tun" in their configuration file. They would start in a random order and each be assigned a numerical tun device.
After the upgrade only the first server to run is assigned a tun device (tun0) and the second falls over with messages such as "TUN/TAP device opened" (instead of "TUN/TAP device tun1 opened") and "Note: Cannot set tx queue length on : No such device (errno=19)" (again note missing device name) before attempting to call " /sbin/ip link set dev up mtu 1500" (i.e. with no device name). Suggesting it is being returned a null name for the next tun device. The order of startup is still random, so on one boot one server will run and on another boot it may be the other server, so it is not a configuration issue with the servers (and it anyway worked before the kernel upgrade). Specifying a particular device name in the configuration files (see WORKAROUND below) allows both servers to run, which seems to confirm that it is the allocation of the next available device name by the kernel that is the failing point. I'm afraid I am not knowledgeable enough about TUN/TAP to debug beyond this. WORKAROUND: By naming a specific tun device in each openvpn configuration file (e.g. "dev tun0" and "dev tun1" instead of "dev tun") both servers come online successfully. However I imagine this is a rather fragile approach for people with large numbers (or dynamically created) vpn servers. I am using Debian GNU/Linux 8.10, kernel 3.16.0-6-amd64 #1 SMP Debian 3.16.56-1 (2018-04-28) and libc6 version 2.19-18+deb8u10 running on a VPS (Vultr).
