History log of /freebsd/tests/sys/netinet6/frag6/Makefile (Results 1 – 5 of 5)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 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 ...