SSH works perfect fine for sessions, scp, sftp and everything else we use it for, but port forwarding has been broken since 3.4.something... The local bind command tries to bind to 1.0.0.127 instead of the proper loopback address. It wasn't crucial for me, and I got lazy about reporting it while chasing down other dramas. I just downloaded the latest source (3.6.1p2) and compiled it and the problem remains. Here's the relevant excerpt from ssh -v ... jrhett@cyclops.elysium.isite.net's password: debug1: Authentication succeeded (password). debug1: Connections to local port 52881 forwarded to remote address medusa:23 debug1: Local forwarding listening on ::1 port 52881. bind: Cannot assign requested address debug1: Local forwarding listening on 1.0.0.127 port 52881. bind: Cannot assign requested address
What are HAVE_GETADDRINFO and BROKEN_GETADDRINFO set to in config.h?
#define HAVE_STRUCT_ADDRINFO 1 /* getaddrinfo is broken (if present) */ /* #undef BROKEN_GETADDRINFO */
Created attachment 357 [details] The generated config.h This is the entire generated config.h from my system, which is Solaris 8, x86.
You do have #define HAVE_GETADDRINFO 1. Try defining BROKEN_GETADDRINFO in config.h and recompiling. It looks like Solaris/Intel might have an endian problem in getaddrinfo.
Changing that config.h parameter solved the problem. Thanks! FYI: this is somewhat funny, because Eric? and I had to solve this problem back in the original SSH 5 or so years ago... it just keeps coming up ;-) Anyway, can you guys come up with a patch or do you want me to dig around and come up with one? I'm fine with headers and such, but I really haven't gotten my head around autoconf at all so you'll have to lead me around by the nose.
Created attachment 358 [details] configure.ac patch Keep in mind that I'm not really good at autoconf, so this may be the absolutely wrong way to do this .. but here is a possible patch for configure.ac that would seem likely to address the problem.
We can put a work-around in OpenSSH but why don't you report the problem to Sun too so they can actually fix it?
Fix applied, thanks. You should report the getaddrinfo problem to Sun, though.
Would it be possible to write a test program to determine whether a given platform has this bug? This would be preferable to unconditionally defining BROKEN_GETADDRINFO as that effectively disables IPv6 support, which is a somewhat high price to pay...
It should be possible to detect this at build time. Does the attached stand-alone test detect the problem on Solaris/x86?
Created attachment 359 [details] Test loopback address for sanity.
Hmm, this is a know Solaris/x86 bug (Sun bug #4356490, patch #111328-01). I think the patch should just be backed out. The problem isn't fatal and as Damien pointed out it can break previously working functionality. If you want it to work right then hack config.h yourself or fix yer system :-)
yeah, back it out. Is the patch in the standard, recommended patch cluster from Sun?
Have backed out the changes. The patch I mentioned is part of the recomended patch cluster for Solaris/x86.
Woah, hold it there. The system on which this problem was found and reported from has 111328-04 installed (we are current on all Recommended patches) and the problem still occurred. While I agree that this could and should be fixed in the Solaris headers, the fix should at least be known. The patch you've mentioned does not fix it.
The Sun bug describes the problem you're having exactly: [quote] The following programs prints an unexpected result on S8/Intel: [snip] straddr: 1.0.0.127 [/quote] So it looks like the fix has regressed between 111328-01 and 111328-04. Does attachment id #359 detect the problem on your system? Have you reported the problem to Sun?
Reminder: we need to know if we can detect this at build time so we can set BROKEN_GETADDRINFO where necessary. Does attachment #359 [details] detect the problem on Solaris/x86?
It seems to think so: % gcc -lsocket -o test test.c % ./test Loopback sane Sorry for the delay
Er, it seems to think not. Sorry.
Created attachment 384 [details] Show htonl() output Maybe the problem is in the htonl() macro? What does the attached program give? On Solaris/SPARC (bigendian) I get: htonl 7f000001 ntohl 7f000001 On an Linux/i386 (little endian) I get: htonl 100007f ntohl 100007f Your Solaris/x86 box should give the same results as Linux, however I suspect it will give the same as the SPARC.
Nope, it seems to mirror Linux: % ./test htonl 100007f ntohl 100007f
Bug is not a bug. Problem was tester, not test.
Mass change of RESOLVED bugs to CLOSED