Project

General

Profile

Bug #16825

"Found something that is not an ethernet packet" intermittent test failure

Added by intrigeri about 1 month ago. Updated about 1 month ago.

Status:
In Progress
Priority:
Elevated
Assignee:
-
Category:
Test suite
Target version:
-
Start date:
Due date:
% Done:

0%

Feature Branch:
test/16825-ignore-rarp
Type of work:
Code
Blueprint:
Starter:
Affected tool:

Description

I've seen this in "Scenario: Using bridges":

    And all Internet traffic has only flowed through the configured pluggable transports # features/step_definitions/tor.rb:375
      Found something that is not an ethernet packet (RuntimeError)
      ./features/support/helpers/firewall_helper.rb:21:in `block in pcap_connections_helper'
      ./features/support/helpers/firewall_helper.rb:17:in `each'
      ./features/support/helpers/firewall_helper.rb:17:in `pcap_connections_helper'
      ./features/support/helpers/firewall_helper.rb:89:in `assert_all_connections'
      ./features/step_definitions/tor.rb:378:in `/^all Internet traffic has only flowed through the configured pluggable transports$/'
      features/tor_bridges.feature:21:in `And all Internet traffic has only flowed through the configured pluggable transports'

and "Scenario: Clock with host's time in bridge mode":

      Found something that is not an ethernet packet (RuntimeError)
      ./features/support/helpers/firewall_helper.rb:21:in `block in pcap_connections_helper'
      ./features/support/helpers/firewall_helper.rb:17:in `each'
      ./features/support/helpers/firewall_helper.rb:17:in `pcap_connections_helper'
      ./features/support/helpers/firewall_helper.rb:89:in `assert_all_connections'
      ./features/support/hooks.rb:337:in `After'

At this point I don't know if random scenarios can be affected, or only these ones.

I guess this is caused by the changes made recently to help debug #16148.

In both cases, I see no .pcap file in the artifacts directory so I'm afraid I can't provide more useful info.


Related issues

Related to Tails - Bug #16148: ICMPv6 leaks detected by test suite Resolved 11/23/2018
Related to Tails - Bug #16788: Tests fail with "Found something in the pcap file that either is non-IP, or cannot be parsed (RuntimeError)" Resolved
Blocks Tails - Feature #16209: Core work: Foundations Team Confirmed 03/22/2019

Associated revisions

Revision 7ff6c1d2 (diff)
Added by anonym about 1 month ago

Test suite: throw FirewallAssertionFailedError for "weird" patckets.

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

Revision 05ccafae (diff)
Added by anonym about 1 month ago

Test suite: ignore RARP packets.

packetfu cannot parse these.

Refs: #16825

History

#1 Updated by intrigeri about 1 month ago

  • Subject changed from "Found something that is not an ethernet packet" inttermitent test failure to "Found something that is not an ethernet packet" intermittent test failure

#2 Updated by intrigeri about 1 month ago

  • Related to Bug #16148: ICMPv6 leaks detected by test suite added

#3 Updated by intrigeri about 1 month ago

  • Related to Bug #16788: Tests fail with "Found something in the pcap file that either is non-IP, or cannot be parsed (RuntimeError)" added

#4 Updated by intrigeri about 1 month ago

#5 Updated by intrigeri about 1 month ago

intrigeri wrote:

In both cases, I see no .pcap file in the artifacts directory so I'm afraid I can't provide more useful info.

That's because we keep the pcap only when FirewallAssertionFailedError is raised, but on parsing failures we raise a simple RuntimeError:

  • raise 'Found something that is not an ethernet packet'
  • raise "Found something that cannot be parsed"

Would it have adverse consequences if we raised FirewallAssertionFailedError in these cases too? In any case, I guess whoever works on this will have to do this at least temporarily, to get an idea of what these non-ethernet things are. OTOH, perhaps we can just revert the recent changes that we needed to debug #16148, and be done with it?

#6 Updated by anonym about 1 month ago

intrigeri wrote:

That's because we keep the pcap only when FirewallAssertionFailedError is raised, but on parsing failures we raise a simple RuntimeError:

Note that the "the hostname should not have been leaked on the network" step has its own code for saving the pcap. Apparently it doesn't work.

Would it have adverse consequences if we raised FirewallAssertionFailedError in these cases too?

No, in fact this exception was added for that specific purpose (see 661c036afda0d2bbd886b689df045dc88b5a5451).

#7 Updated by intrigeri about 1 month ago

Note that the "the hostname should not have been leaked on the network" step has its own code for saving the pcap. Apparently it doesn't work.

The scenarios that fail for me don't use this step, do they?

#8 Updated by anonym about 1 month ago

intrigeri wrote:

Note that the "the hostname should not have been leaked on the network" step has its own code for saving the pcap. Apparently it doesn't work.

The scenarios that fail for me don't use this step, do they?

Ah, sorry, I mixed it up with the related issue for dhcp.feature that was recently fixed.

Indeed, inside pcap_connections_helper() it is a bug that we don't raise FirewallAssertionFailedError.

#9 Updated by anonym about 1 month ago

  • Status changed from Confirmed to In Progress

#10 Updated by anonym about 1 month ago

  • Feature Branch set to test/16825-ignore-rarp

Turns out packetfu doesn't handle RARP. I've pushed a crappy branch derrived from the test code I used when analyzing. A proper solution would be to add a PacketFu::RARPPacket which probably is pretty easy but I didn't have time to check it now.

Also available in: Atom PDF