Closed Bug 329807 Opened 15 years ago Closed 14 years ago

Update HP-UX IPv6 code


(NSPR :: NSPR, defect, P2)



(Not tracked)



(Reporter: wtc, Assigned: wtc)




(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) 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

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.

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.
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).
Closed: 14 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 

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.
Resolution: FIXED → ---
Target Milestone: 4.6.5 → 4.6.6
Duplicate of this bug: 367169
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

Checking in _hpux.h;
/cvsroot/mozilla/nsprpub/pr/include/md/_hpux.h,v  <--  _hpux.h
new revision:; previous revision:
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:; previous revision:
Checking in;
/cvsroot/mozilla/nsprpub/,v  <--
new revision:; previous revision:
Checking in pr/include/md/_hpux.h;
/cvsroot/mozilla/nsprpub/pr/include/md/_hpux.h,v  <--  _hpux.h
new revision:; previous revision:
Closed: 14 years ago14 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 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.