accept() wants address_len of 16 on OpenVMS



17 years ago
16 years ago


(Reporter: Colin Blake, Assigned: Wan-Teh Chang)



Firefox Tracking Flags

(Not tracked)



(2 attachments, 4 obsolete attachments)



17 years ago
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.


> 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
> 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?

Comment 1

17 years ago
OpenVMS doesn't have UNIX-domain (local) sockets (to answer the last question

Given that we only have network sockets, I'm attaching a patch that appears to
hack around this IP bug.

Comment 2

17 years ago
Created attachment 47496 [details] [diff] [review]
Patch (for pre 4.2 stream)


17 years ago
Severity: normal → critical
OS: Windows 98 → OpenVMS
Hardware: PC → DEC


17 years ago
Whiteboard: awaiting checkin

Comment 3

17 years ago
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.

Comment 4

17 years ago
Created attachment 51211 [details] [diff] [review]
Revised patch which works with IPv6


17 years ago
Attachment #47496 - Attachment is obsolete: true

Comment 5

17 years ago
Try sizeof(struct sockaddr_in6).


17 years ago
Attachment #51211 - Attachment is obsolete: true

Comment 6

17 years ago
Created attachment 51527 [details] [diff] [review]
Patch using sizeof(struct sockaddr_in6)

Comment 7

17 years ago
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

Comment 8

17 years ago
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 

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.

Comment 9

17 years ago
Created attachment 54761 [details] [diff] [review]
This is (I believe) the correct fix


17 years ago
Priority: -- → P1
Target Milestone: --- → Future

Comment 10

17 years ago
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.

Comment 11

17 years ago

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.

Comment 12

17 years ago
OK, so when is NSPR 4.2.tiny-bit-more due out?

Comment 13

16 years ago
Any update on the ETA for this one?

Comment 14

16 years ago
Created attachment 87542 [details] [diff] [review]
wtc's patch

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

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

Comment 15

16 years ago
Created attachment 87546 [details] [diff] [review]
Patch to work around OJI's illegal access to PRFileDesc's secret structure

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

Comment 16

16 years ago
I have entered bug 151777 to track the OJI problem in Sun's code.


16 years ago
Attachment #54761 - Attachment is obsolete: true

Comment 17

16 years ago
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.
Last Resolved: 16 years ago
Resolution: --- → FIXED
Target Milestone: Future → 4.2.1


16 years ago
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.