possible regression handling packet fragmentation in 14.0 with tftp/pxe

[Dag-Erling Smørgrav]

192.168.130.3 is the diskless client trying to boot (Linux)
192.168.130.253 is the server for nfsroot and tftp (FreeBSD)
192.168.130.254 is the router and dhcp-server (FreeBSD 13.3/14.0)
[...]
But this suspiciously looked like MTU problems. The VPN only offers an MTU
of 1425 by default, while tftp appears to use 1460. After some
searching and reading I found that the original tftp default was 512 byte
packets, and the client obviously requests larger packets for speed
reasons explicitely with the "blksize 1456" command. Unfortunately, I found
no way to configure the PXE firmware to use smaller packets.
However, adding the "-o" option to FreeBSD's tftpd could disable all extra
options and forced both the server and the client to user smaller packets.
TFTP and PXE-booting were working fine again after that change.

Since you control the routers and endpoints, I would suggest running
tcpdump at various points to see what is the tunnel and pf are doing to
the UDP packets. They are presumably getting fragmented at some point,
and hopefully reassembled somewhere else.

Meanwhile you can also set the net.inet.udp.maxdgram sysctl to 1425 on
the NFS server, as tftpd will cap the blocksize to that value.

DES

[Dag-Erling Smørgrav]

Any idea what the "bad length 1460 > 1392" message on the 13.3 system
means (and why everything is still working)?

Off the top of my head, it means the packet length according to its
header is longer than the capture length but the MF flag is not set.
Historically, it meant you needed to increase tcpdump's snaplen, but
these days it defaults to 256 kB so it shouldn't matter. It might be a
bug in bpf, or an interaction between pf and bpf.

As this appears to be different behaviour on 13.3 and 14.0, I had hoped
this might already be sufficient to ring a bell for someone here reading
this (like "oh, yes, there were changes in pf that cause different
handling of fragmented udp packets").

There were changes in tftpd, but I don't know if that's relevant.

DES

[Dag-Erling Smørgrav]

Is there an easy way to find out where this commit ends up, i.e., whether
it is merged into 14.0, 14.1 or so?

I will make sure it gets into 14.1.

DES