[1/3] autotests: Fix testNetconfig ACD test

Commit Message

Andrew Zaborowski Aug. 23, 2022, 4:36 p.m. UTC

Part of static_test.py starts a second IWD instance and tries to make
it connect to the AP with the same IP address as the first IWD instance
which is already connected, to produce an IP conflict.  For this, the
second instance uses DHCP and the test expects the DHCP server to offer
the address 192.168.1.10 to it.  However in the current setup the DHCP
server manages to detect that 192.168.1.10 is in use and offers .11
instead.  Break the DHCP server's conflict detection by disabling ICMP
ping replies in order to fix the test.

Previously this has worked because the AP's and the DHCP server's
network interface is in the same network namespace as the first IWD
instance's network interface meaning that pings between the two
interfaces shouldn't work (a known Linux kernel routing quirk...).
I am not sure why those pings currently do work but take no chances and
disable ICMP pings.
---
 autotests/testNetconfig/static_test.py | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

Comments

Denis Kenzior Aug. 23, 2022, 8:47 p.m. UTC | #1

Hi Andrew,

On 8/23/22 11:36, Andrew Zaborowski wrote:
> Part of static_test.py starts a second IWD instance and tries to make
> it connect to the AP with the same IP address as the first IWD instance
> which is already connected, to produce an IP conflict.  For this, the
> second instance uses DHCP and the test expects the DHCP server to offer
> the address 192.168.1.10 to it.  However in the current setup the DHCP
> server manages to detect that 192.168.1.10 is in use and offers .11
> instead.  Break the DHCP server's conflict detection by disabling ICMP
> ping replies in order to fix the test.
> 
> Previously this has worked because the AP's and the DHCP server's
> network interface is in the same network namespace as the first IWD
> instance's network interface meaning that pings between the two
> interfaces shouldn't work (a known Linux kernel routing quirk...).
> I am not sure why those pings currently do work but take no chances and
> disable ICMP pings.
> ---
>   autotests/testNetconfig/static_test.py | 15 ++++++++++-----
>   1 file changed, 10 insertions(+), 5 deletions(-)
> 

All applied, thanks.

Regards,
-Denis

Patch

diff --git a/autotests/testNetconfig/static_test.py b/autotests/testNetconfig/static_test.py
index 01d694ca..4ce279f2 100644
--- a/autotests/testNetconfig/static_test.py
+++ b/autotests/testNetconfig/static_test.py
@@ -85,11 +85,16 @@  class Test(unittest.TestCase):
         condition = 'not obj.connected'
         wd_ns0.wait_for_object_condition(ordered_network.network_object, condition)
 
-        # Connect to the same network from a dynamically configured client.  The
-        # DHCP server doesn't know (even though dev1 announced itself) that
-        # 192.168.1.10 is already in use and if it assigns dev2 the lowest
-        # available address, that's going to be 192.168.1.10.  dev1's ACD
-        # implementation should then stop using this address.
+        # Connect to the same network from a dynamically configured client.  We
+        # block ICMP pings so that the DHCP server can't confirm that
+        # 192.168.1.10 is in use by dev1 and if it assigns dev2 the lowest
+        # available address, that's going to be 192.168.1.10.  We also keep the
+        # second client's netdev in a separate namespace so that the kernel
+        # lets us assign the same IP.  dev1's ACD implementation should then
+        # stop using this address.  Yes, a quite unrealistic scenario but this
+        # lets us test our reaction to a conflict appearing after successful
+        # initial setup.
+        os.system("echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all")
         ordered_network.network_object.connect()
 
         condition = 'obj.state == DeviceState.connected'