Re: dhcp integration into the platform

Gil Pitney

Anticipating application initialization code like this:

<wait on semaphore signaled by a NET_DHCP_IPV4_ADDR_ACQUIRED callback >
<use pre-configured static ip address>

It probably doesn't matter how the address is acquired, but the
application needs to somehow know to wait for the IPv4 address
notification before proceeding. If DHCPV4 is configured, at least
the app knows it needs to wait in that case.

Could also remove the #ifdef in the app, have the app ask the net
interface if DHCP is supported (or if IP to be assigned by other
means), and if so, register to wait on a semaphore and wait on it,
otherwise proceed with a static IP address.

On 23 February 2017 at 12:49, Marcus Shawcroft
<marcus.shawcroft@...> wrote:
On 23 February 2017 at 19:35, Gil Pitney <gil.pitney@...> wrote:
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.

For example, echo_client application starts DHCP (if configured), but
does not wait for the IPv4 address to be acquired before proceeding
(and so uses an incorrect static IP address instead).

But perhaps, the event should be something like NET_DHCP_IPV4_ADDR_ACQUIRED?

Is it important to distinguish how the address was acquired?


Join to automatically receive all group messages.