netdev - Re: [PATCH net-next 2/2] selftest: net: add icmp reply address test

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: <d07ad847-634f-fcd3-6b8a-77ca29c622d0@gmail.com>
Date:   Sun, 3 Nov 2019 09:52:21 -0700
From:   David Ahern <dsahern@...il.com>
To:     Francesco Ruggeri <fruggeri@...sta.com>
Cc:     David Miller <davem@...emloft.net>, shuah@...nel.org,
        netdev <netdev@...r.kernel.org>, linux-kselftest@...r.kernel.org
Subject: Re: [PATCH net-next 2/2] selftest: net: add icmp reply address test

On 11/2/19 4:08 PM, Francesco Ruggeri wrote:
>>>> I apologize in advance  for being slow ...
>>>> I have 3 namespaces that have to share the same LAN, I am not trying
>>>> 1-1 connections among those namespaces.
>>>>
>>>
>>> How would you cable this if it were an actual network with physical nodes?
>>> - bridge on R1 (since it is the gw for H1), with connections to R2 and
>>> H1 into the bridge
>>> - second connection between R1 and R2
>>> - connection between R2 and H2
>>>
>>> For the simulation, network namespaces represent physical nodes, veth
>>> pairs act like a cable between the nodes / namespaces and the bridge
>>> makes the LAN.
> 
> Thanks, I see what you mean now.
> I was assuming a different physical model, with all the namespaces on the LAN
> connected to a hub (simulated by the dummy device). For simulation purposes this
> model seem simpler: there are N interfaces instead of N pairs, and one does not
> have to deal with the bridge end of the pairs.
> Why is the model you described preferable?
> 

The tests are about traceroute in modern networks, not broadcast
domains. As such, it is preferable for these tests to be constructed
similar to other extisting networking tests.