Bug 2864 - ssh client 7.7p1: "Tunnel device open failed." (regression from 7.6p1)
Summary: ssh client 7.7p1: "Tunnel device open failed." (regression from 7.6p1)
Status: CLOSED DUPLICATE of bug 2855
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: ssh (show other bugs)
Version: 7.7p1
Hardware: amd64 Linux
: P5 major
Assignee: Assigned to nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-05-06 22:21 AEST by calimeroteknik
Modified: 2018-10-19 17:17 AEDT (History)
1 user (show)

See Also:


Attachments
ssh -vvv -w0:0 remotehost for 7.6p1 and 7.7p1 (3.08 KB, text/plain)
2018-05-06 22:21 AEST, calimeroteknik
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description calimeroteknik 2018-05-06 22:21:41 AEST
Created attachment 3148 [details]
ssh -vvv -w0:0 remotehost for 7.6p1 and 7.7p1

I have tun0 set up on the local and remote host.

Here is what happens with 7.7p1:

calimero@localhost ~ $ ssh -w0:0 remotehost
Tunnel device open failed.
Could not request tunnel forwarding.
calimero@remotehost ~ $

For the verbose (-vvv) output, which didn't seem extremely helpful, see attachment.


Here are strace excerpts:


For 7.6p1:

openat(AT_FDCWD, "/dev/net/tun", O_RDWR) = 4
ioctl(4, TUNSETIFF, 0x7fffaeea8490)     = 0
fcntl(4, F_SETFD, FD_CLOEXEC)           = 0
fcntl(4, F_GETFL)                       = 0x8002 (flags O_RDWR|O_LARGEFILE)
fcntl(4, F_SETFL, O_RDWR|O_NONBLOCK|O_LARGEFILE) = 0
fcntl(4, F_GETFL)                       = 0x8802 (flags O_RDWR|O_NONBLOCK|O_LARGEFILE)
getpid()                                = 4905
dup(0)                                  = 5
dup(1)                                  = 6
dup(2)                                  = 7


For 7.7p1:

openat(AT_FDCWD, "/dev/net/tun", O_RDWR) = 4
ioctl(4, TUNSETIFF, 0x7ffcb8813710)     = 0
close(4)                                = 0
write(2, "Tunnel device open failed.\r\n", 28Tunnel device open failed.
) = 28
write(2, "Could not request tunnel forward"..., 38Could not request tunnel forwarding.
) = 38
dup(0)                                  = 4
dup(1)                                  = 5
dup(2)                                  = 6

Reproducible at will on this box running arch linux with kernel 4.16.6 (same bug also experienced on 4.16.4).
Upgrading or downgrading openssh takes seconds.
Comment 1 calimeroteknik 2018-05-06 23:51:16 AEST
The problem disappears if I erase this block of code that was added.

In function sys_tun_open() for SSH_TUN_LINUX:

Location :
(absent)  openssh-7.6p1/openbsd-compat/port-tun.c:101
(present) openssh-7.7p1/openbsd-compat/port-net.c:188

if (ifname != NULL && (*ifname = strdup(ifr.ifr_name)))
	goto failed;


For some reason I have "Could not request tunnel forwarding." in the console but that's spurious, everything works perfectly.


I replaced the above with :

printf("one, *ifname=%s, ifname=%p\n", *ifname, ifname);

if (ifname != NULL && (*ifname = strdup(ifr.ifr_name))) {
	printf("two, *ifname=%s, ifname=%p\n", *ifname, ifname);
	goto failed;
}

I get this in the output of ssh:
one, *ifname=(null), ifname=0x7ffec28c5dc0
two, *ifname=tun0, ifname=0x7ffec28c5dc0

I'm not sure what should be happening, but this cripples tunnel for me.
Comment 2 Jakub Jelen 2018-05-07 17:25:49 AEST
Already fixed in both master and the 7_7 branch:

https://github.com/openssh/openssh-portable/commit/b81b2d120e9c8a83489e241620843687758925ad

*** This bug has been marked as a duplicate of bug 2855 ***
Comment 3 Damien Miller 2018-10-19 17:17:22 AEDT
Close RESOLVED bugs with the release of openssh-8.0