Closed Bug 51135 Opened 19 years ago Closed 19 years ago

IPv6 support on OpenVMS

Categories

(NSPR :: NSPR, defect, P3)

DEC
OpenVMS
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: wtc, Assigned: colin)

References

Details

Attachments

(5 files)

This bug report is created to hold the
patches for IPv6 support on OpenVMS.
Status: NEW → ASSIGNED
Target Milestone: --- → 4.2
I have IPv6 building and (at least initially) running on OpenVMS. Will
attach the patches next. Can this get checked in soon?
Do you still need patch 13918?
No, only the two patches I posted these. These supercede any other, not yet
checked in, patches.
Colin: your struct _md_sockaddr_in6 is 32 bytes!  How can your
patch work?

+struct _md_in6_addr {
+    union {
+        PRUint8  _S6_u8[16];
+        PRUint16 _S6_u16[8];
+        PRUint32 _S6_u32[4];
+    } _S6_un;
+};
+struct _md_sockaddr_in6 {
+    PRUint16 sin6_family;
+    PRUint16 sin6_port;
+    PRUint32 sin6_flowinfo;
+    struct _md_in6_addr sin6_addr;
+    PRUint32 sin6_scope_id;
+    PRUint32 __sin6_src_id;
+};

2+2+4+16+4+4 = 32.
Sigh, too much cut/paste from the Solaris code, coupled with the fact that I
could only test it on my IPv4 system since I haven't got my M0.91 build onto
my IPv6 system yet.

I'll redo the patch tomorrow and test on both IPv4 and IPv6.
Tested on IPv4 and IPv6. The patches that need checking in are:

  35564 - NSPR changes (define _SOCKADDR_LEN and _PR_HAVE_MD_SOCKADDR_IN6)
  35448 - Non-NSPR changes (define _SOCKADDR_LEN)
Colin, you still need the other parts of patch 35447, right?

So there is no way to use IPv6 without having a sin6_len field
in struct sockaddr_in6?  What is the definition of struct
sockaddr_in6 on OpenVMS?
> Colin, you still need the other parts of patch 35447, right?

Correct.

> So there is no way to use IPv6 without having a sin6_len field
> in struct sockaddr_in6?  What is the definition of struct
> sockaddr_in6 on OpenVMS?

The IPv6 folks told me that I had to fill in the len field. Don't ask why,
but that's what they told me. IPv6 is still in its infancy on OpenVMS...
I checked in my patch on the NSPRPUB_CLIENT_BRANCH and
regenerated mozilla/nsprpub/configure.
I checked in the patch on the trunk of NSPR.  Marked the bug fixed.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
*** Bug 64801 has been marked as a duplicate of this bug. ***
The patch for the non-NSPR files (35448) seems to have been forgotten. This
is define _SOCKADDR_LEN in the following files:

  mozilla/config/OpenVMS.mk
  mozilla/security/coreconf/OpenVMS.mk

I know that all network I/O should be through NSPR, but I don't think that's
the case. Can I get these into M0.9.1?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
> I know that all network I/O should be through NSPR, but I don't think that's
> the case.

That's not why I didn't check in the patch for non-NSPR files.

The reason I only checked in the patch for NSPR files is that
only NSPR cares whether struct sockaddr_in has a length field.
NSPR needs to map between a PRNetAddr (which does not have a
length field) and a struct sockaddr_in (which may have a length
field).  NSPR does not exchange struct sockaddr_in's with other
modules.

Does Mozilla not work on IPv4 or IPv6 without those patches?
I was told by the TCP/IP engineers at Compaq to always define _SOCKADDR_LEN
so that I get the BSD 4.4 socket interface. The OpenVMS socket.h header file
does things differently depending upon whether _SOCKADDR_LEN is defined or
not.
Colin,

To convince yourself, do a search for 'sin_len' and 'sin_family'
(or 'sa_len' and 'sa_family' for the generic struct sockaddr) in
the Mozilla source tree (http://lxr.mozilla.org/mozilla/).
These are the only fields affected by the _SOCKADDR_LEN macro.

You will see that
1. no code in Mozilla sets the sin_len or sa_len field;
2. lots of code sets the sin_family field, but no code reads
   the sin_family field filled in by a socket function such
   as accept(), recvfrom(), getsockname(), and getpeername().

If you define _SOCKADDR_LEN and only set the sin_family field,
doesn't that leave the sin_len field uninitialized?  It seems
that if you define _SOCKADDR_LEN, you should also properly
initialize the sin_len field, agree?  Your patch does not do that.

Although NSPR now uses the BSD 4.4 socket interface, it is okay
for other Mozilla modules to use the older BSD socket interface
as long as they do not exchange struct sockaddr_in's.
I agree with what you say about the use of _SOCKADDR_LEN, I'm just telling
you what I was told! Let's try it the way you want it, and I'll let you know
if anything breaks. Feel free to (re)close again.
I understand, Colin.  It was good to go through the analysis as
I needed to convince myself as well. ;-)
Status: REOPENED → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.