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: ponies: ListenBroadcastUDP(net string, ifi *Interface) (*UDPConn, error) #6935

gopherbot opened this issue Dec 11, 2013 · 6 comments


Copy link

@gopherbot gopherbot commented Dec 11, 2013

by krolaw:

In writing my DHCP library I have found:
l, err := net.ListenPacket("udp4", "")
Listens on one interface but ignores broadcast packets coming to that interface.

So I end up using:
l, err := net.ListenPacket("udp4", ":67")
Listens on all interfaces and captures broadcast packets:

On a device with multiple interfaces this can be problematic.  The workaround so far has
been to use iptables to block dhcp client packets coming in on unwanted interfaces.

However, there is still the issue that any response packet doesn't go over the correct
interface.  When I try to open a new udp socket on the correct interface (using ip), 
and source port, it obviously doesn't work as the listener bound to that port.  The
workaround has been to open a new udp socket on a different port and use iptables to
SNAT the source port on the way through to 67.

Having a ListenBroadcastUDP function would also make writing client side DHCP practical.

Copy link

@mikioh mikioh commented Dec 11, 2013

Comment 1:

Hope and might help you.

Status changed to WaitingForReply.

Copy link

@gopherbot gopherbot commented Dec 12, 2013

Comment 2 by krolaw:

Thanks, but I don't think so as there's no offering for Broadcast packets, only
multicast and unicast.  But I'm happy to be wrong.
Copy link

@mikioh mikioh commented Dec 12, 2013

Comment 3:

Those two packages provide per-packet control to you. You can listen to ["udp4",
"", "67"] and deal with IP packet path by using incoming/outgoing IP interfaces.
Well, a) socket is a simple tuple, b) it doesn't support multiple tuples, c) we need to
specify a specific address or wildcard address for controlling socket, d) ipv4 has two
broadcast addresses: limited and directed broadcast addresses, e) proposed
ListenBroadcastUDP doesn't fix multiple tuple issue, also not fix multihome (packet
path) issue. Hm, I'm not keen on adding ListenBroadcastUDP but I may be wrong. If you
think that ListenBroadcastUDP is really useful, you can discuss at golang-dev, not here.
Copy link

@gopherbot gopherbot commented Dec 28, 2013

Comment 4 by krolaw:

Looks like I should have just focussed on the problem, NOT suggest how I think it should
be fixed. Could we rename this issue to something like: "net:Can't bind broadcast
listeners to an interface" and drop the ponies ListenBroadcastUDP stuff?
Copy link

@mikioh mikioh commented Dec 28, 2013

Comment 5:

File a new issue, please.
FWIW, syscall bind assigns "a local protocol address" to the socket. I guess an IPv4
limited broadcast address is considered as a non-local address on almost all the
platforms (except using some platform-dependent socket options such as IP_BINDANY). Also
basically socket has no concept of network interface or net/link adjacency (except using
some platform-dependent socket options) and also has no multiple address binding
support. I guess that making your own DHCP transport stuff using wildcard (INADDR_ANY)
socket or using BPF/LSF linklayer tap like ISC-DHCP would be a solution for now.

Status changed to Unfortunate.

Copy link

@gopherbot gopherbot commented Jan 15, 2014

Comment 6 by krolaw:

Done. New Issue #7106.
@golang golang locked and limited conversation to collaborators Jun 25, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.