Yup, it seems that all along I've just missed that we could have
IPv6Packet:s in `ip_packet`, and their source is accessed by
`.ipv6_saddr`, not `ip_saddr` (that's for IPv4Packet). So, let's just
try and see which one of the two each `ip_packet` has, because one of
them must be there!

Also, given that UDPPacket can be either IPv4 or IPv6 it seems safest
to try to parse each packet as IPv6Packet first -- that way we keep
looking at transport layer protocols for IPv4 only, and treat
everything IPv6 as the same, which makes sense, since we should block
all IPv6, so everything should be treated the same at all times.

Refs: #11508

I have seen yet another:

    NoMethodError: undefined method `ip_saddr' for nil:NilClass

So we now know that `ip_packet` is not `nil`, it just doesn't have the
`ip_saddr` method (and probably not the `ip_daddr` one either) some
how (feels strange for an IP packet to not have a source or
destination address...).

Refs: #11508

We still get "undefined method `ip_saddr' for nil:NilClass" because
another instance of `ip_packet.ip_saddr` was forgotten and not dealt
with.

Refs: #11508

Presumably from the upgrade from network-manager 1.4.2 to 1.4.4 (since
3.0~alpha1).

We use `assert_*_connections()` in situations where failure is
expected, and then the expectation of whether to save the pcap
artifact is reversed.

Refs: #11508

The `||=` operator will do the assignment if the variable is `nil` *or*
`false`, which is a very unfortunate design decision. :/

The "convenience aliases" were just confusing.

The old design was very inflexible, which over time lead to the
implementation growing messy as different checks were added. The
issue was that it had to hard-code the particular checks we
wanted, and did not allow the user to formulate an expression for
which packets are considered leaks or not. So, let's instead
provide an assertion-like function to which the user passes a
block describing how we want all our packets to look.

Furthermore, now all firewall leak tests should be ok with the
simulated Tor network provided by Chutney. Since all Tor nodes
(incl. bridges) run from the same host (and IP address) we also
include the server port when verifying that no unexpected hosts were
contacted.

Note that in some cases we've lost a bit of information and
precision, e.g. among the anti-tests we no longer exactly match
the protocol that was leaked, but that wasn't very valuable to
begin with, and instead we test *exactly* the code that these are
anti tests for -- a true anti test, indeed!

Also, the 'no traffic has flowed to the LAN' (now renamed) had a
serious bug which was fixed in passing -- the `@lan_host`
variable was not set, so it is `nil`, which could never be among
the IPv4 TCP leaks, so that step always succeeded! :S

I.e. print them at the same time, and use the same naming scheme (only
file extensions differ). Also, include the elapsed time in the name.

Will-fix: #10151

This makes it easier to see what belongs to which run. While we're at
it we also improve the names so they actually refer to the scenario
that failed.

Will-fix: #10151

This commit should probably be split.

It was a mistake to have it saved every time we check for leaks.

For instance, if we want to use the same code for checking whether
only the configured bridges are contacted, we don't have to allow
contact to the TOR_AUTHORITIES too.

The missing @ was crucial here... luckily if we'd ever reach their
usage Ruby would throw an error, but the call to empty? (=> Tails
leaked something for real!) must never have returned false. Note that
the references to these variables are correct in empty?.

This is where it belongs, and soon we'll need to use the same code in
a scenario hook, and calling a step in such a way makes me
uncomfortable.

(FWIW, this is a remnant from the good ol' unmerged
test/firewall-check-tag branch.)

It's a special broadcast address for the local network. See RFC919.

o.instance_of?(c) tests if o has the exact class c, but o.kind_of?(c)
also tests if o's is an instance of some subclass of c.

Also, the comment removed by this commit was wrong; TCPPacket *is* a
subclass if IPPacket, and so are {UDP,ICMP}Packet.

This is currently just a nice try, since the capture part of the sniff/inspect
setup (Sniffer class) is only capturing IPv4 packets.

... especially when the problem is supposed to be fixed already:
we do want to make sure it is, and that no regression occurs.

Now all .feature:s reside directly in the root of features/, and they
are differentiated with tags: source tests are tagged '@source' and
product (i.e. Tails ISO image) tests are tagged '@product'. These tags
then set up the appropriate environment on a feature-by-feature basis.

This will greatly speed up the test suite, and will reduce the stress
on the Tor network.