Is the new MAC address documented in ifconfig red0?
Looking at the source of the WUI and the programs called, the MAC address should be set.
The setting process should be logged to /var/log/messages also.
Try the mac address with the octets separated by the : character.
Because I see no - character being parse in the code. So check this and see if it works because the instructions will have to be changed on the web page.
For any one else wondering:
no split and octet check routine for - as the mac separator my @mac = split(/:/,$macsettings{"MAC"});
in mac.cgi
If : is used then the mac address is changed to use - and that is what is saved in the mac settings file. Also if you have used : in the entry box and then press save the mac value shown in the entry box will now have all the :'s replaced by -'s.
#!/usr/bin/env perl
use warnings;
use strict;
use feature qw/say/;
use NetAddr::MAC;
my $macaddr = '4c-f5-5b-8b-f8-60';
my $mac = NetAddr::MAC->new($macaddr);
say $mac->as_ieee; # 4c:f5:5b:8b:f8:60
I wasn’t able to reproduce the problem.
I changed the MAC of my red interface to the MAC of an inactive desktop’s NIC.
‘Reconnect’ and reboot didn’t give me an IP from the ISP, whether the old nor a new. Maybe my DOCSIS modem has to be restarted in this case also. I did not check, yet.
Other idea is that the DUID doesn’t reflect the MAC change. Is to be checked also.
Well when you change mac or ip address, you suppose to take the interface down and bring it back up, but delayed 2 seconds so any device connected drops the connected info.
So if IPFire has a red reset, it needs a delay inserted after bringing it down for 2 seconds before bringing red0 back online.
Its unfortunate that remote reset modem isn’t standardized.
curl -X POST -H "Content-Type: application/x-www-form-urlencoded" -d "action=reboot" "http://modem_ip_address/admin"
DOCSIS modems usually are configured to identify the custom device by MAC at boot-up. This identification is held during the whole runtime.
Therefore you can change the device at the ethernet port of the modem only, if you force a re-identification ( with a reboot ).
A remote reset isn’t possible.
IPFire doesn’t know about the type of the WAN connection
The API of the modem isn’t standardized. Furthermore, the modem often is the property of the ISP and basic configuration is reserved to the owner.
I haven’t played with running a reset command on the customer side, but I imagine it should work. Because there is only three types of resets established, the last one I haven’t mentioned was the telnet method that is used to log in from the isp side.
So I wonder if the modem hostname or 192.168.100.1 intermediate address can be reached. I tried to ping mine through SSH but it says its unreachable. Even though I know it is the static ip that is always there in the modem.
But there should be 2-5 second delay from bringing down red and bringing it back up so the modem will drop the old red0’s information.
Just for information.
In one location…
There is a CH7465 router belonging to the ISP.
The router is switched to bridge mode.
The CH7465 control panel is available at 192.168.100.1.
If I connect another device (computer, another IPFire, etc. ) instead of the IPFire during operation, the Internet connection stops working.
The Internet connection will only work when I turn off the power, turn on the power and synchronize the CH7465 with the ISP network .
It also worked without turning off and on after assigning the MAC address of the previous device.
Mine shows up in the Zone Config.
the only problem I’ve had in the past was .
On upgrades I would have to rerun setup to fix nic assigment.
and the other strange tine is the way it shows up in the WUI.
This shows that my speculation may be true.
DHCP requests do not sent the MAC directly only, but a ‘clientid’ or ‘DUID’ ( based on the MAC ) also. If this id isn’t changed by the MAC change, dhcpcd in IPFire sends an improper id.
Did not the find the configuration of dhcpcd, yet. I’ll ask in the dev mailing list about this.
EDIT: Found the config. The paths are set by make.
Some trials ( setting a new MAC on red0 ) show some problems with the ids; I suppose.
I deleted the duid file, which holds the superseeding info about the DUID. Did not help.
I changed to clientid in the config. No success.
Setting to the original address succeeded after reboot(!).
I suppose, to succeed it is necessary to toggle the physical connection between modem and IPFire to allow a ‘client change’.