1. Messages
  2. dhcp integration into the platform

Re: dhcp integration into the platform

Shtivelman, Bella <bella.shtivelman@...>
 

Hi,

In the existing DHCP design it’s not enough for application just subscribe to NET_EVENT_IF_UP event.

For our client application we observed situations when the link was up, but IPV4 address still hasn’t been assigned yet.

The issue was solved by subscribing to NET_EVENT_IPV4_ADDR_ADD event.

So maybe in the new design it should be taken into account as well.

 

Thanks,

Bella

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Anas Nashif
Sent: Thursday, February 09, 2017 01:56
To: Marcus Shawcroft <marcus.shawcroft@...>
Cc: Rissanen, Jukka <jukka.rissanen@...>; Bursztyka, Tomasz <tomasz.bursztyka@...>; devel@...
Subject: Re: [Zephyr-devel] dhcp integration into the platform

 

Hi

 

On Thu, Feb 9, 2017 at 4:53 AM, Marcus Shawcroft <marcus.shawcroft@...> wrote:

Hi,

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.

 

What we see here are the first signs of a connection manager :)

 

We do need DHCP to act as a service, when writing an application that relies on DHCP it makes sense to have the initialisation and setup of the networking device consistently with having to reimplement the code over and over again in every application.

 

I can also see the DNS service being setup if we get a DNS server address via DHCP and set the context of the DNS client to allow resolution queries without having to do that by foot.

 

+1 for the approach described above.

 

 


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

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

 

 

Well, this API is not released yet, so I think it should be easy to remove, but we are running out of time for 1.7...

 

 

Anas

 

 


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

Cheers
/Marcus
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel

 

---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
Join devel@lists.zephyrproject.org to automatically receive all group messages.