buglwIP - A Lightweight TCP/IP stack - Bugs: bug #47652, there is always a delay to send...

 
 

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

bug #47652: there is always a delay to send the first Neighbor Solicitation for the new add INCOMPLETE state neighbor entry

Submitter:  shu chen <chenshu>
Submitted:  Sat 09 Apr 2016 12:15:27 AM UTC
   
 
Category:  IPv6 Severity:  3 - Normal
Item Group:  Change Request Status:  Fixed
Privacy:  Public Assigned to:  goldsimon
Open/Closed:  Closed Planned Release:  None
lwIP version:  git head

Jump to the original submission

Tue 23 Aug 2016 01:50:59 PM UTC, comment #7: 

fixed, thanks for reportign

Simon Goldschmidt <goldsimon>
Group administrator
Wed 27 Apr 2016 10:44:14 AM UTC, comment #6: 

Reading this correctly, I think sending the NS right away would be better. After all, this is what etharp.c does, too.

Simon Goldschmidt <goldsimon>
Group administrator
Wed 27 Apr 2016 10:28:29 AM UTC, comment #5: 

D'Oh! Forget the last comments, I confused this bug with DAD...

Simon Goldschmidt <goldsimon>
Group administrator
Tue 26 Apr 2016 08:28:31 PM UTC, comment #4: 

Also, the RFC says we SHOULD have an initial delay for first packets on a link. Although this delay should be random...

Simon Goldschmidt <goldsimon>
Group administrator
Tue 26 Apr 2016 08:06:51 PM UTC, comment #3: 

I'd be happy to send the NS instantly, but that wouldn't remove the delay to send packets: we do have DAD, so we need to wait, anyway, for nd6_tmr() to set the state to PREFERRED, or am I wrong?

Simon Goldschmidt <goldsimon>
Group administrator
Wed 13 Apr 2016 02:23:06 PM UTC, comment #2: 

The main reason why we may need to improve the IPv6 NS process is that the delay blocks all the first packet to the neighbors, all the first packet to a new neighbor always take a longer time(probably near one second) than usual.
My proposal is to send the first NS immediately after add a new 'INCOMPLETE' state neighbor, What's your opinion? Very appreciated for your feedback.

shu chen <chenshu>
Tue 12 Apr 2016 09:11:30 PM UTC, comment #1: 

This is an accurate description of what's going on. This could be improved, but I personally feel that for a lightweight TCP/IP stack, this should be sufficient.

Since this is a judgment call, others feel free to comment please.

Ivan Delamer <idelamer>
Group Member
Sat 09 Apr 2016 12:15:27 AM UTC, original submission:  

The bug is found during the ping test in our project, all the first ping to the new neighbor exceeds one second.

In the current Neighbor Discovery implementation of LwIP, there is always a delay to send the first Neighbor Solicitation for the new add INCOMPLETE state neighbor entry. The delay blocks all the first packet to the neighbors.

In the RFC-4861, the INCOMPLETE state is described as follows (section 7.3.2):
"Address resolution is being performed on the entry. Specifically, a Neighbor Solicitation has been sent to the solicited-node multicast address of the target, but the corresponding Neighbor Advertisement has not yet been received."

But the current LwIP process:
  - create a new neighbor entry, init it as INCOMPLETE
  - wait for the nd6_tmr timer (once a second)
  - nd6_tmr is triggered, send neighbor solicit if the entry's state is INCOMPLETE

The current process is a little non-conformant with the RFC-4861, the correct way is to send Neighbor Solicitation immediately for the new neighbor entry, and then mark it as INCOMPLETE. So there should not be any delay to send the first Neighbor Discovery which blocks the first packet to the neighbor.

shu chen <chenshu>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

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 goldsimon (Posted a comment)
  • -email is unavailable- added by idelamer (Posted a comment)
  • -email is unavailable- added by chenshu (Submitted the item)
  •  

    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 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-08-25 goldsimon StatusWorks For Me Fixed
        Assigned toNone goldsimon
        Open/ClosedOpen Closed
    2016-04-12 idelamer Item GroupFaulty Behaviour Change Request
        StatusNone Works For Me

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code