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

[Oliver Fromme]

Hi,

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 0.0.0.127) or a hostname.  Either the
 > > >
 > > > actually 127.0.0.0
 > >
 > > I'm afraid I think it is 0.0.0.127.
 > > 127.0.0.0 would be 2130706432.
 > 
 > 127.0.0.1 is 0x0000007f.

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

When the input "127" is used when an IP number
is expected, it must be interpreted as 0.0.0.127
(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 127.0.0.0 is 0x0000007f,
but that's a different thing.

 > > I'm pretty sure 127.1 is the same as 127.0.0.1.  Last
 > > time I used telnet 127.1 to test things it worked fine.
 > >
 > > 127.1.0.0 would be 127.65536.
 > 
 > re-reading the man page inet(3) it seems you would be right
 > for 127.0.0.1 == 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

-- 
Oliver Fromme, Bunsenstr. 13, 81735 Muenchen, Germany

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