Teach bridge interfaces to work with async DHCP (devd config)

[dhorn2000_gmail.com]

Summary

When devd initializes the /etc/devd/dhclient.conf configuration for async DHCP, it requires either a media-type match to Ethernet or 802.11 in the current version. Unfortunately, bridge interfaces do not seem to have any media type defined that devd can detect, so does not execute the service dhclient quietstart $subsystem call.

This patch adds a case without a media-type match explicitly to handle bridge interfaces. In my testings, lagg aleady identifies as an Ethernet interface (IFM_ETHER), so works without a special case. This patch ONLY addresses bridge(4) interfaces with async DHCP.

Test Plan

• Testing with multiple bridge interfaces, with and without DHCP and SYNCDHCP flags in /etc/rc.conf.
• Testing with one and more bridge members
• Manually with service netif restart and normal reboot flows.

[dhorn2000_gmail.com]

Bug 290173 for tracking.

[ivy]

could you please recreate the diff with -U9999 to include the missing context, or (preferably) use git arc which does this automatically? otherwise, it is much harder to see what changed.

[dhorn2000_gmail.com]

Updated diff with more context -U9999.

[ivy]

sbin/devd/dhclient.conf

24

i'm not sure this is the right fix. bridges don't need to be named bridgeN; it would be perfectly reasonable to have a bridge called vlan100.

is there not a media-type we can use to match bridge? in the kernel, these are IFT_BRIDGE (as opposed to IFT_ETHER) but i don't know how this is exposed in devd.

@imp any suggestions?

[dhorn2000_gmail.com]

sbin/devd/dhclient.conf

24

Good point on the interface name.

Then can we either make:

1. if_bridge code enumerate as IFM_ETHER (leaving devd code as-is), or
2. add a new feature to devd to detect IFT_BRIDGE from <net/if_types.h> ?

I took a quick look, but those structures and ioctls are outside my current knowledge.

[imp]

I'm agnostic to slightly leaning towards on the 'bridge up' model. I don't know enough to have a really good opinion beyond that, though.

[p.mousavizadeh_protonmail.com]

I think we should assign IFM_ETHER in if_bridge.c instead, we already assign it to other layer 2 interfaces like if_vxlan module.
This requires updating to the bridge_softc struct to store ifmedia and adding the SIOCSIFMEDIA/SIOCGIFMEDIA handling to its ioctl.
I'm not sure whether it should depend on the member_ifaddrs sysctl or not.

adding this code to the clone_create

ifmedia_init(&sc->sc_media, 0, NULL, NULL);
ifmedia_add(&sc->sc_media, IFM_ETHER | IFM_AUTO, 0, NULL);                                                                                                               
ifmedia_set(&sc->sc_media, IFM_ETHER | IFM_AUTO);

And this for clone_destroy

ifmedia_removeall(&sc->sc_media);

what do you think? @ivy

[zlei]

sbin/devd/dhclient.conf

24

I have not tested, but I think the sbin/devd/devd.cc might be a good start point,

media::media(config &, const char *var, const char *type)
        : _var(var), _type(-1)
{
        static struct ifmedia_description media_types[] = {
                { IFM_ETHER,            "Ethernet" },
                { IFM_IEEE80211,        "802.11" },
                { IFM_ATM,              "ATM" },
                { -1,                   "unknown" },
                { 0, NULL },
        };
        for (int i = 0; media_types[i].ifmt_string != NULL; ++i)
                if (strcasecmp(type, media_types[i].ifmt_string) == 0) {
                        _type = media_types[i].ifmt_word;
                        break;
                }
}