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:   Thu, 5 Jul 2018 23:38:35 +0800
From:   Xin Long <lucien.xin@...il.com>
To:     Ido Schimmel <idosch@...sch.org>
Cc:     David Ahern <dsahern@...il.com>,
        network dev <netdev@...r.kernel.org>,
        davem <davem@...emloft.net>, Davide Caratti <dcaratti@...hat.com>
Subject: Re: [PATCHv2 net-next 2/2] selftests: add a selftest for directed
 broadcast forwarding

On Thu, Jul 5, 2018 at 4:21 PM, Xin Long <lucien.xin@...il.com> wrote:
> On Thu, Jul 5, 2018 at 4:39 AM, Ido Schimmel <idosch@...sch.org> wrote:
>> On Thu, Jul 05, 2018 at 01:56:23AM +0800, Xin Long wrote:
>>> On Wed, Jul 4, 2018 at 3:23 AM, David Ahern <dsahern@...il.com> wrote:
>>> > your commands are not a proper test. The test should succeed and fail
>>> > based on the routing lookup, not iptables rules.
>>> A proper test can be done easily with netns, as vrf can't isolate much.
>>> I don't want to bother forwarding/ directory with netns, so I will probably
>>> just drop this selftest, and let the feature patch go first.
>>>
>>> What do you think?
>>
>> You can add a tc rule on the ingress of h2 and make sure that in the
>> first case ping succeeds and the tc rule wasn't hit. In the second case
>> ping should also succeed, but the tc rule should be hit. This is similar
>> to your original netns test.
> With netns, it will be much easier to use
> sysctl net.ipv4.icmp_echo_ignore_broadcasts
> to block the echo_request on r1 or h2, and check if ping works.
> (this's more like the idea of using 'iptables' above) :D
>
>>
>> You can look at tc_flower.sh for reference and in particular at
>> tc_check_packets().
Just noticed this doesn't require reply with MZ. that's better.
Thanks.

> This is a way similar idea of using tcpdump, I just feel it's too much,
> this test should be an as simple test as route.sh. :)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