Kernel/iwd
3
0
Fork 0
mirror of https://git.kernel.org/pub/scm/network/wireless/iwd.git synced 2024-11-06 12:09:23 +01:00
Code Releases Activity
da8a87fcf5
iwd/autotests/testNetconfig/dhcpd.conf

16 lines
423 B
ISCdhcpd
Raw Normal View History

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
default-lease-time 600; # 10 minutes
max-lease-time 7200; # 2 hours
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