passt/dhcp.c, branch bug205

treewide: Don't rely on terminator records in ip[46].dns arrays

2026-01-10T18:27:45+00:00

In our arrays of DNS resolvers to pass to the guest we use a blank entry
to indicate the end of the list.  We rely on this when scanning the array,
not having separate bounds checking.  clang-tidy 21.1.7 has fancier
checking for array overruns in loops, but it's not able to reason that
there's always a terminating entry, so complains.

Indeed, it's correct to do so in this case.  Although we allow space in the
arrays for the terminator (size MAXNS + 1), add_dns[46]() check only for
    idx >= ARRAY_SIZE()
before adding an entry.  This allows it to consume the last slot with a
"real" entry, meaning the places where we scan really could overrun.

Fix the bug, and make it easier to reason about (for both clang-tidy and
people) by using ARRAY_SIZE() base bounds checking.  Treat the terminator
explicitly as an early exit case using 'break'.

Signed-off-by: David Gibson 
Reviewed-by: Laurent Vivier 
[sbrivio: Fix up comments to @dns in structs ip4_ctx and ip6_ctx]
Signed-off-by: Stefano Brivio

dhcp: Fix coding style violations in dhcp() function

2025-09-18T15:11:36+00:00

The dhcp() function wasn't following the inverted Christmas tree
variable declaration ordering convention.

Signed-off-by: Laurent Vivier 
Reviewed-by: David Gibson 
Signed-off-by: Stefano Brivio

dhcp: use iov_tail rather than pool

2025-09-03T18:43:39+00:00

This patch refactors the dhcp() function to accept `struct iov_tail *data`
directly as its packet input, replacing the previous `const struct pool *p`
parameter. Consequently, dhcp() no longer fetches packet data internally
using packet_data().

This change simplifies callers, such as tap4_handler(), which now pass
the iov_tail representing the L2 frame directly to dhcp(). This removes
the need for intermediate packet pool handling for DHCP processing.

Signed-off-by: Laurent Vivier 
Reviewed-by: David Gibson 
Signed-off-by: Stefano Brivio

packet: rename packet_data() to packet_get()

2025-09-03T18:43:35+00:00

As we have removed packet_get(), we can rename packet_data() to packet_get()
as the name is clearer.

Signed-off-by: Laurent Vivier 
Reviewed-by: David Gibson 
Signed-off-by: Stefano Brivio

dhcp: Convert to iov_tail

2025-09-03T18:43:28+00:00

Use packet_data() and extract headers using IOV_REMOVE_HEADER()
and IOV_PEEK_HEADER() rather than packet_get().

Signed-off-by: Laurent Vivier 
Reviewed-by: David Gibson 
Signed-off-by: Stefano Brivio

dhcp: Add option code byte in calculation for OPT_MAX boundary check

2025-02-19T22:33:19+00:00

Otherwise we'll limit messages to 577 bytes, instead of 576 bytes as
intended:

  $ fqdn="thirtytwocharactersforeachlabel.thirtytwocharactersforeachlabel.thirtytwocharactersforeachlabel.thirtytwocharactersforeachlabel.thirtytwocharactersforeachlabel.thirtytwocharactersforeachlabel.thirtytwocharactersforeachlabel.then_make_it_251_with_this"
  $ hostname="__eighteen_bytes__"
  $ ./pasta --fqdn ${fqdn} -H ${hostname} -p dhcp.pcap -- /sbin/dhclient -4
  Saving packet capture to dhcp.pcap
  $ tshark -r dhcp.pcap -V -Y 'dhcp.option.value == 5' | grep "Total Length"
      Total Length: 577

This was hidden by the issue fixed by commit bcc4908c2b4a ("dhcp
Remove option 255 length byte") until now.

Fixes: 31e8109a86ee ("dhcp, dhcpv6: Add hostname and client fqdn ops")
Reviewed-by: David Gibson 
Reviewed-by: Enrique Llorente 
Signed-off-by: Stefano Brivio

conf: Use 0 instead of -1 as "unassigned" mtu value

2025-02-19T05:35:41+00:00

On the command line -m 0 means "don't assign an MTU" (letting the guest use
its default.  However, internally we use (c->mtu == -1) to represent that
state.  We use (c->mtu == 0) to represent "the user didn't specify on the
command line, so use the default" - but this is only used during conf(),
never afterwards.

This is unnecessarily confusing.  We can instead just initialise c->mtu to
its default (65520) before parsing options and use 0 on both the command
line and internally to represent the "don't assign" special case.  This
ensures that c->mtu is always 0..65535, so we can store it in a uint16_t
which is more natural.

Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio

dhcp: Remove option 255 length byte

2025-02-18T07:42:35+00:00

The option 255 (end of options) do not need the length byte, this change
remove that allowing to have one extra byte at other dynamic options.

Signed-off-by: Enrique Llorente 
Reviewed-by: David Gibson 
Signed-off-by: Stefano Brivio

dhcp, dhcpv6: Add hostname and client fqdn ops

2025-02-10T17:30:24+00:00

Both DHCPv4 and DHCPv6 has the capability to pass the hostname to
clients, the DHCPv4 uses option 12 (hostname) while the DHCPv6 uses option 39
(client fqdn), for some virt deployments like kubevirt is expected to
have the VirtualMachine name as the guest hostname.

This change add the following arguments:
 - -H --hostname NAME to configure the hostname DHCPv4 option(12)
 - --fqdn NAME to configure client fqdn option for both DHCPv4(81) and
   DHCPv6(39)

Signed-off-by: Enrique Llorente 
Signed-off-by: Stefano Brivio

dhcp: Don't re-use request message for reply

2025-02-07T09:36:10+00:00

The logic composing the DHCP reply message is reusing the request
message to compose it, future long options like FQDN may
exceed the request message limit making it go beyond the lower
bound.

This change creates a new reply message with a fixed options size of 308
and fills it in with proper fields from requests adding on top the generated
options, this way the reply lower bound does not depend on the request.

Signed-off-by: Enrique Llorente 
Signed-off-by: Stefano Brivio