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 23:26:29 +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

Hi,

On 12.01.2016 21:43, Stas Sergeev wrote:
> 12.01.2016 20:47, Hannes Frederic Sowa пишет:
>> On 12.01.2016 18:33, Stas Sergeev wrote:
>>> 12.01.2016 20:26, Hannes Frederic Sowa пишет:
>>>> On 12.01.2016 18:18, Stas Sergeev wrote:
>>>>> 12.01.2016 20:06, Hannes Frederic Sowa пишет:
>>>>>> On 12.01.2016 17:56, Stas Sergeev wrote:
>>>>>>> 12.01.2016 19:42, Stas Sergeev пишет:
>>>>>>> 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.
>>>>> OK. But how to get such a redirect to work, if (checked with
>>>>> tcpdump) the packets do not even go to eth0, but to "lo"?
>>>>
>>>> I don't know, the router must be on the same shared medium. I guess
>>>> physical reconfiguration is required?
>>> It is same.
>>> Router 192.168.8.1 has just one ethernet port.
>>> And even on the 192.168.10.202 node I can do:
>>> # arp -a |grep "0.1"
>>> ? (192.168.0.1) at 14:d6:4d:1c:97:3d [ether] on eth0
>>> So even 0.1 is about to be reachable.
>>> Still nothing works.
>>> Should it work if 192.168.0.1 router, to which 8.1 redirects,
>>> has shared_media disabled?
>>
>> Can you check with tcpdump?
> That's what I already did.
> I monitored on 8.1 router and on the node itself,
> and my conclusion was that the packets do not
> even reach the eth0 interface. Instead I captured
> them on "lo" interface, so I assumed such route is
> completely broken.

I didn't check a full featured setup but just did some dirty testing 
with namespaces and I had correct arp request for the now to be assumed 
on-link router on the external veth.

> If it is not - how can I even see that it exist? How to
> list these redirect routes?

Yeah, that might be a minor issue. The rt_cache procfs files are empty 
since the deletion of the cache and we probably don't have an interface 
for next hop exceptions, I consider this todo. :) ip route get is your 
only hope right now.

Anyway, seems like there are problems with redirect timeout somehow. I 
am investigating this.

> I'd like to do some investigations, but this looks no
> more than a black magic without a proper support
> from tools, proper documentation, etc.

Hmm, so far I think shared_media is behaving like it should, besides 
maybe it shouldn't be the default setting. Maybe someone who can 
remember why it is default could chime in?

> And I suspect that shared_media is disabled on a 0.1
> router, so I wonder if this can work at all, even if the node
> is cured to do the right thing with those redirects.
> In a nearby message David Miller says:

Default is that shared_media is enabled, so the chances are relatively 
high that it is enabled if it is not turned off.

> ---
>
> 2) increasing the chance of successful communication with peers
>
> ---
> If this can't work right when one of the gateways has
> shared_media disabled, then this rule is clearly violated.

It can work right and I think the RFC actually gives examples where it 
is very useful. Also IPv6 adapts it as the default, so it might make 
sense to have it as default.

I still consider something broken in your network setup, maybe.

>> ping requires the router to also find a correct way back, so packet
>> can get stuck at a lot of places. Also uRPF is maybe active which kind
>> of defeats shared_media and please check netfilter.
> I am pretty sure the node has a default ubuntu without
> any special network tweaks, but I'll double-check.

Please do that. Thanks!

Bye,
Hannes