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.
Severity: normal → critical
OS: Windows 98 → OpenVMS
Hardware: PC → DEC
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.
Try sizeof(struct sockaddr_in6).
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?
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 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.
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 bug.
I have entered bug 151777 to track the OJI problem in Sun's code.
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
Last Resolved: 16 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.