netdev - Re: [BUG] net/ipv4: inconsistent routing table

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: <CAOrge3pSQ7eck14biTncjOyGD-DKY0DvRr7JKpS3BowoSDry-Q@mail.gmail.com>
Date:	Mon, 10 Aug 2015 06:51:07 -0400
From:	Zang MingJie <zealot0630@...il.com>
To:	Hannes Frederic Sowa <hannes@...essinduktion.org>
Cc:	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [BUG] net/ipv4: inconsistent routing table

Here comes several options:

1. reject local next hop w/ EINVAL
2. delete route when local next hop removed
3. transition between RT_SCOPE_HOST amd RT_SCOPE_LINK
4. document it

which one should we choose ?

1 will definitely cause compatibility problem
2 is the easiest solution
3 need a bit of code, not sure if worth it

On Mon, Aug 10, 2015 at 5:16 AM, Hannes Frederic Sowa
<hannes@...essinduktion.org> wrote:
> Hello,
>
> Zang MingJie <zealot0630@...il.com> writes:
>> Days ago I mistakenly set the gateway address on my box, then add the
>> default router, after I deleted the address my box can't access
>> Internet and all things looks fine. It takes me several hours to
>> figure out it is an kernel bug.
>
> I don't consider this a kernel bug.
>
>>>On Sat, Aug 8, 2015, 1:00 AM Hannes Frederic Sowa <hannes@...essinduktion.org> wrote:
>>>If we could rewind time, we could make local nexthops -EINVAL.
>>
>> I don't think this is the proper solution. As almost all network OS
>> considers the routing table recursive, and it's next hop can be any
>> unicast ip address.
>
> You are talking about ios, junos, no?
>
> Linux does not have any kind of recursive routing table. It only helps
> by doing a first-hop lookup during insertion time, that's merely it. If
> you want to compare Linux to a "network OS" you would have to install
> quagga/bird/xorp/... on a box to get the same behavior.
>
> Also notice that we don't talk about adding/removing addresses to
> interfaces but what the routing code considers are the routes which get
> created because of those address changes (like the subnet route added in
> IPv4 if you install an address with subnet on an interface). Thus we
> shouldn't make address changes special, we would have to reevaluate the
> complete FIB/routing-table (I guess everyone is talking about something
> different here) at the time we only change a route. And this is a no-go.
>
> I don't see a problem with adding a "recursive routing table" to the
> stack if people need that. I just don't see the need for that.
>
>> When the next hop is unreachable the entry won't be installed.
>
> In a recursive routing table, the entry could be installed but it will
> only get into effect when the nexthop turns reachable.
>
>> I suggest adding a new sysconf entry, when not set, behavior as the
>> same as now, when set recalculate the fib when necessary
>
> A new sysctl would work, but I don't consider it necessary. I don't
> think we need the additional code for that. Kernel does not run routing
> protocols and those are normally the only ones which need to do that.
>
>> BTW is there any way to check the fib table?
>
> I don't understand the question. Do you mean
>
> ip route get xx.yy.zz.aa ?
>
> Bye,
> Hannes
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html