DHCP Tests - DHCP Request After Timeout?

[noursaidi]

I'm encountering with some of my devices (EasyIO), for the multi subnet tests, the successful DHCP requests sometimes comes within a second after the DHCP lease expired (note the final ip notification in logs below. Thus it fails and stops other DHCP tests.

Seems to be the device tries to renew the existing lease before requesting a new IP as there are several DHCP requests and DHCP NAK's in the packet capture.
test_ipaddr.pcap.tar.gz

I'm not sure if the device should fail, or the if the test should allow a minuscule time period after expiration for a device to obtain a new lease after expiration in these tests? @pisuke @frgitdaq ?

2020-10-22 21:31:29,355 INFO    Setting DHCP timeout at 2020-10-22 21:33:29.355170
2020-10-22 21:31:29,356 INFO    Testing dhcp range: {'start': '172.16.0.1', 'end': '172.31.255.254', 'prefix_length': 12}
2020-10-22 21:33:28,767 INFO    ip notification 172.20.74.137
2020-10-22 21:33:30,774 INFO    Setting DHCP timeout at 2020-10-22 21:35:30.774162
2020-10-22 21:33:30,776 INFO    Testing dhcp range: {'start': '10.0.0.1', 'end': '10.255.255.254', 'prefix_length': 8}
2020-10-22 21:35:30,999 ERROR   DHCP times out after 120s lease time
2020-10-22 21:35:31,001 INFO    Running analyze results
2020-10-22 21:35:31,001 INFO    Setting DHCP timeout at 2020-10-22 21:37:31.001899
2020-10-22 21:35:31,853 INFO    ip notification 10.148.46.87
2020-10-22 21:35:34,196 INFO    Module finalizing

[noursaidi]

Seems to be due to a misconfiguration of the DHCP module at my end. I was using the the module config from resource/baseline which appears to not be up to date hence unexpected behavior I encountered.

https://github.com/faucetsdn/daq/blob/37aafa36a4bf92c1204faff4fb44903c8f64328a/resources/setups/baseline/module_config.json

[frgitdaq]

I'm encountering with some of my devices (EasyIO), for the multi subnet tests, the successful DHCP requests sometimes comes within a second after the DHCP lease expired (note the final ip notification in logs below. Thus it fails and stops other DHCP tests.

Seems to be the device tries to renew the existing lease before requesting a new IP as there are several DHCP requests and DHCP NAK's in the packet capture.
test_ipaddr.pcap.tar.gz

I'm not sure if the device should fail, or the if the test should allow a minuscule time period after expiration for a device to obtain a new lease after expiration in these tests? @pisuke @frgitdaq ?

2020-10-22 21:31:29,355 INFO    Setting DHCP timeout at 2020-10-22 21:33:29.355170
2020-10-22 21:31:29,356 INFO    Testing dhcp range: {'start': '172.16.0.1', 'end': '172.31.255.254', 'prefix_length': 12}
2020-10-22 21:33:28,767 INFO    ip notification 172.20.74.137
2020-10-22 21:33:30,774 INFO    Setting DHCP timeout at 2020-10-22 21:35:30.774162
2020-10-22 21:33:30,776 INFO    Testing dhcp range: {'start': '10.0.0.1', 'end': '10.255.255.254', 'prefix_length': 8}
2020-10-22 21:35:30,999 ERROR   DHCP times out after 120s lease time
2020-10-22 21:35:31,001 INFO    Running analyze results
2020-10-22 21:35:31,001 INFO    Setting DHCP timeout at 2020-10-22 21:37:31.001899
2020-10-22 21:35:31,853 INFO    ip notification 10.148.46.87
2020-10-22 21:35:34,196 INFO    Module finalizing

Seems as if the issue is resolved now. Though to answer the extended lease time suggestion, the DHCP specification RFC 2131 at 4.4.5 states that devices should request a DHCP renewal at T1 and T2 which default at 50% and 87.5% of the time of the renewal. With this in mind, a device which does not request until the end of the lease time should probably fail in this instance.