inet(3) inet_network() bug, [was: cvs commit: src/usr.sbin/jexec
olli at fromme.com
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 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.
Oliver Fromme, Bunsenstr. 13, 81735 Muenchen, Germany
``We are all but compressed light'' (Albert Einstein)
More information about the cvs-src