Hi. On Mon, Oct 05, 2015 at 04:46:01PM +0100, Tony van der Hoff wrote: > On 05/10/15 16:31, Reco wrote: > > Hi. > > > > On Mon, Oct 05, 2015 at 03:51:17PM +0100, Tony van der Hoff wrote: > >> Hi, > >> > >> I have a VPS running up to date wheezy, with an OpenVPN server, and a > >> wheezy box at home running an OpenVPN client. this used to work fine > >> last year. I haven't had cause to use it much recently, and I now find > >> it's died. I don't know when, or what changed to cause the fault. > >> > >> It appears that the client end is failing to start; running > >> openvpn /etc/openvpn/tony-lx.conf ends up with: > >> > >> Mon Oct 5 15:08:50 2015 ROUTE default_gateway=192.168.1.1 > >> Mon Oct 5 15:08:50 2015 Note: Cannot open TUN/TAP dev /dev/net/tun: No > >> such device (errno=19) > > <skip> > >> [1267669.932889] tun: Unknown symbol ipv6_proxy_select_ident (err 0) > >> > >> So, the tun module is failing to load; but now I'm out of ideas to try > >> further. Can anyone please point me in the right direction? > > > > First things first - apparently your tun module is compiled for the > > different kernel that you run. Good, stock in-tree kernel modules do > > not have unresolved symbols. > > > > Second, on my system tun.ko definitely references > > "ipv6_proxy_select_ident kernel" symbol. Which can only lead to suspect > > the kernel. > > > > Third thing is - unless you manage to convince tun module to load - > > openvpn won't function. > > > > Hence, the questions are: > > > > 1) Are you using stock/backported Debian kernel on VPS? > > > > 2) Have you upgraded the kernel since openvpn worked for you? > > > > 3) Any reboots since then? > > > > Reco > > > > Thanks for the quick response, Reco. > > 1. Kernel is stock wheezy: > 3.2.0-4-amd64 #1 SMP Debian 3.2.57-3+deb7u2 x86_64 GNU/Linux
But very old one. Current one is 3.2.68-1+deb7u4. It's a shot in the dark, but - what does this show: apt-cache policy linux-image-3.2.0-4-amd64 > 2. I don't know when 3.2.0-4 was released; I suspect the answer is yes. > > 3. many reboots; the last one earlier today. > > I note bug=767836 describes this problem, but appears closed with 3.2.0-4 It was closed because the problem was not in the kernel in the first place. It was closed because (see Message #43) VPS bootloader required special trickery on kernel upgrade, and that trickery was not applied. A classic local configuration problem (although a weird one). Thanks, now I know who's VPS I should never buy :) Reco
