"Found something that is not an ethernet packet" intermittent test failure
Bug #16825 is back, at least I’ve seen it once.
Related to Tails -
Related to Tails -
|Blocks Tails - Feature #16209: Core work: Foundations Team||Confirmed|
#4 Updated by intrigeri 2019-09-29 12:43:47
I can’t attach the pcap because it’s larger than the maximum size (5 MB) allowed here.
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 2019-10-11 04:19:40
> 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.
#7 Updated by intrigeri 2019-11-12 07:36:02
- 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 commit: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 2019-11-12 07:59:59
> 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
Bug #16825 and Bug #16788 already, in the “fallout of our fix for Bug #16148” series).