How to keep IP configuration after rootfs deployment

Hi there,

I’m developing an IoT device on Revolution Pi /Raspberry Pi 3 running a Yocto image with Qt5, PostgreSQL and nodejs as the core of a new Ticket Vending Machine.

So far, I managed to build an image with Mender client 2.0 connecting to a local demo server on my Ubuntu 16.04 development system.

Building images and deploying them to my device is working as expected.

Before switching to production mode on hosted mender, I need to clarify how my network configuration (systemd-networkd) can be saved and reinstalled to the new rootfs after deployment of a new rootfs.

I came across the following problems:

1.) Using DHCP - the lease information is stored within the rootfs, so after the deployment and reboot, the lease information is cleared and the client starts DCHP_DISCOVER instead of DHCP_REQUEST an I get a new IP address for my client, every time I deploy a new rootfs.

2.) Using a fixed IP, I would have to provide different images for all my devices. I can not manage this for several 100 devices.

Has anybody managed this problem ?

Should I use update scripts in mender artifacts to save eth.network file to /data partition and replace them again in /etc before reboot ?
Can I override network settings with any kind of file on my /data-partition ?

Do you have any experience ? Thank you in advance !

Dirk

Hi @DSiegmund,

Welcome to Mender Hub,

I think your best bet is to utilize state-scripts to transfer configuration when performing the update. We have a couple of examples for inspiration purposes here,

1.) Using DHCP - the lease information is stored within the rootfs, so after the deployment and reboot, the lease information is cleared and the client starts DCHP_DISCOVER instead of DHCP_REQUEST an I get a new IP address for my client, every time I deploy a new rootfs.

I am curious, why is this a problem? I realize that when you are on dev desk, that this can be annoying, but when moving to a production environment and where the updates are less frequent I do not really see the problem.

You can also report the ip address of the device to the Mender Server using inventory scripts, if you ever need to look this up to access the devices.

Hi @mirzak,

thank you for your quick response. I will take a close look at the state-scripts, but I will have to learn how they work, first. I’ve been designing schematicns, printed circuit boards and programming microcontrollers in assembler and C for about 30 years now, but I am still struggeling with the linux world… so many things to learn.

Concerning DHCP you are right, my main problem is development now, where I have to deploy from QtCreator via ssh to several test devices. :wink:

But I am still not sure how to do remote maintenance in future (ssh, VNC, TeamViewer, etc.)
Does Hosted Mender offer any remote access functionality for the devices ?

Kind regards,

Dirk

Hi Dirk,

Mender is strictly focused on OTA functionality and there is no remote access capability. There are of course other solutions that should work fine along-side of Mender. I have seen some folks install an ssh server in their images and then use https://github.com/fatedier/frp to collate all their devices in one place. I’ve not played with it myself and it likely will require some scripting but that may be a good solution.

As for configuring the networking, the state scripts that Mirza mentioned are one possibility, but that is specific to Mender. I gave a talk on this using standard Yocto mechanisms at SCaLE this year. I cannot seem to locate a video of the talk but the slides are here: https://www.slideshare.net/MenderOTA/configuring-wifi-in-open-embedded-builds

That may give you some ideas on how you want to setup the network management in your device fleet.

Hi @drewmoseley,

thank you for your suggestions. I just had a short look at frp, I will keep an eye on it.

I followed mirzaks state-script suggestion and modified one of the example state-scripts to copy systemd *.network files and it works like a charm. :smile:

I also created my first pull request to add my state-script to mirzaks examples.

Thank you for your support !

Hi @drewmoseley: Thank you very much for sharing the slides. I am also facing the same issue with my device (up squared board). The ip address is not changed when I try to reboot my device normally (with command sudo reboot). But if the device power is interrupted suddenly due to unexpected power failure, the ip address of my device got changed. I would like to know what does PACKAGECONFIG_remove = " networkd resolved" play a role in network configuration in this scenario.

For local development, our developers SSH using the mDns name rather than ip. As we have avahi-daemon installed.

For remote development which admittedly is not a big part of our pipeline, our IT departments changed the policy on their DHCP server to give out the same IP address to clients irrespective if the rootfs has changed which inturn changes some of the data sent in the DHCP request which some default policies on DHCP servers use.

Sometimes the DHCP lease information in var/lib/dhcp/dhclient.lease ist not written, when power is lost.
Linux first writes files to RAM buffers and later writes them to non-volatile storage like an SD card or Flash drive. If you hard reset or power down before the files are written to non-volatile storage, you’ll lose the changes. You’ve got the same problem, when changing partitions after a mender update and there’s no lease file.

@DSiegmund: How can I avoid changing ip address of device in any scenarios, power cycle aswell after mender update in production? Using state-script retain-systemd-network ?

Every time, the client asks for an IP address, it looks for an existing lease file and tries to get the old address by sending an DHCP_REQUEST with that IP in it.
If there is no file, or the lease has expired, it sends an DHCP_DISCOVER, so that any DHCP-server can offer a NEW IP address.

The easiest way is to use a static address and the script, to keep that config.

If you need to stay on DHCP, it is easier to make the DHCP-Server to OFFER the same IP to well known MAC-addresses, but it depends on your DHCP-Server.

You could also investigate, where your dhclient.lease file is located and write a script for that lease file.

In my case, I use static IPs only.

If you are using DHCP with dynamically assigned IP addresses, then relying on behavior such as you describe with a proper reboot vs a power down is not well defined. I would suggest either mDNS, static IP configuration on the client, or assigning a static IP address in your DHCP server (the mechanism to enable this is going to vary depending on your DHCP server.)

Thank you very much for your reply. My device does not show file dhclient.leases , but I found dhcpd.leases file in /var/lib/dhcp

For future reference, here is a bitbake file I used to preserve my Ethernet config settings on Kirkstone.

systemd-conf_%.bbappend

FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"

do_install:append() {
    # Move the default file to the data directory
    install -d ${D}/data/lib/systemd/network
    mv ${D}${systemd_unitdir}/network/80-wired.network ${D}/data/lib/systemd/network/80-wired.network
    
    # Link the old location to the new
    ln -sf /data/lib/systemd/network/80-wired.network ${D}${systemd_unitdir}/network/80-wired.network
}
# ${WORKDIR}/51-wireless.network 

FILES:${PN}:append = " /data/lib/systemd/network/80-wired.network "

—systemd-conf/
------systemd-conf_%bbappend
------systemd-conf/
---------wired.network

wired.network

[Match]
Name=en* eth*

[Network]
DHCP=yes
LinkLocalAddressing=fallback
IPv4LLStartAddress=169.254.1.1

[DHCP]
RouteMetric=10
ClientIdentifier=mac

[DHCPv4]
MaxAttempts=3