Closed Bug 97475 Opened 23 years ago Closed 22 years ago

accept() wants address_len of 16 on OpenVMS

Categories

(NSPR :: NSPR, defect, P1)

DEC
OpenVMS
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: colin, Assigned: wtc)

Details

Attachments

(2 files, 4 obsolete files)

This started out as a mail exchange between myself and Wan-Teh. I'm moving it
to a bug report as I'm going to need to fix this somehow.

> Wan-Teh,
> 
> I just spend the best part of a day tracking down a problem in OJI
> (I'm trying to get it running on OpenVMS). It came down to a
> communication channel (socket) not being set up correctly, and the
> reason was because of the way accept() is behaving on OpenVMS.
> 
> I was getting an "invalid buffer length" error back from accept,
> because we were passing in something like 106 as the length on the
> accept call (106 is the sizeof(PRNetAddr)). It turns out that for IPv4
> accept REALLY wants to be passed a size of 16, and anything else, even
> something larger, is an error.

OK.

> I haven't tried IPv6 but I suspect it would want 28 or something like
> that.
> 
> So what's the right way to fix this? It seems like a bug in VMS's IP
> code, but that will take forever to get fixed (assuming I can even
> convince them that its their bug).

Yes, it's a bug.  If it's not too much trouble you
should at least file a bug report.  By the way,
recvfrom, getsockname, and getpeername may have
the same problem.

> So I was going to fix it in
> pt_Accept by examining the family type, but that won't work because
> its an empty PRNetAddr that gets passed in! There's also the
> PRFileDesc for the socket, but that doesn't contain the family type
> either.
> 
> Any ideas?

The only way to fix this is to add a family type field in
PRFileDesc.secret.
 
> I think the only reason I haven't run into this before is because the
> browser only makes outgoing connections!
> 
> I guess I could change the Sun OJI code so that it doesn't use NSPR
> for this socket, but that's real kludgy.

Can you use a Unix-domain (AF_UNIX or AF_LOCAL) socket?
OpenVMS doesn't have UNIX-domain (local) sockets (to answer the last question
above).

Given that we only have network sockets, I'm attaching a patch that appears to
hack around this IP bug.
Attached patch Patch (for pre 4.2 stream) (obsolete) — Splinter Review
Severity: normal → critical
OS: Windows 98 → OpenVMS
Hardware: PC → DEC
Whiteboard: awaiting checkin
Ah, I just got bit by the sizeof(addr->ipv6) problem again. On OpenVMS the
size is actually 28 bytes but the compiler rounds up to 32 for alignment
purposes. And since the bug in our accept refuses to accept anything OVER
the expected length (28 for IPv6), it fails.

I'll attach a new patch next. It uses a hard-wired 28. Ugly, but I don't know
any other way to solve this.
Attachment #47496 - Attachment is obsolete: true
Try sizeof(struct sockaddr_in6).
Attachment #51211 - Attachment is obsolete: true
Comment on attachment 51527 [details] [diff] [review]
Patch using sizeof(struct sockaddr_in6)

That is NOT the correct patch.
Attachment #51527 - Attachment is obsolete: true
OK, here's the scoop on why the previous patch which uses
sizeof(struct sockaddr_in6) is not the right solution for OpenVMS.

On OpenVMS, the IP stack is NOT part of the O/S, its a separate product (and 
there is in fact a selection of IP products available for OpenVMS). But there 
are a set of socket related header files that ship with the O/S so you compile 
code that uses the socket interface. So far, so good. Now here comes the bad 
part. 

The in6.h which ships with OpenVMS V7.1 (the version of VMS I build on) contains 
a struct sockaddr_in6 which does NOT contain the sin6_scope_id field, hence the 
sizeof(struct sockaddr_in6) is 24, not 28. The only IP stack for OpenVMS which 
supports IPv6 wants a socklen of 28 (and ONLY 28) on an accept() call, otherwise 
the accept() fails.

I'll post the righr fix next.
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → Future
Wan-Teh, why did you future this? I can't build NSPR without this fix, and I 
have to manually apply it to each baselevel I download. Please reconsider 
checking this fix in for me.
Colin,

Sorry about the confusion.  Until I have new NSPR versions
added to Bugzilla, any bug that I can't fix in NSPR 4.2 will
be set to target milestone Future.

I can't fix this bug in NSPR 4.2.
OK, so when is NSPR 4.2.tiny-bit-more due out?
Any update on the ETA for this one?
Attached patch wtc's patchSplinter Review
I propose this patch.  It saves the address family of
the socket in PRFileDesc's secret structure so that
PR_Accept can figure out the right addrlen to pass to
accept.

Strictly speaking, PR_RecvFrom, PR_GetPeerName, and
PR_GetSockName should also be fixed similarly.	I am
only fixing just enough of the problem to make OJI
work with Mozilla on OpenVMS.

This patch has been checked into the tip and
NSPRPUB_PRE_4_2_CLIENT_BRANCH of NSPR.
Colin told me that some OJI code uses the secret structure
to grab the fd from the PRFileDesc.  This access to
PRFileDesc's secret->md.osfd field is illegal.	If it is
really necessary to grab the fd from the PRFileDesc, the
OJI code should call the semi-private function
PR_FileDesc2NativeHandle (declared in "private/pprio.h").
Note: the semi-private functions declared in
"private/pprio.h" should only be used when there are
no alternatives using only public NSPR functions.

A bug should be filed against OJI for its illegal
access to PRFileDesc's secret->md.osfd field.

Meantime, this patch works around the problem.	It
adds the new 'af' field to the end of the secret
structure so that the offset of 'md' is unchanged.

I will decide whether this patch should be checked
in after I find out how hard it is to fix the OJI
bug.
I have entered bug 151777 to track the OJI problem in Sun's code.
Attachment #54761 - Attachment is obsolete: true
The patch to work around the OJI problem (bug 151777)
was checked into the tip and NSPRPUB_PRE_4_2_CLIENT_BRANCH
of NSPR yesterday.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Target Milestone: Future → 4.2.1
Whiteboard: awaiting checkin
Target Milestone: 4.2.1 → 4.2.2
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: