Hi Alex,
interesting question...
looking at the code, the connection is handled within the server as the fd
handle to the tunnel device, opened using sys_tun_open() then handed to the
channel_new() function. The allocation of the tunnel with 'any' appear
to be
handled in sys_tun_open() by leaving the ifr.ifr_name empty. From there on
it is kernel specific. The linux kernel module will eventually assign the
interface id protected by a lock in drivers/net/tun.c
(tun_chr_ioct->...->dev_alloc_name). My guess is that *BSD using open()
will work similar to this.
So the tunnel device should be available in ifr.ifr_name ( i.e. tun0,
tun0, etc. ) in sys_tun_open(). At this point the struct is put on the stack
and destroyed of course when leaving sys_tun_open() but not before it is
printed for debugging purposes. The server does not appear to make use of
this information any further than that and relies on open(/dev/net/tun) to
be race condition free and to create a unique fd handle. Have you any reason
to believe that this is not the case ?
As to the latter question - for the above reason the tunnel device is
probably not available anywhere to query. Would be nice though to see it in
when probing the server with "~#".
Hope this helps.
Regards
Ralf.
On Sun, Sep 20, 2009 at 7:38 PM, Alex Bligh <alex at alex.org.uk> wrote:
> If an ssh server receives a successful inbound ssh connection with 'ssh
-w'
> without a tunnel number specified (i.e. in 'any' mode), it
allocates the
> next tunnel device available on the server. The next thing the server
> needs to do is to set up the tunnel device. How does the server know
> which tunnel device was set up by the current connection? I'd really
> like something race-condition free here.
>
> Similarly (but less pressingly), if a client executes a ssh -w and uses
> the next available local tunnel device, is there some way of reading
> the tunnel device the child ssh process allocated?
>
> --
> Alex Bligh
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>