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]

Date:	Tue, 12 Jan 2016 19:56:57 +0300
From:	Stas Sergeev <stsp@...t.ru>
To:	Hannes Frederic Sowa <hannes@...essinduktion.org>
Cc:	netdev <netdev@...r.kernel.org>,
	Sowmini Varadhan <sowmini.varadhan@...cle.com>
Subject: Re: Q: bad routing table cache entries

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. :)
> 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.