phosphor-networkd clobbering usb0 network config

[Oskar Senft]

Hi everyone

I couldn't find any other mention of this and hope this hasn't been asked /
answered / solved before.

We're using both an NC-SI based NIC and the USB virtual NIC on a AST2500
BMC (on the TYAN S7106 mainboard). I found that phosphor-networkd clobbers
the networking configuration (IP address) for the USB virtual NIC (usb0) in
the following scenario:

   1. The USB virtual NIC (usb0) has it default IP address hard coded in
   /etc/systemd/network/00-bmc-usb0.network.
   2. The host has not yet loaded the USB NIC driver (cdc_ether). In this
   case the USB NIC on the BMC does not have an IP address assigned (I haven't
   investigated why that is, but it seems ok).
   3. A process actively assigns / changes the IP address for the BMC's
   other NIC (i.e. eth0) via phosphor-networkd, e.g. via IPMI from the host.

At step #3 phosphor-networkd overwrites all files in /etc/systemd/network
(EthernetInterface::writeConfigurationFile() called from
Manager::writeToConfigurationFile()). Specifically, it rewrites all files
with information captured from the running system. Since the USB NIC (usb0)
doesn't have an IP address at that time, the rewritten file is missing the
IP address, too.

I can think of various ways to fix this:

   - Make the host explicitly configure usb0 via IPMI before trying to talk
   with the BMC via the USB NIC. This won't work since we'd like to stop using
   IPMI from the host completely.
   - Enhance phosphor-networkd to always explicitly exclude "usb0" as a
   managed device. I wonder if this could be done by adding a new key/value
   pair to /etc/systemd/network/00-bmc-usb0.network, e.g. "[PhosphorNetworkD]
   managed=false". This seems pretty straightforward.
   - Come up with some "automatic" way to not clobber the configuration
   file if the running configuration does not match. It feels that this goes
   against the fundamental design of phosphor-networkd.

Thoughts? Ideas? Opinions?

Thanks
Oskar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20191210/f67e0293/attachment.htm>