grugq / PORTALofPi

PORTAL of Pi - RaspberyPi based PORTAL device. Certified UNIX Network Technicians only!

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

macchange all the interfaces

grugq opened this issue · comments

not very useful, but...

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

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.

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.

/etc/conf/kathoey

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.

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...

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.

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=.

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

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

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