-
-
Notifications
You must be signed in to change notification settings - Fork 1k
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
[Feature]: Support for SO_BINDTODEVICE? #532
Comments
Sounds reasonable, I'll see what we can do here. |
I've done some investigation on this. As for Therefore, if we're going to do this, it looks like we're only able to do it on linux and mac. References |
Thanks for digging into this. Would that make the functions just NOPs on other platforms or does it imply platform-specific APIs? |
If we're going to do this, API should be present on all platforms that |
This issue is marked as stale because it has been open for 30 days with no activity. You should take one of the following actions:
This issue will be automatically closed in 7 days if no further activity occurs. |
No more information to share, but still very interested in this functionality. |
This issue is marked as stale because it has been open for 30 days with no activity. You should take one of the following actions:
This issue will be automatically closed in 7 days if no further activity occurs. |
I plan on doing this next month if nothing else gets in the way. |
Updated: After some tests, I found that setting |
Description of new feature
While listening for UDP packets, it is common to listen on "0.0.0.0:123" or just ":123", which allows for the receipt of both unicast and broadcast UDP packets, however there are times where an application might want to listen on just a single network interface. Obtaining that interface's IP and then listening on "1.2.3.4:123" will only receive unicast packets, and thus the preferred mechanism is to still listen on ":123" (for v4+v6) or "0.0.0.0:123" (for v4), but to use SO_BINDTODEVICE to bind the socket to a single interface.
Once bound, tools like
ss
show it as0.0.0.0%eth0:123
rather than just0.0.0.0:123
.Scenarios for new feature
On network appliances with multiple interfaces, those interfaces are often attached to different networks - such as a network gateway that is attached to a LAN network on eth0 and the WAN network on eth1. If that device wants to listen for unicast+broadcast UDP on just the LAN interface, there is currently no way to do this with gnet (at least not that I could find).
Breaking changes or not?
No
Code snippets (optional)
For darwin:
For windows, there is example calls at https://stackoverflow.com/a/73041705 , but they'd need to be converted to go.
Alternatives for new feature
Could have separate listeners for unicast and broadcast traffic, but it gets messy.
Could listen to everything and then filter in
OnTraffic
, but it is much more efficient to have the kernel just bind to a single interface.Additional context (optional)
WithMulticastInterfaceIndex()
does something similar for multicast traffic.The text was updated successfully, but these errors were encountered: