Rob Landley wrote: > On Thursday 30 October 2008 20:17:04 Ming-Ching Tiew wrote: >> Ming-Ching Tiew wrote: >>> Matt Johnston wrote: >>>> On Thu, Oct 30, 2008 at 02:37:44PM +0100, Michael Wiedmann wrote: >>>>> Hi, >>>>> >>>>> how deals dropbear with different clients which are requesting >>>>> each a remote port forwarding to the same local port (on the >>>>> server side), e.g. >>>>> >>>>> system-1> dbclient -l user1 -N -R 7777:client-ip-1:80 server-ip >>>>> ... >>>>> system-2> dbclient -l user2 -N -R 7777:client-ip-2:80 server-ip >>>>> >>>>> Doing a quick test it looks like dropbear accepts the client >>>>> requests but the port forwarding does not work (actually it cannot >>>>> because there is more than one 'target'). >>>> >>>> Unix sockets inherently only allow a single process (so a >>>> single user) to listen on a port. What behaviour would >>>> you expect? >>> >>> I do face the same issue. In my usage, more than one system >>> execute the same command ( ie client-ip is actually one only ) >>> and I don't run any remote shell, the sole purpose of the >>> dbclient connection is to establish remote port forward, I >>> would prefer the last command succeed and it drops the previous >>> connection. However, I do realise such a behaviour is rather >>> "unfair". >> >> And I did try implement a remote shell method to solve my >> problem, but I was stuck at a stage where I could not identify >> the correct dropbear server process to kill ( ie to kill the >> previous instance of dropbear which started up the >> same port forward ). > > lsof -i > > (Note that you may have to run it as root to list the sockets > belonging to processes other than your current user.) > > Of course it may be easier to grovel around in /proc yourself than > try to beat lsof into _not_ displaying port 80 as "www". (You can > always > delete /etc/services...) >
Cool, that looks like what I need. Thanks.
