Hello,

It seems that never versions of iproute (tested with iproute2-2.6.26) no 
longer allow 0/0:

# ip route add 0/0 via 192.168.0.1
Error: an inet prefix is expected rather than "0/0".

Is it intentional? It breaks startup scripts.

Best regards,

 			Krzysztof Ol
[ message continues ]

OK, never mind - found it:

http://git.kernel.org/?p=linux/kernel/git/shemminger/iproute2.git;a=commitdiff_plain;h...

;)

Best regards,

 				Krzysztof Ol
[ message continues ]

Hmm, this breaks several scripts of mine that use 10/8.  Couldn't
we just fall back to the old loop when inet_aton fails?

Thanks,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--

[ message continues ]

On Tue, 14 Oct 2008 22:01:27 +0800


There is no easy solution, I'll will have to go back rewrite this
code, and will document the result. I expect the result will displease
someone, but given the original code that is just going to happen.

Busted cases:
                           correct           incorrect
Original code: 127.2   =>  127.0.0.2         127.2.0.0
inet_pton:     10.0    =>  10.0.0.0          fails invalid
inet_aton:     10      =>  10.0.0.0          0.0.0.10

The problem was Alexey (or Jamal) invented their own abbreviation format
and did not follow unix standard conventions.
--

[ message continues ]

It seems that the original code followed the unix standard:

# telnet 127.2
Trying 127.0.0.2...
telnet: connect to address 127.0.0.2: Connection refused

Best regards,

 				Krzysztof Ol
[ message continues ]

On Tue, 14 Oct 2008 21:15:18 +0200 (CEST)

The incorrect column lists the actual result for each of the routines.
Original code converted 127.2 to 127.2.0.0
--

[ message continues ]

[...]

If only the one-component case needs to be treated specially then you
should be able to use something like:

	/* For backward compatibility, if name is all digits we treat it as
	 * the top 8 bits of an IPv4 address. */
	if (strspn(name, "0123456789") == strlen(name))
		addr->data[0] = atoi(name);
	else if (inet_aton(name, addr->data) > 0)
		;
	else
 		return -1;

But if people also rely on e.g. 192.168/16 working then it gets
trickier.

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

--

[ message continues ]

We fixed the same problem in iptables a few years ago, maybe you could
reuse some of that code. Some quick testing shows that it parses all
addresses according to your table:

# iptables -I OUTPUT -d 127.2
# iptables -I OUTPUT -d 10.0
# iptables -I OUTPUT -d 10
# iptables -vxnL OUTPUT
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
     pkts      bytes target     prot opt in     out     source 
      destination
        0        0            all  --  *      *       0.0.0.0/0 
    10.0.0.0
        0        0            all  --  *      *       0.0.0.0/0 
    10.0.0.0
        0        0            all  --  *      *       0.0.0.0/0 
    127.2.0.0

You can find the code in "xtables.c", function numeric_to_ipaddr().
--

[ message continues ]

OK, the last one is wrong. I thought we fixed that :)
--

[ message continues ]

How about just keeping Alexey's code? POSIX doesn't restrict
the IP address format command utilities should accept.  So to
me 127.2.0.0 is a perfectly acceptable interpretation of the
partial address 127.2.

This also has the benefit of not breaking any existing scripts
that already work.  The scripts which are broken will remain
broken which doesn't surprise anyone.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--

[ message continues ]

Then it would be better to disallow such things. The normal meaning
for "127.2" was always 127.0.0.2, and it was widely documented and
used (though perhaps in RFCs, not in POSIX). Some people use "10.1"

Any script which uses 127.2 to mean 127.2.0.0 is IMHO broken, though
I have never seen anything like that.

Rules always have been simple:
10	- 10.0.0.0
10.1	- 10.0.0.1
10.1.2	- 10.0.1.2

If it can't stay this way, lets remove this shortened notation
completely.
-- 
Krzysztof Halasa
--

[ message continues ]

It's a Berkeley extension which spread via BSD and its inet_aton()

No, a single number is treated by inet_aton() as a 32-bit address, so 10

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

--

[ message continues ]

You may be right, I won't start searching now :-)
Anyway it was like that for years and I guess we shouldn't change it

Hmm, I remember some routes being used without a dot, as a single
number, but OTOH you're right, it was also possible to ping
12345678. Perhaps 10 -> 10.0 was specific to something rather than
used generally, I don't know.
-- 
Krzysztof Halasa
--

[ message continues ]

On Wed, 15 Oct 2008 20:52:47 +0200

I ended up putting in a version similar to the original code but with
more error checking so it would not accept 259.1 etc.
--

[ message continues ]

Thanks Stephen!
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--

[ message continues ]