I tested this with syzkaller (if_tap) and packetdrill (if_tun) and it works as intended.

In D20086#432223, @lwhsu wrote:

In D20086#432185, @tuexen wrote:

Yes, you are right. Not sure what I was looking at. Should I add the trailing empty line to get things consistent?

Oh I just committed rS346873, let see if it helps.

In D20044#432207, @kevans wrote:

I can't seem to reproduce this issue (though some things aren't functional in my current test system (until tomorrow), as I'm bridging with encrypted wifi):

# sysctl net.link.tap.up_on_open=1
# ifconfig tap0 create
# ifconfig bridge0 create
# ifconfig bridge0 addm wlan0 addm tap0 up
# cc tap-test.c
# ./a.out
Received packet of length 86
Received packet of length 130
Received packet of length 130
Received packet of length 74

I'll run more tests in the morning on another system on ethernet, but the only way I was able to reproduce is by not setting the up_on_open sysctl (since the interface isn't up'd in the test).

I tested this patch and the tun interface worked as expected. However, the tap interface didn't. Running the program

tuexen@bsd14:~ % sudo ./tap-test
Received packet of length 42
Received packet of length 86
Received packet of length 130
Received packet of length 150
Received packet of length 86
Received packet of length 90
Received packet of length 74
tuexen@bsd14:~ %

On a patched system I only get:

tuexen@head:~ % sudo ./tap-test
tuexen@head:~ %

When capturing traffic on the tap0 interface on the unpatched system, I see (after some other packets) the injected UDP packet and the resulting ICMP packet.
When running tcpdump -i tap0 -n on a patched system, no packets are shown at all.

In D20044#432075, @kevans wrote:

In D20044#432063, @tuexen wrote:

Would it make sense to use if_tuntap.c instead of if_tun.c, the same for the name of the module to load, the device to compile in?

I was pretty torn on naming- tuntap would definitely make sense and has the advantage of being a lot more obvious if one is looking for the tap driver source. Tun also makes sense to an extent (since tap is just a layer-2 tunnel) and only forces tap users to change things, rather than tap and the subset of tun users that load it as a module rather than letting it remain in their kernel config. That's probably really not that big of a deal, given the nature of this.

In D20086#432179, @lwhsu wrote:

In D20086#432173, @tuexen wrote:

Just to double check: tst.ipv4localsctp.ksh.out and tst.localsctpstate.ksh.out both contain a single empty line at the end. Do you want me to add another one to tst.localsctpstate.ksh.out. This would make them inconsistent...

https://svnweb.freebsd.org/base/head/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/ip/tst.localsctpstate.ksh.out?revision=338213&view=markup

tst.localsctpstate.ksh.out doesn't seem to have an empty line in the end.

Yes, you are right. Not sure what I was looking at. Should I add the trailing empty line to get things consistent?

In D20086#432158, @lwhsu wrote:

I've tested test in my development environment and testvm images from artifact.ci.freebsd.org, for making these two tests passing, we also need to modify tst.localsctpstate.ksh.out to added an extra blank line at the end of the file. I think it's acceptable for now, and other .out files also have this line. I would like to check that extra blank line is generated by the test driver or these ksh test scripts later, and fix them all together.

Remove debug output.

Would it make sense to use if_tuntap.c instead of if_tun.c, the same for the name of the module to load, the device to compile in?

In D20017#430777, @ngie wrote:

Abandoning review based on in-depth analysis from @tuexen.

OK, I have figured out why the tests are failing. The problem is the discard server:

ncat --sctp --listen $local $sctpport &

Once an association is established, it figures out via select that stdin is readable, it reads 0 bytes from stdin and terminates.
For TCP one can get rid of that behaviour (using --no-shutdown / --recv-only), but none of this works for SCTP.

In D20017#430588, @ngie wrote:

In D20017#430585, @tuexen wrote:

In D20017#430241, @lwhsu wrote:

OK, I just check we have nmap in the test vm image and it does the work: https://github.com/freebsd/freebsd-ci/commit/689e19c8c71e1892f476c9ef9392f6b443d0ed15
The other failures are due to some perl stuff which I haven't had time on it: https://ci.freebsd.org/job/FreeBSD-head-amd64-dtrace_test/lastCompletedBuild/testReport/common.ip/t_dtrace_contrib/tst_ipv4localsctp_ksh/

I'm debugging this now. Seems to be a kernel issue. Will let you know once I have understood and fixed the issue.

Is using ncat and issue?

ncat isn't available on FreeBSD. The fact that there isn't a listening ncat service will mean that the test will not properly setup the necessary preconditions in order to test out the functionality.

In D20017#430241, @lwhsu wrote:

OK, I just check we have nmap in the test vm image and it does the work: https://github.com/freebsd/freebsd-ci/commit/689e19c8c71e1892f476c9ef9392f6b443d0ed15
The other failures are due to some perl stuff which I haven't had time on it: https://ci.freebsd.org/job/FreeBSD-head-amd64-dtrace_test/lastCompletedBuild/testReport/common.ip/t_dtrace_contrib/tst_ipv4localsctp_ksh/

I tested that this patch fixes the issue reported by syzkaller.

All for reviews have been committed. Thanks a lot for the very quick reviews!

Integrate change suggested by bz@.

In D19967#429234, @bz wrote:

Can you please improve the description before committing stating that it's related to rip6_output().

In D19965#429179, @bz wrote:

In D19965#429167, @tuexen wrote:

Split up in four reviews or committing them separately once approved?

For review already if possible. Means I need less brain cycles now to divide the four apart as well.