Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

macchange all the interfaces #13

Open
grugq opened this issue Nov 22, 2013 · 10 comments
Open

macchange all the interfaces #13

grugq opened this issue Nov 22, 2013 · 10 comments

Comments

@grugq
Copy link
Owner

grugq commented Nov 22, 2013

not very useful, but...

set macchange to run at init and change the MAC of all the interfaces on the system.

@globalcitizen
Copy link

not healthy for all interfaces. eg. if bonding driver is in use, this may break things.

suggest: ip link show |grep -v LOWER_UP |grep -v MASTER |grep mtu |cut -d ':' -f2 |cut -d ' ' -f2 |sort|uniq

sample output:

enp3s0
hwsim0
wlan0
wlan1

this rejects bond*, vmnet*, etc.

@grugq
Copy link
Owner Author

grugq commented Nov 28, 2013

Ok, so that might not be a good approach.

How about if there is something like:
/etc/conf/macchanger file with a configuration for the macchanger init script, in particular a list of interfaces to change.

Then a systemd file that will only macchange those interfaces? Allows the user more control, and we can pre-populate it at install time w/ using your cmd.

@globalcitizen
Copy link

/etc/conf/kathoey

@grugq
Copy link
Owner Author

grugq commented Dec 26, 2013

This has not been particularly successful. I have not been able to get systemd to change a single MAC. I am quite annoyed at it, actually. Once the interface is up and associating it won't macchange, but I can't figure out how to get a script to run after ifconfig up but before, e.g. wpa_supplicant takes over.

fucking annoying. It would be easier on a Debian based system, but then the size of the base image goes up to something stupid, like 2G.

@globalcitizen
Copy link

https://en.wikipedia.org/wiki/OpenRC might be worth trying, which is Gentoo/Funtoo's native RC system and also works on NetBSD/FreeBSD. It has a very flexible networking system, recently rewritten.

Actually Gentoo makes a lot of sense in general if you are worried about absolute-latest packages, and care about output size (eg. if you want to use specific FS types, maintain feature control within each package, etc.) ... you just use it to make life easy building a small binary distribution, and leave out the Gentoo 'portage' package management/python runtime stuff in the finished system.

IIRC in response to multiple whinges including mine they are currently implementing a system to enable automated end to end crypto on base system images ... https://bugs.gentoo.org/show_bug.cgi?id=453620 .. and looking for input @ #gentoo-keys on freenode ... keys @ http://api.gentoo.org/gentoo-keys/seeds/release.seeds

So automated building of a sub-distro to binary form with full control of package features and cryptographically verified sources should be easy...

@grugq
Copy link
Owner Author

grugq commented Dec 27, 2013

yeah, this is not going to happen: http://dustinhatch.tumblr.com/post/38118003177/minimalist-gentoo-for-the-raspberry-pi

I do this in my spare time. If there was a commercial version that paid for itself, then I would be able to invest the time into that. I think it is a great idea. I just don't have the time to do it. Maybe one of those liberty tech grants would cover paying for it.

@securedmh
Copy link

I got this working for the following configurations:

  1. (wlan0, inet) & (eth0, intranet)
  2. (eth0, inet) & (eth1, intranet)

Haven't setup AP yet but on my list to test next.

I started by looking at the order that systemd loads services (all the main ones point to multi-user.target or network.target).

Order of loading.

  1. network.service & dhcpcd.service [Wants=network.target, Before=network.target]
  2. network.target
  3. ntpd.service & dnsmasq.service [After=network.target]
  4. ntp-wait.service
  5. tor.service

Two problems arose:

  1. dhcpcd tries to allocate an IP to the intranet facing interface which is already getting a static IP.
  2. Adding two MAC changing ExecStart lines (ExecStart=ip link set dev address XX:XX:XX:XX:XX:XX) to network.service before bringing the intranet device up was denied. This happened when dhcpcd was trying to configure the interface already due to systemd parallelism or because the MAC address was invalid (E.g., 11:11:11:11:11:6c)

Fixed this in two steps:

  1. added denyinterfaces to /etc/dhcpcd.conf (E.g., denyinterfaces eth0 for configuration 1 above)
  2. Changed dhcpcd.service to start after network.service finished
    Wants=network.service
    After=network.service

It is easy to generate a permanent MAC address when running build.sh and store the configurations in /etc/conf.d/network as intraMAC= and interMAC= with intraIface= and interIface=.

@grugq
Copy link
Owner Author

grugq commented Mar 1, 2014

sorry, git issues really isn't the best way to contact me. email before next time so i have some forewarning: thegrugq@gmail.com :)

@grugq
Copy link
Owner Author

grugq commented Mar 1, 2014

I don't see a pull request for the updated scripts... can you open one please?

@ad90df8e708e8fa8153e56a059
Copy link
Contributor

If you set the flag MACAddressPolicy=random in your /etc/systemd/network/iface.linkfile, systemd will randomize the mac when it starts the interface. Probably the cleanest way to do this unless you don't want to use systemd to define your interfaces.

(One of the few instances where the systemd feature creep isn't so horrible.)

Example: /etc/systemd/network/eth0.link

[Match]
Name = eth0

[Link]
MACAddressPolicy = random

https://wiki.archlinux.org/index.php/systemd-networkd#.5BLink.5D_section

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants