your mail

[David W. Hankins]

On Tue, May 23, 2006 at 12:15:34PM +0530, JOBY THAMPAN wrote:
> 	When I made DHCP Relay listening on a machine containing PPP
> Interface, the DHCP Relay is not recieving the offer packet from dhcp server
> 
> 	But when I made DHCP Relay listening on ethernet interface on a
> different machine other than the machine containing PPP Interface DHCP Offer
> Successfully recieved.
> 
> 	If somebody knows, Please explain why this is so???

The short answer is that is not presently a supported configuration.

If the relay and server are on the same box, you're better off just
extending the server to cover the additional interfaces directly than
to introduce a middleman.


The ISC DHCP package currently uses a combination of BPF (filtered
raw sockets) and standard BSD sockets.  The BPF sockets are used on
a per-interface basis to read and write contrived, raw packets, in
order to be RFC2131 compliant in regards to broadcast addressing (we
can't get what RFC2131 needs any other way reliably).

The BSD sockets are used to transmit - transmit only - unicast packets,
so that we don't have to do our own routing tables these cases.  Since
they are transmit only, the applications discard any packets received
on these 'Fallback' interfaces.  This is because any packets they receive
are expected to be duplicates of packets received on the BPF sockets.

So in your relay, a BPF socket is opened for ethx, ppp0, and a fallback
BSD socket is opened on 127.0.0.1:67.  The server does the same thing,
a BPF socket on ethy, and a fallback BSD socket on 127.0.0.1:67 (we
set SO_REUSEADDR, so this is legal - both applications receive copies
of these packets).

When the relay forwards to 127.0.0.1, it is sent via the loopback
interface, and is received only on the fallback interfaces - and
discarded by both the DHCP server and relay.


To support this configuration, you will have a substantial amount of
code to rewrite - I'm not really sure how you could rework the io
engine to support this, plus every type of packet processor also uses
127.0.0.1 as a magic 'test case' number (and forwards responses to
port 68 rather than port 67 as you would normally for a relayed packet
(so we can do higher level protocol level testing with USE_SOCKETS off
lo0).

We accept patches.

-- 
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