non operational question related to IP

Mailman List Mirror (Read Only)
1

i was pinging a host from a windows machine and made a typo which seemed harmless. the end result was it interpreted my input differently than what I had intended. thinking this was a m$ issue I quickly took the opportunity to poke fun at windows as the senior m$ admin was near by.

"look at how brain dead this os is, it can't even do simple math!"

He is now looking at my screen scratching his head…..

"watch, i'll open a shell on os x and show you how it can add 0 +10"

I open a shell on os x, same behavior as windows.

" ok so apple is brain dead too, watch, it'll work on linux!"

same deal…

long story short, it does work as expected on all our hardware routing gear. still not sure what is happening here…

osx-gwhynott:~ gwhynott$ ping 10.010.10.1
PING 10.010.10.1 (10.8.10.1): 56 data bytes

gwhynott@ops:~$ ping 10.010.10.1
PING 10.010.10.1 (10.8.10.1) 56(84) bytes of data.

CORE1>ping 10.010.10.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds:
!!!!!

anyone happen to know how the OS's are interpreting the 010? doesn't appear work out in base[2-10] (1010,101,22,20,14,13,12,11,10,A)

thanks!

greg

2

Prefixing the octet with 0 makes it interpret it as octal, not decimal.

Pretty typical on a UNIX system.

3

'Octal' (Base-8) :slight_smile:

The leading '0' is telling the box to interpret it as octal instead of
decimal or hex.

Ken Matlock
Network Analyst
Exempla Healthcare
(303) 467-4671
matlockk@exempla.org

4

Looks base 8 to me.

-j

5

010 is how C represents an octal number. This one is known in decimal as 8.

$ bc
bc 1.06
Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.
ibase=8
10
8

    --Steve Bellovin, http://www.cs.columbia.edu/~smb

6

thanks guys. I should of paid more attention in school.

interesting cisco understands what we meant. 8)

-g

7

Obviously, what Greg meant to type was:
$ ping 012.0xA.10.1
PING 012.0xA.10.1 (10.10.10.1) 56(84) bytes of data.

M.

8

He was on Windows, so he might have intended:

C:\>ping 168430081
Pinging 10.10.10.1 with 32 bytes of data:

-Bill

9

0 as a leading digit on an integer indicate octal...

010 octal is 8 decimal.

Owen

10

'Octal' (Base-8) :slight_smile:

The leading '0' is telling the box to interpret it as octal instead of
decimal or hex.

My guess you're seeing an interface that uses inet_addr() instead
of inet_pton(); the latter is used more nowadays at it supports
both IPv4 and IPv6 addressing schemes.

Whereas I've seen this behavior with a lot of vendors, I'm tempted
to call it a bug:

  The Open Group Base Specifications Issue 6
  IEEE Std 1003.1, 2004 Edition

  http://www.opengroup.org/onlinepubs/009695399/functions/inet_ntop.html

  inet_pton():

  If the af argument of inet_pton() is AF_INET, the src string shall be in
  the standard IPv4 dotted-decimal form:

  ddd.ddd.ddd.ddd

  where "ddd" is a one to three digit decimal number between 0 and 255 (see
  inet_addr()).

No mention of dotted quad being anything other than 'decimal', much
less getting cute about guessing the radix.

The *BSD manpages for inet_pton() call out a similar constraint:

  http://www.freebsd.org/cgi/man.cgi?query=inet_aton&apropos=0&sektion=0&manpath=FreeBSD+8.1-RELEASE&format=html

  STANDARDS
     The inet_ntop() and inet_pton() functions conform to X/Open
     Networking Services Issue 5.2 (``XNS5.2''). Note that inet_pton()
     does not accept 1-, 2-, or 3-part dotted addresses; all four
     parts must be specified and are interpreted only as decimal
     values. This is a narrower input set than that accepted by
     inet_aton().

As does Linux():

  http://www.kernel.org/doc/man-pages/online/pages/man3/inet_pton.3.html

  AF_INET
      src points to a character string containing an IPv4 network
      address in dotted-decimal format, "ddd.ddd.ddd.ddd", ...

RFC 2553 also calls out the non-decimal interpretation as being
'non-standard':

  http://www.ietf.org/rfc/rfc2553.txt

  If the af argument is AF_INET, the function accepts a string in
  the standard IPv4 dotted-decimal form:

      ddd.ddd.ddd.ddd

   where ddd is a one to three digit decimal number between 0 and 255.
   Note that many implementations of the existing inet_addr() and
   inet_aton() functions accept nonstandard input: octal numbers,
   hexadecimal numbers, and fewer than four numbers. inet_pton() does
   not accept these formats.

Etc.

I've never been happy with inconsistencies in serializing data structures...

11

See man inet.

     All numbers supplied as ``parts'' in a `.' notation may be decimal,
     octal, or hexadecimal, as specified in the C language (i.e., a leading 0x
     or 0X implies hexadecimal; otherwise, a leading 0 implies octal; other-
     wise, the number is interpreted as decimal).

Note: inet_pton is supposed to only take dotted decimal quad (no
leading zeros). This was a design decision Paul and I made at the
time. Some OS vendors have incorrectly extended it.

Mark

In message <0A3857A2-B215-4592-A288-A534D460CEE7@oicr.on.ca>, Greg Whynott writ
es:

12

Mostly the input is done by a library implementing the Posix
version of fprintf or fscanf.

  10 = 10, 0xa, 012
010 = 8, 0x8, 010
0x10 = 16, 0x10, 020

and there are others. google( fscanf )

Mostly everything understands fscanf syntax.

Cheers
Peter

Greg Whynott wrote:

13

You're entering land of weird, misdocumentation and bugs.

http://seclists.org/nanog/2010/Feb/285