No Offer Sent by DHCP Relay

David W. Hankins David_Hankins at isc.org
Wed Feb 7 18:23:12 UTC 2007


On Wed, Feb 07, 2007 at 11:43:34AM -0600, Josh wrote:
> If possible, can I get clarification on what problem the point-to-point
> tun adapter poses?  From what I see, the tun adapter is both passing the
> DHCP discover to the real DHCP server and receiving it back.  Here's
> what I see with tcpdump from the remote gateway machine (eth0 is the
> physical LAN link and tun_fv is the remote point-to-point IP link):

The relay, client, and server all use the same sockets implementations
in order to do wacky link layer and ip layer things that RFC2131
requires (but BSD sockets doesn't let us get away with).

Briefly, each of these open one or more raw sockets (usually BPF or
similar) for each interface they're operating on, and one 'fallback'
UDP socket.

The primary sockets are used for packet reception (without this many
unixes can't receive DHCP responses before an interface is addressed),
and transmission of RFC2131 compliant broadcasts.  One unfortunate
side effect of this is that we implement our own link layer, IP, and
UDP framing.

So the implementation can only receive packets on a limited number
of link layers.

The fallback socket is used only for transmitting unicast packets (so
that we don't have to also implement IP routing).

> As I'm reading that, the tun interface is passing the DHCP request to
> the DHCP server and receiving a response as expected.  I'm just confused
> as to how the p-t-p link is the cause of this problem.  Since the return
> DHCP offer comes to the 192.168.101.1 address, what's preventing
> dhcrelay from sending it on back to the client from that same address?

In this case the packet would be received on the 'fallback' socket
and discarded as a duplicate.  A copy of the same packet would be
expected to be obtained via one of the raw sockets.

In order to forward the packet, it has to be received on one of these
raw sockets (BPF/LPF etc).


This is obviously a case where what's good for the client isn't
quite so good for the server and is even worse for the relay.

It's on our drawing board to rethink the interface implementation.
It would be nice to not have to use raw sockets on the server, as
in some unixes this precludes firewall rules.


> If there is no good way around this issue, are there any other DHCP
> relay options available for Linux that allow relaying over
> point-to-point IP-level links?  Something along the lines of the Cisco
> "ip-helper" option is exactly what we're looking for.

Not that I am aware of.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins


More information about the dhcp-users mailing list