Changed MAC-address on boot, connection lost.

P

pr4x4n

You must have seen some topics about this on the forums or elsewhere on the web and here is a new one. I have searched the web for a solution, but i can't find it and many information looks outdated. However i came pretty far i must say. But its still not working when the MAC-address has been changed.

I'm running: FreeBSD 11.0-ALPHA3 release(?): 301873 on a Raspberry PI 2 and my goal is to change the MAC-address on boot with a random new address.

So I've tried making a start_if.ue0 file, containing:
Code: 
#!/bin/sh
ifconfig ue0 lladdr `openssl rand -hex 6 | sed 's/\(..\)/\1:/g; s/.$//'`
I also tried link or ether instead of lladdr.

which does work. The mac-address is changed. However, my connection with my network is completely gone.

I've tried to restart: /etc/rc.d/netif && /etc/rc.d/routing. The last one makes sure the routes are gone. I didn't solve it by manually adding the routes.

Code: 
Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            192.168.1.1        UGS         ue0
127.0.0.1          link#1             UH          lo0
192.168.1.0/24     link#2             U           ue0
192.168.1.9        link#2             UHS         lo0

Internet6:
Destination                       Gateway                       Flags     Netif Expire
::/96                             ::1                           UGRS        lo0
::1                               link#1                        UH          lo0
::ffff:0.0.0.0/96                 ::1                           UGRS        lo0
fe80::/10                         ::1                           UGRS        lo0
fe80::%lo0/64                     link#1                        U           lo0
fe80::1%lo0                       link#1                        UHS         lo0
ff02::/16                         ::1                           UGRS        lo0
My interface without changing the MAC-address:
Code: 
ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=80009<RXCSUM,VLAN_MTU,LINKSTATE>
    ether bX:2X:eX:Xe:X9:0X
    inet 192.168.1.9 netmask 0xffffff00 broadcast 192.168.1.255
    media: Ethernet autoselect (100baseTX <full-duplex>)
    status: active
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
My interface with changing the MAC-address:
Code: 
ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=80009<RXCSUM,VLAN_MTU,LINKSTATE>
    ether 8a:b9:bd:1a:48:c8
    inet 192.168.1.9 netmask 0xffffff00 broadcast 192.168.1.255
    media: Ethernet autoselect (100baseTX <full-duplex>)
    status: active
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
My rc.conf:
Code: 
hostname="redacted"
ifconfig_ue0="inet 192.168.1.9 netmask 255.255.255.0"
defaultrouter="192.168.1.1"
gateway_enabled="YES"
sshd_enable="YES"

powerd_enable="YES"

# Nice if you have a network, else annoying.
#ntpd_enable="YES"
ntpd_sync_on_start="YES"
background_dhclient="NO"
icmp_drop_redirect="NO"
ftpd_enable="NO"
icmp_bmcastecho="NO"

# Uncomment to disable common services (more memory)
#cron_enable="NO"
syslogd_enable="YES"
sendmail_enable="NONE"
sendmail_submit_enable="NO"
sendmail_outbound_enable="NO"
sendmail_msp_queue_enable="NO"
# On first boot, enlarge the root filesystem to fill the SD card
growfs_enable="YES"

#Disable IPV6
ipv6_defaultrouter="NO"
ip6addrctl_enable="NO"
ip6addrctl_policy="ipv4_prefer"
ipv6_activate_all_interfaces="NO"
ipv6_network_interfaces="none"
route6d_enable="NO"
ipv6_gateway_enable="NO"
ipv6_default_interface="NO"
I also checked the logging of the RPI and my router. There are no network-related errors. I'm stuck. Can anyone point me in the right direction?

Update 1: I checked the arp-table of my router. It still had the old mac address. I deleted it and added a static one; still the same issue.

Update 2: I did find a workarround, which is putting my interface in promiscuous mode. But i dont think that is desirable.
 
