How to change the mac address of the DHCP-interface?

[ogogon]

Colleagues, tell me, please, how to change the MAC-address of the interface, which receives leases from DHCP? What should be written in the file rc.conf?

Thanks in advance,
Ogogon.

 

[SirDice]

You typically don't want to muck with the MAC address of an interface. What exactly are you trying to accomplish?

 

[ogogon]

You typically don't want to muck with the MAC address of an interface. What exactly are you trying to accomplish?

I admit honestly, turning to the forum, I counted on an answer on the merits of the question, and not on questions about why this is necessary...

However, I will gladly satisfy your curiosity. A certain provider uses static DHСP, with the help of which it issues the same address to users with static addresses. With tenacity worthy of a better application.
His support service changes the record of the MAC address within a few hours, and in the evening or on weekends it may simply not work.

It has been experimentally established that changing the MAC to previous on new router is easier than talking to this crowd of viscous idiots.

Ogogon.

 

[SirDice]

I admit honestly, turning to the forum, I counted on an answer on the merits of the question, and not on questions about why this is necessary...

People often ask about the wrong things; XY problem.

ifconfig(8):

             The link-level (link) address is specified as a series of colon-
             separated hex digits.  This can be used to, for example, set a
             new MAC address on an Ethernet interface, though the mechanism
             used is not Ethernet specific.

             ether   Synonymous with link (with some exceptions, see -l).

So something like ifconfig_em0="ether de:ad:be:ef DHCP"
Although I'm not sure if this will work with DHCP in there.

 

[ogogon]

So something like ifconfig_em0="ether de:ad:be:ef DHCP"
Although I'm not sure if this will work with DHCP in there.

Well... We'll find out in about two hours.
I believe that the new router is already riding in the trunk of a Land Rover to a new duty station.

 

[T-Daemon]

Changing the mac address of a DHCP leased network interface doesn't work. It only works with static IP addresses.

Example:
/etc/rc.conf

ifconfig_em0="ether be:ef:be:ef:be:ef"
ipv4_addrs_em0="193.35.157.168/24"

References:

set MAC address at boot

I cannot figure out how to set MAC at boot. Any help please. I've all sorts in rc.conf: #ifconfig_em0="link be:ef:be:ef:be:ef" #ifconfig_em0="inet 193.35.157.168 netmask 255.255.255.0" #ifconfig_em0="inet 193.35.157.168 netmask 255.255.255.0 link 2b:3b:4b:5b:6b:7b" Can't set link and inet...

forums.freebsd.org

Solved - ether random

How to configure in /etc/rc.conf an interface with "ether random" so that the MAC address is not the same as the main interface? For example when creating a VLAN I use something like: cloned_interfaces="vlan0" create_args_vlan0="vlan 4000 vlandev em0 mtu 1400 fib 1" ifconfig_vlan0="ether...

forums.freebsd.org

 

[zirias@]

Changing the mac address of a DHCP leased network interface doesn't work.

It doesn't work from /etc/rc.conf because /etc/network.subr doesn't support it, but there's no reason it can't work in general.

Have a look at dhclient-script(8). Something like this in /etc/dhclient-enter-hooks should do:
[ "$reason" = PREINIT ] && ifconfig $interface ether ab:cd:ef:ab:cd:ef (untested)

 

[T-Daemon]

Something like this in /etc/dhclient-enter-hooks should do:

/etc/dhcp-enter-hooks

[ ."$reason" = .PREINIT ] && $interface ether ab:cd:ef:ab:cd:ef

gets following

em0: flags=8863<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=481009b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,VLAN_HWFILTER,NOMAP>
    ether ab:cd:ef:ab:cd:ef
    hwaddr 08:00:27:fc:97:5a
    inet 192.168.34.26 netmask 0xffffff00 broadcast 192.168.34.255
    media: Ethernet autoselect (1000baseT <full-duplex>)
    status: active
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

I'm testing this in a VM. The host is 13.1-RELEASE, the guest 13.2-RELEASE. The "ether" changes to specified address, original "ether" is now "hwaddr". That's all well and good, but now there is no more network communication between host and guest. ping(8) returns "Host is down".

Same with the /etc/rc.conf settings above in post # 6.

Not sure if the cause in my case is some limitation of the DHCP server, which is running on a Android phone. The host is connected at the phones mobile hotspot. On the other hand the static IP address is affected as well.

 

[zirias@]

/etc/dhcp-enter-hooks

[ ."$reason" = .PREINIT ] && $interface ether ab:cd:ef:ab:cd:ef

Uhm, there's ifconfig missing. But as you are getting the expected result, that's probably just a copying error?

