Closed Bug 329807 Opened 19 years ago Closed 18 years ago

Update HP-UX IPv6 code

Categories

(NSPR :: NSPR, defect, P2)

HP
HP-UX
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: wtc, Assigned: wtc)

References

Details

Attachments

(4 files, 2 obsolete files)

I'd like to update NSPR's IPv6 code for HP-UX based on the information I received from HP recently. Here is a mapping table of HP-UX 11i versions and the versions returned by the "uname -r" command. 11i = B.11.11 11i v2 = B.11.23 11i v3 = B.11.31 (not released yet) http://docs.hp.com/en/B2355-90824/ch14.html says: Note: Starting with HP-UX 11i v2, IPv6 is automatically included in HP-UX. Here's the low-down on IPv6 in HP-UX from HP. 11.11 -- IPv6 was first introduced on this release using an EP/NCF bundle. Originally, to get IPv6 on the system one had to install a bundle called IPv6NCF11i. It contained a set of patches that implemented IPv6 functionality (that is the EP part) and a product called IPV6AA (the NCF part) that enabled IPv6 functionality provided in the patches. Since then IPv6NCF11i has been obsolete and replaced with another product called TOUR. If you want to install IPv6 on 11.11 today, you have to install a new product called TOUR, which is just a fancy name for a Transport Patch release vehicle. IPV6AA is part of TOUR. 11.22 -- IPv6 is not supported on this release at all. 11.22 was was an internal release; no customer should be running it. 11.23 -- IPv6 is part of the core. This means that you don't need to install any patches or products to use IPv6 functionality. IPv6 is part of the regular transport stack. 11.31 -- Same as for 11.23, IPv6 is part of the core.
This patch contains some debug printf statements. Do not check it in.
Component: Libraries → NSPR
Product: NSS → NSPR
QA Contact: jason.m.reid → wtchang
Version: 3.11 → 4.6
Attached patch Proposed patch (obsolete) — Splinter Review
I tested this patch in March this year. It is ready for review. The following notes will help you understand this patch. If the make variable USE_IPV6 is defined as 1, it causes the C preprocessor macro _PR_INET6 to be defined. The meanings of _PR_INET6 and _PR_INET6_PROBE are: 1. _PR_INET6 is defined and _PR_INET6_PROBE is not defined. The platform has the IPv6 socket API, and it can actually be used for IPv6. 2. _PR_INET6 is defined and _PR_INET6_PROBE is defined. The platform has the IPv6 socket API, but it can only be used for IPv6 on some machines where IPv6 is installed or enabled, so we need to perform a runtime test (the "probe") to find out. 3. _PR_INET6 is not defined and _PR_INET6_PROBE is not defined. Only IPv4 is available. 4. _PR_INET6 is not defined and _PR_INET6_PROBE is defined. The version of the OS we compiled NSPR on doesn't have the IPv6 socket API, but we know newer versions of the OS have the IPv6 socket API. So we will try to look up the IPv6 socket function symbols at run time and perform a runtime test (the "probe") to see if they can actually be used.
Attachment #214454 - Attachment is obsolete: true
Attachment #238060 - Flags: superreview?(darin)
Attachment #238060 - Flags: review?(nelson)
The previous patch contains a debugging change by mistake.
Attachment #238060 - Attachment is obsolete: true
Attachment #238061 - Flags: superreview?(darin)
Attachment #238061 - Flags: review?(nelson)
Attachment #238060 - Flags: superreview?(darin)
Attachment #238060 - Flags: review?(nelson)
Wan-Teh, what is the relationship (if any) between this bug and bug 324305 ? Is the patch for this bug also expected to fix that bug?
There is no relationship between this bug and bug 324305. If the patch for this bug also fixes bug 324305, it's unintentional because I don't know the cause for that bug.
Attachment #238061 - Flags: superreview?(darin) → superreview+
Comment on attachment 238061 [details] [diff] [review] Proposed patch (corrected) >- [C-Z]*|B.[2-9]*|B.1[2-9]*|B.11.[2-9]*|B.11.1[1-9]*) >+ [C-Z]*|B.[2-9]*|B.1[2-9]*|B.11.[3-9]*|B.11.2[3-9]*) I suspect this new glob pattern string doesn't do what its authors intended for it to do. (I suspect the old string didn't either.) But it's a bit difficult to be certain, because the only specification I have is this comment: >- # HP-UX 11i (B.11.11) or higher >+ # HP-UX 11i v2 (B.11.23) or higher I suspect that it was NOT the author's intent to have this glob pattern match any of the following strings, yet it matches all of them. B.3 B.9 B.11.3 B.11.9 So I'm asking for a clarification of what strings are NOT to be match by this pattern. In the interim, I'm giving this patch r-. I'll reconsider if the clarified specification matches the results.
Attachment #238061 - Flags: review?(nelson) → review-
Here's a little shell script I whipped up to simply testing the glob patterns against real test strings.
HP-UX's version strings all have the format a.dd.dd, where a is the letter A or B, and dd is two digits, padded with 0 if necessary.
Comment on attachment 238061 [details] [diff] [review] Proposed patch (corrected) OK, please add a comment about that to this patch when you commit it. r=nelson
Attachment #238061 - Flags: review- → review+
QA Contact: wtchang → nspr
Wan-Teh, your patch has r+ and SR+. Is it ready to be checked in?
Blocks: 324305
Priority: -- → P2
Target Milestone: --- → 4.6.5
I checked in the "proposed patch (corrected)" on the NSPR trunk (NSPR 4.7), NSPRPUB_PRE_4_2_CLIENT_BRANCH (Mozilla 1.9 alpha 2), and NSPR_4_6_BRANCH (NSPR 4.6.5).
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Slavo reports that, beginning on Saturday morning (1-13-2007, the NSPR QA tests for the nightly builds (from Friday night) have been experiencing a new failure every night on our HPUX QA system. The reported error is "address in use". I don't know what test or tests are failing this way. Slavo, please add the details to this bug. Thanks. The fix for this bug was checked in on Friday afternoon. Since it affects only HPUX, and since HPUX is the only system that began to show a regression, I suspect the problem is related to this checkin. More investigation is needed.
Thank you for the bug report. The reason bind() fails is that NSPR passes the size of PRNetAddr.ipv6 (= 32 bytes) as the address length argument to bind(), but the size of struct sockaddr_in6 is 28 bytes. The 4-byte difference is that PRNetAddr.ipv6 is 64-bit aligned, but struct sockaddr_in6 is 32-bit aligned. NSPR deals with this problem by defining the macro _PR_HAVE_MD_SOCKADDR_IN6 and defining struct _md_sockaddr_in6, which is "isomorphic" to the real struct sockaddr_in6. See mozilla/nsprpub/pr/include/md/_solaris.h for an example.
Attachment #251689 - Flags: review?(nelson)
I backed out the "proposed patch (corrected)" on the NSPR_4_6_BRANCH. We don't have enough time to test the patch thoroughly for NSPR 4.6.5. Let's target NSPR 4.6.6 instead.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: 4.6.5 → 4.6.6
Comment on attachment 251689 [details] [diff] [review] Define struct _md_sockaddr_in6 for HP-UX I have compared this to the other MD implementations of struct _md_in6_addr and struct _md_sockaddr_in6 and it looks right. I have not compared it to the HP header files. Wan-Teh, IIRC, you don't have an HPUX box on which to test this. Would you like us to test it before you commit it?
Attachment #251689 - Flags: review?(nelson) → review+
Yes, please test this patch on your HP-UX system. Thanks.
Comment on attachment 251689 [details] [diff] [review] Define struct _md_sockaddr_in6 for HP-UX Nelson, if you want to compare struct _md_in6_addr and struct _md_sockaddr_in6 with the HP header files, look at struct in6_addr and struct sockaddr_in6 in /usr/include/netinet/in6.h. I have just compared the structures with the header files on HP-UX B.11.11. I checked in this patch on the NSPR trunk (NSPR 4.7) and NSPRPUB_PRE_4_2_CLIENT_BRANCH (Mozilla 1.9 alpha 2). Checking in _hpux.h; /cvsroot/mozilla/nsprpub/pr/include/md/_hpux.h,v <-- _hpux.h new revision: 3.23; previous revision: 3.22 done Checking in _hpux.h; /cvsroot/mozilla/nsprpub/pr/include/md/_hpux.h,v <-- _hpux.h new revision: 3.11.4.10; previous revision: 3.11.4.9 done
I checked in the two patches on the NSPR_4_6_BRANCH (NSPR 4.6.6). Checking in configure; /cvsroot/mozilla/nsprpub/configure,v <-- configure new revision: 1.197.2.13; previous revision: 1.197.2.12 done Checking in configure.in; /cvsroot/mozilla/nsprpub/configure.in,v <-- configure.in new revision: 1.199.2.13; previous revision: 1.199.2.12 done Checking in pr/include/md/_hpux.h; /cvsroot/mozilla/nsprpub/pr/include/md/_hpux.h,v <-- _hpux.h new revision: 3.18.2.5; previous revision: 3.18.2.4 done
Status: REOPENED → RESOLVED
Closed: 18 years ago18 years ago
Resolution: --- → FIXED
Attached patch Combined patchSplinter Review
This patch combines "proposed patch (corrected)" (attachment 238061 [details] [diff] [review]) and "define struct _md_sockaddr_in6 for HP-UX" (attachment 251689 [details] [diff] [review]).
Christophe, Slavomir, Can either of you try the patch in attachment 238061 [details] [diff] [review] on HPUX and report the results? If possible, please try it on 2 HPUX systems, one with IPv6 support, one without.
All the patches in this bug are in NSPR 4.6.6. If you really want to test on HP-UX, you can just test the NSPR 4.6.6 release.
The https://bugzilla.mozilla.org/attachment.cgi?id=257390 breaks HP-UX 10.20 which has no IPv6 at all. After backing out only this patch, I was able to build NSPR of the SEAMONKEY_1_1_19_RELEASE tag on long obsolete HP-UX 10.20. Just for the completeness (comment #22)
Blocks: 587426
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: