FlagUp doesn't tell if for example an ethernet cable is physically attached to a network interface.
According to the IFF_UP vs IFF_RUNNING answer, the flag IFF_RUNNING actually does that.
(I did not verify this.)
I propose to add net.FlagRunning to know if a network interface is operational.
The text was updated successfully, but these errors were encountered:
The current set of net.Flags are chosen from the following criteria:
platform agnostic; we don't want to see an issue like FlagX doesn't work well on operating system Y,
peripheral or driver agnostic; the same as above,
management view agnostic; each network/interface stack implementation differs between operating systems and de facto/de jure standards.
IIUC, IFF_RUNNING was introduced in BSD variants to represent some state of the peripheral driver, then Linux introduced and changed the meaning to represent the operational status of the network interface described in RFC 2863. Windows directly shows the operational status. Also even on Linux, IFF_RUNNING might not cover RFC 2863 perfectly, depending on the interface stack (e.g., virtual bridge interface over ethernet) and the peripheral (e.g., 100Gbps ethernet, perhaps, nowadays can we see lane-related stuff/BIP without using I2C GPIO?).
My recommendation as follows:
if you really need to read out the physical/link-layer information, the safe and correct way still would be to use operating system-specific facilities (e.g., netlink on Linux, route on BSDs) and peripheral-specific facilities (e.g., communication between microcode in the transceiver), the same as many appliances do.
if you really love to have something a bit inaccurate but perhaps useful information in the net package, it's better to add a new API like os.FileInfo and os.FileInfo.Sys rather than trying to abstract platform, driver and management things. There's a similar request: #17445.