search

golang / go

The Go programming language
https://go.dev
BSD 3-Clause "New" or "Revised" License
123.97k stars 17.67k forks source link

net: add FlagRunning as network interface flag #29991

Closed brutella closed 2 years ago

brutella commented 5 years ago

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.

ianlancetaylor commented 5 years ago

CC @mikioh

ianlancetaylor commented 5 years ago

Looks like reporting just IFF_UP, not IFF_RUNNING, dates back to https://codereview.appspot.com/4437087 .

brutella commented 5 years ago

Reading through the code review and I couldn't find anything that speaks against supporting IFF_RUNNING.

rsc commented 5 years ago

It seems like we should have the bit since it's part of the standard network API. (Here's a stack overflow explaining the difference: https://stackoverflow.com/questions/11679514/what-is-the-difference-between-iff-up-and-iff-running).

Accepting.

mikioh commented 5 years ago

The current set of net.Flags are chosen from the following criteria:

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:

  1. 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.
  2. 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.
mikioh commented 5 years ago

http://golang.org/cl/162037 is a counter proposal.

gopherbot commented 5 years ago

Change https://golang.org/cl/162037 mentions this issue: net, syscall: add Sys field to Interface for system-dependent information

tklauser commented 2 years ago

It looks like this was proposed again in #53482 and implemented by https://go.dev/cl/413454, so I think this can be closed as completed.