lwIP - 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
Submitter: | Simon Goldschmidt <goldsimon> | ||
Submitted: | Fri 10 Aug 2012 06:51:25 AM UTC | ||
Category: | IPv4 | Severity: | 3 - Normal |
Item Group: | Faulty Behaviour | Status: | Fixed |
Privacy: | Public | Assigned to: | 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: |
Nirav <neoisnirav> |
Fri 06 Mar 2015 07:50:41 PM UTC, comment #8: ... and fixed again. |
Simon Goldschmidt <goldsimon> |
Thu 05 Mar 2015 08:49:45 PM UTC, comment #7: Yes, thanks for pointing that out. |
Simon Goldschmidt <goldsimon> |
Thu 05 Mar 2015 08:08:52 PM UTC, comment #6: Should we change the comment for NETIF_FLAG_UP then ?
*/
|
Sylvain Rochet <gradator> |
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.
|
Simon Goldschmidt <goldsimon> |
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 -
|
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:
|
Simon Goldschmidt <goldsimon> |
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).
|
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> |
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).
|
Simon Goldschmidt <goldsimon> |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 9 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2015-03-06 | goldsimon | Status | In Progress | Fixed | |
Open/Closed | Open | Closed | |||
2015-03-05 | goldsimon | Status | Fixed | In Progress | |
Open/Closed | Closed | Open | |||
2015-03-05 | goldsimon | Category | None | IPv4 | |
Item Group | None | Faulty Behaviour | |||
Status | None | Fixed | |||
Assigned to | None | goldsimon | |||
Open/Closed | Open | Closed |
Powered by Savane 3.13-f8d8.
Corresponding source code
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.