Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 08 Jun 2025 18:16:06 +0000
From:      bugzilla-noreply@freebsd.org
To:        net@FreeBSD.org
Subject:   [Bug 287229] IP reassembly issue in FreeBSD 14.1
Message-ID:  <bug-287229-7501-t2WMNKG6Em@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-287229-7501@https.bugs.freebsd.org/bugzilla/>
References:  <bug-287229-7501@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D287229

--- Comment #5 from Michael Tuexen <tuexen@freebsd.org> ---
I looked at the code and I think there are not much differences between 14.1
and CURRENT, at least for the IPv4 case, which I am focussing on. The
reassembly algorithm is also deterministic and therefore looking into cases
where you describe it as un-deterministic is interesting.
But to be clear: deterministic means if the IPv4 stack reassembles the same
sequence of incoming packets the same way.
I have two questions for you:
(1) how do you ensure that different test cases do not interfere? Manually
selecting different IP IDs?
(2) how do you ensure that the reassembly buffer is empty, before you start
running a test? If fragments stay there, the second run has a different inp=
ut.
For example, test_495_peosp-oms, the reassembly can be performed after the
first two packets have been received (see the corresponding y trace). So the
last two fragments stay in the reassembly buffer. When you run the test aga=
in,
it looks receiving (in this sequence) the 3rd, 4th, 1st, 2nd, 3rd, 4th segm=
ent.
After the first four fragments, the packet is reassembled, but differently,
since the sequence is different. I guess this results in an ICMP checksum e=
rror
and therefore you don't see the ICMP echo response.
Maybe I can hack packetdrill a bit to test this locally. But right now I
suspect that the cause for the difference in behavior is related to the
reassembly buffer not being in the same state when running the tests.

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-287229-7501-t2WMNKG6Em>