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> |
||
|---|---|---|
| .. | ||
| cram | ||
| README.md | ||
Content
This directory contains tests.
cram
Contains Cram based tests. Cram is a functional testing framework for command line applications. Cram tests look like snippets of interactive shell sessions. Cram runs each command and compares the command output in the test with the command's actual output.
Tests in this directory should be run against device, usually over network via SSH connection.