Spoofmac on VLANs don't work in 2.2.4
-
Have you tried with the "parent" interface in "promiscuous mode" ?
Something like:
ifconfig re2 promisc ifconfig re2_vlan11 ether 01:23:45:67:89:25 ifconfig re2_vlan12 ether 01:23:45:67:89:26and so on….
-
@ptt:
Have you tried with the "parent" interface in "promiscuous mode" ?
ifconfig re2 promisc ifconfig re2_vlan11 ether 01:23:45:67:89:25 ifconfig re2_vlan12 ether 01:23:45:67:89:26Hey dude!
Looks like you found the solution!
Thanks!
Now the question is: how can I make sure the parent interface is in promiscous mode when the VLAN interfaces are configured?
-
Check this Thread/Topic https://forum.pfsense.org/index.php?topic=89593.msg498453#msg498453 Use google translator ;)
-
https://redmine.pfsense.org/issues/2859
-
Thanks for the pointers!
BTW: Google traslator is horrible…
I try to sum up possible solutions:
-
Use startcommand to set interface to promicoius mode at boot time. This is not a real solution, just a work around. I'm not sure how robust this is. What happens when the interface is disabled and enabled again? Maybe by some schedules or when an update/upgrade/package is installed or something?
-
When a VLAN interface with spoofmac is brought up, check whether the parent OR some other VLAN on the same parent uses a different spoofmac. This check might be complicated and error prone.
-
Thinking about the problem for a while brought me to the conclusion that the complicated check in solution 2 might be totally unnecessary. I could not come up with a use case for setting spoofmac without needing it to be unique. Therefore, promiscous mode would always be necessary when spoofmac is used on a VLAN.
Based on those considerations, the solution might look like this:
diff --git a/src/etc/inc/interfaces.inc b/src/etc/inc/interfaces.inc index 9185738..74648d3 100644 --- a/src/etc/inc/interfaces.inc +++ b/src/etc/inc/interfaces.inc @@ -220,6 +220,21 @@ function interfaces_vlan_configure($realif = "") { } } +function get_spoofmac_for_interface($ifname) { + global $config, $g; + + if (is_array($config['interfaces']) && count($config['interfaces'])) { + foreach ($config['interfaces'] as $if) { + if (empty($if['if'])) { continue; } // should never happen? + if ($ifname !== $if['if']) { continue; } // wrong interface + if (empty($if['spoofmac'])) { break; } // spoofmac empty + return $if['spoofmac']; + } + } + + return ""; +} + function interface_vlan_configure(&$vlan) { global $config, $g; @@ -238,6 +253,12 @@ function interface_vlan_configure(&$vlan) { /* make sure the parent interface is up */ interfaces_bring_up($if); + + /* Set parent in promiscous mode if VLAN-if has spoofed MAC */ + if (get_spoofmac_for_interface($vlanif) !== "") { + mwexec("/sbin/ifconfig {$if} promisc\n"); + } + /* Since we are going to add vlan(4) try to enable all that hardware supports. */ pfSense_interface_capabilities($if, IFCAP_VLAN_HWTAGGING|IFCAP_VLAN_MTU|IFCAP_VLAN_HWFILTER); diff --git a/src/usr/local/www/interfaces.php b/src/usr/local/www/interfaces.php index c9cc38c..39e5db8 100644 --- a/src/usr/local/www/interfaces.php +++ b/src/usr/local/www/interfaces.php @@ -1831,7 +1831,9 @@ $group = new Form_Group('MAC controls'); $group->add($macaddress); // $group->add($btnmymac); $group->setHelp('This field can be used to modify ("spoof") the MAC address of this interface.' . ' ' . - 'Enter a MAC address in the following format: xx:xx:xx:xx:xx:xx or leave blank'); + 'Setting this field for a VLAN interface will bring the parent interface to promiscous mode.' . ' ' . + 'Promiscous mode may cause a performance penalty.' . ' ' . + 'Enter a MAC address in the following format: xx:xx:xx:xx:xx:xx or leave blank'); $section->add($group); $section->addInput(new Form_Input(This is not tested yet.
BTW: I am not sure what comment #15 is talking about.
BTW1: I am not a PHP programmer, so I checked google for how to properly compare strings in PHP. Over there on stackoverflow, I found lots of warnings to use == and != for this purpose. In pfsense code, I can find those two operators very often. Not sure whether this is a real problem. Just thought I'd drop a note.
BTW2: The function pfSense_interface_flags don't seem to be defined anywhere in the git repository. Is this function created at runtime by some magic or something?
-
-
So I now had a chance to test the patch in #7, and unfortunately, it don't work.
The parent interface has the prmiscous mode set:
re2: flags=28943 <up,broadcast,running,promisc,simplex,multicast,ppromisc>metric 0 mtu 1500</up,broadcast,running,promisc,simplex,multicast,ppromisc>but the result is the same as described at the beginning of the thread: every time a new vlan-interface with spoofmac is added, the parent and all the other VLAN-interfaces gets the spoofmac of the added interface.
On the other hand:
When I use the "ifconfig re2_vlanXX" command from the command line, it works fine!
Where can I find a description how to debug pfsense?
Any hints?
-
Out of curiosity, what is the application that requires unique MAC addresses for each VLAN ?
-
Out of curiosity, what is the application that requires unique MAC addresses for each VLAN ?
If you want static IPv4 addresses in Baden Wuerttemberg (Germany) the only choice is the provider KabelBW. To get static IPs, you have to provide MAC addresses, which are used to assign you the IPs via DHCP and control the routing.
I know, this is brain dead. You can dive into the details in this (german) thread
-
I've now replaced the original /sbin/ifconfig by a little script which traces ifconfig invocations.
I find it surprising to see that pfsense don't use "ifconfig re2_vlanXX ether XXXXXXX" on the VLAN interface to set the MAC. Instead, it uses "ifconfig re2 link XXXXXXXXX" on the parent before bringing the vlan interface up.
Those are the ifconfig invocations when the system is booted:
Wed Nov 4 22:42:43 CET 2015 ifconfig re2 promisc Wed Nov 4 22:42:43 CET 2015 ifconfig re2 promisc Wed Nov 4 22:42:43 CET 2015 ifconfig re2 promisc Wed Nov 4 22:42:43 CET 2015 ifconfig re2 promisc Wed Nov 4 22:42:43 CET 2015 ifconfig re1 inet6 -accept_rtadv Wed Nov 4 22:42:46 CET 2015 ifconfig re1 inet 0.0.0.0 netmask 255.0.0.0 broadcast 255.255.255.255 up Wed Nov 4 22:42:48 CET 2015 ifconfig re1 inet 192.168.0.203 netmask 255.255.255.0 broadcast 192.168.0.255 Wed Nov 4 22:42:48 CET 2015 ifconfig re1 setfirst 192.168.0.203 Wed Nov 4 22:42:48 CET 2015 ifconfig re1 inet6 accept_rtadv Wed Nov 4 22:42:48 CET 2015 ifconfig re1 -staticarp Wed Nov 4 22:42:48 CET 2015 ifconfig re0 inet6 -accept_rtadv Wed Nov 4 22:42:48 CET 2015 ifconfig re0 -staticarp Wed Nov 4 22:42:48 CET 2015 ifconfig re2_vlan11 inet6 -accept_rtadv Wed Nov 4 22:42:48 CET 2015 ifconfig re2_vlan11 -staticarp Wed Nov 4 22:42:48 CET 2015 ifconfig re2_vlan12 inet6 -accept_rtadv Wed Nov 4 22:42:48 CET 2015 ifconfig re2_vlan12 -staticarp Wed Nov 4 22:42:48 CET 2015 ifconfig re2_vlan13 inet6 -accept_rtadv Wed Nov 4 22:42:48 CET 2015 ifconfig re2_vlan13 -staticarp Wed Nov 4 22:42:48 CET 2015 ifconfig re2_vlan14 inet6 -accept_rtadv Wed Nov 4 22:42:48 CET 2015 ifconfig re2_vlan14 -staticarp Wed Nov 4 22:42:48 CET 2015 ifconfig re2_vlan21 inet6 -accept_rtadv Wed Nov 4 22:42:48 CET 2015 ifconfig re2 link 01:23:45:67:89:21 Wed Nov 4 22:42:52 CET 2015 ifconfig re2_vlan21 inet 0.0.0.0 netmask 255.0.0.0 broadcast 255.255.255.255 up Wed Nov 4 22:43:49 CET 2015 ifconfig re2_vlan21 -staticarp Wed Nov 4 22:43:49 CET 2015 ifconfig re2_vlan22 inet6 -accept_rtadv Wed Nov 4 22:43:49 CET 2015 ifconfig re2 link 01:23:45:67:89:22 Wed Nov 4 22:43:53 CET 2015 ifconfig re2_vlan22 inet 0.0.0.0 netmask 255.0.0.0 broadcast 255.255.255.255 up Wed Nov 4 22:44:50 CET 2015 ifconfig re2_vlan22 -staticarp Wed Nov 4 22:44:50 CET 2015 ifconfig re2_vlan23 inet6 -accept_rtadv Wed Nov 4 22:44:50 CET 2015 ifconfig re2 link 01:23:45:67:89:23 Wed Nov 4 22:44:54 CET 2015 ifconfig re2_vlan23 inet 0.0.0.0 netmask 255.0.0.0 broadcast 255.255.255.255 up Wed Nov 4 22:45:51 CET 2015 ifconfig re2_vlan23 -staticarp Wed Nov 4 22:45:51 CET 2015 ifconfig re2_vlan24 inet6 -accept_rtadv Wed Nov 4 22:45:51 CET 2015 ifconfig re2 link 01:23:45:67:89:24 Wed Nov 4 22:45:55 CET 2015 ifconfig re2_vlan24 inet 0.0.0.0 netmask 255.0.0.0 broadcast 255.255.255.255 up Wed Nov 4 22:46:52 CET 2015 ifconfig re2_vlan24 -staticarp Wed Nov 4 22:46:52 CET 2015 ifconfig pfsync0 -syncdev -syncpeer down Wed Nov 4 22:46:58 CET 2015 ifconfig re0 -staticarp Wed Nov 4 22:46:58 CET 2015 ifconfig re2_vlan11 -staticarp Wed Nov 4 22:46:58 CET 2015 ifconfig re2_vlan12 -staticarp Wed Nov 4 22:46:58 CET 2015 ifconfig re2_vlan13 -staticarp Wed Nov 4 22:46:58 CET 2015 ifconfig re2_vlan14 -staticarp Wed Nov 4 22:47:00 CET 2015 ifconfig enc0 down Wed Nov 4 22:48:20 CET 2015 ifconfig re1 Wed Nov 4 22:48:20 CET 2015 ifconfig re0 Wed Nov 4 22:48:20 CET 2015 ifconfig re2_vlan11 Wed Nov 4 22:48:20 CET 2015 ifconfig re2_vlan12 Wed Nov 4 22:48:21 CET 2015 ifconfig re2_vlan13 Wed Nov 4 22:48:21 CET 2015 ifconfig re2_vlan14 Wed Nov 4 22:48:21 CET 2015 ifconfig re2_vlan21 Wed Nov 4 22:48:21 CET 2015 ifconfig re2_vlan22 Wed Nov 4 22:48:21 CET 2015 ifconfig re2_vlan23 Wed Nov 4 22:48:21 CET 2015 ifconfig re2_vlan24 Wed Nov 4 22:48:32 CET 2015 ifconfig re1 Wed Nov 4 22:48:32 CET 2015 ifconfig re0 Wed Nov 4 22:48:33 CET 2015 ifconfig re2_vlan11 Wed Nov 4 22:48:33 CET 2015 ifconfig re2_vlan12 Wed Nov 4 22:48:33 CET 2015 ifconfig re2_vlan13 Wed Nov 4 22:48:33 CET 2015 ifconfig re2_vlan14 Wed Nov 4 22:48:33 CET 2015 ifconfig re2_vlan21 Wed Nov 4 22:48:33 CET 2015 ifconfig re2_vlan22 Wed Nov 4 22:48:33 CET 2015 ifconfig re2_vlan23 Wed Nov 4 22:48:33 CET 2015 ifconfig re2_vlan24 -
There are a couple of issues in your scenario that I see as challenges beyond the MAC address issue…
First, each vlan requires a different tag number. That means the re2 port will send packets with vlan tag set depending on which vlan traffic is going out. How are you going to remove this tag before the packet gets to the modem, otherwise the modem is likely going to ignore it?
Second, assuming that you do manage the flatten out the vlans, you now have basically linked several different layer 2 networks together (short-circuit), not sure how well that's going to behave in the presence of broadcast packets. Specifically DHCP discovery requests which are initiated using broadcast.
Third, should the above plan work and you get your static IPs from the provider, unless they are each on a different subnet, you will end up with a bunch of interfaces all on the same layer 3 subnet, but on different layer 2 networks from the perspective of pfSense. Again, not sure how that's going to work out.A more "sane" solution would be to talk to the provider, and ask them to route a static /29 subnet to the static IP you get from DHCP. Since you will always get the same IP, presumably based on how you describe their service, there is no reason why they can leave a permanent route in their routing table.
-
First, each vlan requires a different tag number. That means the re2 port will send packets with vlan tag set depending on which vlan traffic is going out. How are you going to remove this tag before the packet gets to the modem, otherwise the modem is likely going to ignore it?
The packets go to a tagged port of a managed switch via the parent interface. This managed switch puts each VLAN onto its own untagged port. Those untagged ports are connected to an unmanaged switch, which in turn is connected to the modem and represents the LAN segment of the provider.
Logically, this should be the same as if the router had multiple interfaces connected to an unmanaged switch (that is: multiple virtual interfaces connected to the same LAN segment). This should be no problem, as long as the interfaces have unique MACs. This way, every VLAN-interface could get its own DHCP lease from the provider.
Second, assuming that you do manage the flatten out the vlans, you now have basically linked several different layer 2 networks together (short-circuit), not sure how well that's going to behave in the presence of broadcast packets. Specifically DHCP discovery requests which are initiated using broadcast.
The result should be one layer 2 network. Broadcasts should appear on all the VLAN interfaces. This is standard behaviour for unmanaged switches.
Third, should the above plan work and you get your static IPs from the provider, unless they are each on a different subnet, you
will end up with a bunch of interfaces all on the same layer 3 subnetThat's exaclty what I'm trying to achieve. For the provider, it should look like I had multiple PCs connected directly to the modem.
but on different layer 2 networks from the perspective of pfSense. Again, not sure how that's going to work out.
I don't quite understand what you are trying to tell me here. As stated above, the result should be a single layer 2 network.
The routing should be done like this:
VLAN11 <-> VLAN21 (static IP 1)
VLAN12 <-> VLAN22 (static IP 2)
VLAN13 <-> VLAN23 (static IP 3)
VLAN14 <-> VLAN24 (static IP 4)Here, VLAN2x would be the interfaces with unique MACs. For VLAN1x, there's no need to have unique MACs.
This way, I'd have four separate VLANs (VLAN1x), each of them accessible by their own static IP.
A more "sane" solution would be to talk to the provider, and ask them to route a static /29 subnet to the static IP you get from DHCP. Since you will always get the same IP, presumably based on how you describe their service, there is no reason why they can leave a permanent route in their routing table.
Believe me, I tried to talk to them for almost a year now. And many other people tried that, too. The internet is full of such discussions.
They simply assume you connect your PCs directly to the WAN without any router/firewall.
And they call that their "business contract" >:(So I've given up to convince them to route a /29 to me :(
-
Third, should the above plan work and you get your static IPs from the provider, unless they are each on a different subnet, you
will end up with a bunch of interfaces all on the same layer 3 subnetThat's exactly what I'm trying to achieve. For the provider, it should look like I had multiple PCs connected directly to the modem.
So this is way out of scope of pfSense, but I took a crack at it directly on a FreeBSD 10 box.
I setup a bridge interface with a bunch of vlans, each with a different MAC and the physical interface all attached together, that is basically the same thing, it flattens down all the vlans into a single layer 2, out the physical interface.
The only problem is that broadcast traffic (the dhcp kind) isn't properly seen.
I can see DHCP requests hitting my server, with the MAC address of the VLAN, and the responses going back, but for some reason the packets aren't seen by the vlan interface.
While I realise this is the critical part for your setup, but I'm more concerned about what happens next…Leaving the DHCP issue aside for a moment, I setup each vlan interface with a static IP, in the same subnet.
I can ping the default gateway with from each interface by specifying ping -S source_ip dest_ip.
However, packets arriving at the destination IP are originating from only a single MAC address, despite selecting different source addresses.
I even tried with private vlans on the bridge interface, makes no difference.
That tells me that the FreeBSD kernel picks one interface (out of many) that are on the same layer3 subnet and uses it for all communications.
This can be checked using route -n get dest_ip, in which case a single Interface is returned.In the end, I think there are still bigger challenges in Layer3 to overcome, even if you manage to get the Layer2 working.
My only other suggestion would be to look for a tunnel service provider that offers static IPs that you can tunnel over your existing connection.
-
I setup a bridge interface with a bunch of vlans, each with a different MAC and the physical interface all attached together, that is basically the same thing, it flattens down all the vlans into a single layer 2, out the physical interface.
And you had a dhcp client bound to each of those vlan interfaces?
The only problem is that broadcast traffic (the dhcp kind) isn't properly seen.
Only the DHCPDISCOVER should use broadcast. The replies from the DHCP server shoud have the destination MAC of the sending interface. At least as long as the broadcast bit is not set.
But if (as you mention below) the outgoing packet is sent with the wrong MAC, the response would obviously not arrive at the proper destination.I can see DHCP requests hitting my server, with the MAC address of the VLAN, and the responses going back, but for some reason the packets aren't seen by the vlan interface.
The responses have the correct MAC? Wouldn't that be a bug? Maybe the managed switch eats the packet?
Leaving the DHCP issue aside for a moment, I setup each vlan interface with a static IP, in the same subnet.
I can ping the default gateway with from each interface by specifying ping -S source_ip dest_ip.
However, packets arriving at the destination IP are originating from only a single MAC address, despite selecting different source addresses.So you have something like:
reX_vlanXX with MACXX and IPXX
and you use "ping -s IPXX dest_ip"
and the packet arrives with something different than MACXX?
Wouldn't that be a bug?
I even tried with private vlans on the bridge interface, makes no difference.
That tells me that the FreeBSD kernel picks one interface (out of many) that are on the same layer3 subnet and uses it for all communications.This can be checked using route -n get dest_ip, in which case a single Interface is returned.
You are talking about outbound traffic? The pfsense outbound NAT dialog offers "interface address" as the "translation" filed. Shouldn't this give the correct address when the NAT rule is bound to the VLAN-interface instead of the parent interface?
-
I setup a bridge interface with a bunch of vlans, each with a different MAC and the physical interface all attached together, that is basically the same thing, it flattens down all the vlans into a single layer 2, out the physical interface.
And you had a dhcp client bound to each of those vlan interfaces?
The only problem is that broadcast traffic (the dhcp kind) isn't properly seen.
Only the DHCPDISCOVER should use broadcast. The replies from the DHCP server shoud have the destination MAC of the sending interface. At least as long as the broadcast bit is not set.
But if (as you mention below) the outgoing packet is sent with the wrong MAC, the response would obviously not arrive at the proper destination.Correct, the DHCP packets arrived at the destination but with the expected source MAC corresponding to each interface.
This is because the DHCP server controls what MAC address is going to be used to send the packet, as it is building the packets from scratch.I can see DHCP requests hitting my server, with the MAC address of the VLAN, and the responses going back, but for some reason the packets aren't seen by the vlan interface.
The responses have the correct MAC? Wouldn't that be a bug? Maybe the managed switch eats the packet?
Maybe, I didn't troubleshoot that aspect any further.
Leaving the DHCP issue aside for a moment, I setup each vlan interface with a static IP, in the same subnet.
I can ping the default gateway with from each interface by specifying ping -S source_ip dest_ip.
However, packets arriving at the destination IP are originating from only a single MAC address, despite selecting different source addresses.So you have something like:
reX_vlanXX with MACXX and IPXX
and you use "ping -s IPXX dest_ip"
and the packet arrives with something different than MACXX?
Wouldn't that be a bug?
Exactly, although my interface was emX, it doesn't make any difference.
It might be a bug, or just how it was chosen to be implemented in this case. I'm not a kernel guru, so I can't say.I even tried with private vlans on the bridge interface, makes no difference.
That tells me that the FreeBSD kernel picks one interface (out of many) that are on the same layer3 subnet and uses it for all communications.This can be checked using route -n get dest_ip, in which case a single Interface is returned.
You are talking about outbound traffic? The pfsense outbound NAT dialog offers "interface address" as the "translation" filed. Shouldn't this give the correct address when the NAT rule is bound to the VLAN-interface instead of the parent interface?
Yes, you're right, pfSense does offer outbound NAT to choose the interface IP address as the translation field, but this would make little difference, pfSense only re-writes the Layer3 part of the packet, the Layer2 part is left up to the Kernel. The testing that I did reveals that irrespective of what interface source IP address you select, the Kernel picks the path that it thinks is the "best" from it's internal tables in order to reach the chosen destination.
-
@deejohn
Please have a look at your older thread here in the german section of this forum, I was answering this
question there in German, perhaps for us both better to understand and to solve it out.But for the other forum members here I will give a short description
- Call Unity Media (KabelBW) sign up a business contract for a business Internet connection.
- Provide them only the MAC address of the WAN port from the modem in front of pfSense or from the WAN Port
of your pfSense firewall and then let them assign the public static IP addresses to that MAC address! - Insert this IP addresses in the pfSense firewall and do a 1:1 NAT with setting up routes and port forwarding
to the internal private IP addresses insite of your LAN or DMZ! - Thats it all is going fine for you like for all other KabelBW customers!
The only thing you must be know or clear up is the following point:
Which MAC address they need really from your setup?- The MAC address from the WAN port at the Modem
- The MAC address from the WAN port of the pfSense firewall
Thats it.
In normal administrators are able follow two way, but not here, based on the regulations of the ISP!
- Setting up and configure out the public static IP addresses at the pfSense firewall
- And setting up and configure out the public static IP addresses at the endpoint or device inside of your LAN or DMZ (but this way is not given here owed to thee following statement of the ISP)
Eine statische Eintragung der IP-Adresse am Endgerät ist nicht möglich.
A set up of the public static IP address at the endpoint is not able to do or supportedSo all five public IP addresses are able to set up in the pfSense related and associated to the MAC Address
of there WAN port or the WAN port of the Modem in front of the pfSense.Jede statische IP-Adresse kann nur jeweils einem Ihrer Endgeräte mit eigener MAC-Adresse zugewiesen werden.
Each static IP-Address is only able to set up on and provide to one of your endpoints with an own MAC Address.Also it is only able to associate on IP to a MAC address, but also 5 public IP address can be associated to one
MAC address of the WAN port from am Modem or the pfSense firewall.Der Unitymedia DHCP Server weist der angemeldeten MAC-Adresse automatisch Ihre beantragte statische IP-Adresse zu.
The DHCP Server from UnityMedia is associating the public IP address to the provided MAC address by the customer -
@BlueKobold:
@deejohn
Please have a look at your older thread here in the german section of this forum, I was answering this question there in German, perhaps for us both better to understand and to solve it out.Please go and re-read the german thread. Please note that you are talking about unitymedia while I am talking about KabelBW.
short summary:
1. While Unitymedia(in NRW and Hessen) will assign you a /29 and route it to you, Unitymedia in Baden Wuerttemberg (previously KabelBW) won't route any packets to you unless you get a DHCP lease.
2. KabelBW's web interface won't allow you to use a MAC for multiple IP-addresses. And this rightfully, because that would be against the DHCP specification.- Call Unity Media (KabelBW) sign up a business contract for a business Internet connection.
I have a business contract.
-
Can we please come back to the question why pfsense does
ifconfig re2 link 01:23:45:67:89:21when it should do
ifconfig re2_vlan21 link 01:23:45:67:89:21?
Please check the transcript attached to #11
-
It's probably worth posting a link to your findings in Redmine #2859.
The code in question is in the interface_configure() function of /etc/inc.interfaces.inc (around line 2907):
$mac = get_interface_mac($realhwif); /* * Don't try to reapply the spoofed MAC if it's already applied. * When ifconfig link is used, it cycles the interface down/up, which triggers * the interface config again, which attempts to spoof the MAC again, * which cycles the link again... */ if ($wancfg['spoofmac'] && ($wancfg['spoofmac'] != $mac)) { mwexec("/sbin/ifconfig " . escapeshellarg($realhwif) . " link " . escapeshellarg($wancfg['spoofmac'])); } else { if ($mac == "ff:ff:ff:ff:ff:ff") { /* this is not a valid mac address. generate a * temporary mac address so the machine can get online. */ echo gettext("Generating new MAC address."); $random_mac = generate_random_mac_address(); mwexec("/sbin/ifconfig " . escapeshellarg($realhwif) . " link " . escapeshellarg($random_mac)); $wancfg['spoofmac'] = $random_mac; write_config(); file_notice("MAC Address altered", sprintf(gettext('The INVALID MAC address (ff:ff:ff:ff:ff:ff) on interface %1$s has been automatically replaced with %2$s'), $realif, $random_mac), "Interfaces"); } }The thought occurs that replacing $realhwif (and the one seemingly incorrect occurrence of $realif) with $interface_to_check throughout that block of code might make the behaviour more correct - act on the interface itself except in the case of PPPoE, where you need to be acting on the parent interface.
