netdev - Re: [Patch net v3 2/2] selftests: add a test case for rp

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]

Message-ID: <50364490-9e86-a26e-3a56-78459b3b5151@gmail.com>
Date:   Mon, 15 Nov 2021 09:06:50 -0700
From:   David Ahern <dsahern@...il.com>
To:     Cong Wang <xiyou.wangcong@...il.com>,
        Hangbin Liu <liuhangbin@...il.com>
Cc:     Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: [Patch net v3 2/2] selftests: add a test case for rp_filter

On 11/14/21 10:08 PM, Cong Wang wrote:
> On Wed, Nov 10, 2021 at 1:18 AM Hangbin Liu <liuhangbin@...il.com> wrote:
>>
>> On Wed, Jul 17, 2019 at 02:41:59PM -0700, Cong Wang wrote:
>>> Add a test case to simulate the loopback packet case fixed
>>> in the previous patch.
>>>
>>> This test gets passed after the fix:
>>>
>>> IPv4 rp_filter tests
>>>     TEST: rp_filter passes local packets                                [ OK ]
>>>     TEST: rp_filter passes loopback packets                             [ OK ]
>>
>> Hi Wang Cong,
>>
>> Have you tried this test recently? I got this test failed for a long time.
>> Do you have any idea?
>>
>> IPv4 rp_filter tests
>>     TEST: rp_filter passes local packets                                [FAIL]
>>     TEST: rp_filter passes loopback packets                             [FAIL]
> 
> Hm, I think another one also reported this before, IIRC, it is
> related to ping version or cmd option. Please look into this if
> you can, otherwise I will see if I can reproduce this on my side.
> 

The test does 'ping -I dummy1'. As I recall newer version of ping uses
SO_BINDTODEVICE vs cmsg to specify the device binding. The setsockopt is
stronger and I bet the socket lookup is failing. If that is the case,
the test needs to be fixed because it will never pass again.