Bug#497011: /sbin/ip: abbreviation of network-prefix is no longer possible with ip route

2008-09-20 Thread Andreas Unterkircher

I hope the current situation is good enough.


Sure, but please note it somewhere in the package that this behavior has 
changed. At least I can't find any hint about in upstream.


Andreas



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#497011: /sbin/ip: abbreviation of network-prefix is no longer possible with ip route

2008-09-18 Thread Andreas Henriksson
tag 497011 fixed-upstream
thanks

The patch I wrote to support classful abbrevated addresses has been
supported applied in the upstream git repository. This means deprecated
classfull addresses like 10.0/8 should now work again, but invalid
address specifications that happened to work before like 10/8 still is
treated as invalid.
This is as far as I see we can go in backwards compatability. The
upstream change was after all a bugfix (127.2/8 was treated as
127.2.0.0/8 which is wrong by all current and obsolete standards).
I'll close this bug when we package the next upstream release. You could
argue that this problem is only partially fixed, but that would only
result in a wontfix tag and more clutter in the bug tracking system
unless you have a really good idea on how to improve the situation.
I hope the current situation is good enough.

-- 
Regards,
Andreas Henriksson



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#497011: /sbin/ip: abbreviation of network-prefix is no longer possible with ip route

2008-08-29 Thread Andreas Unterkircher
Package: iproute
Version: 20080725-2
Severity: normal
File: /sbin/ip

Since I upgraded iproute today from 20080417-1 it seems to be no longer
possible to do a abbreviation of the network-prefix when handling it
with ip route.

Former it was possible, for example, to add a route by using the
following syntax:

ip route add 10/8 via some-gateway

where 10/8 stands for 10.0.0.0/8. Now ip route rejects this with:

Error: an inet prefix is expected rather than 10/8.

Only

ip route add 10.0.0.0/8 via some-gateway

works for now. But I'm using this shortened syntax quiet often in
my configs as it helps me avoiding typos.

Thanks,
Andreas

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.25-2-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages iproute depends on:
ii  libc6 2.7-13 GNU C Library: Shared libraries
ii  libdb4.6  4.6.21-8   Berkeley v4.6 Database Libraries [

Versions of packages iproute recommends:
pn  libatm1   none (no description available)

Versions of packages iproute suggests:
pn  iproute-doc   none (no description available)

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#497011: /sbin/ip: abbreviation of network-prefix is no longer possible with ip route

2008-08-29 Thread Andreas Henriksson
On Fri, Aug 29, 2008 at 09:24:26AM +0200, Andreas Unterkircher wrote:
 where 10/8 stands for 10.0.0.0/8. Now ip route rejects this with:
 Error: an inet prefix is expected rather than 10/8.

I'm guessing this is caused by 
http://git.kernel.org/?p=linux/kernel/git/shemminger/iproute2.git;a=commitdiff;h=516ffb6b7724e97ca035293dcfd9f94cf6ce3a47
which replaces iproutes own address parsing code with the glibc
version. The reason for this change was that shortened addresses was
parsed incorrectly, which is kind of ironic.

If you want to test rebuilding the iproute package with that commit reverted,
to verify if it's the cause, that would be great!
I'll investigate and get back to you on this as soon as I get some spare
time.

-- 
Andreas Henriksson



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#497011: /sbin/ip: abbreviation of network-prefix is no longer possible with ip route

2008-08-29 Thread Andreas Unterkircher

where 10/8 stands for 10.0.0.0/8. Now ip route rejects this with:
Error: an inet prefix is expected rather than 10/8.


I'm guessing this is caused by  
http://git.kernel.org/?p=linux/kernel/git/shemminger/iproute2.git;a=commitdiff;h=516ffb6b7724e97ca035293dcfd9f94cf6ce3a47


You are right! That is exactly the code. I have reverted the patch
now and rebuilt iproute and that restored the behaviour of ip route.

But I do not know if it is so wise to remove that feature that
silently? Maybe I'm not the only one relying on that.

Regards,
Andreas





--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#497011: /sbin/ip: abbreviation of network-prefix is no longer possible with ip route

2008-08-29 Thread Andreas Henriksson
On fre, 2008-08-29 at 11:43 +0200, Andreas Unterkircher wrote:
 But I do not know if it is so wise to remove that feature that
 silently? Maybe I'm not the only one relying on that.

Silently? Didn't you get a big fat error message? Silent breakage was
what the original commit I pointed you to fixed.

inet_aton supports the ancient classful address format, but this does
not include the 10/8 format so you would have to settle for 10.0/8. I'll
post a patch in a second asking upstream to consider it. I'm not
prepared to carry this in the debian package if upstream doesn't pick it
up, specially since it doesn't restore full backwards compatibility and
the usefullness of the feature is doubtful. Going back to the
home-made parser would be even worse, since it's known to be broken.


-- 
Regards,
Andreas Henriksson



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#497011: [PATCH] Re: Bug#497011: /sbin/ip: abbreviation of network-prefix is no longer possible with ip route

2008-08-29 Thread Andreas Henriksson
Commit 516ffb6b7724e97ca035293dcfd9f94cf6ce3a47 says:

Stephen Hemminger [Thu, 22 May 2008 20:41:40 + (13:41 -0700)]
 Use the standard POSIX inet_pton to convert from string to IPV4
 address. This avoids problems where ip parses 127.2 wrong.

Apparently inet_pton doesn't support abbreviated/shortened/classful
ipv4 addresses at all, but inet_aton does.
Since the function only deals with AF_INET anyway maybe using
inet_aton to increse backwards compatability (please those
who still want to use the format) could be considered?
(This will still not restore the 10/8 format which apparently used
to work in iproute, so people would have to settle for 10.0/8)

(See http://bugs.debian.org/497011)

diff --git a/lib/utils.c b/lib/utils.c
index a88f82b..21cf0ea 100644
--- a/lib/utils.c
+++ b/lib/utils.c
@@ -284,7 +284,7 @@ int get_addr_1(inet_prefix *addr, const char *name, int 
family)
addr-family = AF_INET;
if (family != AF_UNSPEC  family != AF_INET)
return -1;
-   if (inet_pton(AF_INET, name, addr-data) = 0)
+   if (inet_aton(name, addr-data) = 0)
return -1;
addr-bytelen = 4;
addr-bitlen = -1;




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#497011: /sbin/ip: abbreviation of network-prefix is no longer possible with ip route

2008-08-29 Thread Andreas Unterkircher

Silently? Didn't you get a big fat error message? Silent breakage was
what the original commit I pointed you to fixed.


Sure, but I got it when it was already to late - after the upgrade of 
iproute and the following reboot for a new kernel image. Then I was 
wondering why my server did not come back on the network and had to run 
down to our server room... :-)


To use ip route in this way was possible for as long as I can think 
about it. With Debian at least till etch - if this behavior will now be 
removed by the new upstream version in lenny, then I would say it should 
be noted somewhere (readme, warning during upgrade, manpage, wherever).


Because now that I know what will happen, I can schedule checking 
/etc/network/interfaces on our 200 etch servers before upgrading them to 
lenny :-)


Regards,
Andreas




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]