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: <56952593.8040409@stressinduktion.org>
Date:	Tue, 12 Jan 2016 17:10:59 +0100
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Stas Sergeev <stsp@...t.ru>
Cc:	netdev <netdev@...r.kernel.org>
Subject: Re: Q: bad routing table cache entries

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.

You can also disable shared_media on the client and it won't accept such 
redirects anymore. It is just what we defined as the default.

> If you think router did the right thing, then please explain
> the breakage from that point of view.

Hope it makes sense.

Bye,
Hannes