Project

General

Profile

Bug #17102

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

Added by intrigeri about 2 months ago. Updated 2 days ago.

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

100%

Feature Branch:
test/17102-deduplicate-sniffers
Type of work:
Code
Blueprint:
Starter:
Affected tool:

Description

Looks like #16825 is back, at least I've seen it once.


Related issues

Related to Tails - Bug #16825: "Found something that is not an ethernet packet" intermittent test failure Resolved
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 92fefe10 (diff)
Added by intrigeri 4 days ago

Test suite: don't have multiple instances of tcpdump writing to the same file, resulting in an unparsable network capture (refs: #17102)

The "Found something that is not an ethernet packet" test failure happens pretty
often in the "The MAC address is not leaked when booting Tails" scenario.
I suspect that's because during this scenario, we run two instances of Sniffer,
that have the same name, and therefore write to the same pcap file. They are
both started by the "I capture all network traffic" step: one in the Background,
the other one in this scenario itself. I would not be surprised if this
generated invalid pcap files, which is exactly the problem we see here.

Let's avoid this by dropping the Background, at the cost of duplicating
a few lines of Gherkin.

The other solutions I can think of don't look great:

- We could move this scenario (that has the unique property here that we don't
want to restore a snapshot: we want a complete boot) to a dedicated Feature.
This makes no sense to me: this scenario really fits well into
mac_spoofing.feature.
- We could have "I capture all network traffic" deduplicate stuff behind the
curtain before starting a new capture, i.e. detect whether another Sniffer
instance with the same name is already running, and when that's the case, run
@sniffer.stop and @sniffer.clear. I'm worried that the resulting code will be
too complex and magical to be maintainable.

Revision f1a1a9c3
Added by segfault 2 days ago

Merge branch 'test/17102-deduplicate-sniffers' into stable (Closes: #17102)

History

#1 Updated by intrigeri about 2 months ago

#2 Updated by intrigeri about 2 months ago

  • Related to Bug #16825: "Found something that is not an ethernet packet" intermittent test failure added

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

I can't attach the pcap because it's larger than the maximum size (5 MB) allowed here.

Here it is: https://jenkins.tails.boum.org/view/RM/job/test_Tails_ISO_devel/1894/artifact/build-artifacts/03%3A38%3A46_The_MAC_address_is_not_leaked_when_booting_Tails.pcap

I've also saved that file locally so that I can send it out of band to whoever will work on this.

I've tried opening it with Wireshark but that fails with "The capture file appears to be damaged or corrupt. (pcap: File has 34246810-byte packet, bigger than maximum of 262144)".

#5 Updated by intrigeri about 1 month ago

intrigeri wrote:

I've also saved that file locally so that I can send it out of band to whoever will work on this.

I've tried opening it with Wireshark but that fails with "The capture file appears to be damaged or corrupt. (pcap: File has 34246810-byte packet, bigger than maximum of 262144)".

Reproduced while testing 4.0~rc1, saved pcap locally, same issue in Wireshark as last time.

#6 Updated by intrigeri 27 days ago

  • Priority changed from Normal to Elevated

This happens quite regularly these days, and it affects tons of scenarios so we can't simply tag one or 3 of them as fragile ⇒ bumping priority.

#7 Updated by intrigeri 4 days ago

  • Status changed from Confirmed to In Progress
  • Assignee set to intrigeri
  • Target version set to Tails_4.1
  • Feature Branch set to test/17102-deduplicate-sniffers

This made the last 3 test suite runs on the stable branch fail, so I took a closer look.

Every time the failing scenario is "The MAC address is not leaked when booting Tails", which has one interesting property: in mac_spoofing.feature, we have "I capture all network traffic" as a Background step, but then this very scenario also has a "I capture all network traffic" step. That's been the case since 2e13ad46fda71d55192e5946d7a36d9b3401fbb0. I understand it's because for this very scenario, we want a complete boot instead of restoring a snapshot. But it seems to me that the current implementation results in having two tcpdump processes sniffing the same interface and writing to the same file, which could cause trouble.

#8 Updated by intrigeri 4 days ago

intrigeri wrote:

This happens quite regularly these days, and it affects tons of scenarios

I'm not so sure about the "it affects tons of scenarios" part. I wonder if I did check this when I wrote that. I propose we first fix the problem where it's occurring super often, and if the problem comes back elsewhere, then we can reopen or file another ticket (just like we had #16825 and #16788 already, in the "fallout of our fix for #16148" series).

#9 Updated by intrigeri 3 days ago

  • Status changed from In Progress to Needs Validation
  • Assignee deleted (intrigeri)

In 5 test suite runs on this branch on Jenkins, this problem did not occur, while it happens almost every time on the stable branch.

#10 Updated by segfault 2 days ago

  • Status changed from Needs Validation to Resolved
  • % Done changed from 0 to 100

Also available in: Atom PDF