Mar 24, 2019, 10:09 PM by dsah...@gmail.com: > 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, >>>> emersonbern...@tutanota.com >>>> <mailto:emersonbern...@tutanota.com>>>>> 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/
