On Sun, May 8, 2016 at 9:04 PM, Markus Friedl <mfriedl at gmail.com> wrote:> I have an ugly patch for that feature that requires protocol modification.Why does it require a protocol modification? Couldn't the client request regular forwarded-tcpip from the server then decode SOCKS entirely within the client? -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.
That's pretty much what I was thinking. The most significant change will be that the client has to include the socks server code, which it doesn't currently (I suppose!). Or am I mistaken? Rogan On Sun, 8 May 2016, 21:27 Darren Tucker, <dtucker at zip.com.au> wrote:> On Sun, May 8, 2016 at 9:04 PM, Markus Friedl <mfriedl at gmail.com> wrote: > > I have an ugly patch for that feature that requires protocol > modification. > > Why does it require a protocol modification? Couldn't the client > request regular forwarded-tcpip from the server then decode SOCKS > entirely within the client? > > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. >
On Sun, May 8, 2016 at 10:04 PM, Rogan Dawes <rogan at dawes.za.net> wrote:> That's pretty much what I was thinking.Me too, but Markus is smarter than I am so I fear I've overlooked something :-)> The most significant change will be > that the client has to include the socks server code, which it doesn't > currently (I suppose!).The client has (and uses) the socks code. On most platforms it'll also get linked into the server (and anything else that links the channel code). $ nm ssh | grep socks5 00030450 t channel_decode_socks5.isra.11 $ nm sshd | grep socks5 0003a930 t channel_decode_socks5.isra.11 -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.
> Am 08.05.2016 um 21:27 schrieb Darren Tucker <dtucker at zip.com.au>: > >> On Sun, May 8, 2016 at 9:04 PM, Markus Friedl <mfriedl at gmail.com> wrote: >> I have an ugly patch for that feature that requires protocol modification. > > Why does it require a protocol modification? Couldn't the client > request regular forwarded-tcpip from the server then decode SOCKS > entirely within the client? >Yes. That's better and the reason why my patch is ugly ;). I'll look into doing this.> -- > Darren Tucker (dtucker at zip.com.au) > GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement.
That's what I thought! As mentioned, it would be awesome if this could be exposed as a Unix socket as well as a TCP port. I guess if you simply reuse the existing "port forward" code, that should come automatically? Rogan On Sun, May 8, 2016 at 10:34 PM Markus Friedl <mfriedl at gmail.com> wrote:> > > > Am 08.05.2016 um 21:27 schrieb Darren Tucker <dtucker at zip.com.au>: > > > >> On Sun, May 8, 2016 at 9:04 PM, Markus Friedl <mfriedl at gmail.com> > wrote: > >> I have an ugly patch for that feature that requires protocol > modification. > > > > Why does it require a protocol modification? Couldn't the client > > request regular forwarded-tcpip from the server then decode SOCKS > > entirely within the client? > > > > Yes. That's better and the reason why my patch is ugly ;). > I'll look into doing this. > > > > -- > > Darren Tucker (dtucker at zip.com.au) > > GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 > > Good judgement comes with experience. Unfortunately, the experience > > usually comes from bad judgement. >