Date: Tue, 23 Apr 2024 09:50:33 -0500 From: Matthew Grooms <mgrooms@shrew.net> To: stable@freebsd.org Subject: Re: possible regression handling packet fragmentation in 14.0 with tftp/pxe Message-ID: <922446cd-4511-4132-8e8f-9c9144a7f9b1@shrew.net> In-Reply-To: <20240423071923.52b90652@arc.aei.uni-hannover.de> References: <20240419153951.5a23ce5f@arc.aei.uni-hannover.de> <86y1999wwe.fsf@ltc.des.dev> <20240422075948.5bb856ac@arc.aei.uni-hannover.de> <86o7a18ppl.fsf@ltc.des.dev> <20240423071923.52b90652@arc.aei.uni-hannover.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Sorry. I didn't missed some of the previous details here, but I see you mention pf below. Did you happen to see this? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276856 -Matthew On 4/23/24 00:19, Gerrit Kühn wrote: > Am Mon, 22 Apr 2024 15:57:42 +0200 > schrieb Dag-Erling Smørgrav <des@FreeBSD.org>: > >> 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. > So maybe this is rather a red herring than a pointer to the actual > difference in packet handling. > >> There were changes in tftpd, but I don't know if that's relevant. > Most certainly not as I didn't touch the server side. The tftpd there is > certainly old, but it worked fine up to FreeBSD 13.3 on the router. It is > the update to 14.0 that triggered the problem. > > > cu > Gerrit
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?922446cd-4511-4132-8e8f-9c9144a7f9b1>