Re: link-state change for virtual interfaces

 ---- On Wed, 25 Sep 2024 14:27:36 +0100  Valery Ushakov  wrote --- 
 > On Wed, Sep 25, 2024 at 22:05:41 +0900, Rin Okuyama wrote:
 > 
 > > ````
 > > # rump.ifconfig shmif0 media auto
 > > # rump.ifconfig shmif0
 > > shmif0: flags=0x8802
 >  mtu 1500
 > >   capabilities=0x7ff80
 > >   capabilities=0x7ff80
 > >   capabilities=0x7ff80
 > >   enabled=0
 > >   address: b2:a0:01:9d:82:a5
 > >   linkstr: bus1
 > >   media: Ethernet autoselect
 > > # rump.ifconfig shmif0 media none
 > > # rump.ifconfig shmif0
 > > shmif0: flags=0x8802
 >  mtu 1500
 > >   capabilities=0x7ff80
 > >   capabilities=0x7ff80
 > >   capabilities=0x7ff80
 > >   enabled=0
 > >   address: b2:a0:6b:44:5b:bd
 > >   linkstr: bus1
 > >   media: Ethernet none
 > > ````
 > > 
 > > If `-v` option is specified to ifconfig,
 > >   linkstate: up
 > > and
 > >   linkstate: down
 > > appear b/w linkstr and media lines. This should happen also for vether:
 > > 
 > > https://mail-index.netbsd.org/source-changes/2024/08/20/msg152936.html
 > 
 > I see that ifconfig(8) also talks about the connection between link
 > state and media state.  So that seems like a natural choice then.

Actually there is no connection. I've updated the man page to reflect reality.

 > 
 > PS: Roy, that passage in ifconfig.8 was added by you back in 2020 and
 > it seems to have some sort of edito, where the sentence fragment
 > 
 >   +For interface drivers that do not support media status reporting.
 > 
 > is inserted in the middle of a phrase, seemingly at random.  Please,
 > could you take a look and fix it?

I've ripped the media status check out of ifconfig.8 - it was removed from ifconfig itself a while back.

So every interface sets if_link_state, it's part of ifnet.
Not every interface sets media, nor reports link state via media.

It's just unfortunate that *all* examples of link state checks I found as my reference for dhcpcd used media checks.
The *only* guaranteed way of checking link state is by SIOCGIFDATA  and checking ifdr.ifdr_data.ifi_link_state
OR by checking ifm_data->ifi_link_state from RTM_IFINFO or getifaddrs(3) for AF_LINK family.

Anyway, vether with media rather than link0

netbsd$ ifconfig vether0
vether0: flags=0x8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
        ec_capabilities=0x5<VLAN_MTU,JUMBO_MTU>
        ec_enabled=0
        address: f2:0b:a4:29:94:bb
        media: Ethernet autoselect
        status: active
netbsd$ doas ifconfig vether0 media none
netbsd$ ifconfig vether0
vether0: flags=0x8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
        ec_capabilities=0x5<VLAN_MTU,JUMBO_MTU>
        ec_enabled=0
        address: f2:0b:a4:29:94:bb
        media: Ethernet none
        status: no carrier
netbsd$

That being said, the argument agaisnt putting it into media is that it's more code, more complexity and as shmif proves, easy to get wrong:

1) shmif_mediachange() should not test ifp->if_link_state, it should just call if_link_state_change()

2) shmif_mediastatus() does not set IFM_AVALID or IFM_ACTIVE in ifm_status
This probably let to the addition of linkstate to `ifconfig -v` which wasn't really needed.
If it sets IFM_AVALID then the status line as shown anove will appear.

Here's how I'm doing it (not committed):

+static int
+vether_mediachange(struct ifnet *ifp)
+{
+       struct vether_softc *sc = ifp->if_softc;
+       int link_state;
+
+       if (IFM_SUBTYPE(sc->sc_im.ifm_cur->ifm_media) == IFM_NONE)
+               link_state = LINK_STATE_DOWN;
+       else
+               link_state = LINK_STATE_UP;
+
+       if_link_state_change(ifp, link_state);
+       return 0;
+}
+static void
+vether_mediastatus(struct ifnet *ifp, struct ifmediareq *imr)
+{
+       struct vether_softc *sc = ifp->if_softc;
+
+       imr->ifm_status = IFM_AVALID;
+       imr->ifm_active = sc->sc_im.ifm_cur->ifm_media;
+
+       if (IFM_SUBTYPE(imr->ifm_active) != IFM_NONE)
+               imr->ifm_status |= IFM_ACTIVE;
+}

What do people think? Keep vether link0 or use media?

Roy