netdev - Re: [PATCH net 1/2] ipv6: Fix route replacement with dev-only route

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] [day] [month] [year] [list]

Message-ID: <CAM_iQpXY0L-ghJaHbLwAupMCiQzyEVe9XLJcWd4umm7sxBbftw@mail.gmail.com>
Date:   Wed, 19 Feb 2020 19:20:42 -0800
From:   Cong Wang <xiyou.wangcong@...il.com>
To:     Benjamin Poirier <bpoirier@...ulusnetworks.com>
Cc:     David Ahern <dsahern@...il.com>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        Michal Kubeček <mkubecek@...e.cz>,
        Nicolas Dichtel <nicolas.dichtel@...nd.com>,
        Ido Schimmel <idosch@...sch.org>
Subject: Re: [PATCH net 1/2] ipv6: Fix route replacement with dev-only route

On Sun, Feb 16, 2020 at 7:12 PM Benjamin Poirier
<bpoirier@...ulusnetworks.com> wrote:
>
> On 2020/02/15 11:00 -0700, David Ahern wrote:
> [...]
> >
> > Thanks for adding a test case. I take this to mean that all existing
> > tests pass with this change. We have found this code to be extremely
> > sensitive to seemingly obvious changes.
>
> I saw two failures from that test suite, regardless of this change:
>
> IPv4 rp_filter tests
>     TEST: rp_filter passes local packets                                [FAIL]
>     TEST: rp_filter passes loopback packets                             [FAIL]
>
> The other tests, including the ipv6_rt group of tests, are OK.
>
>
> The rp_filter tests fail for me even if I build a kernel from commit
> adb701d6cfa4 ("selftests: add a test case for rp_filter")
>
> Running the first ping manually, tcpdump shows:
> root@...d:~# tcpdump -nepi lo
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
> 12:01:12.618623 52:54:00:6a:c7:5e > 52:54:00:6a:c7:5e, ethertype IPv4 (0x0800), length 98: 198.51.100.1 > 198.51.100.1: ICMP echo request, id 616, seq 435, length 64
> 12:01:12.618650 52:54:00:6a:c7:5e > 52:54:00:6a:c7:5e, ethertype IPv4 (0x0800), length 98: 198.51.100.1 > 198.51.100.1: ICMP echo reply, id 616, seq 435, length 64
>
> `ping` doesn't show any replies (since it's bound to dummy1...?).

I suspect this is related to the version of ping, as it works perfectly
for me on an old Fedora:

IPv4 rp_filter tests
ping: Warning: source address might be selected on device other than dummy1.
PING 198.51.100.1 (198.51.100.1) from 198.51.100.1 dummy1: 56(84) bytes of data.
64 bytes from 198.51.100.1: icmp_seq=1 ttl=64 time=0.452 ms
64 bytes from 198.51.100.1: icmp_seq=2 ttl=64 time=0.418 ms
64 bytes from 198.51.100.1: icmp_seq=3 ttl=64 time=0.485 ms
64 bytes from 198.51.100.1: icmp_seq=4 ttl=64 time=0.446 ms
64 bytes from 198.51.100.1: icmp_seq=5 ttl=64 time=0.388 ms
64 bytes from 198.51.100.1: icmp_seq=6 ttl=64 time=0.362 ms
64 bytes from 198.51.100.1: icmp_seq=7 ttl=64 time=0.373 ms
64 bytes from 198.51.100.1: icmp_seq=8 ttl=64 time=0.515 ms
64 bytes from 198.51.100.1: icmp_seq=9 ttl=64 time=0.641 ms

--- 198.51.100.1 ping statistics ---
9 packets transmitted, 9 received, 0% packet loss, time 8012ms
rtt min/avg/max/mdev = 0.362/0.453/0.641/0.083 ms
    TEST: rp_filter passes local packets                                [ OK ]


I do see the same failure on a new Fedora. So, I will take a look
at this tomorrow.

Thanks!