Closed
Bug 51135
Opened 24 years ago
Closed 23 years ago
IPv6 support on OpenVMS
Categories
(NSPR :: NSPR, defect, P3)
Tracking
(Not tracked)
RESOLVED
FIXED
4.2
People
(Reporter: wtc, Assigned: colin)
References
Details
Attachments
(5 files)
749 bytes,
patch
|
Details | Diff | Splinter Review | |
3.85 KB,
patch
|
Details | Diff | Splinter Review | |
1.53 KB,
patch
|
Details | Diff | Splinter Review | |
1.08 KB,
patch
|
Details | Diff | Splinter Review | |
3.89 KB,
patch
|
Details | Diff | Splinter Review |
This bug report is created to hold the patches for IPv6 support on OpenVMS.
Reporter | ||
Comment 1•24 years ago
|
||
Assignee | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Reporter | ||
Updated•23 years ago
|
Target Milestone: --- → 4.2
Assignee | ||
Comment 2•23 years ago
|
||
I have IPv6 building and (at least initially) running on OpenVMS. Will attach the patches next. Can this get checked in soon?
Assignee | ||
Comment 3•23 years ago
|
||
Assignee | ||
Comment 4•23 years ago
|
||
Reporter | ||
Comment 5•23 years ago
|
||
Do you still need patch 13918?
Assignee | ||
Comment 6•23 years ago
|
||
No, only the two patches I posted these. These supercede any other, not yet checked in, patches.
Reporter | ||
Comment 7•23 years ago
|
||
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.
Assignee | ||
Comment 8•23 years ago
|
||
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.
Assignee | ||
Comment 9•23 years ago
|
||
Assignee | ||
Comment 10•23 years ago
|
||
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)
Reporter | ||
Comment 11•23 years ago
|
||
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?
Assignee | ||
Comment 12•23 years ago
|
||
> 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...
Reporter | ||
Comment 13•23 years ago
|
||
Reporter | ||
Comment 14•23 years ago
|
||
I checked in my patch on the NSPRPUB_CLIENT_BRANCH and regenerated mozilla/nsprpub/configure.
Reporter | ||
Comment 15•23 years ago
|
||
I checked in the patch on the trunk of NSPR. Marked the bug fixed.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 16•23 years ago
|
||
*** Bug 64801 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 17•23 years ago
|
||
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 → ---
Reporter | ||
Comment 18•23 years ago
|
||
> 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?
Assignee | ||
Comment 19•23 years ago
|
||
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.
Reporter | ||
Comment 20•23 years ago
|
||
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.
Assignee | ||
Comment 21•23 years ago
|
||
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.
Reporter | ||
Comment 22•23 years ago
|
||
I understand, Colin. It was good to go through the analysis as I needed to convince myself as well. ;-)
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•