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:	Wed, 13 Jan 2016 01:57:17 +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

13.01.2016 01:26, Hannes Frederic Sowa пишет:
> 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.
I haven't checked anything with arp.
I set up tcpdump to only capture icmp.
What would you like me to check, could you please
give the detailed instructions?

>> 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,
No, unless you correct the documentation:
https://www.frozentux.net/ipsysctl-tutorial/chunkyhtml/theconfvariables.html
It says not what you say.
So this feature is essentially poorly (or wrongly) documented.

> 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,
On what OS, and since what version?

> so the chances are relatively high that it is enabled if it is not 
> turned off.
I don't even know what is there in a 0.1 router - maybe windows95,
who knows. You can't assume the latest linux kernel is everywhere.

>> ---
>>
>> 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!
OK but please make it clear what should I check.
iptables do not seem to be in the game, what else to check?