tests: disable transmit checksum offloading for epair interfaces

[tuexen]

Summary

Some tests expect transmit checksum offloading to be turned of when using epair interfaces. Make this explicit which avoids breaking the tests when epair supports transmit checksum offloading.

[kp]

tests/sys/common/vnet.subr

45

The comment is probably fine, but I wanted my understanding to be explicitly written down somewhere:

It's not so much that the tests don't expect checksum offloading, but that they don't expect that to mean that received packets have an incorrect/unset checksum.
If we were running these tests with real hardware the checksum would not be set on the send side, but would be there on the receive side (because the sending hardware actually filled out the checksum). if_epair is different, in that the received packet still doesn't have a checksum, just flags indicating that no checksum verification is required, which breaks the expectations of a few tests (that actually capture the on-wire packet, and look at its checksum).
By disabling the checksum offload support in if_epair we force our IP stack to actually calculate the checksum, which fixes the affected tests.

Most users won't actually care about the checksum (because packet corruption for packets that never leave system memory is vanishingly unlikely).

It might be interesting to mention this somewhere in the if_epair man page.
I know that checksum offload already catches people out when they look at network captures (i.e. it shows unexpected incorrect checksums in Wireshark), but now we've added an extra little gotcha (in that received packets can also have incorrect checksums and still just work).

46

Perhaps

# Disable checksum offloading because if_epair never computes checksums, it just marks packets as not needing checksum verification. Some test cases want to verify the checksum.

would actually be clearer.

[tuexen]

tests/sys/common/vnet.subr

45

The comment is probably fine, but I wanted my understanding to be explicitly written down somewhere:

It's not so much that the tests don't expect checksum offloading, but that they don't expect that to mean that received packets have an incorrect/unset checksum.

Correct.

If we were running these tests with real hardware the checksum would not be set on the send side, but would be there on the receive side (because the sending hardware actually filled out the checksum). if_epair is different, in that the received packet still doesn't have a checksum, just flags indicating that no checksum verification is required, which breaks the expectations of a few tests (that actually capture the on-wire packet, and look at its checksum).

Correct.
But I would like to add that pf dealing with the the csum_flags could not be tested yet, but can be tested with the improved epair code. This could be relevant, I think, if a VM sends a packet and pf handles it before it hits a physical interface actually performing the checksum computation. So it is relevant that pf handles the flags and the pseudo header checksum in addition to the full checksum.

By disabling the checksum offload support in if_epair we force our IP stack to actually calculate the checksum, which fixes the affected tests.

Most users won't actually care about the checksum (because packet corruption for packets that never leave system memory is vanishingly unlikely).

It might be interesting to mention this somewhere in the if_epair man page.

Will add a sentence.

I know that checksum offload already catches people out when they look at network captures (i.e. it shows unexpected incorrect checksums in Wireshark), but now we've added an extra little gotcha (in that received packets can also have incorrect checksums and still just work).

46

I will use

	# When transmit checksum offloading is enabled, if_epair does not
	# compute checksums, it just marks packets that this computation still
	# needs to be done. However, some test cases verify the checksum.
	# Therefore disable this for IPv4 and IPv6.

while (in my view) improves your text.