Last edited:
Mine does not change automatically:
Code: 
hopo # ifconfig em0 lladdr `openssl rand -hex 6 | sed 's/\(..\)/\1:/g; s/.$// >
hopo # ifconfig em0
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
  options=4219b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC,VLAN_HWTSO>
  ether 50:78:3d:c6:6b:8f
  inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
  nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
  media: Ethernet autoselect
  status: no carrier
hopo # arp -a
? (192.168.3.1) at 55.66.77.88.11.22.33.44.a.2.ff.fe.0.0.0.0 on fwip0 permanent [firewire]
hopo (192.168.0.1) at 64:31:50:71:f6:38 on em0 permanent [ethernet]

Juha

I'm not helping, and can't test further, just one PC.
Naughty corner for sloppy cut&paste, that > came from ksh, command was okay
 
Juha Nurmela said:
Mine does not change automatically:
Code: 
hopo # ifconfig em0 lladdr `openssl rand -hex 6 | sed 's/\(..\)/\1:/g; s/.$// >
hopo # ifconfig em0
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
  options=4219b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC,VLAN_HWTSO>
  ether 50:78:3d:c6:6b:8f
  inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
  nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
  media: Ethernet autoselect
  status: no carrier
hopo # arp -a
? (192.168.3.1) at 55.66.77.88.11.22.33.44.a.2.ff.fe.0.0.0.0 on fwip0 permanent [firewire]
hopo (192.168.0.1) at 64:31:50:71:f6:38 on em0 permanent [ethernet]

Juha

I'm not helping, and can't test further, just one PC.
Click to expand...

Thats because:
Code: 
hopo # ifconfig em0 lladdr `openssl rand -hex 6 | sed 's/\(..\)/\1:/g; s/.$// >
you added a > and missing a ' and `. Again, the script is not the problem. Its what should happen after the mac-address has changed.
 
Ethernet MAC addresses are not just a 48 bit freely usable number space. In particular, the LSB of the first octet is the unicast/multicast bit. So, your random address selection is guaranteed to be invalid 50% of the time, due to it improperly selecting a multicast address. The second-to-least bit of the first octet is the universal/local bit, so should be set when you are locally assigning an address. I don't know if either of these are the issue you are experiencing (multicast is certainly improper as an interface address, and potentially some hardware might have an issue if asked to assign an address without the local bit set. Even if the local system accepts an invalid address, remote systems (including routers, switches, and bridges) may take exception to improper use of multicast addresses (or just not behave in a useful manner).

Try using 02:xx:xx:xx:xx:xx, as a locally assigned unicast address, with just 40 random bits. You might be able to use more bits out of the first octet, but it's generally easier to just skip the first octet. Changing to always use a valid address under the Ethernet standards is certainly an essential step in figuring out what is going on.

If this is on a private network, I quite strongly recommend against doing this, as it is not something which is expected behaviour on Ethernet, there should be no real benefit from doing it, and I struggle to see any justification for it. On a public network, I can see possible motivation for it, but it's still abnormal behaviour in Ethernet terms.

Lastly, be cautious about doing this on an ISP's layer 2 network, as it might break your terms of service contract.
 
Murph said:
Ethernet MAC addresses are not just a 48 bit freely usable number space. In particular, the LSB of the first octet is the unicast/multicast bit. So, your random address selection is guaranteed to be invalid 50% of the time, due to it improperly selecting a multicast address. The second-to-least bit of the first octet is the universal/local bit, so should be set when you are locally assigning an address. I don't know if either of these are the issue you are experiencing (multicast is certainly improper as an interface address, and potentially some hardware might have an issue if asked to assign an address without the local bit set. Even if the local system accepts an invalid address, remote systems (including routers, switches, and bridges) may take exception to improper use of multicast addresses (or just not behave in a useful manner).

Try using 02:xx:xx:xx:xx:xx, as a locally assigned unicast address, with just 40 random bits. You might be able to use more bits out of the first octet, but it's generally easier to just skip the first octet. Changing to always use a valid address under the Ethernet standards is certainly an essential step in figuring out what is going on.

