DHCP over PPP - or how to use sockets instead of BPF?
plahti at qnx.com
Fri Apr 16 17:19:08 UTC 2010
On 15/04/10 05:59 PM, David W. Hankins wrote:
> On Thu, Apr 15, 2010 at 02:51:17PM -0400, Patrik Lahti wrote:
>> PS. I know IPCP provides IPv4 addresses and link-local IPv6 addresses, but
>> DHCP over PPP is useful to get other configuration (such as name servers)
>> as well as IPv6 (global/UL scope) address configuration.
> This is basically a known design limit. We've been trying to gear up
> for a rework of the common interface discovery/socket-management code,
> but haven't made enough momentum for escape velocity yet.
That's very understandable, gravity and all, I know how it is :-)
Wrt rework, the patch to change to socket use, which Steinar Haug
suggested on this thread, is a start. Together with a simple change to
get_hw_addr() to recognize IFT_PPP, I got a successful basic DHCPv6
SOLICIT/ADV/REQ/REPL exchange over PPP. I had to require the DUIDs be
pre-configured. However, I noted the IAID was zero, and realized it's
based on hw_address too... More about this below...
> Essentially we only want to permit ppp interfaces for DHCPv6 since
> DHCPv4 isn't specified for ppp links.
Aha, I see. For this reason my main interest would be DHCPv6 too.
But it would be nice to allow DHCPv4 to "work" somehow. Otherwise, how
do people automatically get DNS servers on PPP links? I remember
statically configuring name servers back in the modem days but we're
trying to make things "just work" when you plug them in these days right :-)
Is there any implementation which supports DHCPv4/PPP (in a non-standard
way) out there? Is there a "de facto" way of doing it?
> One of the thorny parts of this move is that we do still need to fetch
> data from _some_ physical interface, like ethernet or etc, in order to
> draw a MAC address to create an initial DUID.
Yes, I investigated the use of struct interface_info.hw_address in the
code, and saw the issue with DUID and also IAID.
a) DUID LL and LLT is required by standards, and in practice one could
automagically try to create it by scanning for Ethernet interfaces on
the box in order to create them, and fail with an error message if that
b) Alternatively, and much more simple, would be to require that DUID
manually configured through dhcp-client-id and server-duid (or already
be present inside the lease file upon startup - this is what I did in my
c) DUID Enterprise would always need to be manually configured, right?
The hw_address is also used for:
1) IAID, but as I understand this it is an implementation choice and
maybe another scheme which still meets the RFC uniqueness requirement
could be used for PPP interfaces?
2) Random seed
3) CHADDR in DHCPv4, maybe the only way to solve this is to write an
IETF draft and go through the whole procedure, unless there's an
interoperable way to do this "out there"...
4) Tracing code.... not sure what this is about yet...
IMHO, what's left to do is a) make the code use sockets for PPP
interfaces, and still use BPF for other interfaces, rather than a crude
compile directive to make all interfaces use sockets, and b) try to
generate "something" into hw_address to make the rest which depend on it
fly, alternatively make the rest fly without hw_address but I don't
think I'd want to go there...
Do you think that would take care of it?
Do you know of any other problems beside the ones related to hw_address
More information about the dhcp-users