Project

General

Profile

Bug #9531

MAC spoofing failure doesn't result in panic mode (module removal), bis

Added by intrigeri over 2 years ago. Updated about 2 years ago.

Status:
Resolved
Priority:
High
Assignee:
-
Category:
Spoof MAC
Target version:
Start date:
06/04/2015
Due date:
% Done:

100%

QA Check:
Pass
Feature Branch:
bugfix/9531-fix-mac-spoof-panic-mode-again
Type of work:
Code
Blueprint:
Easy:
Affected tool:

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.


Related issues

Related to Tails - Bug #8571: MAC spoofing failure doesn't result in panic mode (module removal) Resolved 01/06/2015
Related to Tails - Bug #8687: macchanger failure logs the incorrect exit code Resolved 01/13/2015

Associated revisions

Revision 39bce141 (diff)
Added by intrigeri over 2 years ago

Fix panic mode on MAC spoofing failure, bis repetita.

In the past, we had "exit 1" in there. This problem was identified (#8571) and
fixed (commit 1b46b5b) in Tails 1.2.3, by replacing this "exit 1"
with "return 1".

Then, while working on another, minor problem (#8687), the "exit 1" was
reintroduced (commit 4ea050a) in Tails 1.3.2, presumably because we pasted
sample code from the ticket, that had been drafted before #8571 was fixed.
Sadly, nobody noticed in time.

I cannot easily reproduce the bug on Tails/Wheezy (because I lack hardware whose
MAC address fails to be spoofed there), but I could reproduce it with
Tails/Jessie ("thanks" to the fact we're currently shipping the buggy 'wl'
kernel module in there).

Will-Fix: #9531

Revision 158d1c64
Added by anonym over 2 years ago

Merge remote-tracking branch 'origin/bugfix/9531-fix-mac-spoof-panic-mode-again' into stable

Fix-committed: #9531

History

#1 Updated by intrigeri over 2 years ago

  • 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 over 2 years ago

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 over 2 years ago

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 4ea050a is responsible? It's weird that this code landed, since 1b46b5b precisely replaced exit 1 with return 1, with a justification that makes sense to me.

#4 Updated by intrigeri over 2 years ago

  • 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 #9531#note-3, make me confident that this buggy exit 1 was reintroduced by mistake: the example code on #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 over 2 years ago

  • Related to Bug #8571: MAC spoofing failure doesn't result in panic mode (module removal) added

#6 Updated by intrigeri over 2 years ago

  • Related to Bug #8687: macchanger failure logs the incorrect exit code added

#7 Updated by intrigeri over 2 years ago

  • Status changed from Confirmed to In Progress

#8 Updated by intrigeri over 2 years ago

  • 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 over 2 years ago

  • Feature Branch set to bugfix/9531-fix-mac-spoof-panic-mode-again

It seems the feature branch field was lost.

#10 Updated by anonym over 2 years ago

  • Assignee set to anonym

I take the review'n'merge.

intrigeri wrote:

Maybe the exit 1 that replaced return 1 in 4ea050a is responsible? It's weird that this code landed, since 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 over 2 years ago

  • Status changed from In Progress to Fix committed
  • % Done changed from 50 to 100

#12 Updated by anonym over 2 years ago

  • Assignee deleted (anonym)
  • QA Check changed from Ready for QA to Pass

#13 Updated by BitingBird about 2 years ago

  • Status changed from Fix committed to Resolved

Also available in: Atom PDF