-
Notifications
You must be signed in to change notification settings - Fork 753
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
link_linux: Add deserialization of IFF_RUNNING
flag
#1038
link_linux: Add deserialization of IFF_RUNNING
flag
#1038
Conversation
Thank you @dylandreimerink |
Hmm, it seems |
I bumped the Go version, which seems to have fixed the original failure. But now we have a new one:
Interestingly the suite contains the exact same test twice (hence the Not sure if this is test flakyness or something the Go bump might have caused 🤔 . |
Thanks @dylandreimerink Can you please push a separate PR to bump go to 1.22. This project follows a 1 fix/change/feature per PR. Thanks |
Understandable. I will make a separate PR for the go version bump and rebase this PR once that one is in. |
please rebase to latest |
Add deserialization of the `IFF_RUNNING` link flag which translates to `net.FlagRunning`. Signed-off-by: Dylan Reimerink <[email protected]>
f817abd
to
ace2555
Compare
LGTM |
PR vishvananda#1038 started using net.FlagRunning which was introduced in Go 1.20, see https://go.dev/doc/go1.20#netpkgnet. Bump the minimum required Go version in go.mod accordingly and run `go mod tidy`.
I noticed that the decoded link flags never include
net.FlagRunning
. It seems deserialization logic was never added for this particular flag. Having access to the running flag is actually useful to detect when a link is in a NO-CARRIER state, which happens when a layer 1 issue occurs such as an unplugged or broken cable.I also removed the comment since the function now deviates from the original.