Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

net: add FlagRunning as network interface flag #29991

Closed
brutella opened this issue Jan 30, 2019 · 8 comments
Closed

net: add FlagRunning as network interface flag #29991

brutella opened this issue Jan 30, 2019 · 8 comments
Labels
FrozenDueToAge help wanted NeedsFix The path to resolution is known, but the work has not been done. Proposal Proposal-Accepted
Milestone

Comments

@brutella
Copy link

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
Copy link
Contributor

CC @mikioh

@ianlancetaylor
Copy link
Contributor

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

@brutella
Copy link
Author

brutella commented Feb 1, 2019

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

@rsc
Copy link
Contributor

rsc commented Feb 6, 2019

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.

@rsc rsc changed the title proposal: net: add FlagRunning as network interface flag net: add FlagRunning as network interface flag Feb 6, 2019
@rsc rsc modified the milestones: Proposal, Go1.13 Feb 6, 2019
@ianlancetaylor ianlancetaylor added help wanted NeedsFix The path to resolution is known, but the work has not been done. labels Feb 6, 2019
@mikioh
Copy link
Contributor

mikioh commented Feb 7, 2019

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:

  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: net: add Sys field to Interface for retrieving platform-specific information #17445.

@mikioh
Copy link
Contributor

mikioh commented Feb 12, 2019

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

@gopherbot
Copy link

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

@andybons andybons modified the milestones: Go1.13, Go1.14 Jul 8, 2019
@rsc rsc modified the milestones: Go1.14, Backlog Oct 9, 2019
@tklauser
Copy link
Member

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.

@golang golang locked and limited conversation to collaborators Aug 30, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge help wanted NeedsFix The path to resolution is known, but the work has not been done. Proposal Proposal-Accepted
Projects
None yet
Development

No branches or pull requests

7 participants