inet(3) inet_network() bug, [was: cvs commit: src/usr.sbin/jexec

Oliver Fromme olli at
Thu May 29 16:06:04 UTC 2008


Bjoern A. Zeeb wrote:
 > On Thu, 29 May 2008, Oliver Fromme wrote:
 > > > > However, I do share the concern that there's an ambiguity
 > > > > in the syntax:  "127" can be a jail ID as well as an IP
 > > > > number (same as or a hostname.  Either the
 > > >
 > > > actually
 > >
 > > I'm afraid I think it is
 > > would be 2130706432.
 > is 0x0000007f.

I'm confused.  I assume you meant (not .1).

When the input "127" is used when an IP number
is expected, it must be interpreted as
(which would be 0x7f000000 as in_addr_t).  This
is required by POSIX/SUSv3.  It is correctly
explained in our inet_addr() manpage.

Of course the in_addr_t of is 0x0000007f,
but that's a different thing.

 > > I'm pretty sure 127.1 is the same as  Last
 > > time I used telnet 127.1 to test things it worked fine.
 > >
 > > would be 127.65536.
 > re-reading the man page inet(3) it seems you would be right
 > for == 127.1 -- just that our implementation of
 > inet_network() doesn't think you are... *sigh* I know this
 > function. It's from bind sources...

You should use inet_addr() instead of inet_network().

inet_addr() returns an IP number in network byte order
which is correct input for inet_ntop().  However,
inet_network() returns a network number in host byte
order which is *not* suitable for inet_ntop().

That's why your test program produces wrong output.

Best regards

Oliver Fromme, Bunsenstr. 13, 81735 Muenchen, Germany

``We are all but compressed light'' (Albert Einstein)

More information about the cvs-src mailing list