getpeername is supposed to return data for the remote host (ip address and port). The ipv6 support in NSPR (pripv6.c) is returning the local data instead. This bug is causing the SSL cache to be ineffective, since the port number for each connection to a host appears to change. SSL fails to find any session to resume since the port number now doesn't match the previous entry in the cache. In addition, there seems to be some byte ordering issue in the port field. addr->ipv6.port returns a value that is byte-swapped from the requested port. For example port 443 (0x01bb) appears as 0xbb01. This may be an issue with the lower layer (ipv4 code) rather than the ipv6 module.
Good catch, Terry! Your patch is correct and I've already checked it in on the trunk of NSPR. I went through the file and did not find any other such errors. Its handling of the port field is correct. There is no byte swapping. Note that the port field is in network byte order, which is different from the host byte order on Intel x86. I believe this is why you see port 443 (0x01bb) appear as 0xbb01. Patches for NSPR do not require a super-review. However, it requires an approval from the "drivers" to be checked in on the NSPRPUB_CLIENT_BRANCH and the branch for mozilla0.9.1. I'll send email to firstname.lastname@example.org.
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → 4.1.2
One thing this tells me is that our QA tests aren't testing with IPv6. Terry, is there a call to htons missing somewhere in PSM or NSS?
a=blizzard for 0.9.1 and the trunk.
The fix has been checked in on the MOZILLA_0_9_1_BRANCH.
I checked in the fix on the NSPRPUB_CLIENT_BRANCH. Marked the bug fixed.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
I checked in the fix on the NSPRPUB_RELEASE_4_1_BRANCH for the NSPR 4.1.2 release.
You need to log in before you can comment on or make changes to this bug.