Matt Keenan writes:Kevin K wrote:I'll give it a try to see whether packets sent to 255.255.255.255 can
make it to ppp with the IP address unchanged.
You should be able to make DHCP work by sending ordinary unicast UDP
packets to the peer. There shouldn't be any need to hack around with
special broadcast addresses.
Use AF_INET, SOCK_DGRAM, and send away.
You shouldn't need to run DHCP over PPP, PPP uses LCP to configure
connections. I suspect the only time you would need to run DHCP over a
PPP link is if you had a DHCP proxy run the request over the PPP link,
but that sounds way more complicated than what you are looking for.
I don't think that DHCP over PPP is a bad idea at all, particularly so
with DHCPINFORM messages, which are stateless and don't involve any
sort of address assignment.
PPP is not designed to provide arbitrary client application layer
configuration. The RFC 1877 nonsense is a Microsoft proprietary thing
that doesn't actually work very well -- see my book for a more
substantial list of its flaws.
In contrast, DHCP works everywhere, includes *far* more configuration
information (such as boot servers, print servers, SIP addresses,
domain names, and the like), and is easier to manage than cramming
things into PPP.
Have
a quick look at
http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/ppp.htm that
should bring you up to speed on how PPP works. You will probably find
that LCP does everything you need. If you really need some of the
functionality of DHCP (such as setting up WINS servers et al) you might
find that you need to hack a way to do this.
The existing pppd already supports the MS proprietary hacks for DNS
and WINS server addresses. Since that's a dead end, you'll need DHCP
if you want to go further