BTW, the dots here (also shown in the manpage) are some kind of cargo cult. Their origin is buggy shells where the (nowadays typically builtin) test can't correctly compare equality if one side is empty. This certainly doesn't apply to FreeBSD's /bin/sh. They are (or, IMHO, were) only required to make a script portable to some ancient Unix systems that had such a buggy shell.

I'm testing this in a VM. The host is 13.1-RELEASE, the guest 13.2-RELEASE. The "ether" changes to specified address, original "ether" is now "hwaddr". That's all well and good, but now there is no more network communication between host and guest. ping(8) returns "Host is down".

I'm pretty sure this is not related to dhcp, there must be some other networking issue...

 

[T-Daemon]

Uhm, there's ifconfig missing. But as you are getting the expected result, that's probably just a copying error?

Sorry for the late reply.

Yes, the ifconfig got lost when transcribing. At the time drafting a response, there was no communication between host and guest, no way to transfer the configuration file. I transcribed this line of code and obviously overlooked it.

BTW, the dots here (also shown in the manpage) are some kind of cargo cult. Their origin is buggy shells where the (nowadays typically builtin) test can't correctly compare equality if one side is empty. This certainly doesn't apply to FreeBSD's /bin/sh. They are (or, IMHO, were) only required to make a script portable to some ancient Unix systems that had such a buggy shell.

I wish I knew what you are talking about. Nevertheless, I appreciate the detailed information on this topic. I'm sure others appreciate it also, thank you for taking the time. Maybe in the future I will understand what it is all about.

This also applies to other topics. I may not log in to like or thank you, but I do follow many of your posts with interest, as I do with other forum users.

I'm pretty sure this is not related to dhcp, there must be some other networking issue...

It looks that way. As said, I'm testing in a VM, VirtualBox VM to be precise. The VMs network adapter is attached to a bridged adapter, a wireless device (wlan0) in my case.

Consulting the VitualBox manual I found a note regarding

6.5. Bridged Networking
...
Note

Bridging to a wireless interface is done differently from bridging to a wired interface, because most wireless adapters do not support promiscuous mode. All traffic has to use the MAC address of the host's wireless adapter, and therefore Oracle VM VirtualBox needs to replace the source MAC address in the Ethernet header of an outgoing packet to make sure the reply will be sent to the host interface. When Oracle VM VirtualBox sees an incoming packet with a destination IP address that belongs to one of the virtual machine adapters it replaces the destination MAC address in the Ethernet header with the VM adapter's MAC address and passes it on. Oracle VM VirtualBox examines ARP and DHCP packets in order to learn the IP addresses of virtual machines.

Apparently when the MAC address in a VirtualBox VM is spoofed, a network adapter attached to a bridged adapter needs to allow promiscuous mode.

Setting the VMs network bridged adapter (wlan0) to allow promiscuous mode restores communication with the internet (couldn't try with a wired interface, there is no hardware I can connect to the machines (laptop) Ethernet port).

But communication between host and guest remains interrupted, couldn't figure out why, haven't looked into it further.

Modifying promiscuous mode settings of a running VM modifies the hosts network interface instantly, and no reboot of the VM required:

wlan0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500

 

[SirDice]

I wish I knew what you are talking about. Nevertheless, I appreciate the detailed information on this topic. I'm sure others appreciate it also, thank you for taking the time. Maybe in the future I will understand what it is all about.

With the check, [ $reason = BAR ] if $reason was empty it would get interpreted as [ = BAR] which would be a syntax error and the script would error out. To prevent this from happening you added a bogus string; [ X$reason = XBAR ]. If the $reason variable is empty it would be interpreted as [ X = XBAR], which is a valid check, no more syntax errors. However, if you properly quote the variable the check will work, regardless if the variable is empty or not; [ "$reason" = BAR ]

Yet people still use this 'trick' without realizing it's not needed anymore (or was ever needed) (hence the cargo cult reference).

cargo cult programming

$ unset FOO
$
$ [ $FOO = BAR ]
[: =: unexpected operator
$ [ X$FOO = XBAR ]
$ [ "$FOO" = BAR ]
$

 

[T-Daemon]

Alright, with your example I understand what zirias explained. Thank you very much for the illustration SirDice.

 

[zirias@]

Yet people still use this 'trick' without realizing it's not needed anymore (or was ever needed)

The sad thing is, it was needed on some (ancient?) Unix systems with broken shell/test. They still misbehaved even with quotes added. The funny thing is, the example in the manpage does both, quoting* and adding some gratuitous character .

The sane thing nowadays is, just quote properly, that way it's readable

(This was a gratuitous "the sad, the funny and the sane" posting, hehe)

*edit: the quoting of course also protects against errors caused by whitespace in the expanded variable. But dhcp will never set anything containing whitespace for this variable, so doing both is indeed kind of funny here...