83845 - IPv6 support returns wrong data for getpeername

Status: RESOLVED FIXED

(NSPR :: NSPR, defect, P1)

Description

[Terry Hayes]

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.

Comment 1

[Terry Hayes]

Attachment: Patch for pripv6.c to fix this problem

Comment 2

[Wan-Teh Chang]

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 [e-mail].

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

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?

Comment 4

[Christopher Blizzard (:blizzard)]

a=blizzard for 0.9.1 and the trunk.

Comment 5

[Wan-Teh Chang]

The fix has been checked in on the MOZILLA_0_9_1_BRANCH.

Comment 6

[Wan-Teh Chang]

I checked in the fix on the NSPRPUB_CLIENT_BRANCH.
Marked the bug fixed.

Comment 7

[Wan-Teh Chang]

I checked in the fix on the NSPRPUB_RELEASE_4_1_BRANCH
for the NSPR 4.1.2 release.