netdev - Re: Q: bad routing table cache entries

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: <569532A6.1070905@stressinduktion.org>
Date:	Tue, 12 Jan 2016 18:06:46 +0100
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Stas Sergeev <stsp@...t.ru>
Cc:	netdev <netdev@...r.kernel.org>,
	Sowmini Varadhan <sowmini.varadhan@...cle.com>
Subject: Re: Q: bad routing table cache entries

On 12.01.2016 17:56, Stas Sergeev wrote:
> 12.01.2016 19:42, Stas Sergeev пишет:
>> 12.01.2016 19:10, Hannes Frederic Sowa пишет:
>>> On 12.01.2016 17:03, Stas Sergeev wrote:
>>>> 12.01.2016 18:52, Hannes Frederic Sowa пишет:
>>>>> On 12.01.2016 16:34, Hannes Frederic Sowa wrote:
>>>>>> On 29.12.2015 11:54, Stas Sergeev wrote:
>>>>>>> Hello.
>>>>>>>
>>>>>>> I was hitting a strange problem when some internet hosts
>>>>>>> suddenly stops responding until I reboot. ping to these
>>>>>>> host gives "Destination Host Unreachable". After the
>>>>>>> initial confusion, I've finally got to
>>>>>>> ip route get
>>>>>>> and got something quite strange.
>>>>>>>
>>>>>>>
>>>>>>> Example for GOOD address (the one that I can ping):
>>>>>>>
>>>>>>> ip route get 91.189.89.237
>>>>>>> 91.189.89.237 via 192.168.8.1 dev eth0  src 192.168.10.202
>>>>>>>        cache
>>>>>>>
>>>>>>>
>>>>>>> Example for BAD address (the one that stopped responding):
>>>>>>>
>>>>>>> ip route get 91.189.89.238
>>>>>>> 91.189.89.238 via 192.168.0.1 dev eth0  src 192.168.10.202
>>>>>>>        cache <redirected>
>>>>>>
>>>>>> I tried to understand this thread and now wonder why this redirect route
>>>>>> isn't there always. Can you please summarize again why this shouldn't
>>>>>> happen? It looks totally fine to me from the configuration of your
>>>>>> router and the subnet masks.
>>>>>
>>>>> Just an addendum:
>>>>>
>>>>> In IPv6 a redirect is seen as a notification telling hosts, this new address is on the same link as you. I think this semantic is the same for IPv4, so we are informing you that in essence you are
>>>>> getting a /32 route installed to your new interface and can do link layer resolving of the new host.
>>>>>
>>>>> I do think this is valid and fine.
>>>> You can't call "valid and fine" something that doesn't
>>>> work, at first place. Why and where does it fail, was the
>>>> subject of this thread.
>>>
>>> In terms of the shared media specification <https://tools.ietf.org/html/rfc1620> it is valid and fine.
>> Good luck sending users to RFC without giving any explanations. :)

It explains how and what extensions need to be added to an ip 
routing/host device to deal better with shared media.

>> Well, yes, an interesting reading, but:
>> https://tools.ietf.org/html/rfc1812
>> ---
>>     Routers MUST NOT generate a Redirect Message unless all the following
>>     conditions are met:
>>
>>     o The packet is being forwarded out the same physical interface that
>>        it was received from,
>>
>>     o The IP source address in the packet is on the same Logical IP
>>        (sub)network as the next-hop IP address, and
>>
>>     o The packet does not contain an IP source route option.
>>
>>     The source address used in the ICMP Redirect MUST belong to the same
>>     logical (sub)net as the destination address.
>> ---
>>
>> Could you please explain why the above does not apply?
> Also the rfc1620 you pointed, seems to be saying this:
>
>                  A Redirect message SHOULD be silently discarded if the
>                  new router address it specifies is not on the same
>                  connected (sub-) net through which the Redirect arrived,
>                  or if the source of the Redirect is not the current
>                  first-hop router for the specified destination.
>
> It seems, this is exactly the rule we were trying to find
> during the thread. And it seems violated, either. Unless I am
> mis-interpreting it, of course.

If you read on you will read that with shared_media this exact clause 
(the first of those) is not in effect any more.

I don't know why shared_media=1 is the default in Linux, this decision 
was made long before I joined here. Anyway, with shared_media=1 this is 
absolutely the required behavior.

Bye,
Hannes