netdev - Re: [PATCH] Fix routing tables with id

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0806031220490.3438@bizon.gios.gov.pl>
Date:	Tue, 3 Jun 2008 12:37:35 +0200 (CEST)
From:	Krzysztof Oledzki <olel@....pl>
To:	Jarek Poplawski <jarkao2@...il.com>
cc:	kaber@...sh.net, netdev@...r.kernel.org
Subject: Re: [PATCH]  Fix routing tables with id > 255 for legacy software



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