Firewall leak detector makes bad assumptions about PacketFu parsing
I’ve seen this:
calling as amnesia: host -T torproject.org 208.67.222.222
call returned: [0, "Using domain server:\nName: 208.67.222.222\nAddress: 208.67.222.222#53\nAliases: \n\ntorproject.org has address 86.59.30.40\ntorproject.org has address 38.229.72.16\ntorproject.org has address 82.195.75.101\ntorproject.org has address 138.201.14.197\ntorproject.org has IPv6 address 2001:41b8:202:deb:213:21ff:fe20:1426\ntorproject.org has IPv6 address 2001:858:2:2:aabb:0:563b:1e28\ntorproject.org has IPv6 address 2a01:4f8:172:1b46:0:abba:5:1\ntorproject.org has IPv6 address 2620:0:6b0:b:1a1a:0:26e5:4810\ntorproject.org mail is handled by 10 eugeni.torproject.org.\n", ""]
When I do a TCP DNS lookup of "torproject.org" # features/step_definitions/firewall_leaks.rb:19
Then the firewall leak detector has detected leaks # features/step_definitions/firewall_leaks.rb:1
<Test::Unit::AssertionFailedError> exception expected but was
<NoMethodError(<undefined method `ip_saddr' for nil:NilClass>)>. (Test::Unit::AssertionFailedError)
./features/step_definitions/firewall_leaks.rb:2:in `/^the firewall leak detector has detected leaks$/'
features/tor_enforcement.feature:33:in `Then the firewall leak detector has detected leaks'
This implies that the various PacketFu
.parse
methods can return
nil
despite .can_parse?
returning true
. This feels like a bug in
PacketFu
.
Sadly the way this error happened prevented a .pcap
artifact to be
saved. Also:
Then(/^the firewall leak detector has detected leaks$/) do
assert_raise(Test::Unit::AssertionFailedError) do
step 'all Internet traffic has only flowed through Tor'
end
end
That step calls assert_all_connections
and given how we have the
opposite expectation about the assertion (assert_raise
) the artifact
saving occurs in the opposite of what we want here.
Also: probably we’ll end up throwing in some assert
s in the
pcap_connections_helper
(e.g. for the nil
issue above) so we should
probably introduce another exception to throw when
assert_all_connections
fails, and a subclass of
Test::Unit::AssertionFailedError
would be good enough to make it
possible to distinguish.
Parent Task: #10288
Original created by @anonym on 11508 (Redmine)