[ANNOUNCE] iproute2 v2.6.25

[ANNOUNCE] iproute2 v2.6.25

[Stephen Hemminger]

New version of iproute2 utilities that includes bug fixes and
support for all the new features in kernel 2.6.25.

Source: (note old developer.osdl.org address works as well)
	http://devresources.linux-foundation.org/dev/iproute2/download/iproute2-2.6.25.tar.bz2

Git tree:
	git://git.kernel.org/pub/scm/network/iproute2/iproute2.git

Changelog:

Andreas Henriksson (3):
      iproute2: revert syntax help text mistake.
      iproute2: add synonyms for ip rule options to ip(8) manpage.
      iproute2: fix ip manpage typo (syntax error)

Björn Steinbrink (1):
      ss: Fix return value checks for net_*_open

Jesper Dangaard Brouer (7):
      In police, fix uninitialized "overhead" variable.
      TBF overhead parameter parsing.
      CBQ use matches() function instead of strcmp().
      CBQ, implement overhead parameter parsing.
      CBQ, doc usage of overhead parameter.
      police, implement overhead parameter parsing.
      ATM cell alignment.

Marcela Maslanova (2):
      I found out when I was writing manual page, that options ALGO_NAME and
      man ip.8 miss xfrm option

Mike Frysinger (1):
      Do not strip binaries with `install`

PJ Waskiewicz (1):
      Update various classifiers' help output for expected CLASSID syntax

Patrick McHardy (4):
      Add support for SFQ xstats
      Add flow classifier support
      cls_flow: add vlan-tag support
      Fix classifier help

Stephen Hemminger (33):
      Merge header file changes from net-2.6.25
      Fix breakage from netfilter/ip_tables header change.
      rlim qdisc support
      netem potential dist table overflow
      Update header files from net-2.6.25
      Revert "TC action parsing bug fix"
      fix typo in ip batch error message
      vlan meta tag match
      libnetlink: don't spin forever on receive error
      remove extra newline from perror() calls
      poll for errors after rtnl_send
      whitespace typo in tc_common.h
      fix problem caused by rtnl_send checks
      harmonize headers with upcoming 2.6.25
      Change where vlan option shows up in help
      ignore emacs backup files
      fix typos in help message for meta match
      reharmonize headers with pre-freeze 2.6.25
      add support for matching AOE and CAN ether types
      Protocol field on tc_filter is required
      minor typo fixes
      add include/linux/hdlc/ioctl.h
      Revert "rlim qdisc support"
      break excessively long lines
      get rid of warning from misnamed prototype
      decode the output of u32 matches
      missing dport in f_u32 output
      Add default value to /etc/iproute2/rt_dsfield
      revert earlier mistake ALGO_NAME is okay
      Update address of FSF in license
      IP link state show enhancements
      Update kernel headers to 2.6.25-rc7
      Update version

Templin, Fred L (1):
      iproute2-2.6.23: RFC4214 Support (v2.5)

Varun Chandramohan (1):
      Add missing prefix bit length for addrlabel

YOSHIFUJI Hideaki / 吉藤英明 (3):
      Add addrlabel sub-command.
      Add more aliases for tunnel subcommand.
      Add missing description about ISATAP and IPv6 tunnels in ip(8) manpage.

PATCH WAS( Re: [ANNOUNCE] iproute2 v2.6.25

[jamal]

[-- Attachment #1: Type: text/plain, Size: 242 bytes --]


Quick test:
My u32 scripts broke. It seems that i need to pass -raw to get same
output as before; i am sure this will break anyone else depending on old
output.
I have introduced a "cooked" mode instead to output new format.

cheers,
jamal


[-- Attachment #2: u32_p --]
[-- Type: text/plain, Size: 1868 bytes --]

[TC] Restore old output of u32 on output

My scripts broke because of the new change that beautifies output.
Restore old output as default and have user enter -cooked if they
want beautified output...

Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>

---
commit d37302089fbc4c4b5374372e587331ab431b6ae3
tree 05403c85aa727ae9ae939ce8978c4b43b0c478b6
parent 727d468e54bd903b91536e28435a43f73b023222
author Jamal Hadi Salim <hadi@cyberus.ca> Thu, 17 Apr 2008 16:32:46 -0400
committer Jamal Hadi Salim <hadi@cyberus.ca> Thu, 17 Apr 2008 16:32:46 -0400

 include/utils.h |    1 +
 tc/f_u32.c      |    2 +-
 tc/tc.c         |    3 +++
 3 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/include/utils.h b/include/utils.h
index 5daed6b..3a7312c 100644
--- a/include/utils.h
+++ b/include/utils.h
@@ -13,6 +13,7 @@ extern int preferred_family;
 extern int show_stats;
 extern int show_details;
 extern int show_raw;
+extern int show_cooked;
 extern int resolve_hosts;
 extern int oneline;
 extern int timestamp;
diff --git a/tc/f_u32.c b/tc/f_u32.c
index 7e4d56c..db492fe 100644
--- a/tc/f_u32.c
+++ b/tc/f_u32.c
@@ -793,7 +793,7 @@ static void show_key(FILE *f, const struct tc_u32_key *key)
 {
 	char abuf[256];
 
-	if (show_raw)
+	if (!show_cooked)
 		goto raw;
 
 	switch (key->off) {
diff --git a/tc/tc.c b/tc/tc.c
index 6126c71..06058fb 100644
--- a/tc/tc.c
+++ b/tc/tc.c
@@ -33,6 +33,7 @@
 int show_stats = 0;
 int show_details = 0;
 int show_raw = 0;
+int show_cooked = 0;
 int resolve_hosts = 0;
 int use_iec = 0;
 int force = 0;
@@ -273,6 +274,8 @@ int main(int argc, char **argv)
 			++show_details;
 		} else if (matches(argv[1], "-raw") == 0) {
 			++show_raw;
+		} else if (matches(argv[1], "-cooked") == 0) {
+			++show_cooked;
 		} else if (matches(argv[1], "-Version") == 0) {
 			printf("tc utility, iproute2-ss%s\n", SNAPSHOT);
 			return 0;

Re: PATCH WAS( Re: [ANNOUNCE] iproute2 v2.6.25

[Stephen Hemminger]

On Thu, 17 Apr 2008 16:35:39 -0400
jamal <hadi@cyberus.ca> wrote:

> 
> Quick test:
> My u32 scripts broke. It seems that i need to pass -raw to get same
> output as before; i am sure this will break anyone else depending on old
> output.
> I have introduced a "cooked" mode instead to output new format.
> 

The raw flag already existed and humans are the main users.

Re: PATCH WAS( Re: [ANNOUNCE] iproute2 v2.6.25

[jamal]

On Thu, 2008-17-04 at 13:46 -0700, Stephen Hemminger wrote:

> The raw flag already existed and humans are the main users.

My scripts dont count as humans ;->
"raw" was not intepreted for the output on u32. Your patch changed the
semantics when you added what amounts to a cooked mode. 
I think changing old standing outputs should be treated in the same
spirit as existing ABIs. Was this ever posted somewhere - I apologize if
the discussion already happened.

cheers,
jamal

Re: PATCH WAS( Re: [ANNOUNCE] iproute2 v2.6.25

[Stephen Hemminger]

On Thu, 17 Apr 2008 16:59:11 -0400
jamal <hadi@cyberus.ca> wrote:

> On Thu, 2008-17-04 at 13:46 -0700, Stephen Hemminger wrote:
> 
> > The raw flag already existed and humans are the main users.
> 
> My scripts dont count as humans ;->
> "raw" was not intepreted for the output on u32. Your patch changed the
> semantics when you added what amounts to a cooked mode. 
> I think changing old standing outputs should be treated in the same
> spirit as existing ABIs. Was this ever posted somewhere - I apologize if
> the discussion already happened.
> 
> cheers,
> jamal
> 

By that logic no program output would ever change. 

Re: PATCH WAS( Re: [ANNOUNCE] iproute2 v2.6.25

[jamal]

On Thu, 2008-17-04 at 14:08 -0700, Stephen Hemminger wrote:

> By that logic no program output would ever change. 


Ok, come on now Stephen;-> You dont think theres consequences to
changing output for a program that had the same exact output for like 10
years? If you dont believe me, try changing the output of programs like
ifconfig, route etc which people are all the time scripting around and
see how loud they scream. I see this in the same way.

Note: I am not arguing against changing output - it could be done if
there was some discussion which resulted in enough warning. We give i
think a years warning for ABI changes.

cheers,
jamal

Re: PATCH WAS( Re: [ANNOUNCE] iproute2 v2.6.25

[jamal]

Scanning that region of u32 that changed:
show_key() certainly assumes IPv4 (it will fail if we filter on IPV6,
ARP etc). I think this is even more reason to do the cooked variant as
the non-default.
Let me know if you are ok with changing that and i will invest time
"cooking" patches ;-> 

BTW, speaking of scripts and command line output changes (and to
emphasize my earlier comments):
A lot of people managing router configuration out there in the wild do
write parsers that depend on how output looks like (typically a
send/expect interaction)[1]. They invest time in writting such scripts.
In an old job at one point, a customer was adamant they wouldnt buy our
new super-dupper device merely because we changed the command output by
iirc removing a ":" in one of them. Theyd have to rewrite things and go
through whole regression testing.

cheers,
jamal
[1] Contrary to popular theory that provider use SNMP to do router
config (as found out by some study related to the IETF). Things are
changing a little with newer protocols showing up at the IETF to address
these sort of issues.

Re: PATCH WAS( Re: [ANNOUNCE] iproute2 v2.6.25

[Patrick McHardy]

jamal wrote
> BTW, speaking of scripts and command line output changes (and to
> emphasize my earlier comments):
> A lot of people managing router configuration out there in the wild do
> write parsers that depend on how output looks like (typically a
> send/expect interaction)[1]. They invest time in writting such scripts.
> In an old job at one point, a customer was adamant they wouldnt buy our
> new super-dupper device merely because we changed the command output by
> iirc removing a ":" in one of them. Theyd have to rewrite things and go
> through whole regression testing.


Yes, that sucks (ran into the same problem with iproute in a
previous job). I added the ENV dump format to libnl a couple
of years ago (NAME=val), should be easy to add a set of simple
tools to get the information and export it in the environment.

Re: PATCH WAS( Re: [ANNOUNCE] iproute2 v2.6.25

[jamal]

On Fri, 2008-18-04 at 16:22 +0200, Patrick McHardy wrote:

> 
> Yes, that sucks (ran into the same problem with iproute in a
> previous job). I added the ENV dump format to libnl a couple
> of years ago (NAME=val), should be easy to add a set of simple
> tools to get the information and export it in the environment.

Can you explain this a little? Would these variables define what
the command line parameters look like before invoking?

cheers,
jamal

Re: PATCH WAS( Re: [ANNOUNCE] iproute2 v2.6.25

[Stephen Hemminger]

On Fri, 18 Apr 2008 20:08:16 -0400
jamal <hadi@cyberus.ca> wrote:

> On Fri, 2008-18-04 at 16:22 +0200, Patrick McHardy wrote:
> 
> > 
> > Yes, that sucks (ran into the same problem with iproute in a
> > previous job). I added the ENV dump format to libnl a couple
> > of years ago (NAME=val), should be easy to add a set of simple
> > tools to get the information and export it in the environment.
> 
> Can you explain this a little? Would these variables define what
> the command line parameters look like before invoking?
> 
> cheers,
> jamal
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

If somebody doesn't do it first, maybe split the u32 output into:
	(nothing) original format
	-raw	  value/offset
	-pretty	  decoded equivalent of original command

Re: PATCH WAS( Re: [ANNOUNCE] iproute2 v2.6.25

[jamal]

On Fri, 2008-18-04 at 17:59 -0700, Stephen Hemminger wrote:


> If somebody doesn't do it first, maybe split the u32 output into:
> 	(nothing) original format
> 	-raw	  value/offset
> 	-pretty	  decoded equivalent of original command

If there is an agreement to make the original output default i.e use
-cooked if you want to prettify, else old output - then i will do it.
i.e i can work on top of the patch i sent.

cheers,
jamal

Re: PATCH WAS( Re: [ANNOUNCE] iproute2 v2.6.25

[Patrick McHardy]

jamal wrote:
> On Fri, 2008-18-04 at 16:22 +0200, Patrick McHardy wrote:
>
>   
>> Yes, that sucks (ran into the same problem with iproute in a
>> previous job). I added the ENV dump format to libnl a couple
>> of years ago (NAME=val), should be easy to add a set of simple
>> tools to get the information and export it in the environment.
>>     
>
> Can you explain this a little? Would these variables define what
> the command line parameters look like before invoking?

I imagine something like this:

# nl-link-dump env eth0

LINK_NAME=eth0
LINK_IFINDEX=2
LINK_LLADDR=.....
LINK_OPERSTATE=...

and so on. You could then do something like this:

export $(nl-link-dump env eth0)

and use $LINK_... in your scripts.

Re: PATCH WAS( Re: [ANNOUNCE] iproute2 v2.6.25

[jamal]

On Sat, 2008-19-04 at 18:45 +0200, Patrick McHardy wrote:

> I imagine something like this:
> 
> # nl-link-dump env eth0
> 
> LINK_NAME=eth0
> LINK_IFINDEX=2
> LINK_LLADDR=.....
> LINK_OPERSTATE=...
> 
> and so on. You could then do something like this:
> 
> export $(nl-link-dump env eth0)
> 
> and use $LINK_... in your scripts.
> 

Clever. That would certainly help in portability; i will take a closer
look on what you did for libnl and see how well it applies for iproute2.

Stephen, I have some cycles today - I am going to assume no-response
from you implies ok on the change i sent earlier - so i will work on
adding additional changes on top of the one i sent earlier to fixup the
pretty printing (which is not as serious a regression IMO as breakage of
the output).

cheers,
jamal

Re: PATCH WAS( Re: [ANNOUNCE] iproute2 v2.6.25

[Patrick McHardy]

jamal wrote:
> On Sat, 2008-19-04 at 18:45 +0200, Patrick McHardy wrote:
> 
>> I imagine something like this:
>>
>> # nl-link-dump env eth0
>>
>> LINK_NAME=eth0
>> LINK_IFINDEX=2
>> LINK_LLADDR=.....
>> LINK_OPERSTATE=...
>>
>> and so on. You could then do something like this:
>>
>> export $(nl-link-dump env eth0)
>>
>> and use $LINK_... in your scripts.
>>
> 
> Clever. That would certainly help in portability; i will take a closer
> look on what you did for libnl and see how well it applies for iproute2.

I just noticed the libnl example code already supports this:

$ ./nl-link-dump env dev eth0
LINK_NAME=eth0
LINK_IFINDEX=2
LINK_FAMILY=unspec
LINK_TYPE=ether
...

I wouldn't duplicate it for iproute, but rather complete the
libnl support (I think some object types are still missing
ENV dump format support) and tell people to use that for
scripting.

Re: PATCH WAS( Re: [ANNOUNCE] iproute2 v2.6.25

[jamal]

On Mon, 2008-21-04 at 13:50 +0200, Patrick McHardy wrote:


> I just noticed the libnl example code already supports this:
> 
> $ ./nl-link-dump env dev eth0
> LINK_NAME=eth0
> LINK_IFINDEX=2
> LINK_FAMILY=unspec
> LINK_TYPE=ether
> ...
> 
> I wouldn't duplicate it for iproute, but rather complete the
> libnl support (I think some object types are still missing
> ENV dump format support) and tell people to use that for
> scripting.

Sounds sensible.
It would be useful to probably port iproute2 to use libnl. Or something
new that provides iproute2 input/output.

on libnl (CC Thomas):
I havent looked at libnl in a long time; it is certainly the right
direction forward - my main contention with it (which i mentioned to
Thomas) is it has too many knobs/hooks. Last conversation we had he told
me it is optional for me to use all those knobs. For a geek that may not
be sufficient answer: if you give me a swiss army knife i need to know
what everything does ;->
Once you go that path network code that provides callbacks in more than
send/recv as well as statefulness (like caching runtime objects which
libnl did when i looked) then you no longer pass the smell-test for
"library" - you are into "framework" domain[1] - which requires more
steep knowledge of the framework to bypass mechanisms provided to you
that you dont like. I tried to port some app back then from libnetlink
to libnl and found it to be extra curve-climbing and abandoned it; i
will revisit at some point.

cheers,
jamal
[1] Python twisted for example falls under "framework"

Re: PATCH WAS( Re: [ANNOUNCE] iproute2 v2.6.25

[Patrick McHardy]

jamal wrote:
> On Mon, 2008-21-04 at 13:50 +0200, Patrick McHardy wrote:
> 
> 
>> I just noticed the libnl example code already supports this:
>>
>> $ ./nl-link-dump env dev eth0
>> LINK_NAME=eth0
>> LINK_IFINDEX=2
>> LINK_FAMILY=unspec
>> LINK_TYPE=ether
>> ...
>>
>> I wouldn't duplicate it for iproute, but rather complete the
>> libnl support (I think some object types are still missing
>> ENV dump format support) and tell people to use that for
>> scripting.
> 
> Sounds sensible.
> It would be useful to probably port iproute2 to use libnl. Or something
> new that provides iproute2 input/output.


Yes, that would be nice, the iproute netlink infrastructure is really
lagging behind. I'm not sure which way would be preferrable, build
something new on top of libnl without disturbing existing users or
gradually port iproute on top of libnl, probably starting with the
netlink infrastructure.

> on libnl (CC Thomas):
> I havent looked at libnl in a long time; it is certainly the right
> direction forward - my main contention with it (which i mentioned to
> Thomas) is it has too many knobs/hooks. Last conversation we had he told
> me it is optional for me to use all those knobs. For a geek that may not
> be sufficient answer: if you give me a swiss army knife i need to know
> what everything does ;->
 >
> Once you go that path network code that provides callbacks in more than
> send/recv as well as statefulness (like caching runtime objects which
> libnl did when i looked) then you no longer pass the smell-test for
> "library" - you are into "framework" domain[1] - which requires more
> steep knowledge of the framework to bypass mechanisms provided to you
> that you dont like. I tried to port some app back then from libnetlink
> to libnl and found it to be extra curve-climbing and abandoned it; i
> will revisit at some point.

Yes, its a bit overwhelming at the beginning because of all
those knobs, but the simple things are actually real easy :)

Re: PATCH WAS( Re: [ANNOUNCE] iproute2 v2.6.25

[jamal]

On Mon, 2008-21-04 at 15:39 +0200, Patrick McHardy wrote:

> 
> Yes, that would be nice, the iproute netlink infrastructure is really
> lagging behind. 

Agreed.

> I'm not sure which way would be preferrable, build
> something new on top of libnl without disturbing existing users or
> gradually port iproute on top of libnl, probably starting with the
> netlink infrastructure.

I would say build something new would be the proper way to go. Maintain
output of ip/tc/ifconfig/route and phase them out slowly.

> Yes, its a bit overwhelming at the beginning because of all
> those knobs, but the simple things are actually real easy :)

The majority of new users out there may not have the same challenges i
had:
I wanted to do some simple things in a short period; i knew how to use
libnetlink - i thought the mapping would be easy to follow from
libnetlink to libnl; after a few hours, rather than investing more time
i found it easier to update things on top of libnetlink.
People who are totaly starting may find it easier to learn libnl first.
I certainly do plan to poke fingers at libnl - i just happen to have
something that works.

cheers,
jamal

Re: PATCH WAS( Re: [ANNOUNCE] iproute2 v2.6.25

[Thomas Graf]

* Patrick McHardy <kaber@trash.net> 2008-04-21 13:50
> jamal wrote:
> >On Sat, 2008-19-04 at 18:45 +0200, Patrick McHardy wrote:
> >
> >>I imagine something like this:
> >>
> >># nl-link-dump env eth0
> >>
> >>LINK_NAME=eth0
> >>LINK_IFINDEX=2
> >>LINK_LLADDR=.....
> >>LINK_OPERSTATE=...
> >>
> >>and so on. You could then do something like this:
> >>
> >>export $(nl-link-dump env eth0)
> >>
> >>and use $LINK_... in your scripts.
> >>
> >
> >Clever. That would certainly help in portability; i will take a closer
> >look on what you did for libnl and see how well it applies for iproute2.
> 
> I just noticed the libnl example code already supports this:
> 
> $ ./nl-link-dump env dev eth0
> LINK_NAME=eth0
> LINK_IFINDEX=2
> LINK_FAMILY=unspec
> LINK_TYPE=ether
> ...
> 
> I wouldn't duplicate it for iproute, but rather complete the
> libnl support (I think some object types are still missing
> ENV dump format support) and tell people to use that for
> scripting.

The framework is there (dump objects via NL_DUMP_ENV) but not all
objects output all attributes yet. It's a low priority item for me
though but I'm happy to accept patches.

Re: PATCH WAS( Re: [ANNOUNCE] iproute2 v2.6.25

[Thomas Graf]

* jamal <hadi@cyberus.ca> 2008-04-21 10:21
> On Mon, 2008-21-04 at 15:39 +0200, Patrick McHardy wrote:
> 
> > 
> > Yes, that would be nice, the iproute netlink infrastructure is really
> > lagging behind. 
> 
> Agreed.
> 
> > I'm not sure which way would be preferrable, build
> > something new on top of libnl without disturbing existing users or
> > gradually port iproute on top of libnl, probably starting with the
> > netlink infrastructure.
> 
> I would say build something new would be the proper way to go. Maintain
> output of ip/tc/ifconfig/route and phase them out slowly.

Personally I'm in favour of having many small tools like git, i.e.
rtnl-link-add, rtnl-link-list, etc.

Tools like NetworkManager are already using or currently being ported to
libnl and will hide almost all trivial networking configuration tasks
behind a nice gui.

Alternatively there can be an advanced configuration tool with a focus
on Linux being used as a router.

> The majority of new users out there may not have the same challenges i
> had:
> I wanted to do some simple things in a short period; i knew how to use
> libnetlink - i thought the mapping would be easy to follow from
> libnetlink to libnl; after a few hours, rather than investing more time
> i found it easier to update things on top of libnetlink.
> People who are totaly starting may find it easier to learn libnl first.
> I certainly do plan to poke fingers at libnl - i just happen to have
> something that works.

I'm not going to argue with you Jamal :-) In fact I'm pretty sure that
most of the basic tasks are really trivial with libnl and many common
tasks are now accessible via clean interfaces. I agree though that the
number of functions makes it difficult to find the proper interfaces.
That's why I'm thinking about splitting things up in components like
libnl, libnl-link, libnl-tc, etc. to separate the actual netlink library
from netlink family implementations. Won't happen before 2.0 though.