Hi all ARM freaks,
I’m running a Nanopi R4S as a backup and very low power ipfire for longer times of absence for some years now without any problems, until one of the latest core updates killed my root password. And one of 199 or 200 cannot reestablish the second Realtek NIC after a shutdown and power cycle. I always must run setup again, remove the second NIC and set it up again.
What is going wrong, and where/in which file I can fix it?
Best regards
Hello jopa,
Some information from your logs might be helpful in figuring out why your second nic doesn’t start. Can you check your /var/log/bootlog and /var/log/messages for any messages related to the nic your having problems with. I would search for the driver name and/or the interface name (i.e. red0/green0).
Also check to see if the interface is getting renamed the way that it should. If you ‘ls /sys/class/net’ you will see the interface names. And if you have, for example, an eth0 or eth1 interface but missing a green0 or red0 interface it would mean that the interface isn’t getting renamed when IPFire starts.
Another thing to check would be if your microSD card is failing - pull it and fsck it on another box.. I’ve had strange things starting to happen with IPFire on my Raspberry Pi 4B a couple of times and a failing microSD card has been the cause twice. Running an OS off of a microSD puts a lot of stress on the microSD.
When you run setup, the ethernet settings get written to /var/ipfire/ethernet/settings. Take a look at that file and see if you notice any issues. You should have the mac addresses and drivers for both nics in that file.
You said that running setup and removing and replacing the nic fixes the issue. That action would rewrite the ethernet/settings file, but would also restart the network. Have you tried just doing a network restart to see if that fixes things? –> ‘/etc/init.d/network restart’
Regards,
Stephen
Hello Stephen,
thanks for your explanation. Most helpful was the tip to look at /var/ipfire/ethernet/settings file, which I actually searched for but not found yet.
As it told me, why the second NIC (Realtek 8169) fails to be init’ed: Its MAC address gets changed by any reboot. For what reason ever.
This seems to be an issues of latest ipfire, because I setup the Nanopi with CU 18x and had no problem with upgrades upto, say CU197.
BTW: Maybe the first microSD, which lost my root-password, really isn’t reliable fully no more. I still need to run fsck on it. But the one, I’m using now, a SanDisk Ultra 16GB, is it.
CU
Johannes
If still interesting, I copied PUTty output of console while booting, bootlog, messages and two settings showing changed Realtek NIC MAC address to text files. Over all they are ~400KB, so I’ll post or send them on demand only.
Hi again,
after looking thru the bootlog, it is obvious, why the realtek NIC is not found no more:
[ 18.628031] r8169 0000:01:00.0: can't read MAC address, setting random one
[ 18.725590] r8169 0000:01:00.0 eth0: RTL8168h/8111h, 0a:20:28:d0:ee:22, XID 541, IRQ 78
[ 18.725621] r8169 0000:01:00.0 eth0: jumbo features [frames: 9194 bytes, tx checksumming: ko]
So it seems, that my problem is similar to this:
https://community.ipfire.org/t/need-static-mac-address-as-soon-as-possible-after-boot/11853/10
Only that I need a bit help. E.g. I don’t know at all how to the extra file in /etc/rc.d/rcsysinit.d and how to put the MAC address setting into it.
Thanks in advance and
best regards
Hello jopa,
Taking the ‘eth0’ and ‘0a:20:28:d0:ee:22’ from the output that you posted above, the commands to use to set the mac address would be:
ip link set dev eth0 down
ip link set dev eth0 address 0a:20:28:d0:ee:22
ip link set dev eth0 up
(You might want to use a different mac address since you posted that one publicly.)
You can create a file for the commands in rcsysinit.d:
/etc/rc.d/rcsysinit.d/S09setmacaddress
Create the file with root ownership and chmod the permissions to ‘754’.
The ‘setmacaddress’ part of the file name I gave above could be whatever you want to call it. The ‘S09’ prefix will cause the commands to run right before udev starts in S10udev. I’m not sure if it’s absolutely necessary that the commands run before udev starts but that’s where I would put them.
Regards,
Stephen
edit:
Just FYI - setting a random mac address is actually a design feature of the nanopi. I found several posts on other forums regarding this same issue.
Well, I created file
/etc/rc.d/rcsysinit.d/S09setmacaddress
with file permissions and the three lines you told me, with a different MAC address of course, and now get on console:
Cannot find device "eth0"
Cannot find device "eth0"
Cannot find device "eth0" [ FAIL ]
FAILURE:
You should not be reading this error message.
It means that an unforeseen error took place in /etc/rc.d/rcsysinit.d/S09setmacaddress, which exited with a return value of 1.
If you're able to track this error down to a bug in one of the files provided by ipfire, please be so kind to inform us at https://bugzilla.ipfire.org.
Press Enter to continue or wait a minute...
and so no red0 because of an unknown MAC address again.
What did I wrong?
Best regards
P.S. As far as I remember from unassembling my R4S, I own an “E” version, by which I should have at least one reliable MAC address on rockchip’s on-chip-NIC, which I can actually have.
Btw: As /var/ipfire/ethernet/settings formally looked quite sorted like:
CONFIG_TYPE=1
GREEN_DEV=green0
GREEN_MACADDR=xx:xx:xx:xx:xx:xx
GREEN_DESCRIPTION=‘“of: rk_gmac-dwmac”’
GREEN_DRIVER=rk_gmac-dwmac
RED_DEV=red0
RED_MACADDR=0a:20:28:d0:ee:22
RED_DESCRIPTION=‘“pci: Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller (rev 15)”’
RED_DRIVER=r8169
GREEN_ADDRESS=192.168.2.2
GREEN_NETMASK=255.255.255.0
GREEN_NETADDRESS=192.168.2.0
RED_DHCP_HOSTNAME=ipfire-ARM
RED_DHCP_FORCE_MTU=
RED_DHCP_RAPID_COMMIT=on
RED_ADDRESS=0.0.0.0
RED_NETMASK=0.0.0.0
DEFAULT_GATEWAY=0.0.0.0
RED_TYPE=DHCP
RED_NETADDRESS=0.0.0.0
it’s now, with S09setmacaddress:
GREEN_SLAVES=
GREEN_ADDRESS=192.168.2.2
RED_MACADDR=2e:1f:13:a4:28:1d
ORANGE_MODE=
GREEN_NETADDRESS=192.168.2.0
BLUE_SLAVES=
RED_DRIVER=r8169
RED_DESCRIPTION=‘“pci: Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411 PC
I Express Gigabit Ethernet Controller (rev 15)”’
RED_DHCP_HOSTNAME=ipfire-ARM
RED_STP=
ORANGE_STP=
BLUE_STP=
GREEN_MACADDR=xx:xx:xx:xx:xx:xx
RED_NETMASK=0.0.0.0
RED_SLAVES=
GREEN_NETMASK=255.255.255.0
RED_DEV=red0
GREEN_DEV=green0
ORANGE_SLAVES=
GREEN_DRIVER=rk_gmac-dwmac
ORANGE_MACADDR=
I spent another evening with trying other S09s, but always the same
Cannot find device “eth0” [ FAIL ]
FAILURE:You should not be reading this error message.
…
The only help for now is to change settings by setup and not to reboot afterwards.
By this, I still found out a discepancy between ipfire’s setup and WUI:
While setup shows:
WUI states:
which actually seems to be wrong, as my DSL modem tells:
I don’t know if the same or at least similar is on x64 platform, but not really want to find it out 
Best regards
the jopa
Not sure what kind of nic you are using.
Perhaps this will help?
This is a common thing with wifi. you can do a search in the forum. for “random mac address”
I am using the two gigabit NICs of Nanopi R4s, no usb attached WiFi.
One of them is the Rockchip SoC based, which works perfectly, the other is a Realtek RTL8169 and getting a new mac address on every boot.
But I will give the search for “random mac address” a try. But not this week no more.
Best regards
Isn’t this the reason?, fragment of the device description:
The R4S Enterprise version has a built-in EEPROM chip (Model: 24AA025E48T) which has a globally unique MAC address. This is a permanent and temper-proof address.
The R4S Standard version doesn’t have this chip and has a MAC address that is generated by a software utility. Apart from this difference, the two versions have the same hardware configuration.
You see? Regards
The problem can be solved by using a cheap external switch with 802.1q support, but I don’t know if you want to do that
If you know a “cheap” switch supporting VLAN while drawing say 0.3W max from 5V supply and show me how to setup ipfire to run red and green interface over the same ethernet port, then it could be interesting.
But why do you think of VLAN at all and not suggest to “simply” use the native friendly-wrt?
An example switch is the TL-SG105E. Power consumption depends on the cable length (according to the manufacturer).
The idea is to run logical zones supported by IPFire on a single physical interface (max. config: red, green, orange, blue).
The connection between the NanoPI and the switch is configured as an 802.1.q trunk.
The zones will be available on defined switch ports as access ports (red, green, orange, blue).
The forum is about the IpFire solution.
Hello jopa,
I currently don’t own any ARM based device anymore, but if I remeber correctly, there should be an environment file for the u-boot bootloader located in /boot.
You can try to set the MAC address with environment variables/commands for your network devices there.
Searching the web should provide you with deeper details and instructions.
Hopefully this hint was helpfull,
-Stefan
Hi @jopa ,
some months ago I had the same issue with a randomly chaning NIC after reboot on an ARM device. Back then I was able to fix this by setting the MAC persistent using udev rules.
I documented it here: fixes.brecht-schule.hamburg/linux/linux-tutorials/set-persistent-mac-rtl8111
My device back then was the router carrier board for RPi CM4 from DFRobots, but maybe this also works for the NanoPi.
Maybe this solves your problem.
Best regards,
Peer
Back again.
@alexand I’m aware, that this is the IPFire forum. My last reply was meant ironically, sorry. Because: Why should I go VLAN, even it may work, as long as I have a real NIC left? And btw routing RED by VLAN always is a severe security issue, that I don’t like to accept.
@stevee Well, uboot is special. I know.
@zyzonix Thanks. Will go your link tomorrow - or better to say, next evening..
CU
Using VLANs for network segmentation is standard. In large network installations, there’s no other implementation option.
I also understand the concerns about implementing RED and GREEN networks on a single physical interface.
Personally, I don’t think it’s dangerous, but I agree that a volumetric attack on RED, for example, will degrade GREEN.
In my opinion, a dedicated interface is better used for firewall management to isolate administrative access.
