Skip site navigation (1)Skip section navigation (2)
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>