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:42:41 +0300
From:	Stas Sergeev <stsp@...t.ru>
To:	Hannes Frederic Sowa <hannes@...essinduktion.org>
Cc:	netdev <netdev@...r.kernel.org>
Subject: Re: Q: bad routing table cache entries

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?

> You can also disable shared_media on the client and it won't accept such redirects anymore.
Only "such" redirects, or any redirects?


>> If you think router did the right thing, then please explain
>> the breakage from that point of view.
> Hope it makes sense.
No, because it still doesn't work for me.
What should I do to get such redirects to work?
What should I do to at least list them?
Even if this is with accordance to some RFC (which it seems not, though),
this doesn't help me a tiny bit, unless it also works. :)