I.e. non-ethernet packets and things that cannot even be parsed. This
will help us debug refs: #16825.

Fix-committed: #16823

Fix-committed: #16824

It brings linux 4.19.37-4.

Fixes regression I've introduced in
commit:f223532e.

This is a follow-up on commit:7174efed,
that claimed to test whether we were building a stable release,
but merely checked whether $TAILS_CHANNEL == alpha. Both are equivalent
at the moment but as anonym pointed out, this assumption might become
wrong, e.g. if we ever add a "beta" channel.

Fix-committed: #16788

This reverts commit dc644257.

Fix-committed: #11521

While it is true that DHCP only uses IP(v6) we might as well be more
thorough. The only non-IP(v6) packets that are expected here are ARP
packets, so let's just fail on anything else, like we did prior to
commit 86bd6d5d.

Refs: #16788

Until now we have relied on either one of the generated "snapshot
restore" steps or the "[Given] a computer" step to implicitly stop the
old VM when we move on to a new scenario. That meant the old VM was
still running during the new scenarios @Before@ hooks. If the new
scenario is tagged @check_tor_leaks that means we start its sniffer
while the old VM is still running, possibly sending packets that then
affect the new scenario. That would explain some myserious "Unexpected
connections were made" failures we have seen (refs: #11521).

Fix-committed: #16687

Fix-committed: #12003

Since we started recording the router's traffic in our PCAP
files (refs: #16148) we have started to see this check fail. Indeed,
in some of the captures I've seen the router send an ARP request,
which we don't have a case for. It is sufficient to check only IP
packets, since DHCP only uses IP packets, so we don't have to fail if
we find something else, just ignore them.

Will-fix: #16788

Fix-committed: #16793