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:
parent
e932480683
commit
0db0e27c05
@ -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
|
||||
|
||||
Loading…
Reference in New Issue
Block a user