Error: an inet prefix is expected rather than "0/0".

Error: an inet prefix is expected rather than "0/0".

[Krzysztof Oledzki]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 273 bytes --]

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ędzki

Re: Error: an inet prefix is expected rather than "0/0".

[Krzysztof Oledzki]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 498 bytes --]



On Wed, 8 Oct 2008, Krzysztof Oledzki wrote:

> 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.

OK, never mind - found it:

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

;)

Best regards,

 				Krzysztof Olędzki

Re: Error: an inet prefix is expected rather than "0/0".

[Herbert Xu]

Krzysztof Oledzki <ole@ans.pl> wrote:
>
> http://git.kernel.org/?p=linux/kernel/git/shemminger/iproute2.git;a=commitdiff_plain;h=2ca4abdcb823e708b88156f947fa5b493055618a
> 
> ;)

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

Re: Error: an inet prefix is expected rather than "0/0".

[Stephen Hemminger]

On Tue, 14 Oct 2008 22:01:27 +0800
Herbert Xu <herbert@gondor.apana.org.au> wrote:

> Krzysztof Oledzki <ole@ans.pl> wrote:
> >
> > http://git.kernel.org/?p=linux/kernel/git/shemminger/iproute2.git;a=commitdiff_plain;h=2ca4abdcb823e708b88156f947fa5b493055618a
> > 
> > ;)
> 
> 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,


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.

Re: Error: an inet prefix is expected rather than "0/0".

[Krzysztof Oledzki]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1250 bytes --]



On Tue, 14 Oct 2008, Stephen Hemminger wrote:

> On Tue, 14 Oct 2008 22:01:27 +0800
> Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
>> Krzysztof Oledzki <ole@ans.pl> wrote:
>>>
>>> http://git.kernel.org/?p=linux/kernel/git/shemminger/iproute2.git;a=commitdiff_plain;h=2ca4abdcb823e708b88156f947fa5b493055618a
>>>
>>> ;)
>>
>> 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,
>
>
> 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.

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ędzki

Re: Error: an inet prefix is expected rather than "0/0".

[Stephen Hemminger]

On Tue, 14 Oct 2008 21:15:18 +0200 (CEST)
Krzysztof Oledzki <ole@ans.pl> wrote:

> 
> 
> On Tue, 14 Oct 2008, Stephen Hemminger wrote:
> 
> > On Tue, 14 Oct 2008 22:01:27 +0800
> > Herbert Xu <herbert@gondor.apana.org.au> wrote:
> >
> >> Krzysztof Oledzki <ole@ans.pl> wrote:
> >>>
> >>> http://git.kernel.org/?p=linux/kernel/git/shemminger/iproute2.git;a=commitdiff_plain;h=2ca4abdcb823e708b88156f947fa5b493055618a
> >>>
> >>> ;)
> >>
> >> 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,
> >
> >
> > 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.
> 
> 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

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

Re: Error: an inet prefix is expected rather than "0/0".

[Ben Hutchings]

On Tue, 2008-10-14 at 12:18 -0700, Stephen Hemminger wrote:
> On Tue, 14 Oct 2008 21:15:18 +0200 (CEST)
> Krzysztof Oledzki <ole@ans.pl> wrote:
> 
> > 
> > 
> > On Tue, 14 Oct 2008, Stephen Hemminger wrote:
[...]
> > > 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.
> > 
> > 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
> 
> The incorrect column lists the actual result for each of the routines.
> Original code converted 127.2 to 127.2.0.0
[...]

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.

Re: Error: an inet prefix is expected rather than "0/0".

[Patrick McHardy]

Stephen Hemminger wrote:
> 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.

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().

Re: Error: an inet prefix is expected rather than "0/0".

[Patrick McHardy]

Patrick McHardy wrote:
> Stephen Hemminger wrote:
>> 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.
> 
> 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

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

Re: Error: an inet prefix is expected rather than "0/0".

[Herbert Xu]

On Tue, Oct 14, 2008 at 10:46:21AM -0700, Stephen Hemminger wrote:
>
> 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.

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

Re: Error: an inet prefix is expected rather than "0/0".

[Krzysztof Halasa]

Herbert Xu <herbert@gondor.apana.org.au> writes:

> 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.

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"
syntax all the time.

> 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.

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

Re: Error: an inet prefix is expected rather than "0/0".

[Ben Hutchings]

On Wed, 2008-10-15 at 17:35 +0200, Krzysztof Halasa wrote:
> Herbert Xu <herbert@gondor.apana.org.au> writes:
> 
> > 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.
> 
> 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).

It's a Berkeley extension which spread via BSD and its inet_aton()
function.  I don't believe it's specified in any RFC.

> Some people use "10.1" syntax all the time.
> 
> > 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.
> 
> 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

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

> If it can't stay this way, lets remove this shortened notation
> completely.

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.

Re: Error: an inet prefix is expected rather than "0/0".

[Krzysztof Halasa]

Ben Hutchings <bhutchings@solarflare.com> writes:

> It's a Berkeley extension which spread via BSD and its inet_aton()
> function.  I don't believe it's specified in any RFC.

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
(except perhaps for removing).

> No, a single number is treated by inet_aton() as a 32-bit address, so 10
> is equivalent to 0.0.0.10.

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

Re: Error: an inet prefix is expected rather than "0/0".

[Stephen Hemminger]

On Wed, 15 Oct 2008 20:52:47 +0200
Krzysztof Halasa <khc@pm.waw.pl> wrote:

> Ben Hutchings <bhutchings@solarflare.com> writes:
> 
> > It's a Berkeley extension which spread via BSD and its inet_aton()
> > function.  I don't believe it's specified in any RFC.
> 
> 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
> (except perhaps for removing).
> 
> > No, a single number is treated by inet_aton() as a 32-bit address, so 10
> > is equivalent to 0.0.0.10.
> 
> 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.

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.

Re: Error: an inet prefix is expected rather than "0/0".

[Herbert Xu]

On Mon, Oct 27, 2008 at 10:39:50AM -0700, Stephen Hemminger wrote:
>
> 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.

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