| Summary: | Address bits are backwards when setting up port forwarding on Solaris/intel | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Portable OpenSSH | Reporter: | Joe Rhett <jrhett> | ||||||||||
| Component: | ssh | Assignee: | OpenSSH Bugzilla mailing list <openssh-bugs> | ||||||||||
| Status: | CLOSED INVALID | ||||||||||||
| Severity: | major | ||||||||||||
| Priority: | P3 | ||||||||||||
| Version: | 3.6.1p2 | ||||||||||||
| Hardware: | ix86 | ||||||||||||
| OS: | Solaris | ||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Joe Rhett
2003-07-17 09:30:55 AEST
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 |