Re: [cobalt-users] IP addys

["Rob Evans" <robe@xxxxxxxxxxxxxxxxxxx>]

----- Original Message -----
From: "Gordon" <root@xxxxxxxxxxxxxxxxxxxxxxxx>
To: <cobalt-users@xxxxxxxxxxxxxxx>
Sent: Thursday, 16 March 2000 02:17
Subject: Re: [cobalt-users] IP addys


>
> > > >  ping 1.2.3.0x10
> > > >PING 1.2.3.0x10 (1.2.3.16): 56 data bytes
> > >
> > > My testing shows the problem is with how linux answers, not how ping
> > sends.
> > >
>
>   The problem is the linux resolver library is taking liberties it's not
> supposed to when converting numbers to bunary, at least 2 RFC's give
> examples with leading zeros (see 'assigned numbers' for pages of them)
> The rfc's specificaly refer to IP numbers as 'dotted decimal', the key
> word being decimal, linux inet_aton() has no justification for treating
> numbers with leading zeros as octal or hex or anything else but decimal
>
> The problem has nothing to do with ping btw, it will happen in netscape
> nslookup or any other network service using the standard library....
> (probably including bind)
>
> However, the original question was if they were equivelant, the answer
> >should< be yes, but the fact that it breaks at least one resolver would
> tend to suggest it generally a bad idea....plus the fact the person who
> asked it probably using linux....
>

Don't blame Linux.  I did my PING tests from a Windows DOS box, and that did
the octal and hex interpretations for leading zeroes.  I've just tried from
a Unix box running SunOS, and that seems to do the same thing.  So, it looks
as though it's best not to assume that leading zeroes don't matter - they
can change the interpretation of the address.

Rob E.

> >
> > The component "0x10" in the above PING is hexadecimal (base 16), which
> > equals 16 in decimal.  The "0x" prefix indicates that what follows is a
1 or
> > 2 digit hexadecimal number - each digit is in the range 0-9,a-f.  E.g.
"0xa"
> > equals 10 in decimal, "0xb9" equals 185 in decimal.