[PATCH] Fix routing tables with id > 255 for legacy software

[PATCH] Fix routing tables with id > 255 for legacy software

[Krzysztof Oledzki]

>From 4cb8c341fc444afc638cf9ce4efb7e4248e88b5e Mon Sep 17 00:00:00 2001
From: Krzysztof Piotr Oledzki <ole@ans.pl>
Date: Tue, 3 Jun 2008 00:03:41 +0200
Subject: [NET] Fix routing tables with id > 255 for legacy software

Most legacy software do not like tables > 255 as rtm_table is u8
so tb_id is sent &0xff and it is possible to mismatch for example
table 510 with table 254 (main).

This patch introduces RT_TABLE_COMPAT=253 so the code uses it if
tb_id > 255. It makes such old applications happy, new
ones are still able to use RTA_TABLE to get a proper table id.

Signed-off-by: Krzysztof Piotr Oledzki <ole@ans.pl>
---
 include/linux/rtnetlink.h |    1 +
 net/ipv4/fib_semantics.c  |    5 ++++-
 2 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/include/linux/rtnetlink.h b/include/linux/rtnetlink.h
index 44c81c7..8bcdea8 100644
--- a/include/linux/rtnetlink.h
+++ b/include/linux/rtnetlink.h
@@ -246,6 +246,7 @@ enum rt_class_t
 {
 	RT_TABLE_UNSPEC=0,
 /* User defined values */
+	RT_TABLE_COMPAT=252,
 	RT_TABLE_DEFAULT=253,
 	RT_TABLE_MAIN=254,
 	RT_TABLE_LOCAL=255,
diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
index 3b83c34..0d4d728 100644
--- a/net/ipv4/fib_semantics.c
+++ b/net/ipv4/fib_semantics.c
@@ -960,7 +960,10 @@ int fib_dump_info(struct sk_buff *skb, u32 pid, u32 seq, int event,
 	rtm->rtm_dst_len = dst_len;
 	rtm->rtm_src_len = 0;
 	rtm->rtm_tos = tos;
-	rtm->rtm_table = tb_id;
+	if (tb_id < 256)
+		rtm->rtm_table = tb_id;
+	else
+		rtm->rtm_table = RT_TABLE_COMPAT;
 	NLA_PUT_U32(skb, RTA_TABLE, tb_id);
 	rtm->rtm_type = type;
 	rtm->rtm_flags = fi->fib_flags;
-- 
1.5.5.3

Re: [PATCH] Fix routing tables with id > 255 for legacy software

[Jarek Poplawski]

On 03-06-2008 00:09, Krzysztof Oledzki wrote:
> From 4cb8c341fc444afc638cf9ce4efb7e4248e88b5e Mon Sep 17 00:00:00 2001
> From: Krzysztof Piotr Oledzki <ole@ans.pl>
> Date: Tue, 3 Jun 2008 00:03:41 +0200
> Subject: [NET] Fix routing tables with id > 255 for legacy software
> 
> Most legacy software do not like tables > 255 as rtm_table is u8
> so tb_id is sent &0xff and it is possible to mismatch for example
> table 510 with table 254 (main).
> 
> This patch introduces RT_TABLE_COMPAT=253 so the code uses it if
> tb_id > 255. It makes such old applications happy, new
> ones are still able to use RTA_TABLE to get a proper table id.
> 

Probably, as usual, some people will grumble this breaks their scripts,
so, probably, some if or ifdef is needed? BTW, I wonder, how these old
appliction would treat RT_TABLE_UNSPEC instead.

Regards,
Jarek P.

Re: [PATCH] Fix routing tables with id > 255 for legacy software

[Krzysztof Oledzki]

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



On Tue, 3 Jun 2008, Jarek Poplawski wrote:

> On 03-06-2008 00:09, Krzysztof Oledzki wrote:
>> From 4cb8c341fc444afc638cf9ce4efb7e4248e88b5e Mon Sep 17 00:00:00 2001
>> From: Krzysztof Piotr Oledzki <ole@ans.pl>
>> Date: Tue, 3 Jun 2008 00:03:41 +0200
>> Subject: [NET] Fix routing tables with id > 255 for legacy software
>>
>> Most legacy software do not like tables > 255 as rtm_table is u8
>> so tb_id is sent &0xff and it is possible to mismatch for example
>> table 510 with table 254 (main).
>>
>> This patch introduces RT_TABLE_COMPAT=253 so the code uses it if
>> tb_id > 255. It makes such old applications happy, new
>> ones are still able to use RTA_TABLE to get a proper table id.
>>
>
> Probably, as usual, some people will grumble this breaks their scripts,
> so, probably, some if or ifdef is needed?
Why? If scripts are based on a recent version of iproute2 that uses 
RTA_TABLE then everything should work, especially there is no way to use 
tables with id > 255 with old iproute2.

> BTW, I wonder, how these old appliction would treat RT_TABLE_UNSPEC 
> instead.

Such old appliction is for example zebra/quagga: it asks for all routes, 
does not know about RTA_TABLE so uses rtm_table and selects all entries 
with rtm_table == RT_TABLE_MAIN or zebrad.rtm_table_default which is 
unfortunately 0 by default. So no, RT_TABLE_UNSPEC (0) does not help, even 
makes everythink worse here.

Best regards,

 			Krzysztof Olędzki

Re: [PATCH] Fix routing tables with id > 255 for legacy software

[Jarek Poplawski]

On Tue, Jun 03, 2008 at 12:37:35PM +0200, Krzysztof Oledzki wrote:
>
>
> On Tue, 3 Jun 2008, Jarek Poplawski wrote:
>
>> On 03-06-2008 00:09, Krzysztof Oledzki wrote:
>>> From 4cb8c341fc444afc638cf9ce4efb7e4248e88b5e Mon Sep 17 00:00:00 2001
>>> From: Krzysztof Piotr Oledzki <ole@ans.pl>
>>> Date: Tue, 3 Jun 2008 00:03:41 +0200
>>> Subject: [NET] Fix routing tables with id > 255 for legacy software
>>>
>>> Most legacy software do not like tables > 255 as rtm_table is u8
>>> so tb_id is sent &0xff and it is possible to mismatch for example
>>> table 510 with table 254 (main).
>>>
>>> This patch introduces RT_TABLE_COMPAT=253 so the code uses it if
>>> tb_id > 255. It makes such old applications happy, new
>>> ones are still able to use RTA_TABLE to get a proper table id.
>>>
>>
>> Probably, as usual, some people will grumble this breaks their scripts,
>> so, probably, some if or ifdef is needed?
> Why? If scripts are based on a recent version of iproute2 that uses  
> RTA_TABLE then everything should work, especially there is no way to use  
> tables with id > 255 with old iproute2.

If such an old app uses rtm_table, this 253 table could be used for
something and get additional entries after this patch. Another case
would be when such an overflow on 0xff is "expected", then old tables
would loose their entries. I hope I'm wrong with this, but it looks
like admins can do strange things, and then this would be called a
regression. So, I think this patch is right if we are sure there are
no such cases...

>
>> BTW, I wonder, how these old appliction would treat RT_TABLE_UNSPEC  
>> instead.
>
> Such old appliction is for example zebra/quagga: it asks for all routes,  
> does not know about RTA_TABLE so uses rtm_table and selects all entries  
> with rtm_table == RT_TABLE_MAIN or zebrad.rtm_table_default which is  
> unfortunately 0 by default. So no, RT_TABLE_UNSPEC (0) does not help, 
> even makes everythink worse here.

I see: so we don't care for these RT_TABLE_COMPAT entries, let only
they don't go to _MAIN or _UNSPEC!

Thanks for the explanation,
Jarek P.

Re: [PATCH] Fix routing tables with id > 255 for legacy software

[Jarek Poplawski]

On Tue, Jun 03, 2008 at 11:33:43AM +0000, Jarek Poplawski wrote:
> On Tue, Jun 03, 2008 at 12:37:35PM +0200, Krzysztof Oledzki wrote:
...
> > Why? If scripts are based on a recent version of iproute2 that uses  
> > RTA_TABLE then everything should work, especially there is no way to use  
> > tables with id > 255 with old iproute2.
> 
> If such an old app uses rtm_table, this 253 table could be used for

...Of course I mean when old apps are used together with new iproute2
and ids > 255...

Jarek P.

Re: [PATCH] Fix routing tables with id > 255 for legacy software

[Patrick McHardy]

Jarek Poplawski wrote:
> On Tue, Jun 03, 2008 at 12:37:35PM +0200, Krzysztof Oledzki wrote:
>>
> If such an old app uses rtm_table, this 253 table could be used for
> something and get additional entries after this patch. Another case
> would be when such an overflow on 0xff is "expected", then old tables
> would loose their entries. I hope I'm wrong with this, but it looks
> like admins can do strange things, and then this would be called a
> regression. So, I think this patch is right if we are sure there are
> no such cases...
> 
>>> BTW, I wonder, how these old appliction would treat RT_TABLE_UNSPEC  
>>> instead.
>> Such old appliction is for example zebra/quagga: it asks for all routes,  
>> does not know about RTA_TABLE so uses rtm_table and selects all entries  
>> with rtm_table == RT_TABLE_MAIN or zebrad.rtm_table_default which is  
>> unfortunately 0 by default. So no, RT_TABLE_UNSPEC (0) does not help, 
>> even makes everythink worse here.
> 
> I see: so we don't care for these RT_TABLE_COMPAT entries, let only
> they don't go to _MAIN or _UNSPEC!

Well, if people already use table 253, I guess they might care.
I'm not convinced this is any better than overflowing.

Quoting the changelog from the patch which introduces this:

     Introduce RTA_TABLE route attribute and FRA_TABLE routing rule 
attribute
     to hold 32 bit routing table IDs. Usespace compatibility is provided by
     continuing to accept and send the rtm_table field, but because of its
     limited size it can only carry the low 8 bits of the table ID. This
     implies that if larger IDs are used, _all_ userspace programs using 
them
     need to use RTA_TABLE.

And I still don't see any other way to handle this properly.

Re: [PATCH] Fix routing tables with id > 255 for legacy software

[Krzysztof Oledzki]

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



On Tue, 3 Jun 2008, Patrick McHardy wrote:

> Jarek Poplawski wrote:
>> On Tue, Jun 03, 2008 at 12:37:35PM +0200, Krzysztof Oledzki wrote:
>>> 
>> If such an old app uses rtm_table, this 253 table could be used for
>> something and get additional entries after this patch. Another case
>> would be when such an overflow on 0xff is "expected", then old tables
>> would loose their entries. I hope I'm wrong with this, but it looks
>> like admins can do strange things, and then this would be called a
>> regression. So, I think this patch is right if we are sure there are
>> no such cases...
>> 
>>>> BTW, I wonder, how these old appliction would treat RT_TABLE_UNSPEC 
>>>> instead.
>>> Such old appliction is for example zebra/quagga: it asks for all routes, 
>>> does not know about RTA_TABLE so uses rtm_table and selects all entries 
>>> with rtm_table == RT_TABLE_MAIN or zebrad.rtm_table_default which is 
>>> unfortunately 0 by default. So no, RT_TABLE_UNSPEC (0) does not help, even 
>>> makes everythink worse here.
>> 
>> I see: so we don't care for these RT_TABLE_COMPAT entries, let only
>> they don't go to _MAIN or _UNSPEC!
>
> Well, if people already use table 253, I guess they might care.

Not really as if pople use a FRA_TABLE aware application they should not 
notice any difference.

> I'm not convinced this is any better than overflowing.

But if they use FRA_TABLE unaware application than overflowing means 
mismatching all:
  - N*256 table as RT_TABLE_UNSPEC
  - N*256+253 tables as RT_TABLE_DEFAULT
  - N*256+254 tables as RT_TABLE_MAIN
  - N*256+255 tables as RT_TABLE_LOCAL

And as I just find out, when it happens is quite unexpected and can really 
hurt. :(

> And I still don't see any other way to handle this properly.

Exactly. So that's why I came with above solution, similar to AS_TRANSIT 
idea used in BGP to handle 16bit -> 32bit ASN transformation.

Best regards,

 				Krzysztof Olędzki

Re: [PATCH] Fix routing tables with id > 255 for legacy software

[Patrick McHardy]

Krzysztof Oledzki wrote:
> On Tue, 3 Jun 2008, Patrick McHardy wrote:
> 
>> Well, if people already use table 253, I guess they might care.
> 
> Not really as if pople use a FRA_TABLE aware application they should not 
> notice any difference.

In that case not of course.

>> I'm not convinced this is any better than overflowing.
> 
> But if they use FRA_TABLE unaware application than overflowing means 
> mismatching all:
>  - N*256 table as RT_TABLE_UNSPEC
>  - N*256+253 tables as RT_TABLE_DEFAULT
>  - N*256+254 tables as RT_TABLE_MAIN
>  - N*256+255 tables as RT_TABLE_LOCAL
> 
> And as I just find out, when it happens is quite unexpected and can 
> really hurt. :(
> 
>> And I still don't see any other way to handle this properly.
> 
> Exactly. So that's why I came with above solution, similar to AS_TRANSIT 
> idea used in BGP to handle 16bit -> 32bit ASN transformation.

I think the proper solution is what I wrote in the changelog
entry: fix userspace applications when using extended table
IDs.

Your patch makes it more predictable, so I'm not completely
opposed, but still its just a workaround.

Re: [PATCH] Fix routing tables with id > 255 for legacy software

[Krzysztof Oledzki]

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



On Tue, 3 Jun 2008, Patrick McHardy wrote:

> Krzysztof Oledzki wrote:
>> On Tue, 3 Jun 2008, Patrick McHardy wrote:
>> 
>>> Well, if people already use table 253, I guess they might care.
>> 
>> Not really as if pople use a FRA_TABLE aware application they should not 
>> notice any difference.
>
> In that case not of course.
>
>>> I'm not convinced this is any better than overflowing.
>> 
>> But if they use FRA_TABLE unaware application than overflowing means 
>> mismatching all:
>>  - N*256 table as RT_TABLE_UNSPEC
>>  - N*256+253 tables as RT_TABLE_DEFAULT
>>  - N*256+254 tables as RT_TABLE_MAIN
>>  - N*256+255 tables as RT_TABLE_LOCAL
>> 
>> And as I just find out, when it happens is quite unexpected and can really 
>> hurt. :(
>> 
>>> And I still don't see any other way to handle this properly.
>> 
>> Exactly. So that's why I came with above solution, similar to AS_TRANSIT 
>> idea used in BGP to handle 16bit -> 32bit ASN transformation.
>
> I think the proper solution is what I wrote in the changelog
> entry: fix userspace applications when using extended table
> IDs.

It is unquestionably true, however it may take some time and people may 
still use old version of such applications for whatsoever reasons.

> Your patch makes it more predictable, so I'm not completely
> opposed, but still its just a workaround.

Indeed - it is a workaround but I believe we need it.

Best regards,

 				Krzysztof Olędzki

Re: [PATCH] Fix routing tables with id > 255 for legacy software

[Jarek Poplawski]

On Tue, Jun 03, 2008 at 05:15:04PM +0200, Krzysztof Oledzki wrote:
>
>
> On Tue, 3 Jun 2008, Patrick McHardy wrote:
...
>> Your patch makes it more predictable, so I'm not completely
>> opposed, but still its just a workaround.
>
> Indeed - it is a workaround but I believe we need it.
>

IMHO, adding a safety with e.g. CONFIG_IP_FIB_COMPAT_DEPRECATED
(default N) for one stable, letting to change this back in some
(probably nonexistent) strange cases, should be enough to keep up
appearances...

Jarek P.

Re: [PATCH] Fix routing tables with id > 255 for legacy software

[Patrick McHardy]

Jarek Poplawski wrote:
> On Tue, Jun 03, 2008 at 05:15:04PM +0200, Krzysztof Oledzki wrote:
>>
>> On Tue, 3 Jun 2008, Patrick McHardy wrote:
> ...
>>> Your patch makes it more predictable, so I'm not completely
>>> opposed, but still its just a workaround.
>> Indeed - it is a workaround but I believe we need it.
>>
> 
> IMHO, adding a safety with e.g. CONFIG_IP_FIB_COMPAT_DEPRECATED
> (default N) for one stable, letting to change this back in some
> (probably nonexistent) strange cases, should be enough to keep up
> appearances...


Mhh .. I don't think this is a good solution. Things can
only break if you actually use the new feature, and if
you do, you should simply make sure that all software
running can deal with it. Fixing the routing daemons
should be a triviality.

Re: [PATCH] Fix routing tables with id > 255 for legacy software

[Jarek Poplawski]

On Tue, Jun 03, 2008 at 07:58:42PM +0200, Patrick McHardy wrote:
> Jarek Poplawski wrote:
...
>> IMHO, adding a safety with e.g. CONFIG_IP_FIB_COMPAT_DEPRECATED
>> (default N) for one stable, letting to change this back in some
>> (probably nonexistent) strange cases, should be enough to keep up
>> appearances...
>
>
> Mhh .. I don't think this is a good solution. Things can
> only break if you actually use the new feature, and if
> you do, you should simply make sure that all software
> running can deal with it. Fixing the routing daemons
> should be a triviality.

But, I think, you've written earlier there is no good solution. And,
probably, there is no way to make sure. This is mainly for appearances
(niceness), and maybe let us know if the problem really existed. But,
I don't insist on this...

Jarek P.

Re: [PATCH] Fix routing tables with id > 255 for legacy software

[Krzysztof Oledzki]

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



On Tue, 3 Jun 2008, Patrick McHardy wrote:

> Jarek Poplawski wrote:
>> On Tue, Jun 03, 2008 at 05:15:04PM +0200, Krzysztof Oledzki wrote:
>>> 
>>> On Tue, 3 Jun 2008, Patrick McHardy wrote:
>> ...
>>>> Your patch makes it more predictable, so I'm not completely
>>>> opposed, but still its just a workaround.
>>> Indeed - it is a workaround but I believe we need it.
>>> 
>> 
>> IMHO, adding a safety with e.g. CONFIG_IP_FIB_COMPAT_DEPRECATED
>> (default N) for one stable, letting to change this back in some
>> (probably nonexistent) strange cases, should be enough to keep up
>> appearances...
>
>
> Mhh .. I don't think this is a good solution.

I second that. If you know that you need this option then you don't need 
it as you may avoid selected tables.

> Things can only break if you actually use the new feature, and if you 
> do, you should simply make sure that all software running can deal with 
> it. Fixing the routing daemons should be a triviality.

Indeed, it is trivial and I even have a small patch for quagga I'm going 
to push to the upstream soon. However the problem is the non intuitive 
behavior of old applications that may lead into a critical network outage 
(been there, done that) and my patch is supposed to minimize such a 
possibility. Without special knowledge it is not obvious that that routes 
in 256, 510, etc tables may be handle as routes in RT_TABLE_MAIN table.

Best regards,

 				Krzysztof Olędzki

Re: [PATCH] Fix routing tables with id > 255 for legacy software

[Jarek Poplawski]

On Tue, Jun 03, 2008 at 08:29:49PM +0200, Krzysztof Oledzki wrote:
>
>
> On Tue, 3 Jun 2008, Patrick McHardy wrote:
>
>> Jarek Poplawski wrote:
>>> On Tue, Jun 03, 2008 at 05:15:04PM +0200, Krzysztof Oledzki wrote:
>>>>
>>>> On Tue, 3 Jun 2008, Patrick McHardy wrote:
>>> ...
>>> IMHO, adding a safety with e.g. CONFIG_IP_FIB_COMPAT_DEPRECATED
>>> (default N) for one stable, letting to change this back in some
>>> (probably nonexistent) strange cases, should be enough to keep up
>>> appearances...
>>
>>
>> Mhh .. I don't think this is a good solution.
>
> I second that. If you know that you need this option then you don't need  
> it as you may avoid selected tables.

This is only for those (nonexistent, I hope) who would report a
regression to the list or bugzilla ("my scripts are broken") to let
them fix this easy way, or maybe for even fewer ones, who read
config options and would be alarmed with this "DEPRECATED" word.

Jarek P.

Re: [PATCH] Fix routing tables with id > 255 for legacy software

[Patrick McHardy]

Krzysztof Oledzki wrote:
> On Tue, 3 Jun 2008, Patrick McHardy wrote:
> 
>> I think the proper solution is what I wrote in the changelog
>> entry: fix userspace applications when using extended table
>> IDs.
> 
> It is unquestionably true, however it may take some time and people may 
> still use old version of such applications for whatsoever reasons.
> 
>> Your patch makes it more predictable, so I'm not completely
>> opposed, but still its just a workaround.
> 
> Indeed - it is a workaround but I believe we need it.

I'm neither opposed (as long as we don't add CONFIG options for
this) nor in favour - people using fixed applications won't notice,
and for other people it substitutes undesired behaviour by more
predictable undesirable behaviour, which is at least no loss :)

Re: [PATCH] Fix routing tables with id > 255 for legacy software

[Krzysztof Oledzki]

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



On Tue, 3 Jun 2008, Patrick McHardy wrote:

> Krzysztof Oledzki wrote:
>> On Tue, 3 Jun 2008, Patrick McHardy wrote:
>> 
>>> I think the proper solution is what I wrote in the changelog
>>> entry: fix userspace applications when using extended table
>>> IDs.
>> 
>> It is unquestionably true, however it may take some time and people may 
>> still use old version of such applications for whatsoever reasons.
>> 
>>> Your patch makes it more predictable, so I'm not completely
>>> opposed, but still its just a workaround.
>> 
>> Indeed - it is a workaround but I believe we need it.
>
> I'm neither opposed (as long as we don't add CONFIG options for
> this) nor in favour - people using fixed applications won't notice,
> and for other people it substitutes undesired behaviour by more
> predictable undesirable behaviour,

Exactly,

> which is at least no loss :)

OK, so I assume it is a very weak ack-by? ;)

