DHCP Relay + PPP (your mail)

JOBY THAMPAN JOBYTHAMPAN at nestec.net
Wed May 24 05:11:49 UTC 2006



Hi,
	First of all thanks for your great comments.

	I didn't understand the part I have pasted below.
	
	- you just need to be able to receive a unicast packet to the
GIAddr.

	When I captured packets using ethereal there it is shown DHCP OFFER
is sent as a unicast packet to GIAddr 
	
	so there seems already support to recieve a unicast packet to
GIAddr...
	
	When I start dhcrelay I see a message like this....

	./dhcrelay -d -i eth0 -i ppp0 192.168.10.2
		
	Copyright 2004 Internet Systems Consortium.
	All rights reserved.
	For info, please visit  <http://www.isc.org/sw/dhcp/>
	ppp0 unknown hardware address type 514
	Listening on LPF/ppp0/
	Sending on   LPF/ppp0/
	Listening on LPF/eth0/00:40:63:da:3b:e6
	Sending on   LPF/eth0/00:40:63:da:3b:e6
	Sending on   Socket/fallback	

	Could be the message "unknown hardware address type 514" the reason
?


	1) In discover.c file in discover_interfaces function.
   	I saw a checking whether

           /* Skip non broadcast interfaces (plus loopback and
                   point-to-point in case an OS incorrectly marks them
                   as broadcast). Also skip down interfaces unless we're
                   trying to get a list of configurable interfaces. */
                if (((!(ifr.ifr_flags & IFF_BROADCAST) ||
                      ifr.ifr_flags & IFF_LOOPBACK ||
                      ifr.ifr_flags & IFF_POINTOPOINT) && !tmp) ||
                    (!(ifr.ifr_flags & IFF_UP) &&
                     state != DISCOVER_UNCONFIGURED))
                        continue;

		
	Could this be the reason?

Rgds
Joby


	

-----Original Message-----
From: dhcp-users-bounce at isc.org [mailto:dhcp-users-bounce at isc.org]On
Behalf Of Simon Hobson
Sent: Wednesday, May 24, 2006 4:05 AM
To: dhcp-users at isc.org
Subject: Re: DHCP Relay + PPP (your mail)


Thinking more about this, things are even simpler that I first 
thought - unless you know differently that is !

The relay agent has only one function, to receive broadcast packets 
from clients which are forwarded to the dhcp server, and to broadcast 
the returned packets. To deal with the broadcast packets requires 
jumping through the hoops it does.

However, handling the packets from the dhcp server is surely a 
trivial exercise - all that is required is to open the right port (67 
or 68 ?) on any IP address(es) that the relay agent might use for the 
GIAddr. The actual interface doesn't matter and probably isn't the 
real interface that the packet arrives on from the server - you just 
need to be able to receive a unicast packet to the GIAddr.

If done that way, then there would be no need to worry about the 
technology of any upstream connections - only that of the client 
networks. Also, the only configuration required would be the 
network(s) to listen on for client broadcasts (and server 
address(es)) - certainly no need to worry about how server reply 
packets will arrive.

Have I missed something blindingly obvious ?

Simon


---------------------------------------------------------------------------
       "This e-mail and any files transmitted with it are for the sole use
of the intended recipient(s) and may contain confidential and privileged
information. If you are not the intended recipient, please contact the
sender by reply e-mail and destroy all copies of the original message.

       Any unauthorized review, use, disclosure, dissemination, forwarding,
printing or copying of this email or any action taken upon this e-mail is
strictly prohibited and may be unlawful."
---------------------------------------------------------------------------


More information about the dhcp-users mailing list