Closed Bug 127130 Opened 23 years ago Closed 23 years ago

odd SSL client behavior with NSS 3.4 and NSPR 4.2

Categories

(NSS :: Libraries, defect, P1)

Product:
NSS
Component:
Libraries
Platform:
x86
Windows 2000
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 124337

People

(Reporter: julien.pierre, Assigned: wtc)

Details

I ran NES6 with NSS 3.4 and NSPR 4.2 beta 2.
I also ran the httptest stress client using the same libraries.
Both were running with fibers.

On NT, the test ran only 45897 full handshake sessions, from 2am to 3am. The NES
access log shows that included a 12 minute time period without any request.
After 3am there were no requests in the server's log, but also no errors. This
is despite the fact that a single client was continuously running the whole
time. When I finally came by at the machine today at 4pm, I saw continuous
PR_Recv errors on the client side.

I was able to hit the server with a browser though, so the server state appeared
to be fine, only the stress client was hosed.

Since I'm using two new libraries here, I'm not sure if the problem is with NSS
3.4 or NSPR 4.2.
Priority: -- → P1
Summary: odd SSL server behavior with NSS 3.4 and NSPR 4.2 → odd SSL client behavior with NSS 3.4 and NSPR 4.2
Target Milestone: --- → 3.4
What errors were being reported for PR_Recv?
Actually, it's both PR_Send and PR_Recv :

error: PR_Send failure - NSPR rc = -5961 , OS rc = 64
       Connection reset by peer
error: PR_Recv failure - NSPR rc = -5961 , OS rc = 64
       Connection reset by peer
This bug should not be P1 because NSPR 4.2 Beta is
pre-release software.  Or it should be changed to
be an NSPR bug.
I will verify this again with NSPR 4.1.2 and the current tip of NSS 3.4 . This
bug may well be a duplicate bug of 124337 .
I haven't been able to verify this. I'm not sure why, but my client always fails
on Win2K right now regardless of the versions of NSS/NSPR that I use, client
auth or no client auth, or which server I connect to ...

Never mind. I can't even figure out the command-line switches to the client I
myself wrote anymore, there are so many of them ...
Doh. The test will run. I will run it again overnight to see if the problem
occurs again.

I switched back to NSS 3.4 and NSPR 4.1.2 . I'm not seeing the problem anymore.
I believe the problem was in fact a dupe of 124337. I changed the server's I/O
timeout to prevent the SSL handshakes from timing out, which contributed to
resolving this issue. Marking dupe.


*** This bug has been marked as a duplicate of 124337 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Julien wrote:
> I switched back to NSS 3.4 and NSPR 4.1.2 . I'm not seeing the
> problem anymore.

Did you mean NSPR 4.1.2 or NSPR 4.2?  This bug was about odd SSL
client behavior when you were using NSPR 4.2 (beta 2).




Wan-Teh,
No, I meant with NSPR 4.1.2 . I opened the bug against NSS 3.4 , but was trying
a new combination with NSS 3.4 and NSPR 4.2 beta.
I tried with just NSS 3.4 as a variable, keeping the new NSPR out of the
picture. The problem did not occur. So there is no NSS 3.4 issue. I believe the
problem was the same as 124337 - timeout issues in the handshake. This is why I
didn't try with NSPR 4.2 again. I just don't think there is an NSPR 4.2 bug, I
believe the results would be the same.

Whew (sigh of relief).

Wan-Teh the NSPR maintainer
You need to log in before you can comment on or make changes to this bug.