Kernel/iwd
3
0
Fork 0
mirror of https://git.kernel.org/pub/scm/network/wireless/iwd.git synced 2024-11-22 14:49:24 +01:00
Code Releases Activity
a2b2f66c4c
iwd/autotests/testNetconfig/dhcpd.conf

26 lines
1.0 KiB
ISCdhcpd
Raw Normal View History

autotests: DHCPv4 renewal/resend test in testNetconfig Test that the DHCPv4 lease got renewed after the T1 timer runs out. Then also simulate the DHCPREQUEST during renew being lost and retransmitted and the lease eventually getting renewed T1 + 60s later. The main downside is that this test will inevitably take a while if running in Qemu without the time travel ability. Update the test and some utility code to run hostapd in an isolated net namespace for connection_test.py. We now need a second hostapd instance though because in static_test.py we test ACD and we need to produce an IP conflict. Moving the hostapd instance unexpectedly fixes dhcpd's internal mechanism to avoid IP conflicts and it would no longer assign 192.168.1.10 to the second client, it'd notice that address was already in use and assign the next free address, or fail if there was none. So add a second hostapd instance that runs in the main namespace together with the statically-configured client, it turns out the test relies on the kernel being unable to deliver IP traffic to interfaces on the same system.
2022-07-09 02:23:32 +02:00
default-lease-time 120; # 2 minutes
min-lease-time 120; # 2 minutes
max-lease-time 120; # 2 minutes
option dhcp-renewal-time 15; # 15 secs for T1
# We set a relatively low lease lifetime of 2 minutes but our renewal interval
# (T1) is still unproportionally low to speed the test up -- 12% instead of the
# default 50% lifetime value. We need a lifetime in the order of minutes
# because minimum lease renewal retry interval is 60s per spec. However by
# default dhcpd will not renew leases that are newer than 25% their lifetime.
# Set that threshold to 1% so that we can verify that the lease is renewed
# without waiting too long.
dhcp-cache-threshold 1;
auto-t: add netconfig autotest Tests that DHCP using IWD's internal netconfig functions properly. The actual IP address assignment is not verified, but since IWD does not signal the connection as successful unless DHCP succeeds we can assume it was successful by checking that the device is connected. The process of actually starting dhcpd and configuring the interfaces is quite simple so it was left in the autotest itself. If (or when) more tests require IP capabilities (p2p, FILS, etc) this could be moved into test-runner itself and be made common. The reason I did not put it in there now is a) because this is the only test and b) more complex DHCP cases are likely to develop and may require more than this simplistic setup (like multiple APs/interfaces)
2020-09-16 02:00:22 +02:00
auto-t: Validate netmasks in testNetconfig, add utility Extend test_ip_address_match to support IPv6 and to test the netmask/prefix length while it reads the local address since those are retrieved using the same API. Modify testNetconfig to validate the prefix lengths, change the prefix lengths to be less common values (not 24 bits for IPv4 or 64 for IPv6), minor cleanup.
2022-06-16 02:02:24 +02:00
option broadcast-address 192.168.127.255;
auto-t: add netconfig autotest Tests that DHCP using IWD's internal netconfig functions properly. The actual IP address assignment is not verified, but since IWD does not signal the connection as successful unless DHCP succeeds we can assume it was successful by checking that the device is connected. The process of actually starting dhcpd and configuring the interfaces is quite simple so it was left in the autotest itself. If (or when) more tests require IP capabilities (p2p, FILS, etc) this could be moved into test-runner itself and be made common. The reason I did not put it in there now is a) because this is the only test and b) more complex DHCP cases are likely to develop and may require more than this simplistic setup (like multiple APs/interfaces)
2020-09-16 02:00:22 +02:00
option routers 192.168.1.254;
auto-t: Validate netmasks in testNetconfig, add utility Extend test_ip_address_match to support IPv6 and to test the netmask/prefix length while it reads the local address since those are retrieved using the same API. Modify testNetconfig to validate the prefix lengths, change the prefix lengths to be less common values (not 24 bits for IPv4 or 64 for IPv6), minor cleanup.
2022-06-16 02:02:24 +02:00
option subnet-mask 255.255.128.0;
auto-t: add netconfig autotest Tests that DHCP using IWD's internal netconfig functions properly. The actual IP address assignment is not verified, but since IWD does not signal the connection as successful unless DHCP succeeds we can assume it was successful by checking that the device is connected. The process of actually starting dhcpd and configuring the interfaces is quite simple so it was left in the autotest itself. If (or when) more tests require IP capabilities (p2p, FILS, etc) this could be moved into test-runner itself and be made common. The reason I did not put it in there now is a) because this is the only test and b) more complex DHCP cases are likely to develop and may require more than this simplistic setup (like multiple APs/interfaces)
2020-09-16 02:00:22 +02:00
auto-t: Validate netmasks in testNetconfig, add utility Extend test_ip_address_match to support IPv6 and to test the netmask/prefix length while it reads the local address since those are retrieved using the same API. Modify testNetconfig to validate the prefix lengths, change the prefix lengths to be less common values (not 24 bits for IPv4 or 64 for IPv6), minor cleanup.
2022-06-16 02:02:24 +02:00
subnet 192.168.0.0 netmask 255.255.128.0
auto-t: add netconfig autotest Tests that DHCP using IWD's internal netconfig functions properly. The actual IP address assignment is not verified, but since IWD does not signal the connection as successful unless DHCP succeeds we can assume it was successful by checking that the device is connected. The process of actually starting dhcpd and configuring the interfaces is quite simple so it was left in the autotest itself. If (or when) more tests require IP capabilities (p2p, FILS, etc) this could be moved into test-runner itself and be made common. The reason I did not put it in there now is a) because this is the only test and b) more complex DHCP cases are likely to develop and may require more than this simplistic setup (like multiple APs/interfaces)
2020-09-16 02:00:22 +02:00
{
option routers 192.168.1.1;
auto-t: Validate netmasks in testNetconfig, add utility Extend test_ip_address_match to support IPv6 and to test the netmask/prefix length while it reads the local address since those are retrieved using the same API. Modify testNetconfig to validate the prefix lengths, change the prefix lengths to be less common values (not 24 bits for IPv4 or 64 for IPv6), minor cleanup.
2022-06-16 02:02:24 +02:00
option subnet-mask 255.255.128.0;
auto-t: Verify DNS entries added from DHCP/static Add a fake resolvconf executable to verify that the right nameserver addresses were actually committed by iwd. Again use unique nameserver addresses to reduce the possibility that the test succeeds by pure luck.
2022-06-16 02:02:28 +02:00
option domain-name-servers 192.168.1.2;
auto-t: add netconfig autotest Tests that DHCP using IWD's internal netconfig functions properly. The actual IP address assignment is not verified, but since IWD does not signal the connection as successful unless DHCP succeeds we can assume it was successful by checking that the device is connected. The process of actually starting dhcpd and configuring the interfaces is quite simple so it was left in the autotest itself. If (or when) more tests require IP capabilities (p2p, FILS, etc) this could be moved into test-runner itself and be made common. The reason I did not put it in there now is a) because this is the only test and b) more complex DHCP cases are likely to develop and may require more than this simplistic setup (like multiple APs/interfaces)
2020-09-16 02:00:22 +02:00
range 192.168.1.10 192.168.1.20;
range 192.168.1.100 192.168.1.200;
}
Copy Permalink