My NanoPi R1 has 3 network interfaces.
LAN, WAN, WiFi
Since this is a headless device and the system is stored on the internal eMMC I would like to use WAN with a static IP as parachute.
LAN and WiFi should be used with DHCP. And my DHCP server should hand out the same IP for both MAC addresses.
This works fine with my DHCP server (running OpenWrt) when I’m using my laptop.
Since DietPi config did not support 3 interfaces. I configured /etc/network/interfaces myself.
─────────────────────────────────────────────────────
DietPi v8.20.1 : 16:13 - Mon 07/31/23
─────────────────────────────────────────────────────
- Device model : NanoPi R1 (armv7l)
- Uptime : up 17 minutes
- CPU temp : 32 °C / 89 °F : Cool runnings
- LAN IP : 192.168.0.100 (eth0)
- WAN IP : curl: (28) Failed to connect to dietpi.com port 443: Connection timed out
- Freespace (RootFS) : 4.3G
- Freespace (userdata) : 4.3G
─────────────────────────────────────────────────────
Hm. WAN and LAN are apparently swapped…
But thats not the main problem. When I have disconnected the LAN cable at startup, the R1 requests the IP via WiFi but is still unreachable.
I have to plug in the ethernet cable too. A few seconds later the R1 requests a IP for the LAN interface an is reachable via LAN and WiFi.
How to configure the system that it can be used with WLAN if Wifi is available and with LAN if there is a lan connection.
Ok,
since fiddeling with a headless device when using the internal eMMC is risky, I decided to start from scratch with a new SD.
So I have downloaded the actual image and flashed it to a 32GB sd card.
I inserted the card into the R1, connected power and wait for the blinking “SYS LED”. Then I connected my ethernet cable to physical WAN port.
Nothing happens. Then I connected the cable to physical LAN port and got an address. Fine, thas what I want. I could connect via ssh and the installation & update process starts.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
─────────────────────────────────────────────────────
DietPi v8.19.1 : 17:37 - Mon 07/31/23
─────────────────────────────────────────────────────
- LAN IP : 192.168.200.157 (eth1)
DietPi-Update
─────────────────────────────────────────────────────
Phase: Checking for available DietPi update
[ OK ] DietPi-Update | Checking IPv4 network connectivity
[ OK ] DietPi-Update | Checking DNS resolver
[ OK ] DietPi-TimeSync | systemctl stop systemd-timesyncd
[ OK ] DietPi-TimeSync | mkdir -p /run/systemd/timesync
[ INFO ] DietPi-Update | Getting latest version from: https://raw.githubusercontent.com/MichaIng/DietPi/master/.update/version
[ OK ] DietPi-Update | Got valid latest version: 8.20.1
[ OK ] DietPi-Update | Update available:
[ INFO ] DietPi-Update | Current version : v8.19.1
[ INFO ] DietPi-Update | Latest version : v8.20.1
DietPi-Update
─────────────────────────────────────────────────────
Phase: Checking for update pre-requirements
[ OK ] DietPi-Update | DietPi-Userdata validation: /mnt/dietpi_userdata
[ OK ] DietPi-Update | Free space check: path=/ | available=27259 MiB | required=100 MiB
[ SUB1 ] DietPi-Services > stop
[ OK ] DietPi-Services | stop : cron
DietPi-Update
─────────────────────────────────────────────────────
Phase: Applying pre-patches
[ OK ] DietPi-Update | Downloading pre-patches
[ OK ] DietPi-Update | Applying execute permission
[ OK ] DietPi-Update | Successfully applied pre-patches
DietPi-Update
─────────────────────────────────────────────────────
Phase: Upgrading APT packages
[ INFO ] DietPi-Update | APT update, please wait...
Get:1 https://deb.debian.org/debian bookworm InRelease [151 kB]
...
Get:14 https://mirrors.xtom.de/armbian bookworm/main armhf Packages [36.2 kB]
Fetched 9181 kB in 11s (820 kB/s)
Reading package lists...
[ OK ] DietPi-Update | APT update
[ INFO ] DietPi-Update | APT upgrade, please wait...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
The following packages will be upgraded:
armbian-firmware base-files curl libc-bin libc-l10n libc6 libcurl4
libdbus-1-3 libsystemd-shared libsystemd0 libudev1 linux-dtb-current-sunxi
linux-image-current-sunxi locales sudo systemd systemd-sysv
systemd-timesyncd udev
19 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 60.4 MB of archives.
After this operation, 115 MB of additional disk space will be used.
Get:1 https://deb.debian.org/debian bookworm/main armhf libc6 armhf 2.36-9+deb12u1 [2141 kB]
...
Get:19 https://deb.debian.org/debian bookworm/main armhf libdbus-1-3 armhf 1.14.8-2~deb12u1 [178 kB]
debconf: delaying package configuration, since apt-utils is not installed
Fetched 60.4 MB in 9s (6364 kB/s)
(Reading database ... 16808 files and directories currently installed.)
Preparing to unpack .../base-files_23.08.0-trunk--bookworm-1armbian1-B9e4a_armhf.deb ...
Unpacking base-files (23.08.0-trunk--bookworm-1armbian1-B9e4a) over (12.4) ...
Setting up base-files (23.08.0-trunk--bookworm-1armbian1-B9e4a) ...
(Reading database ... 16809 files and directories currently installed.)
Preparing to unpack .../libc6_2.36-9+deb12u1_armhf.deb ...
Unpacking libc6:armhf (2.36-9+deb12u1) over (2.36-9) ...
Setting up libc6:armhf (2.36-9+deb12u1) ...
(Reading database ... 16809 files and directories currently installed.)
...
Image Name: uInitrd
Created: Mon Jul 31 17:40:32 2023
Image Type: ARM Linux RAMDisk Image (gzip compressed)
Data Size: 9363750 Bytes = 9144.29 KiB = 8.93 MiB
Load Address: 00000000
Entry Point: 00000000
'/boot/uInitrd' -> 'uInitrd-6.1.40-sunxi'
Armbian: update last-installed kernel symlink to 'zImage'...
'/boot/zImage' -> 'vmlinuz-6.1.40-sunxi'
Armbian: Debian compat: linux-update-symlinks install 6.1.40-sunxi boot/vmlinuz-6.1.40-sunxi
I: /vmlinuz.old is now a symlink to boot/vmlinuz-6.1.40-sunxi
I: /initrd.img.old is now a symlink to boot/initrd.img-6.1.40-sunxi
I: /vmlinuz is now a symlink to boot/vmlinuz-6.1.40-sunxi
I: /initrd.img is now a symlink to boot/initrd.img-6.1.40-sunxi
Armbian 'linux-image-current-sunxi' for '6.1.40-sunxi': 'postinst' finishing.
Setting up locales (2.36-9+deb12u1) ...
Generating locales (this might take a while)...
C.UTF-8... done
Generation complete.
Setting up linux-dtb-current-sunxi (23.08.0-trunk--6.1.40-S7538-De1a3-Pcb77-Caca9Hfe66-HK01ba-V014b-B18f9) ...
Armbian 'linux-dtb-current-sunxi' for '6.1.40-sunxi': 'postinst' starting.
Armbian: DTB: symlinking /boot/dtb to /boot/dtb-6.1.40-sunxi...
'dtb' -> 'dtb-6.1.40-sunxi'
Armbian 'linux-dtb-current-sunxi' for '6.1.40-sunxi': 'postinst' finishing.
Setting up libdbus-1-3:armhf (1.14.8-2~deb12u1) ...
Setting up systemd-timesyncd (252.12-1~deb12u1) ...
Setting up udev (252.12-1~deb12u1) ...
Setting up sudo (1.9.13p3-1+deb12u1) ...
Setting up armbian-firmware (23.08.0-trunk--1-SA1251-B226d) ...
Setting up libcurl4:armhf (7.88.1-10+deb12u1) ...
Setting up curl (7.88.1-10+deb12u1) ...
Processing triggers for libc-bin (2.36-9+deb12u1) ...
Processing triggers for initramfs-tools (0.142) ...
update-initramfs: Generating /boot/initrd.img-6.1.40-sunxi
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8156b-2.fw for module r8152
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8156a-2.fw for module r8152
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8153c-1.fw for module r8152
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8153a-4.fw for module r8152
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8153a-3.fw for module r8152
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8153a-2.fw for module r8152
update-initramfs: Converting to U-Boot format
Image Name: uInitrd
Created: Mon Jul 31 17:41:42 2023
Image Type: ARM Linux RAMDisk Image (gzip compressed)
Data Size: 9363827 Bytes = 9144.36 KiB = 8.93 MiB
Load Address: 00000000
Entry Point: 00000000
'/boot/uInitrd' -> 'uInitrd-6.1.40-sunxi'
[ OK ] DietPi-Update | APT upgrade
DietPi-Update
─────────────────────────────────────────────────────
Phase: Installing new DietPi code
[ OK ] DietPi-Update | Downloading update archive
[ OK ] DietPi-Update | Unpacking update archive
[ OK ] DietPi-Update | Removing unused files
[ OK ] DietPi-Update | Hardening update archive mode
[ OK ] DietPi-Update | Installing new DietPi scripts
[ OK ] DietPi-Update | Installing new DietPi system files
[ SUB1 ] DietPi-Set_software > verify_dietpi.txt
[ OK ] DietPi-Set_software | Downloading current dietpi.txt
[ OK ] verify_dietpi.txt | Completed
[ OK ] DietPi-Update | sync
[ OK ] DietPi-Update | systemctl daemon-reload
DietPi-Update
─────────────────────────────────────────────────────
Phase: Applying incremental patches
[ INFO ] DietPi-Update | Current version : v8.19.1
[ INFO ] DietPi-Update | Latest version : v8.20.1
[ INFO ] DietPi-Patch | Patching to DietPi v8.20...
[ OK ] DietPi-Patch | Patched to DietPi v8.20
[ INFO ] DietPi-Update | APT autopurge, please wait...
Reading package lists...
Building dependency tree...
Reading state information...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
[ OK ] DietPi-Update | APT autopurge
[ OK ] DietPi-Update | systemctl daemon-reload
[ OK ] DietPi-Update | Incremental patching to v8.20.1 completed
[ INFO ] DietPi-Update | Checking for new available live patches
[ OK ] DietPi-Update | eval echo 1 > /boot/dietpi/.install_stage
DietPi-Update
─────────────────────────────────────────────────────
Phase: Completed
[ INFO ] DietPi-Update | Current version : v8.20.1
[ INFO ] DietPi-Update | Latest version : v8.20.1
[ OK ] DietPi-Survey | Setting in /boot/dietpi.txt adjusted: SURVEY_OPTED_IN=0
[ OK ] DietPi-Survey | Purging survey data
[ OK ] DietPi-Update | sync
[ INFO ] DietPi-Update | A reboot is done to finalise the kernel upgrade
Failed to connect to bus: No such file or directory
Connection to 192.168.200.157 closed by remote host.
Connection to 192.168.200.157 closed.
The ssh connection was dropped and did not came up again.
After some research I found, that I have to connect my ethernet cable to the WAN port now !
─────────────────────────────────────────────────────
DietPi v8.20.1 : 19:01 - Mo 31.07.2023
─────────────────────────────────────────────────────
- Device model : NanoPi R1 (armv7l)
- Uptime : up 14 minutes
- CPU temp : 35 °C / 95 °F : Cool runnings
- LAN IP : 192.168.200.157 (eth1)
- WAN IP : 94.31.98.182 Lower Saxony DE
- Freespace (RootFS) : 27G
- Freespace (userdata) : 27G
─────────────────────────────────────────────────────
Why this? My intention was to keep the physical LAN port connected to my lan, and did not connect anythin to the physical WAN port.
So, how to use eth0 as LAN network?
does it really matter which Ethernet port is used at the end?? Usually one of the Ethernet/WAN ports should be eth0 but I’m not sure which one. @MichaIng do you know the usage of ports on a NanoPi R1?
Which port is used can definitely play a role.
With the R1, the port marked as LAN on the housing (eth0) handles 100 MBit, while the WAN port (eth1) handles 1 GBit.
In a way it made sense that the faster port was assigned to the LAN with DietPi. Because usually the LAN is faster than the WAN.
On the other hand, the designations on the housing no longer match the notation in DietPi. That is confusing.
Especially since the LAN port is simply switched from eth0 to eth1 during the installation.
It would therefore be helpful if the end user had a simple, comprehensible option for assigning an interface to the LAN or WAN side…
Did some more tests…
Generaly, if more then 1 ethernet interface with option “auto, or allow-hotplug” is defined in /etc/network/interfaces, then DietPi will not start up with a valid network connection.
Be warned, if you are using a headless device with internal eMMC remote access is not more possible.
I have tested ifplugd too.
I recommend to disable ifplugd after apt-get install immediately. systemctl disable ifplugd
This is because it is enabled by default. And if you configure something wrong, you could be locked out…
You can start it as you need by hand and enable it again after finishing all tests.
I tried the script pointed to by the link above. But it didn’t work reliable.
Sometimes my eth1 device seems to hang in a busy state. So I add “ifdown device --force”. The other problem was wifi-monitor.
Looks, as the monitor brings up wlan0 again, while I’m trying to bring it down
This is my (not very nice) /etc/ifplugd/ifplugd.action for now.
set -e
if [ -z "$1" ] || [ -z "$2" ] ; then
echo "Wrong arguments" > /dev/stderr
exit 1
fi
if [ "$1" != "eth1" ]; then
echo "Wrong interface!" > /dev/stderr
exit 1
fi
if [ "$2" = "up" ] ; then
echo "bring down WiFi"
/bin/systemctl disable --now dietpi-wifi-monitor.service
/sbin/ifdown eth1 --force
/sbin/ifdown wlan0 --force
/sbin/ifup eth1 --force
exit 0
elif [ "$2" = "down" ] ; then
echo "bring up WiFi"
/sbin/ifdown wlan0 --force
/sbin/ifdown eth1 --force
/sbin/ifup wlan0 --force
/bin/systemctl enable --now dietpi-wifi-monitor.service
exit 0
fi
exit 1
The system (and DietPi) drives me crazy …
After finishing my tests using the sd-card I tried to configure the internal emmc in the same way. Only difference was that the system on emmc is an upgrade from a old dietpi installation, with some additional tools like octoprint installed.
And since I would like to keep all configs, I’m not willing to do a full reset.
But ups again. eth0 and eth1 are reveresd.
So my question for now is:
How and where the physical interfaces are assigned to device names in DietPi ?
The problem in your case is that you basically configure both Ethernet interfaces to be used as gateway. As the system surely shall access the Internet through eth0, and you have the gateway explicitly assigned there, you must not use DHCP on eth1 but a static IP as well. A DHCP server usually distributes a gateway as well, and ifupdown creates a default route for them. So I guess you end up with two default routes, one on each interface:
ip r l 0/0
And when you do network requests now, the system does no know which one to use, of uses any of both randomly.
Isn’t the LAN interface anyway intended to be used as gateway by other network peers to access the Internet through this NanoPi R1, or what is the purpose of this? For a gateway, a static IP makes sense anyway + running the DHCP server just on this very same system (if it is not the case already).
eth0 is btw just assigned to the very first Ethernet adapter detected/loaded by the kernel, eth1 by the second. As long as the hardware does not change (e.g. if one is a USB adapter and switch to another port), the naming is however always the same. So you should be able to rely on it when you found out once which one is which. But you say now it changes between boot sessions? Theoretically it is possible to enable “predictable” network interface naming, so you get names like enp0s1. Or you could create own udev rules to fix the naming, but I would also need to check how to do it properly.
I would btw recommend to use a dedicated config file for the LAN interface, like /etc/network/interfaces/eth1.conf, so there is not chance that dietpi-config can override your changes.
But does it work somehow?