Closed
Bug 97475
Opened 23 years ago
Closed 22 years ago
accept() wants address_len of 16 on OpenVMS
Categories
(NSPR :: NSPR, defect, P1)
Tracking
(Not tracked)
RESOLVED
FIXED
4.2.2
People
(Reporter: colin, Assigned: wtc)
Details
Attachments
(2 files, 4 obsolete files)
2.84 KB,
patch
|
Details | Diff | Splinter Review | |
926 bytes,
patch
|
Details | Diff | Splinter Review |
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?
Reporter | ||
Comment 1•23 years ago
|
||
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.
Reporter | ||
Comment 2•23 years ago
|
||
Reporter | ||
Updated•23 years ago
|
Severity: normal → critical
OS: Windows 98 → OpenVMS
Hardware: PC → DEC
Reporter | ||
Updated•23 years ago
|
Whiteboard: awaiting checkin
Reporter | ||
Comment 3•23 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.
Reporter | ||
Comment 4•23 years ago
|
||
Reporter | ||
Updated•23 years ago
|
Attachment #47496 -
Attachment is obsolete: true
Assignee | ||
Comment 5•23 years ago
|
||
Try sizeof(struct sockaddr_in6).
Reporter | ||
Updated•23 years ago
|
Attachment #51211 -
Attachment is obsolete: true
Reporter | ||
Comment 6•23 years ago
|
||
Reporter | ||
Comment 7•23 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
Reporter | ||
Comment 8•23 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 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.
Reporter | ||
Comment 9•23 years ago
|
||
Assignee | ||
Updated•23 years ago
|
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → Future
Reporter | ||
Comment 10•23 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.
Assignee | ||
Comment 11•23 years ago
|
||
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.
Reporter | ||
Comment 12•23 years ago
|
||
OK, so when is NSPR 4.2.tiny-bit-more due out?
Reporter | ||
Comment 13•22 years ago
|
||
Any update on the ETA for this one?
Assignee | ||
Comment 14•22 years ago
|
||
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.
Assignee | ||
Comment 15•22 years ago
|
||
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.
Reporter | ||
Comment 16•22 years ago
|
||
I have entered bug 151777 to track the OJI problem in Sun's code.
Assignee | ||
Updated•22 years ago
|
Attachment #54761 -
Attachment is obsolete: true
Assignee | ||
Comment 17•22 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.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Target Milestone: Future → 4.2.1
Assignee | ||
Updated•22 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.
Description
•