PR_StringToNetAddr and PR_Bind on OSF1

RESOLVED FIXED in 4.1.1

Status

defect
P3
normal
RESOLVED FIXED
19 years ago
19 years ago

People

(Reporter: wtc, Assigned: wtc)

Tracking

4.1.1
DEC
OSF/1

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

Assignee

Description

19 years ago
This bug was reported by Chris Elving:
    I've run into a problem with PR_StringToNetAddr()
    and PR_Bind() on DEC.

    PR_StringToNetAddr() calls StringToV6Addr() which
    attempts to parse the string first as an IPv6 address
    and then as an IPv4 address.  When the string is an
    IPv4 address, inet.pad in PRNetAddr is left with some
    junk in it.

    Unfortunately, bind() on DEC won't bind to an IPv4
    address other than INADDR_ANY if the unused portion
    of sockaddr_in isn't zeroed out.

I understand that BSD-derived TCP/IP stacks do a memcmp
of the sockaddr you want to bind to with the sockaddr's
of the network interfaces of the local host if you are
binding to an IP address other than INADDR_ANY.  This
kind of problem has also been reported on AIX and NetBSD.
Assignee

Comment 1

19 years ago
Assignee

Comment 2

19 years ago
Comments on my patch.
1. I took the opportunity to change PR_StringToNetAddr to
   parse the string first as an IPv4 address and then as
   an IPv6 address.  Please let me know if this is a bad
   idea.
2. I added code to zero the 'inet.ip' field after we fail
   to parse the string as an IPv4 address.

Does this patch look okay?
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → 4.1.1

Comment 3

19 years ago
Have you verified that inet_addr() will return -1 on ipv6 addresses?

Assignee

Comment 4

19 years ago
No, I haven't.  I'll attach a safer patch.
Assignee

Comment 6

19 years ago
I checked in the safer patch (attachment id=26343) on the
tip and NSPRPUB_RELEASE_4_1_BRANCH of NSPR.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.