I have a new fiber internet provider. I was able to avoid using their modem by changing the mac address on the red interface and it has been working fine for a couple of weeks.
Today I upgraded to 194 from 193 and everything seemed to go fine except the red interface would not connect. I double checked the mac address, but there was not even a link light on the ONT.
Fortunately, I was able to swap my backup system in which is running 192 and as soon as I fixed the mac address or red, it picked up a connection and I am back on line.
It appears to me that the mac address spoof is not working and DHCP failed.
I am loathe to upgrade the backup system.
What is the log for RED?
Let me get back to you on that. I will need to extract the system and get into it as it is down at the moment.
| 05:48:21 | dhcpcd[25046] | : sending signal ALRM to pid 2157 |
|---|---|---|
| 05:48:21 | dhcpcd[25046] | : waiting for pid 2157 to exit |
| 05:48:21 | dhcpcd[2158] | : received SIGALRM, releasing |
| 05:48:21 | dhcpcd[2158] | : red0: removing interface |
| 05:48:21 | dhcpcd[2158] | : red0: releasing lease of 64.222.235.216 |
| 05:48:21 | dhcpcd[2158] | : red0: deleting route to 64.222.232.0/22 |
| 05:48:21 | dhcpcd[2158] | : red0: deleting default route via 64.222.232.1 |
| 05:48:24 | dhcpcd[2158] | : main: control_stop: No such file or directory |
| 05:48:24 | dhcpcd[2158] | : dhcpcd exited |
logs for red
This can’t be all.
Execute via Terminal
dhcpcd start red0
And see again.
I am copying what is in the system log for red on web interface.
Above command entered in SSH session gives command not found
Can you be more specific on where to look for log. The system is not connected at the moment so there will not be any new logs. I have a laptop connected to it at the moment and can SSH into it.
Ah guess it’s without _
There is not a traditional initscript for dhcpcd.
The commands to release the red0 interface and then rebind it are
dhcpcd -k red0
dhcpcd -n red0
then you can see if the red0 interface gets connected or not after the second command.
Alternatively a reboot will do the same thing.
I did try rebooting a couple of times as well as re-applying the mac address, but nothing worked. It is as if the mac address is not correct and the ONT does not recognize it.
If the ONT thinks the mac address is incorrect then after running those two commands I specified above, there should be something in your red logs to show what the communication process was between IPFire and your ISP’s connection.
I have a fibre connection from my ISP and it ends with a code converter to convert from light signals to ethernet signals and then it goes into my IPFire. The re-connection after reboot at the end of the CU194 update went without any problems.
Here is my log from the update which starts the same way to yours but has dhcpcd starting again.
11:54:28 dhcpcd[24379] : sending signal ALRM to pid 2182
11:54:28 dhcpcd[24379] : waiting for pid 2182 to exit
11:54:28 dhcpcd[2183] : received SIGALRM, releasing
11:54:28 dhcpcd[2183] : red0: removing interface
11:54:28 dhcpcd[2183] : red0: releasing lease of xxx.xxx.yyy.yyy
11:54:28 dhcpcd[2183] : red0: deleting route to xxx.xxx.zzz.zzz/23
11:54:28 dhcpcd[2183] : red0: deleting default route via xxx.xxx.zzz.www
11:54:33 dhcpcd[2183] : main: control_stop: No such file or directory
11:54:33 dhcpcd[2183] : dhcpcd exited
11:55:48 dhcpcd[2177] : dhcpcd-10.2.2 starting
11:55:48 dhcpcd[2180] : DUID 00:01:00:01:2c:2c:3e:3a:00:0d:b9:5e:aa:dc
11:55:49 dhcpcd[2180] : red0: IAID ff:00:01:2c
11:55:51 dhcpcd[2180] : red0: soliciting a DHCP lease
11:55:51 dhcpcd[2180] : red0: offered xxx.xxx.yyy.yyy from xxx.xxx.zzz.www
11:55:51 dhcpcd[2180] : red0: ignoring offer of xxx.xxx.yyy.yyy from xxx.xxx.zzz.www
11:55:51 dhcpcd[2180] : red0: probing address xxx.xxx.yyy.yyy/23
11:55:56 dhcpcd[2180] : red0: leased xxx.xxx.yyy.yyy for 1800 seconds
11:55:56 dhcpcd[2180] : red0: adding route to xxx.xxx.zzz.zzz/23
11:55:56 dhcpcd[2180] : red0: adding default route via xxx.xxx.zzz.www
Your log just seems to stop after dhcpcd has exited.
It would be good if you could run the two dhcpcd commands to release and rebind the red0 interface and then see what the logs for the red interface contain.
05:48:21 dhcpcd[25046] : sending signal ALRM to pid 2157 05:48:21 dhcpcd[25046] : waiting for pid 2157 to exit 05:48:21 dhcpcd[2158] : received SIGALRM, releasing 05:48:21 dhcpcd[2158] : red0: removing interface 05:48:21 dhcpcd[2158] : red0: releasing lease of 64.222.235.216 05:48:21 dhcpcd[2158] : red0: deleting route to 64.222.232.0/22 05:48:21 dhcpcd[2158] : red0: deleting default route via 64.222.232.1 05:48:24 dhcpcd[2158] : main: control_stop: No such file or directory 05:48:24 dhcpcd[2158] : dhcpcd exited 08:17:09 dhcpcd[7472] : dhcpcd is not running 08:17:19 dhcpcd[7479] : dhcpcd-10.2.2 starting 08:17:19 dhcpcd[7482] : DUID 00:01:00:01:2c:47:d6:e6:00:15:17:6d:19:50 08:17:20 dhcpcd[7482] : red0: interface not found 08:17:20 dhcpcd[7482] : main: control_stop: No such file or directory 08:17:20 dhcpcd[7482] : dhcpcd exited
This is log showing that the dhcpcd commands do work.
I expect that I need to hook it back up to see what really is going one?
Try rebooting the ONT first, then reboot IPFire. Mine gets picky about the RED signature. Usually it’s a MAC address change but it’s worth a shot maybe?
Is the end of the duid the mac? If so it does not look like the spoofed address. As a matter of fact it appears to be the hardware mac.
I appreciate the help. As I have the backup running and I need to get to work. I will resume troubleshooting later.
Let me know here, if there are any other things to try.
Thanks!
In the past my IPfire on upgrades.
Also using spoofed mac address.
Red would not connect.
I would run “setup”
For some reasons my network card would be un assigned.
Reset in setup and it would work.
Have not had that problem in awhile.
DUID is the Dhcpcd Unique IDentifier and is only used to identify your connection uniquely. It has nothing to do with the mac address that is actually presented to your ISP.
The DUID can actually be one of three things depending on which is globally unique.
1 Link-layer address plus time
2 Vendor-assigned unique ID based on Enterprise Number
3 Link-layer address
Your DUID listed (and mine) are the second one in the above list.
Your log showed the above, which indicates that no red0 interface could be found. That should exist even if the red rj45 connector is pulled out.
As mentioned by @hvacguy , it would be worth running setup from the console and see if the red interface is assigned or not. From your log message the suspicion is that for some reason it has become unassigned.
I am wondering if there is a better place to put the ip-link commands so they do not get altered by an update?
I ran setup and the network interfaces are still configured.
I plugged the red into my lan just to see if it would pickup an address. There is no link light.
It is as if the interface port is dead.
Did you run the dhcpcd -n red0 after plugging the cable back in?
Maybe it has died.
You can test this by running setup and using the nic for green for red instead and vice versa. Swap the plugs around and see if you can then access the red connection, and also if the clients on green can still get an IP via the IPFire dhcp.
1 Like
Tried switching ports. Get a link light but no connection.
Former green now red port gets link light on reboot. but no connection.
I guess it is fresh install time!
OK, It only took a few minutes to reinstall 194.
It picked up all of the interfaces just fine on install and I set red and green to the same interfaces they were using before.
I set the address for green to 192.168.1.1 and let red get a address from the backup system on 192.168.0.1 subnet.
Everything appears normal. I will do some configuration and change the green subnet and see if the system will swap in and work as before. If so, I guess something went wrong in the upgrade process.
That will teach me to backup before every upgrade!
2 Likes