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: <4577a5aa-0d95-accd-f581-e1f25b0fcd68@ziu.info> Date: Thu, 9 May 2019 18:17:48 +0200 From: Michal Soltys <soltys@....info> To: linux-netdev <netdev@...r.kernel.org> Subject: [question] rp_filter=1 ~implies arp_filter Hi, This got me a bit surprised actually and I'm wondering if it's intended. While both options are somewhat similar in their function, they do different things after all (and for different protocols): - arp_filter - whether all interfaces should consider responding for arp request (which then can be further tuned by arp_ignore whether they actually should reply) - rp_filter (=1) - will discard ip packets incoming on interface that is not considered the best But it seems rp_filter (=1) also either nukes arp or inhibits arp reply. For example: ::In 1st namespace: a2 inet 192.168.77.88/24 scope global a2 b2 inet 192.168.77.89/24 scope global b2 192.168.77.0/24 dev b2 proto kernel scope link src 192.168.77.89 192.168.77.0/24 dev a2 proto kernel scope link src 192.168.77.88 metric 20 So 77.89 is "better" in route context. rp_filter=1 arp_filter=0 arp_ignore=1 ::In 2nd namespace: a1 and b1 enslaved to bridge brX with address 192.168.77.77/24 In such scenario, doing from this namespace: arping -b -I brX 192.168.77.89 - works as expected with replies from 192.168.77.89's interface arping -b -I brX 192.168.77.88 - nothing Setting arp_ignore=0 (in 1st namespace) would (as expected) give replies in both cases from 192.168.77.89's interface only.
Powered by blists - more mailing lists