Matt Johnston wrote: > Adding unspecified-port remote forwarding would probably be > fairly straightforward - I just didn't see a need for it > previously.
I need some hints about implementing remote port forwarding w/o specifying a remote port on the client side: I know already how to handle the server side: Adding a hook in svr-tcpfwd.c:svr_remotetcpreq() by calling a custom function if (port == 0) to let this function choose somehow an unused port. The thing I'm not sure about is the client side: The relevant part of RFC 4254, '7.1. Requesting Port Forwarding' reads: If a client passes 0 as port number to bind and has 'want reply' as TRUE, then the server allocates the next available unprivileged port number and replies with the following message; otherwise, there is no response-specific data. Does this mean, that the client does _not_ necessarily wait for a response from the server? If yes, there is no need to modify existing dropbear source code to work with an unspecifed remote-port? Otherwise I'm not sure how to change the client code to handle the the 'SSH_MSG_REQUEST_SUCCESS' message (containing the port chosen by the server). Without the need to modify the client side it really would be trivial to add this at the server side. This would be great for my usage scenario. Michael
