How do I listen for broadcast (dhcp) packets on eth1?

[krolaw]

Hi,

I'm writing a DHCP server/client library, because I need one, can't find one and others have asked for one.  Everything is going rather well except on my multiple interface router I can't bind to a particular interface such as eth1.

Binding to a particular IP (net.Listen("udp4","172.30.0.1:67")) which the desired interface uses or broadcast address ("172.30.255.255") stops me from getting the dhcp discover broadcast packets.  However, listening to "0.0.0.0" allows me to receive the broadcast packets, but I am listening on all interfaces, not just eth1.  Unfortunately, I can't tell which interface the packets are coming from to filter, which makes things a bit messy when there is another dhcp server looking after clients (including my router) on the router's gateway interface (eth0).

I see that Multicast can bind to an interface, so I hope I'm missing something straight forward.  I'm also open to alternative elegant solutions.

Thanks.

[Mikio Hara]

On Tue, Sep 3, 2013 at 12:48 PM, krolaw <kro...@gmail.com> wrote:

> I see that Multicast can bind to an interface, so I hope I'm missing
> something straight forward. I'm also open to alternative elegant solutions.

I guess, no, unfortunately there's no solution to make things easier or smarter.

If you really need DHCP stuff, I usually recommend to kick it by using
os/exec package.
But if you really want to fill up your curiosity, FWIW, here is a
short summary of how to implement DHCP stuff in Go, no warranty.

Required components:

1. Transport
1.1. BPF, LSF or similar stuff (for bootstrapping)
1.2. UDP socket (when you don't want to use BPF/LSF after bootstrapping)
2. Information base
2.1. Address block information base
2.2. Lease information base
2.3. Network facility information base
3. Protocol
3.1. BOOTP messages and options encoder, decoder
3.2. DHCP messages and options encoder, decoder
3.3. Client FSM
3.4. Server FSM
3.5. Relay-agent FSM
4. System adaptation
4.1. Routing socket or netlink socket for capturing and re-configuring
network state inside the kernel
4.2. Configuration, operation and monitoring stuff
5. Security
(snip)
6. High availability (optional)
6.1. Something that makes information base resilient
6.2. Something that makes network resilient

Hope this helps.

[Kyle Lemons]

I think you can use http://godoc.org/code.google.com/p/go.net/ipv4#PacketConn.ReadFrom, which will give you a http://godoc.org/code.google.com/p/go.net/ipv4#ControlMessage, whose IfIndex you should be able to match with the http://godoc.org/net#Interface.Index from http://godoc.org/net#Interfaces.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Mikio Hara]

On Wed, Sep 4, 2013 at 2:38 AM, Kyle Lemons <kev...@google.com> wrote:

> I think you can use
> http://godoc.org/code.google.com/p/go.net/ipv4#PacketConn.ReadFrom, which
> will give you a
> http://godoc.org/code.google.com/p/go.net/ipv4#ControlMessage, whose IfIndex
> you should be able to match with the http://godoc.org/net#Interface.Index
> from http://godoc.org/net#Interfaces.

The problem is how to transmit a DHCPDISCOVER packet and what' the
best transport for it. IIRC, there's no universal way to transmit an
IPv4 packet that contains unspecified source address except AF_PACKET
on Linux, BPF on BSD, NIT on Solaris and/or LSF on Linux. In the case
of IPv6, it doesn't matter because we use link-local unicast and
multicast addresses for DHCP message exchange.

[Mikio Hara]

On Wed, Sep 4, 2013 at 10:35 AM, Mikio Hara <mikioh...@gmail.com> wrote:

> best transport for it. IIRC, there's no universal way

aha, http://godoc.org/code.google.com/p/gopacket/pcap.

[Kyle Lemons]

I think this is a server library he's writing, though I could well be wrong.  In any case, I think the question at hand was how to associate an incoming DISCOVER with the interface on which it was received so that only hosts on the appropriate interface will wind up being served.  The OFFER responses do have a source address and such, so the standard net.Conns work fine.