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
| ||
|
Message-ID: <CAJGXZLjLXrUzz4S9C7SqeyszMMyjR6RRu52y1fyh_d6gRqFHdA@mail.gmail.com> Date: Wed, 3 May 2023 18:01:03 +0300 From: Aleksey Shumnik <ashumnik9@...il.com> To: netdev@...r.kernel.org, waltje@...lt.nl.mugnet.org, Jakub Kicinski <kuba@...nel.org>, gw4pts@...pts.ampr.org, kuznet@....inr.ac.ru, "willemdebruijn.kernel@...il.com" <willemdebruijn.kernel@...il.com>, gnault@...hat.com Subject: [BUG] Dependence of routing cache entries on the ignore-df flag Dear maintainers, I found such a dependency, if the ignore-df flag is set on the interface, then entries appear in the routing cache. You can reproduce it as follows: # cat /etc/network/interfaces.d/mgre0 auto mgre0 iface mgre0 inet static address 10.10.10.1 netmask 255.255.255.0 pre-up ip tunnel add mgre0 mode gre key 1 ttl 64 tos inherit pre-up ethtool -K mgre0 tx off > /dev/null pre-up ip link set mgre0 mtu 1400 pre-up ip link set mgre0 multicast on pre-up ip link set mgre0 type gre nopmtudisc pre-up ip link set mgre0 type gre ignore-df post-down ip link del mgre0 # ifup mgre0 # ip link set mgre0 arp on # ip neigh add 10.10.10.2 dev mgre0 lladdr <some ipv4 addr> # ping 10.10.10.2 # ip route show cache 10.10.10.2 dev mgre0 cache expires 598sec mtu 1400 Creating mgre interface using the following config. Set arp on (this is necessary). Add an entry to the neighbor table for arp routing, specify the address from the same subnet as the address on the mgre interface. Ping this address. After that, an entry is added to the routing cache. It seems that after it was not possible to find a suitable entry in the routing table for the address 10.10.10.2, before looking at the arp table, an entry is added to the routing cache. But the most incomprehensible thing for me is if you remove the ignore-df flag, restart (ifdown, ifup) the interface, then the problem is not observed, that is, entries are not added to the routing cache. The answer to the question of how the ignore-df flag and adding entries to the routing cache is connected, I have not found. On the one hand, the routing cache has not been supported in linux for a long time, and there should not be such entries. On the other hand, when some services are started, they request the routing table via netlink and the kernel responds by sending not only the entries of the main routing table, but also the routing cache. As a result, incorrect routing entries with 0.0.0.0 nexthop address appear in the peer list of these services. Of course, it's not difficult to fix it in the services themselves, but it seems to me that this will be a correction of the consequences of the problem, and not the cause itself. It seems to me that this is the wrong behavior. Might you answer the questions: 1. How the ignore-df flag and adding entries to the routing cache is connected? In which kernel files may I look to find this connection? 2. Is this behavior wrong? 3. Is there any way to completely disable the use of the routing cache? (as far as I understand, it used to be possible to set the rhash_entries parameter to 0, but now there is no such parameter) 4. Why is an entry added to the routing cache if a suitable entry was eventually found in the arp table (it is added directly, without being temporarily added to the routing table)? Regards, Aleksey
Powered by blists - more mailing lists