#
e9ac4169 |
| 15-Jul-2024 |
Warner Losh <imp@FreeBSD.org> |
Remove residual blank line at start of Makefile
This is a residual of the $FreeBSD$ removal.
MFC After: 3 days (though I'll just run the command on the branches) Sponsored by: Netflix
|
Revision tags: release/14.1.0, release/13.3.0, release/14.0.0 |
|
#
8b57b2a9 |
| 18-Jun-2023 |
Mark Johnston <markj@FreeBSD.org> |
frag6 tests: Serialize
I'm not sure exactly why, but these tests consistently fail when run in parallel. Serialize them for now.
MFC after: 1 week
|
#
d0b2dbfa |
| 16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
Remove $FreeBSD$: one-line sh pattern
Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/
|
Revision tags: release/13.2.0, release/12.4.0, release/13.1.0, release/12.3.0, release/13.0.0, release/12.2.0, release/11.4.0, release/12.1.0 |
|
#
619456bb |
| 25-Oct-2019 |
Bjoern A. Zeeb <bz@FreeBSD.org> |
frag6: prevent overwriting initial fragoff=0 packet meta-data.
When we receive the packet with the first fragmented part (fragoff=0) we remember the length of the unfragmentable part and the next he
frag6: prevent overwriting initial fragoff=0 packet meta-data.
When we receive the packet with the first fragmented part (fragoff=0) we remember the length of the unfragmentable part and the next header (and should probably also remember ECN) as meta-data on the reassembly queue. Someone replying this packet so far could change these 2 (3) values. While changing the next header seems more severe, for a full size fragmented UDP packet, for example, adding an extension header to the unfragmentable part would go unnoticed (as the framented part would be considered an exact duplicate) but make reassembly fail. So do not allow updating the meta-data after we have seen the first fragmented part anymore.
The frag6_20 test case is added which failed before triggering an ICMPv6 "param prob" due to the check for each queued fragment for a max-size violation if a fragoff=0 packet was received.
MFC after: 3 weeks Sponsored by: Netflix
show more ...
|
#
f74e6e49 |
| 21-Oct-2019 |
Bjoern A. Zeeb <bz@FreeBSD.org> |
frag6: import a set of test cases
In order to ensure that changing the frag6 code does not change behaviour or break code a set of test cases were implemented.
Like some other test cases these use
frag6: import a set of test cases
In order to ensure that changing the frag6 code does not change behaviour or break code a set of test cases were implemented.
Like some other test cases these use Scapy to generate packets and possibly wait for expected answers. In most cases we do check the global and per interface (netstat) statistics output using the libxo output and grep to validate fields and numbers. This is a bit hackish but we currently have no better way to match a selected number of stats only (we have to ignore some of the ND6 variables; otherwise we could use the entire list).
Test cases include atomic fragments, single fragments, multi-fragments, and try to cover most error cases in the code currently. In addition vnet teardown is tested to not panic.
A separate set (not in-tree currently) of probes were used in order to make sure that the test cases actually test what they should.
The "sniffer" code was copied and adjusted from the netpfil version as we sometimes will not get packets or have longer timeouts to deal with.
Sponsored by: Netflix
show more ...
|