Thu 23 Jun 2016 12:27:07 PM UTC, comment #9:
I think I may have found an incorrect behavior/regression in inbuilt DHCP Client of lwip. I think it was introduced When the bug #37068 was fixed. I see that the status callback notifying netif driver that the DHCP is complete gets triggered before dhcp_bind is complete.
IIUC, before commit id 4e520cdd3009cf2e04c50c173737b379ff7d72a2 the status callback would trigger only after dhcp_bind was complete. Below is the detailed flow to elaborate it further.
Earlier LWIP : 1.4.0
DHCPclient Flow was as follows:
1. Netif driver registers a callback using
netif_set_status_callback
2. Netif driver starts DHCP Client by calling netifapi_dhcp_start
It used to call dhcp_start in src/core/dhcp.c
3. DHCP client's state machine execution starts
When the state is reached to DHCP_BOUND
netif was set up by calling netifapi_netif_set_up
4. This would call the callback registered in step 1
5. In callback,netif flags are checked
Check for NETIF_FLAG_DHCP and this helps to find out
that a DHCP address has been gained by the client for the interface
With new LWIP code:
1. Setup of interface has become a must before calling DHCP start
2. Code sequence
netifapi_netif_set_up
netif_set_status_callback
netifapi_dhcp_start
3. DHCP state machine executes and after dhcp_discover is executed, the
registered callback is called.
This happens immediately after an IP address is received by the netif.
4. Callback cannot use flag NETIF_FLAG_DHCP as it is not available now
5. dhcp_supplied_address is used to check if address is supplied using HCP
This code checks for DHCP client state and it should be
DHCP_STATE_BOUND
6. But it appears that before dhcp_bind is done and state is changed, callback is called.
|
Fri 06 Mar 2015 07:50:41 PM UTC, comment #8:
... and fixed again.
|
Thu 05 Mar 2015 08:49:45 PM UTC, comment #7:
Yes, thanks for pointing that out.
|
Thu 05 Mar 2015 08:08:52 PM UTC, comment #6:
Should we change the comment for NETIF_FLAG_UP then ?
/** Whether the network interface is 'up'. This is
- a software flag used to control whether this network
- interface is enabled and processes traffic.
- It is set by the startup code (for static IP configuration) or
- by dhcp/autoip when an address has been assigned.
*/
|
Thu 05 Mar 2015 07:59:19 PM UTC, comment #5:
Fixed by correclty separating administrative status of a netif (up/down) from 'valid address' status.
ATTENTION: netif_set_up() now always has to be called, even when dhcp/autoip is used!
|
Fri 07 Mar 2014 08:22:53 AM UTC, comment #4:
A related issue is about having separate NETIF_FLAG_UP for IPv4 and IPv6. Below the description of the issue -
netif_set_up() function is called from DHCP state machine inside lwip, or it should be called by netif driver while static IP address is configured.
Lets consider a scenario where a device is configured with DHCP, however for some reasons device do not get DHCP (IPv4) address. Irrespective of the success/failure with DHCP (IPv4), one wants to configure link local IPv6 address for an interface and start IPv6 traffic.
One can call netif_set_up() while configuring IPv6 address. However as struct netif is shared by IPv4 and IPv6 both, calling netif_set_up() wrongly assumes that both IPv4 and IPv6 address have been configured successfully - hence it starts sending different kinds of IPv4 (Gratuitous ARP, IGMP, SNMP, etc.) and IPv6 (MLD, RS,etc.) traffic.
How about separating out the "NETIF_FLAG_UP" flag for IPv4 &
IPv6? If either of IPv4 or IPv6 address is successfully configured then only the traffic pertaining to that address need to be activated.
NETIF_FLAG_UP is checked only in IPv6 specific functions and not used in IPv4 specific functions other than netif_set_down(). Is there any specific reason behind this.
|
Fri 10 Aug 2012 09:44:38 AM UTC, comment #3:
I thought of enabling/disabling hardware, not only of stopping TX/RX:
- the hardware may stop send/receive when the link is down, but it may also continue (although send has no effect an there will be nothing to receive)
- the hardware cannot be powered down when only the link is down or it will not detect link-reconnect
- in contrast to this, the hardware could be powered down while lwIP does not use the netif - in this case, link state is not interesting
|
Fri 10 Aug 2012 08:57:48 AM UTC, comment #2:
Should the hardware not respect/maintain the NETIF_FLAG_LINK_UP state as the send/receive flag? (rather than use the NETIF_FLAG_UP as referenced by DHCP, AutoIP, et-al).
So use netif_is_link_up() instead if netif_is_up()?
|
Fri 10 Aug 2012 06:52:18 AM UTC, comment #1:
This would also make it possible to disable the hardware when a netif is in 'down' state (we would need an additional call into the netif driver for that).
|
Fri 10 Aug 2012 06:51:25 AM UTC, original submission:
We currently send and receive on netifs that are 'administratively' set down (netif_set_down()). This happens for DHCP and AutoIP (netif is only set to 'up' after successfully acquiring an IP address).
I think this is somewhat unclear and should be cleaned up in a way that a netif must always be up when sending or receiving on it. The initialization phase of DHCP/AutoIP should just set the netif IP address to '0.0.0.0' and routing should ignore netifs with '0.0.0.0'.
|