Opened 5 years ago

Closed 5 years ago

#17846 closed defect (invalid)

32bit decimal IP address fail (i.e. no octets) on nbsd and obsd

Reported by: amonk Owned by:
Priority: Very Low Milestone:
Component: Core Tor/Tor Version: Tor:
Severity: Minor Keywords: lorax
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


Tor (at least) fails to start on NetBSD 7.0 (at least) and OpenBSD 5.8 (at least) when given a 32bit, decimal IP address for ORPort and/or DirPort.

Example error:

Dec 13 15:12:01.255 [warn] Couldn't parse address '"1755800511:443"' for ORPort
Dec 13 15:12:01.256 [warn] Failed to parse/validate config: Invalid ORPort/ORListenAddress configuration

Such addresses are legal inet_aton() addresses, and work, as they should, on the following, other Tor/OS combinations...

tor on FreeBSD 10.1
tor on DragonFly BSD
tor on Debian GNU/Linux 8.2
tor on Debian GNU/Hurd (hurd 0.7, Mach 1.6)

So, it looks like a pretty esoteric issue with NetBSD and OSs thereby derived, at least from some point in its history that includes OpenBSD.

I tracked it to tor_addr_parse(), but that's as far as I got.

It's certainly a non-critical, limited exposure, fringe case,
but something is obviously amiss.

Child Tickets

Change History (4)

comment:1 Changed 5 years ago by yawning

Keywords: lorax added

The issue isn't in tor_addr_parse(), which is backed by a correctly implemented inet_pton() implementation. tor_addr_lookup() first tries to inet_pton() the address as AF_INET and AF_INET6, and falls back to getaddrinfo() on systems that support it.

NetBSD (and I assume OpenBSD) both have a getaddrinfo() based entirely around inet_pton(), with code that would make this work #if 0-ed out.

So IMO it's a Net/OpenBSD libc bug, assuming you think they should provide a standards compliant getaddrinfo() (IEEE Std 1003.1, 2013 Edition mandates the X/Open behavior).

comment:2 Changed 5 years ago by yawning

~It's worth noting that the code that's #if 0-ed out isn't quite right according to POSIX due to:~

If the specified address family is AF_INET or AF_UNSPEC, address strings using
Internet standard dot notation as specified in inet_addr are valid.


Edit: Shallow reading of code, the caller iterates over the AFs, so the code should work (and is what FreeBSD/Dfly do).

Last edited 5 years ago by yawning (previous) (diff)

comment:4 Changed 5 years ago by cypherpunks

Resolution: invalid
Status: newclosed

Thanks for the follow-up, amonk.

Closing as invalid because problem is not in Tor itself.

Note: See TracTickets for help on using tickets.