cram: fix flaky dhcpv4client stats test due to race condition

Calling Stats.Reset() clears the counters, but an active DHCP client
can immediately transmit a new DISCOVER packet before the test dumps
the stats. This race condition caused the Discover=0 assertion to
fail sporadically (observing 1 instead).

This commit fixes the flakiness by quiescing the DHCP client:
- Disable the client (Enable=0) before resetting stats.
- Perform the stats reset and verify they are 0.
- Re-enable the client (Enable=1) to restore state.

References: PPW-1593
Signed-off-by: Ruslana Popovych <ruslana.popovych@globallogic.com>
This commit is contained in:
Ruslana Popovych 2026-03-04 17:22:41 +02:00 committed by ahmed sassi
parent e932480683
commit 0db0e27c05

View File

@ -2,7 +2,18 @@ Create R alias:
$ alias R="${CRAM_REMOTE_COMMAND:-}"
Disable Device.DHCPv4.Client.1.:
$ R ba-cli 'Device.DHCPv4.Client.1.Enable=0' | grep -Ev '^>|^$'
Device.DHCPv4.Client.1.
Device.DHCPv4.Client.1.Enable=0
Wait 5 seconds to ensure the DHCP client is fully disabled:
$ sleep 5
Reset Stats:
$ R "ba-cli 'Device.DHCPv4.Client.1.Stats.Reset()' | grep -Ev '^>|^$'"
Device.DHCPv4.Client.1.Stats.Reset() returned
[
@ -25,3 +36,9 @@ Dump Stats object:
.R....V. <public> uint32 Device.DHCPv4.Client.1.Stats.ForceRenew=0
.R....V. <public> uint32 Device.DHCPv4.Client.1.Stats.ACK=0
.R....V. <public> uint32 Device.DHCPv4.Client.1.Stats.Discover=0
Enable Device.DHCPv4.Client.1.:
$ R "ba-cli 'Device.DHCPv4.Client.1.Enable=1' | grep -Ev '^>|^$'"
Device.DHCPv4.Client.1.
Device.DHCPv4.Client.1.Enable=1