tech-net archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
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
Home |
Main Index |
Thread Index |
Old Index