network interface/rdomain setup bug

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

network interface/rdomain setup bug

norman
Configuring a loopback interface for an additional rdomain N via
/etc/hostname.loN causes /etc/netstart to misconfigure any
real network interface intended to be in that rdomain; it is
left in rdomain 0 instead.  Arguably it's a bug in the kernel
rather than in netstart.

I stumbled across the problem in a real configuration, but
one in which I later realized I didn't need that loopback
interface anyway.  So no urgency by me.

====

A.  Demonstration, using unmodified OpenBSD 6.7:

On a freshly-booted system with em1 an unused, not-yet-
configured Ethernet interface, running as super-user:

        echo 192.168.100.1/24 rdomain 10 >/etc/hostname.em1
        echo 127.0.0.1/8 rdomain 10 >/etc/hostname.lo10
        sh /etc/netstart

Expected result:

em1 and lo10 are brought up, with the addresses and
netmasks shown, both in rdomain 10.

Actual, unexpected result:

netstart prints an error message:

ifconfig: SIOCSIFRDOMAIN: Invalid argument

em1 is given the expected address and netmask, but is left
in rdomain 0: ifconfig em1 says

em1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        lladdr xx:xx:xx:xx:xx:xx
        index 4 priority 0 llprio 3
        media: Ethernet autoselect (none)
        status: no carrier
        inet 192.168.100.1 netmask 0xffffff00 broadcast 192.168.100.255

lo10 is configured as expected:

lo10: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> rdomain 10 mtu 32768
        index 7 priority 0 llprio 3
        groups: lo
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo10 prefixlen 64 scopeid 0x7
        inet 127.0.0.1 netmask 0xff000000

These things happen whether /etc/netstart is run manually, as
shown, or at boot time once those two hostname.* files exist.

If one then does
        rm /etc/hostname.lo10
        reboot
the system comes up without printing the SIOCSIFRDOMAIN error;
em1 is configured as expected (first line for em1 also says
`rdomain 10'); lo10 is left unconfigured, as expected.

Likewise if you remove both new hostname.* files, reboot
to get a clean start, and do

        echo 192.168.100.1/24 rdomain 10 >/etc/hostname.em1
        sh /etc/netstart

em1 is correctly configured (in rdomain 10).  The problem
shows only if lo10 is also given a hostname.lo10 file.

====

B.  Slightly-deeper analysis: by instrumenting a copy of
netstart, I figured out what it is doing.  (netstart -n
doesn't tell the whole story--it doesn't say when it would
ifconfig XX create.)

When hostname.em1 and hostname.lo10 both exist, netstart does
        ifconfig lo10 create
        ifconfig em1 192.168.100.1/24 rdomain 10
        ifconfig lo10 127.0.0.1/8 rdomain 10

If, on a freshly-booted system with neither hostname.em1
nor hostname.lo10, I run those commands by hand, I get
the same erroneous results.  The ifconfig em1 produces
the SIOCSIFRDOMAIN message.  The second ifconfig lo10
isn't necessary to demonstrate the problem, of course;
it is configuring em1 that goes wrong.

But if only hostname.em1 exists, not hostname.lo10,
netstart just does
        ifconfig em1 192.168.100.1/24 rdomain 10
and there is no error message and em1 is correctly
configured.

Apparently netstart believes it must pre-create any
explicitly-configured loN devices (because ifconfig -C
lists lo as a pseudo-device), but doing so somehow
interferes with later assigning a real device to the
corresponding rdomain.

====

C.  Related thoughts

Arguably feature requests rather than bugs:

-- sh /etc/netstart -n lo10 (with hostname.lo10 extant)
doesn't report that it would do ifconfig lo10 create.
Maybe it should say so.
-- Maybe netstart -n shouldn't require a list of
interface names; if none is given, just print everything
it would do to set up all interfaces.

Neither of these make a difference in normal operation,
but they would speed up debugging setup problems.

I'd be glad to write and submit a patch for those
things if you folks think they're worth doing.

Thanks,

Norman Wilson

PS: I'm really pleased with rdomains.  I did something
vaguely similar a long time ago in an ancient version of
UNIX, but never worked out all the details.  The OpenBSD
implementation feels complete and makes me very happy
when building firewalls and routers.  Thanks!