Page MenuHomeFreeBSD

pf tests: Test scrub fragment reassemble on interfaces with different MTU
ClosedPublic

Authored by kp on Apr 27 2021, 6:49 PM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Nov 13, 9:28 PM
Unknown Object (File)
Tue, Nov 12, 4:17 AM
Unknown Object (File)
Sep 24 2024, 3:22 AM
Unknown Object (File)
Sep 24 2024, 2:08 AM
Unknown Object (File)
Sep 22 2024, 10:21 AM
Unknown Object (File)
Sep 21 2024, 4:59 PM
Unknown Object (File)
Sep 21 2024, 12:41 PM
Unknown Object (File)
Sep 20 2024, 4:05 AM

Details

Summary

There's a problem with pf's reassembly code where it produces incorrect
checksums when reassembling across interfaces with different MTUs.
Test this.

PR: 255432
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

kp requested review of this revision.Apr 27 2021, 6:49 PM

How do you ensure, that the packet is indeed reassembled by pf and not by the receiving stack?

There's no explicit verification for that here. I suppose that if pf did nothing at all this test would still pass.
Happily I know it does actually do something, because it fails right now.

I suppose we could verify the counters on the scrub rule, but that would still only confirm that pf counted the packets and not that it actually reassembled the packet.
The primary intent of this test is to ensure that this configuration actually works, so it doesn't matter much if pf sends out an 8k packet or reassembles and refragments (as it'd do for IPv6).

Can you add a rule to drop fragments in jail "second"?

Can you add a rule to drop fragments in jail "second"?

Interesting idea, but no, pf doesn't look at the fragmentation flag. Not for filtering anyway.

This revision is now accepted and ready to land.Apr 29 2021, 12:45 PM