David?

Best regards,

 				Krzysztof Olędzki

Re: [PATCH] Fix routing tables with id > 255 for legacy software

[Patrick McHardy]

Krzysztof Oledzki wrote:
> 
> 
> On Tue, 3 Jun 2008, Patrick McHardy wrote:
> 
>> Krzysztof Oledzki wrote:
>>> On Tue, 3 Jun 2008, Patrick McHardy wrote:
>>>
>>>> I think the proper solution is what I wrote in the changelog
>>>> entry: fix userspace applications when using extended table
>>>> IDs.
>>>
>>> It is unquestionably true, however it may take some time and people 
>>> may still use old version of such applications for whatsoever reasons.
>>>
>>>> Your patch makes it more predictable, so I'm not completely
>>>> opposed, but still its just a workaround.
>>>
>>> Indeed - it is a workaround but I believe we need it.
>>
>> I'm neither opposed (as long as we don't add CONFIG options for
>> this) nor in favour - people using fixed applications won't notice,
>> and for other people it substitutes undesired behaviour by more
>> predictable undesirable behaviour,
> 
> Exactly,
> 
>> which is at least no loss :)
> 
> OK, so I assume it is a very weak ack-by? ;)

Its a Not-NACKed-by: Patrick McHardy <kaber@trash.net> :)

