Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Layer 2: Metallb shouldn't reply on interface with NOARP flag #351
Is this a bug report or a feature request?:
Speaker sends replies to any interface, even if arp disabled for it
What you expected to happen:
If interface have NOARP flag set, speaker should ignore it.
How to reproduce it (as minimally and precisely as possible):
Then try to arping
Anything else we need to know?:
I'm not a huge fan of adding a dependency, especially one that uses syscall and unsafe. Those are hard to get right, even for experienced Go programmers.
The one netlink library I trust is the one by @mdlayher . It's very well tested, and Matt's got a bunch of experience with kernel interfacing. But AFAICT, he hasn't implemented interface reading, so we'd have to add that on top of the base netlink (or genetlink? Not sure) package.
I mean, with that said, if I get a PR with anything, I'll probably merge it. If it's not using mdlayher's netlink packages, I'll just file an extra bug to remind me to change it later ;)
Hmm, actually, it looks like that repository is mostly just copy/pasting the linux implementation of net.Interfaces, and adding support for more flags. If we're going to just do that anyway, I would prefer it if we just copy/paste our own implementation using https://golang.org/src/net/interface_linux.go as a reference. That way we can tailor it to exactly the data we need.
But like I said, if you're sending a PR, I'll merge it if it's not hugely unsafe. Worst case I'll just file a bug to think about improving it later, but that's not a big deal.
I would have assumed the stdlib would have the "No ARP" flag, but apparently not.
vishvananda/netlink is pretty widely used. I personally am not a big fan of some of the design choices it has made, but it seems reliable enough. The equivalent in my netlink ecosystem would be https://godoc.org/github.com/jsimonetti/rtnetlink, but this one is currently less mature and less battle tested.
That said, if you can read that flag from /sys, I'd just do that instead of mucking with (route) netlink for this one tiny thing.
Unfortunately it can't be simple readed from
The result is combination of all of them is written in
I have no better idea for parse this value for and apply bitwise OR for all of them.
In bash I would like to use some workaround like: