elapsed-time attribute in DHCPv6 SOLICIT

[aleheux-tc]

Describe the bug

Not entirely sure if this is a bug or me being a n00b:

While testing our DHCPv6 server's fail-over abilities I noticed that the elapsed-time attribute remains 0.
In this scenario the DHCPv6 server is not actually responding to any requests so bngblaster will keep trying to send SOLICITs every 5 seconds.

The transaction-id attribute remains constant and rfc8415 says:

  elapsed-time         The amount of time since the client began its
                       current DHCP transaction.  This time is
                       expressed in hundredths of a second
                       (10^-2 seconds).  A 2-octet field containing
                       an unsigned integer.

Which suggests to me that it should increase.

Version (bngblaster -v):

bngblaster -v

Version: 0.9.5
Compiler: GNU (9.4.0)
IO Modes: packet_mmap_raw (default), packet_mmap, raw

JSON configuration:

{
}

Steps to reproduce the behavior:

1. turn off DHCP server
2. start bngblaster
3. observe DHCP requests with tcpdump or wireshark

Expected behavior

I expect the elapsed-time attribute to increase (which in this case signals to the standby DHCP server that something's amiss)

Screenshots

If applicable, add screenshots to help explain your problem.

Additional context

Add any other context about the problem here.

[GIC-de]

The elapsed time is currently not incrementing, but let me see if this can be done quickly.

[aleheux-tc]

A bit more background on why the elapsed time attribute is useful:

From the Kea DHCP manual:

max-ack-delay - is one of the parameters controlling partner failure-detection. When communication with the partner is interrupted, the server examines the values of the secs field (DHCPv4) or Elapsed Time option (DHCPv6), which denote how long the DHCP client has been trying to communicate with the DHCP server. This parameter specifies the maximum time in milliseconds for the client to try to communicate with the DHCP server, after which this server assumes that the client failed to communicate with the DHCP server (is “unacked”). The default value of this parameter is 10000.

max-unacked-clients - specifies how many “unacked” clients are allowed (see max-ack-delay) before this server assumes that the partner is offline and transitions to the partner-down state. The special value of 0 is allowed for this parameter, which disables the failure-detection mechanism. In this case, a server that can’t communicate with its partner over the control channel assumes that the partner server is down and transitions to the partner-down state immediately. The default value of this parameter is 10.

When the "elapsed time" is always 0 the max-unacked-clients will always remain zero.

[GIC-de]

Could you try with latest dev branch (see b427699)!

[aleheux-tc]

I compiled the dev branch but it dump core :(

core._home_spoc_bngblaster_build_code_bngblaster_bngblaster.0.2e6a0c06-667e-4caf-9846-128e01be95bb.2989050.8723818052.zip

[GIC-de]

There was a regression from a ISIS change, please try again.

[aleheux-tc]

Perfect! Elapsed time Option: Elapsed time (8) Length: 2 Elapsed time: 10560ms Thank you for the quick action! Best regards, Alex Le Heux Network Architect Tucows Inc / Ting Fiber ***@***.***

…

On 4 Sep 2024, at 17:00, Christian Giese ***@***.***> wrote: There was a regression from a ISIS change, please try again. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[GIC-de]

Thanks for conformation, fix will be included in next release planned for today or latest tomorrow.