Re: [PATCH] Fix routing tables with id > 255 for legacy software

[Patrick McHardy]

Patrick McHardy wrote:
> Krzysztof Oledzki wrote:
>>
>>> I'm neither opposed (as long as we don't add CONFIG options for
>>> this) nor in favour - people using fixed applications won't notice,
>>> and for other people it substitutes undesired behaviour by more
>>> predictable undesirable behaviour,
>>
>> Exactly,
>>
>>> which is at least no loss :)
>>
>> OK, so I assume it is a very weak ack-by? ;)
> 
> Its a Not-NACKed-by: Patrick McHardy <kaber@trash.net> :)


I'll upgrade that to a full ACK - the predictability allows
to use the new features in combination with legacy apps and
avoid any trouble if done carefully. There is some small risk
of new breakage, but things probably won't work as expected
anyway.

Thanks Krzysztof.

Re: [PATCH] Fix routing tables with id > 255 for legacy software

[David Miller]

From: Patrick McHardy <kaber@trash.net>
Date: Wed, 04 Jun 2008 01:23:24 +0200

> Patrick McHardy wrote:
> > Krzysztof Oledzki wrote:
> >>
> >>> I'm neither opposed (as long as we don't add CONFIG options for
> >>> this) nor in favour - people using fixed applications won't notice,
> >>> and for other people it substitutes undesired behaviour by more
> >>> predictable undesirable behaviour,
> >>
> >> Exactly,
> >>
> >>> which is at least no loss :)
> >>
> >> OK, so I assume it is a very weak ack-by? ;)
> > 
> > Its a Not-NACKed-by: Patrick McHardy <kaber@trash.net> :)
> 
> 
> I'll upgrade that to a full ACK - the predictability allows
> to use the new features in combination with legacy apps and
> avoid any trouble if done carefully. There is some small risk
> of new breakage, but things probably won't work as expected
> anyway.

Patch applied with a typo fix in the changelog, it mentioned
that the new value was 253 when actually it is 252 :-)

Thanks!