Bug #16825
"Found something that is not an ethernet packet" intermittent test failure
0%
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 Bug #16148.
In both cases, I see no .pcap
file in the artifacts directory so I’m afraid I can’t provide more useful info.
Subtasks
Related issues
Related to Tails - |
Resolved | 2018-11-23 | |
Related to Tails - |
Resolved | ||
Related to Tails - |
Resolved | ||
Blocks Tails - Feature #16209: Core work: Foundations Team | Confirmed |
History
#1 Updated by intrigeri 2019-06-19 07:58:34
- 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 2019-06-19 07:58:39
- related to
Bug #16148: ICMPv6 leaks detected by test suite added
#3 Updated by intrigeri 2019-06-19 07:58:59
- 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 2019-06-19 07:59:09
- blocks Feature #16209: Core work: Foundations Team added
#5 Updated by intrigeri 2019-06-19 08:05:44
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 Bug #16148, and be done with it?
#6 Updated by anonym 2019-06-19 08:23:56
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 commit:661c036afda0d2bbd886b689df045dc88b5a5451).
#7 Updated by intrigeri 2019-06-19 08:56:47
> 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 2019-06-19 09:02:19
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 2019-06-19 13:10:09
- Status changed from Confirmed to In Progress
Applied in changeset commit:tails|7ff6c1d2ff6a065a4d492f9b63ff198308a91e8b.
#10 Updated by anonym 2019-06-19 14:40:41
- 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 2019-08-10 17:08:42
- 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 2019-08-10 17:10:36
Code review passes, merged stable into the topic branch so that Jenkins tests it again.
#13 Updated by intrigeri 2019-08-10 20:53:37
- Status changed from Needs Validation to Fix committed
#14 Updated by CyrilBrulebois 2019-09-05 00:03:22
- Status changed from Fix committed to Resolved
#15 Updated by intrigeri 2019-09-29 12:39:47
- related to
Bug #17102: "Found something that is not an ethernet packet" intermittent test failure added