dhcp integration into the platform

Marcus Shawcroft <marcus.shawcroft@...>


This evening I took a look at how we might better integrate dhcpv4
into the platform.

In the current tree, in order to use dhcp the application is expected
to start the dhcp client explicitly. There is no synchronization
between network link up / link down events and the dhcp state machine.

The dhcp state machine will start issuing discover messages
irrespective of the link status, once the link comes up, dhcp will
typically run through request/ack and install an IP number and GW etc.
Should the link drop and subsequently up again the dhcp state machine
remains oblivious.

Better integration of dhcp into the stack looks reasonably straight forward.

I propose the following:

- dhcp_start() is modified to initialize the dhcp context, but remain
in the INIT state.
- net_if is modified to generate network management link up / down events
- dhcpv4 is modified to capture link up and link down events from net mgmt
- dhcpv4 enters discover on link up
- dhcpv4 performs unset_dhcpv4_on_iface for link down
- unset_dhcpv4_on_iface needs to net_if_ipv4_addr_rm (it should
probably do that anyway)
- dhcp_start is renamed and hooked in by SYS_INIT ?
- A new empty dhcp_start is defined and marked deprecated (to be nice
to apps that might currently call it).
- The current public include/dhcp.h exposed interface is removed.

There are a few details Ive not thought through properly yet, notably:

- The net_if layer already has link_up and link_down events. These
however are defined to fire when a net_if is enabled or disabled, not
when its link goes up or down, hence either these events need to be
redefined or we introduce two new events to represent the link up and

- I'm not sure what the appropriate way of managing the removal of a
public .h file should be.

- There are several way of wiring up the network management link up /
down notifiers:
1) Drivers do it directly.
2) Drivers call the net_if layer which in turn issues the network
management events.

Before I take this any further I'd appreciate feed back on sanity of
the approach and indeed whether such patches would be welcome.


Join devel@lists.zephyrproject.org to automatically receive all group messages.