After shutdown and repower Nanopi R4S loses second NIC

Network
21

@zyzonix Tried the suggestion from your link. But without success. I still need to run setup after reboot to fix network. Think, I have to live with it, until someone in the ARM team finds a reliably working solution.

@alexand It’s my opinion, too, that it is alway better for firewall management, to have dedicated NICs for at least RED and GREEN. As the Nanopi R4S basically provides. Only one of them changes its MAC address on every boot…

22

Okay, that sounds weird. The error you get, is exactly the same I got back then. Are you sure, that there was no typo or a wrong PCI device?

23

Hi all, especially stephen and zyzonix,

back from a relaxing weekend I looked at my last change again and actually found a typo in /etc/udev/rules.d/10-setmacaddress.rules (ACTIOM instead of ACTION).

After correcting it, I get my macaddress set reliably on every cold and warm boot now.

There is only one question remaining: Which is more secure? To use my macadress on green or on red interface? By my own, I’d like to use it on green, but I don’t know, whether my Fritz!Box discovers or may leak it to the internet…

Edit: I’d like to use my macaddress on RED, not on green. Because I else, in case, that it changes again, I still can use green to change red again.

Thanks so far and best regards

24

Hello @jopa,

I’m glad to hear, that you got it working. Maybe just select my answer als solution, so that it is pinned on top.

I would also recommend to set this workaround for the RED interface, so that you can still access the webinterface via GREEN in case of a failure of this solution.

Best regards

25

Hey @zyzonix,

I marked your reply as solution.

Btw: You probably did not notice my “Edit”, where I mentioned, what you recommended. Or, more concretely, I swapped RED and GREEN, so that GREEN now is the LAN port with the always known MAC address. I needed to swap my cables for this, so that my GREEN is connected to the WAN port of R4S case now and RED to the LAN port.

Thanks again and best regards

26

Thanks for that info. It might also be useful for FriendlyElec NanoPi R1S H5, that is 64-bit and basically works with IPF, but has the dynamic MAC problem for green0. I have one of those devices and will try try the fix.

27

Just a short expansion of the given solution to be usefull for several Nanopi R4S systems.

I faced the problem, that after implementing the udev file with
nano /etc/udev/rules.d/10-setmacaddress.rules
and the content: `SUBSYSTEM==“net”, ACTION==“add”, KERNELS==“0000:01:00.0”, PROGRAM=“/sbin/ip link set %k address XX:XX:XX:XX:XX:XX”

( exchange the MAC XX:XX…with your given version by setup utility )

now the red interface will not be active after reboot. There is a certain race condition while running the udev script. The command: /etc/init.d/network restart red
resolved the issue .
So i included this in adding following lines to rc.local:
nano /etc/sysconfig/rc.local

sleep 3

/etc/init.d/network restart red

Unsuccesfull tries:

  • A exchange of the parameter PROGRAM= with RUN+= ist unknown ( not functional ) in ipfire-distribution
  • Early-Init-Skript with /etc/rc.d/rc3.d/S19macfix and use of
    /sbin/ip link set dev eth0 down
    /sbin/ip link set dev eth0 address XX:XX:XX:XX:XX:XX
    ( device not known … )
  • …

P.S. i did not change LAN / WAN sockets for cables …