> On 15. Sep 2025, at 19:16, Karl Denninger <[email protected]> wrote: > > On 9/15/2025 13:00, Michael Tuexen wrote: >>> On 15. Sep 2025, at 14:59, Karl Denninger <[email protected]> wrote: >>> >>> Hmmmmm.... just came in via git pull: >>> commit ffd956a3918cd5e64c8850eb77247428a29f7221 >>> Author: Michael Tuexen <[email protected]> >>> Date: Wed Sep 10 17:13:35 2025 +0200 >>> >>> dhclient: improve UDP checksum handling >>> >>> When sending UDP packets: >>> * compute the checksum in the correct order. This only has an impact >>> if the length of the payload is odd. >>> * don't send packet with a checksum of zero, use 0xffff instead as >>> required. >>> When receiving UDP packets: >>> * don't do any computations when the checksum is zero. >>> * compute the checksum in the correct order. This only has an impact >>> if the length of the payload is odd. >>> * when computing the checksum, store the pseudo header checksum >>> * if the checksum is computed as zero, use 0xffff instead. >>> * also accept packets, when the checksum in the packet is the pseudo >>> header checksum. >>> The last point fixes a problem when the DHCP client runs in a VM, >>> the DHCP server runs on the host serving the VM and the network >>> interface supports transmit checksum offloading. Since dhclient >>> doesn't use UDP sockets but bpf devices to read the packets, the >>> checksum will be incorrect and only contain the checksum of the >>> pseudo header. >>> >>> This could potentially apply to other bpf-using things -- which includes >>> dhcpcd. And you have tso/lro turned on. >>> >> Hi Karl, >> >> this is true. Do we have an dhcpd in-tree? Or are you aware of other in-tree >> programs which use UDP via bpf and not via the socket interface? >> >> Best regards >> Michael > dhclient uses it in base but dhcp6c is, I believe, out of packages/ports (as > is dhcpcd which replaces both dhclient and dhcp6c in terms of functionality.) OK. But this is not something I can easily investigate and possibly fix, since that software is not in the tree I can make changes to. I think fixes to ports should go upstream.
Best regards Michael > One of dhcp6c or dhcpcd is necessary to get a delegation from an ISP; you can > get a SLACC address without either simply by enabling it such as: > ifconfig_mce0_ipv6="inet6 accept_rtadv" > rtsold_enable="YES" > That is sufficient on a client machine if your gateway hands out addresses > based on SLACC, but the gateway then has to get the upstream delegation (and > run rtadvd in order to send the routing data out on the local side so your > SLACC client can pick it up) so unless you have that delegation hard-coded in > your edge device on the outside interface one of the above has to be running > on the gateway, presuming its a FreeBSD gateway of course. > -- > Karl Denninger > [email protected] > The Market Ticker > [S/MIME encrypted email preferred]
