net: ponies: ListenBroadcastUDP(net string, ifi *Interface) (*UDPConn, error)

[gopherbot]

by krolaw:

In writing my DHCP library I have found:
l, err := net.ListenPacket("udp4", "192.168.1.250:67")
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.

Thanks.

[mikioh]

Comment 1:

Hope http://godoc.org/code.google.com/p/go.net/ipv4 and
http://godoc.org/code.google.com/p/go.net/ipv6 might help you.

Status changed to WaitingForReply.

[gopherbot]

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.

[mikioh]

Comment 3:

Those two packages provide per-packet control to you. You can listen to ["udp4",
"0.0.0.0", "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.

[gopherbot]

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?

[mikioh]

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.

[gopherbot]

Comment 6 by krolaw:

Done. New Issue #7106.