Bug #17128
Investigate whether internal network adapters consistently use their previously spoofed MAC address after resuming from suspend
Start date:
Due date:
% Done:
0%
Description
On resume, apparently internal network adapters are not seen as “added” by the kernel, so no udev event is triggered, so we don’t spoof their MAC address again.
So it seems we’re implicitly relying on the assumption that all internal network adapters and their firmware will remember and use their previously spoofed MAC after resuming from suspend.
Is this actually true?
Note that if we let NetworkManager handle the whole MAC spoofing dance itself (Feature #11293), we would not have to wonder.
Subtasks
Related issues
| Related to Tails - Bug #17115: MAC spoofing can fail and disable a network adapter when waking up from suspend | Confirmed | ||
| Related to Tails - Feature #11293: Check if/how we should use NetworkManager's new MAC address spoofing capabilities | Confirmed | 2016-03-31 |
History
#1 Updated by intrigeri 2019-10-07 07:36:42
- related to Bug #17115: MAC spoofing can fail and disable a network adapter when waking up from suspend added
#2 Updated by intrigeri 2019-10-07 07:36:50
- related to Feature #11293: Check if/how we should use NetworkManager's new MAC address spoofing capabilities added
#3 Updated by intrigeri 2019-10-09 15:43:54
One data point: the wired Ethernet adapter in a ThinkPad X200 keeps its previously spoofed MAC address after resuming from suspend. But of course, that does not fully answer the question this ticket is about.