tests: provide test case for malformed IEEE 802.15.4 packets

[miri64]

Contribution description

This provides a test case for #11398

Testing procedure

Compile and run the test on native.

make -C tests/gnrc_netif_ieee802154/ all test

Revert 3c19aa7 and compile and run again. This time the test will fail.

Issues/PRs references

Provides regression test for #11399.

[miri64]

Ping? We should merge this test case soonish to prevent regression.

[miri64]

Mhhh. Murdock seems to have a problem with the sockets. @kaspar030 any idea what's happening?

[miri64]

Ping @kaspar030?

[kaspar030]

Mhhh. Murdock seems to have a problem with the sockets. @kaspar030 any idea what's happening?

I think docker containers don't have ipv6 enabled.

[miri64]

Mhhh. Murdock seems to have a problem with the sockets. @kaspar030 any idea what's happening?

I think docker containers don't have ipv6 enabled.

Not nice. Let's see how it deals with an IPv4 socket then.

[miri64]

Works :-)

[miri64]

Works :-)

Then again it doesn't because now the test still works when I revert 3c19aa7. :-/. For now I revert the last commit

[miri64]

I think docker containers don't have ipv6 enabled.

@cladmi any idea why?

[kaspar030]

@cladmi any idea why?

(as discussed offline) This is just Docker's default configuration, see https://docs.docker.com/v17.09/engine/userguide/networking/default_network/ipv6/.

So this is not a container option, but a container runtime configuration issue.
If we really need that, we could probably configure the workers accordingly. @smlng I assume k8s doesn't have problems configuring IPv6?

[miri64]

Then again it doesn't because now the test still works when I revert 3c19aa7. :-/. For now I revert the last commit

The problem on my local machine at least was that some weird other address (2.somethingsomething; looked like garbage) was returned by getaddrinfo for localhost, 0.0.0.0 and 127.0.0.1 here

RIOT/cpu/native/socket_zep/socket_zep.c

Lines 337 to 341 in 5eaf45c

	if ((res = real_getaddrinfo(params->local_addr, params->local_port, &hints,
	&ai)) < 0) {
	errx(EXIT_FAILURE, "ZEP: unable to get local address: %s\n",
	gai_strerror(res));
	}

and here

RIOT/cpu/native/socket_zep/socket_zep.c

Lines 357 to 361 in 5eaf45c

	if ((res = real_getaddrinfo(params->remote_addr, params->remote_port, &hints,
	&ai)) < 0) {
	errx(EXIT_FAILURE, "ZEP: unable to get remote address: %s\n",
	gai_strerror(res));
	}

[miri64]

(so the socket is bound to a non-existing address, so it isn't able to receive anything so the packet that triggers a bogus packet without 3c19aa7 is never received :-/)

[miri64]

If we really need that, […]

Since RIOT doesn't even speak IPv4 I think it is important for our main testing environment to support IPv6, no?

[miri64]

Since RIOT doesn't even speak IPv4 I think it is important for our main testing environment to support IPv6, no?

(without packages ;-))

[cladmi]

On my machine there is no failure when run with the ipv4 case.

I before tried to only have the script with ipv4 without changing riot configuration… as I did not thought about it, and it worked.

I think that sending a "please tell me you answer" first or last packet could help ensuring we are sending to the right destination.

[miri64]

I think that sending a "please tell me you answer" first or last packet could help ensuring we are sending to the right destination.

Done

[miri64]

Pushed the IPv4 version again, so we can see what murdock is saying about it.

[cladmi]

On my machine ipv4 does not work as well, I do not receive the valid packet.
So it is not only on your machine :)

[miri64]

On my machine ipv4 does not work as well, I do not receive the valid packet.
So it is not only on your machine :)

Same goes for Murdock... I guess we need to fix socket_zep first to get this test merged ^^

[cladmi]

Or IPv6 in the test environments.

[miri64]

I think it was the test after all. I have a new machine now, and there the test also failed. Will fix.

[miri64]

Fixed

[miri64]

Works: https://ci.riot-os.org/RIOT-OS/RIOT/11401/1e3407c49aaad518468d06c630b56defb1571292/output/compile/tests/gnrc_netif_ieee802154/native:gnu.txt...

Now let's ruin it ;-P

[miri64]

(by porting the test to scapy... while it still uses sockets, afaik Murdock does not have scapy installed ;-))

[miri64]

Once RIOT-OS/riotdocker#77 is deployed, this test should work again. @kaspar030 @smlng any timeline on this?

[miri64]

Let's try it. ;-)

[benpicco]

Murdock only complains about Pull request needs squashing so it looks like scapy has been deployed.

So why not make Murdock firmly happy and squash :)

[miri64]

Squashed and rebased

[miri64]

I noticed an error in the test script. It should now be fixed.

[miri64]

(i.e. please make sure to follow the testing procedures before merging ;-))

[haukepetersen]

Reasoning is valid to me, so is the code. Test runs as expected -> ACK

[miri64]

Thanks for the review!