The --stdin-stdout option is broken, both in the client (htc) and the server (hts). When used, the program writes its output to stdin instead of stdout. This breaks anything calling htc or hts with --stdin-stdout, unless stdin happens to be something which can be written to (e.g. a socket or a pseudo-terminal). In particular, it will break programs that communicate with htc or hts with via pipes, such as the OpenSSH client with the ProxyCommand set to "htc --stdin-stdout %h:%p" (which is one of the main purposes for which someone would want to use httptunnel in the first place). What happens is an infinite connect/disconnect loop where htc connects, gets the banner from the server (sshd for example), fails to pass it to the client (ssh in this case) because it tries to write to stdin, then reconnects to try again, over and over. Reproducible: Always Steps to Reproduce: 1. Run an httptunnel server somewhere, for example: $ hts -F www.example.com:80 -w 2. Run the client with --stdin-stdout, so that its stdin is not a tty. Assuming the server is on the same machine: $ cat | htc --stdin-stdout localhost 3. While the client is still running, check the active connections. $ netstat -at Actual Results: Hundreds of connections are created and closed, in an infinite loop. No data from the server ever reaches the client side (htc's stdout, in this case, the terminal). If you type "GET / HTTP/1.0" on htc's stdin on step 2, you never see the HTML reply from www.example.com (for the reasons detailed in the description above). Expected Results: htc should not create and destroy hundreds of connections per second. htc should actually pass the data it receives from hts to its caller (that is, it should write the data to stdout).
Created attachment 122652 [details, diff] Patch to fix the problem (caused by a broken check in the source) ChangeLog entry: 2007-06-20 Israel G. Lugo <israel.lugo@lugosys.com> * common.c (handle_tunnel_input): really write to stdout if fd == 0.
Which ebuild is this about?
(In reply to comment #2) > Which ebuild is this about? > I appologize, that's an obvious piece of information which I neglected to mention. This is for net-misc/httptunnel. The problem exists in the latest version, httptunnel-3.3, and also upstream, in their latest version (3.3 as of this writing, dated 2001). I have also sent a bug report to the program maintainers, and the same patch I submitted here. Being as though the latest upstream version is from 2001, I hope they are still maintaining it.
Have you submitted this upstream? (bug-httptunnel@gnu.org)
(In reply to comment #4) > Have you submitted this upstream? (bug-httptunnel@gnu.org) > Yes, that's what I meant when I mentioned having reported to the program maintainers. I sent them a bug report, and the same patch I submitted here, via email. I reported here for thoroughness, and mainly because the last released upstream version (3.3) is from 2001 (so I don't know whether it's being actively and timely maintained or not).
Adding "inclusion" keyword and bumping, 4 months since bug report with an available patch for revision. Upstream has not responded to the bug report. I have also reported the bug and submitted the patch on Debian ( http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=429885 ), where it was accepted and merged. Someone please review it and commit?
Fixed in 3.3-r1 revision bump. Thanks for reporting.
