Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • T tails
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 971
    • Issues 971
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 27
    • Merge requests 27
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • tails
  • tails
  • Issues
  • #17128
Closed
Open
Issue created Oct 07, 2019 by intrigeri@intrigeriMaintainer

Investigate whether internal network adapters consistently use their previously spoofed MAC address after resuming from suspend

Originally created by @intrigeri on #17128 (Redmine)

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 (#11293), we would not have to wonder.

Related issues

  • Related to #17115
  • Related to #11293
Edited May 15, 2020 by intrigeri
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking