Date: Mon, 22 Apr 2024 15:57:42 +0200 From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@FreeBSD.org> To: Gerrit =?utf-8?Q?K=C3=BChn?= <gerrit.kuehn@aei.mpg.de> Cc: freebsd-stable@freebsd.org Subject: Re: possible regression handling packet fragmentation in 14.0 with tftp/pxe Message-ID: <86o7a18ppl.fsf@ltc.des.dev> In-Reply-To: <20240422075948.5bb856ac@arc.aei.uni-hannover.de> ("Gerrit =?utf-8?Q?K=C3=BChn=22's?= message of "Mon, 22 Apr 2024 07:59:48 %2B0200") References: <20240419153951.5a23ce5f@arc.aei.uni-hannover.de> <86y1999wwe.fsf@ltc.des.dev> <20240422075948.5bb856ac@arc.aei.uni-hannover.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Gerrit K=C3=BChn <gerrit.kuehn@aei.mpg.de> writes: > 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 --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86o7a18ppl.fsf>