Bug #9531
MAC spoofing failure doesn't result in panic mode (module removal), bis
100%
Description
On a feature/jessie built on 20150528, MAC spoofing fails for wlan0 (silly wl driver’s fault) but successes for eth0. And then, then network is left enabled.
Subtasks
History
#1 Updated by intrigeri 2015-06-04 09:55:50
- Priority changed from Normal to High
- Type of work changed from Code to Test
Next step: try to reproduce on Tails/Wheezy (it might be that when we have more than 1 network interface and the 2nd one’s MAC address spoofing works, we fail to disable the network).
#2 Updated by intrigeri 2015-07-08 10:35:28
The way our system is meant to work is that if MAC spoofing fails for 1 device out of 2, then only that device will be disabled. If that fails, then NetworkManager will be stopped. So, what needs to be tested is that the system actually works this way: my initial report doesn’t make it clear whether the iface whose MAC address wasn’t spoofed was left enabled, or whether I was just surprised to see the network stack not fully disabled in the end.
#3 Updated by intrigeri 2015-07-08 11:36:32
Reproduced on current feature/jessie, and bad news: wlan0 is still present. I see the “macchanger failed for NIC” message, but nothing about going to panic mode. Maybe the exit 1 that replaced return 1 in commit:4ea050a is responsible? It’s weird that this code landed, since commit:1b46b5b precisely replaced exit 1 with return 1, with a justification that makes sense to me.
#4 Updated by intrigeri 2015-07-08 11:53:35
- Subject changed from Jessie: network is unblocked even though MAC spoofing failed to MAC spoofing failure doesn't result in panic mode (module removal), bis
- Target version changed from Tails_2.0 to Tails_1.5
- Type of work changed from Test to Code
OK, I can’t reproduce this on Tails/Wheezy because we don’t ship the wl driver in there, so on the same hardware MAC spoofing works there even for wlan0. Anyway, my understanding of the code, and the historical info in Bug #9531#note-3, make me confident that this buggy exit 1 was reintroduced by mistake: the example code on Bug #8687 has exit 1, and was added before we fixed the code to instead return 1, and I bet it was simply copied’n’pasted, and neither the developer nor the reviewers noticed.
=> I’ll bring the return 1 back for Tails 1.5.
#5 Updated by intrigeri 2015-07-08 11:53:51
- related to
Bug #8571: MAC spoofing failure doesn't result in panic mode (module removal) added
#6 Updated by intrigeri 2015-07-08 11:54:13
- related to
Bug #8687: macchanger failure logs the incorrect exit code added
#7 Updated by intrigeri 2015-07-08 12:32:47
- Status changed from Confirmed to In Progress
Applied in changeset commit:39bce1410795c11b3b4dca83f64c9c8ef787c973.
#8 Updated by intrigeri 2015-07-08 12:33:48
- Assignee deleted (
intrigeri) - % Done changed from 0 to 50
- QA Check set to Ready for QA
Fixes the problem once merged into feature/jessie, on the hardware that exposed the problem in there. Can’t easily test on Tails/Wheezy.
#9 Updated by anonym 2015-07-20 13:03:21
- Feature Branch set to bugfix/9531-fix-mac-spoof-panic-mode-again
It seems the feature branch field was lost.
#10 Updated by anonym 2015-07-20 13:13:30
- Assignee set to anonym
I take the review’n’merge.
intrigeri wrote:
> Maybe the exit 1 that replaced return 1 in commit:4ea050a is responsible? It’s weird that this code landed, since commit:1b46b5b precisely replaced exit 1 with return 1, with a justification that makes sense to me.
You are absolutely correct. My bad!
#11 Updated by anonym 2015-07-21 05:12:50
- Status changed from In Progress to Fix committed
- % Done changed from 50 to 100
Applied in changeset commit:158d1c647d0f811cfafcc0102156eb86ba295f79.
#12 Updated by anonym 2015-07-21 05:13:19
- Assignee deleted (
anonym) - QA Check changed from Ready for QA to Pass
#13 Updated by BitingBird 2015-08-11 10:41:44
- Status changed from Fix committed to Resolved