MoodleBox 4.11.1 "Trixie", best way for a fix IP for eth0

Ratna

Hi all

I notice that Trixie has moved head-on to networkmanager, netplan, nmcli, some such complication.
:-(

How can I set the IP address of eth0 manually (in a LAN with a DHCP server)? It is all headless, I'm hoping to SSH through the wireless access point of the MoodleBox and to change the network settings of eth0.

Ideally, I would like to stop all these "cloud" thinks and edit my /etc/networking/interfaces! Failing that I can set the router to give the RPi the fix IP address. I'm not sure which is the most stable setup. This is a remote "network cellar".

Nicolas

Try this (not tested, but it should work). Good luck!

# Edit the connection
sudo nmcli con modify "netplan-eth0" ipv4.method manual ipv4.address 192.168.1.32/24
sudo nmcli con modify "netplan-eth0" ipv4.gateway 192.168.1.254
sudo nmcli con modify "netplan-eth0" ipv4.dns 192.168.1.254

# Save the config.
sudo nmcli con reload "netplan-eth0" 

# Do a down followed by up, but pulling the LAN cable out and plugging it back in also works
# Putting them on the one line works over ssh remotely
sudo nmcli con down "netplan-eth0"; sudo nmcli con up "netplan-eth0"

Obviously change the addresses according to your needs.

Some (pedantic) points:

netplan has nothing to do with Debian (Trixie), netplan is a Ubuntu thing and the RPi OS devs decided to use it in the RPi OS Trixie image.
nmcli is the command line utility to configure NetworkManager, and was already there in Bookworm images.

Edit: The connection name should be "netplan-eth0".

See: https://forums.raspberrypi.com/viewtopic.php?p=2313365 for more context.

Ratna

Nicolas

Whaaat? Is Raspberry Pi OS financed by Canonical? Wait.. I have a sneaking suspicion why Raspbian suddenly became Raspberry Pi OS.
:-(

Well, to the story: I didn't trust those nmcli commands and traveled to housing cellar - knowing that in the vicinity I have the Moodlebox access point as a backdoor. Then the network admin there proposed 'nmtui', the "Textual User Interface" of the NetworkManager as a compromise. It looked more familiar and did the intended address change - well, almost. We couldn't log in from the WAN, only LAN. The network setup in the data center is complicated, WAN access through Nginx reverse proxy, /24 network blocks withing 10.0.0.0/24 given to each customer. After close to an hour of debugging found that nmtui has decided the netmask of its own, overwritten 255.255.255.0 we put with 255.0.0.0. In hindsight it is clear: This "intelligent" tool saw the 10.x.x.x IP address and decided on the Class A netmask.

Compare that hulabooo with the conventional method:
Change
iface INTERFACE inet dhcp
to

iface INTERFACE inet static
    address IPADDRESS
    netmask NETMASK
    gateway IPGATEWAY

and restart the networking daemon, that has worked 99% of the time for decades! I find no words to conclude.