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)
Jan 15 2024, 10:12 AM
Unknown Object (File)
Dec 20 2023, 9:13 PM
Unknown Object (File)
Dec 20 2023, 4:20 AM
Unknown Object (File)
Dec 8 2023, 10:39 PM
Unknown Object (File)
Nov 5 2023, 4:49 AM
Unknown Object (File)
Oct 29 2023, 3:35 PM
Unknown Object (File)
Oct 4 2023, 4:50 AM
Unknown Object (File)
Sep 10 2023, 1:38 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
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 38892
Build 35781: arc lint + arc unit

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