If this is on a private network, I quite strongly recommend against doing this, as it is not something which is expected behaviour on Ethernet, there should be no real benefit from doing it, and I struggle to see any justification for it. On a public network, I can see possible motivation for it, but it's still abnormal behaviour in Ethernet terms.

Lastly, be cautious about doing this on an ISP's layer 2 network, as it might break your terms of service contract.
Click to expand...
Thank you for your time and answer Murph. I agree. You should not be doing this for no reason. However, in terms of privacy i want to do so. Im using it on my own private network. It still is a way of identifying a device which is what i want to prevent. Linux 'just' simply accepts a lot of this stuff. Unix doesnt. I like that a lot, but a simple adjustment like this should be possible.

I kinda new that a mac-address is not just a freely usable number space as you describe. Just didnt gave it much thought. However, using macchanger -A ue0 gives me a random mac-address from a known vendor, but even then, i dont get any connection to my local network. So, whatever mac-address i give my interface, it wont simply work after doing so. This should definitely be possible.

I did find a workarround, which is putting my interface in promiscuous mode. But i dont think that is desirable.
 
pr4x4n said:
… However, in terms of privacy i want to do so. Im using it on my own private network. It still is a way of identifying a device which is what i want to prevent. …
Click to expand...
I don't see how you gain any privacy benefit if this is on your own private network. If random untrusted people can see the MAC addresses being used on your private network, the major concern is security (and privacy should be mostly unimportant). The MAC address is not visible to anyone beyond your router/firewall; it is only visible to other hosts on the same local network subnet. (With the exception of the case where an application exposes it, which is quite abnormal in terms of the usual Internet protocols, and nothing about IP (including UDP and TCP) itself will ever expose MAC addresses.) If you have your own router (i.e. not owned/managed by your ISP), even your ISP can't see the MAC addresses of devices inside your network. The L2 headers containing the MAC addresses never make it past a router, it's a fundamental property of routed IP over Ethernet.

Yes, it should be possible to change the MAC address used, and I'm fairly certain that it is possible on FreeBSD. I'm not entirely certain why it is not working for you (once you change your method to only use valid addresses).

If you do a arp -an locally on the system with the changed MAC address, are you seeing it properly there? You should see something like the following (and I'm even giving you the real MAC address of one of my servers here as a way of saying how unimportant it is to privacy):
Code: 
? (192.0.2.1) at 00:1c:c0:42:a9:55 on re0 permanent [ethernet]

If there's a mismatch between what is shown in ifconfig -a, and arp -an, you might possibly be running into a bug. There should be a "permanent" entry in the ARP table for every IP address configured on the system's Ethernet interfaces (and Ethernet-like interfaces, i.e. all interfaces which use the ARP protocol to establish L2 connectivity with peers).

There is another reason why you should always have the locally assigned address bit set; network equipment vendors are pretty much free to define special behaviour for addresses within their vendor prefix. E.g. HSRP/VRRP/CARP have special behaviour for certain MAC addresses. If your random selection happens to stumble across one of these cases, odd things could happen, and setting the locally assigned bit should guarantee avoiding that.
 
The main concern about MAC addresses is that a locally running process can inspect the machine configuration and of course read the MAC address from ifconfig(8) output and then use it as identification on services where you connect. If you're just browsing the net using a browser without any special plugins this is not a big concern but as soon as you're required to install third party software/plugins to use a service there are no guarantees that the third party software is not going to do this. Changing the MAC address to another fixed address accomplishes nothing to counter this.

Outside that the MAC address is purely a layer 2 thing and won't be visible outside the immediately connected ethernet (or WLAN in case of wireless) segment (or a segment made of one or more segments connected via bridges).
 
Hi!

Here is a working solution for the NIC (smsc) in FreeBSD 11.0-STABLE (RPI-B). Apply that patch to the sources, build a new kernel with modules and copy kernel and module to /boot/kernel. Afterwards you can change the MAC on boot (/etc/start_if.ue0) without promiscuous mode.

Many thanks to hselasky

@pr4x4n: hopefully that helps

Regards
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top