buglwIP - A Lightweight TCP/IP stack - Bugs: bug #37068, netif up/down handling is unclear

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #37068: netif up/down handling is unclear

Submitted by:  Simon Goldschmidt <goldsimon>
Submitted on:  Fri 10 Aug 2012 06:51:25 AM UTC  
 
Category:  IPv4 Severity:  3 - Normal
Item Group:  Faulty Behaviour Status:  Fixed
Privacy:  Public Assigned to:  Simon Goldschmidt <goldsimon>
Open/Closed:  Closed Planned Release:  None
lwIP version:  CVS Head

( Jump to the original submission)

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.

  
Nirav <neoisnirav>
Fri 06 Mar 2015 07:50:41 PM UTC, comment #8: 

... and fixed again.

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
Thu 05 Mar 2015 08:49:45 PM UTC, comment #7: 

Yes, thanks for pointing that out.

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
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.

*/

Sylvain Rochet <gradator>
Project Member
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!

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
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.

Rahul <rahul_g>
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

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
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()?

James Smith <rallysmith>
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).

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
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'.

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by neoisnirav (Posted a comment)
  • -email is unavailable- added by gradator (Posted a comment)
  • -email is unavailable- added by rahul_g (Posted a comment)
  • -email is unavailable- added by rallysmith (Posted a comment)
  • -email is unavailable- added by goldsimon (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-03-06 goldsimon StatusIn Progress => Fixed
        Open/ClosedOpen => Closed
    2015-03-05 goldsimon StatusFixed => In Progress
        Open/ClosedClosed => Open
    2015-03-05 goldsimon CategoryNone => IPv4
        Item GroupNone => Faulty Behaviour
        StatusNone => Fixed
        Assigned toNone => goldsimon
        Open/ClosedOpen => Closed

    Back to the top


    Powered by Savane 3.5