Subject: Re: [BUG][iproute2][5.0] ip route show table default: "Error: ipv4: FIB table does not exist."

From: <[email-masked]>
Date: Thu, 2 May 2019 15:17:55 +0200 (CEST)

Mar 24, 2019, 10:09 PM by [email-masked]:

> On 3/24/19 12:36 PM, Michal Kubecek wrote:
>
>> On Sun, Mar 24, 2019 at 07:29:08PM +0100, Michal Kubecek wrote:
>>
>>> On Sun, Mar 24, 2019 at 11:20:33AM -0600, David Ahern wrote:
>>>
>>>> On 3/24/19 11:02 AM, >>>> [email-masked] <mailto:[email-masked]>>>>>  wrote:
>>>>
>>>>> Ok but previous versions of iproute2 didn't treat this as error and didn't exited with non-zero status. Is non existing default route a system error which needs fixing?
>>>>>
>>>>
>>>> The kernel is returning that error, not iproute2.
>>>>
>>>> It is the default *table*, not a default route.
>>>>
>>>
>>> Something did change on iproute2 side between 4.20 and 5.0, though:
>>>
>>> lion:~ # rpm -q iproute2
>>> iproute2-4.20-0.x86_64
>>> lion:~ # ip route show table default ; echo $?
>>> 0
>>> lion:~ # ip route show table 123 ; echo $?
>>> 0
>>> ...
>>> lion:~ # rpm -q iproute2
>>> iproute2-5.0.0-0.x86_64
>>> lion:~ # ip route show table default ; echo $?
>>> Error: ipv4: FIB table does not exist.
>>> Dump terminated
>>> 2
>>> lion:~ # ip route show table 123 ; echo $?
>>> Error: ipv4: FIB table does not exist.
>>> Dump terminated
>>> 2
>>>
>>> All I did was updating iproute2 package, the same kernel was running for
>>> both (I tried 5.0.3 and 5.1-rc1).
>>>
>>
>> Commit c7e6371bc4af ("ip route: Add protocol, table id and device to
>> dump request") seems to be an obvious candidate. Before it, no matching
>> rules in the dump used to be presented as an empty table but now ip gets
>> a kernel error which it displays to the user.
>>
>
> It's the commit that enables strict checking. Kernel side has been
> changed to better inform the user of what happens on a request when
> strict checking is enabled. iproute2 has been updated to use this.
>
> Essentially, ip asks for a dump of table 253. In the past there is no
> data, so nothing to return. The strict checking tells you explicitly
> "that table does not exist" versus the old method where nothing is
> returned and the user has to guess "the table exists but is empty or
> there is a bug dumping the table?"
>
> Given the legacy of table 253/default, iproute2 can easily catch this
> error and just do nothing for backwards compatibility.
>
Hi, 

are those changes planned then? I don't see anything in repo
https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/log/