Project

General

Profile

Bug #16825

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

Added by intrigeri 3 months ago. Updated 14 days ago.

Status:
Resolved
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

Associated revisions

Revision 7ff6c1d2 (diff)
Added by anonym 3 months 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 3 months ago

Test suite: ignore RARP packets.

packetfu cannot parse these.

Refs: #16825

History

#1 Updated by intrigeri 3 months 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 3 months ago

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

#3 Updated by intrigeri 3 months 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 3 months ago

#5 Updated by intrigeri 3 months 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 3 months 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 3 months 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 3 months 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 3 months ago

  • Status changed from Confirmed to In Progress

#10 Updated by anonym 3 months 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.

#11 Updated by intrigeri about 1 month ago

  • Status changed from In Progress to Needs Validation
  • Assignee set to intrigeri
  • Target version set to Tails_3.16

This happens too often to me and I'd rather not revert the improvements that caused this regression (too complicated as we've already piled some follow up fixes on top of them), so I'll see if I can review'n'merge this branch in its current state.

@anonym, it would be sweet to file a bug report against PacketFu about it, though; or if there's already one, to reference it in the comment where you referenced this ticket :)

#12 Updated by intrigeri about 1 month ago

Code review passes, merged stable into the topic branch so that Jenkins tests it again.

#13 Updated by intrigeri about 1 month ago

  • Status changed from Needs Validation to Fix committed

#14 Updated by CyrilBrulebois 14 days ago

  • Status changed from Fix committed to Resolved

Also available in: Atom PDF