Problem: 017-dhcpv4-force-option.t intermittently fails with a bare [2] on
the two probes that follow the Force=0 write, while the Force=1 probe just
before them passes.
Writing a Device.DHCPv4.Server. parameter makes dhcpv4-manager rewrite the
dnsmasq configuration and restart dnsmasq. The test only waited one second
afterwards and dhcpv4_option_probe.py sent its DHCPDISCOVER exactly once,
so a request issued during that restart window was lost and the probe gave
up after the timeout instead of reporting the option state under test.
The reason was invisible: all five probe error paths wrote to stderr, which
the test discards with 2>/dev/null, so every one of them looked identical in
the .t.err artifact.
Solution:
- retransmit an unanswered DHCPDISCOVER/DHCPREQUEST, --retries (default 2)
- print the ERROR line on stdout so it stays visible in the Cram diff
- release the lease on the last probe so no lease is left behind
A passing run is unaffected: retransmission stops as soon as the reply
arrives and nothing is written to stderr on success.
References: PPW-2188
Signed-off-by: Alexandre Fiset <alexandre.fiset@softathome.com>
Add two dhcpv4 client tests. first one check if option provided by a
client is correctly provided in the DHCPv4.Server DM. Second one check
that if multiple client provide the same option with different value,
the value are not mixed up.
References: PCF-2262
Signed-off-by: Alexandre Fiset <alexandre.fiset@softathome.com>
