buglwIP - A Lightweight TCP/IP stack - Bugs: bug #45353, IPv6 router / neighbor...

 
 

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

bug #45353: IPv6 router / neighbor relationship is not always consistent

Submitter:  Stian Sebastian Skjelstad <mywave>
Submitted:  Fri 19 Jun 2015 08:27:05 AM UTC
   
 
Category:  IPv6 Severity:  2 - Minor
Item Group:  Faulty Behaviour Status:  Fixed
Privacy:  Public Assigned to:  idelamer
Open/Closed:  Closed Planned Release:  None
lwIP version:  git head

Sun 06 Mar 2016 01:49:29 PM UTC, comment #4: 

The race condition I'm seeing would be that router sends RA but then is offline a again and does not respond in state INCOMPLETE (without the router's invalidation_timer expiring). In normal communication, this does not happen, but it's not unlikely when plugging and pulling cables on the net...

The attached patch fixes this in a better way than checking for 'isrouter' in the free() function, as the latter fix would stop sending out NS.

Fixed by slightly changing the attached patch.

Simon Goldschmidt <goldsimon>
Group administrator
Fri 19 Jun 2015 05:00:19 PM UTC, comment #3: 

Yes, this is the potential case I am seeing, although it is hard to imagine a router that is both sending RAs and is also not online.

It will be fixed soon...

Ivan Delamer <idelamer>
Group Member
Fri 19 Jun 2015 04:54:39 PM UTC, comment #2: 

I only have my phone this weekend. But the issue i saw in codepath

RA causes a new router to be created, and the router creates a fresh neigtbor (or uses existing from RA traffic)

If this router temporary is offline, the neigbor entry might time out and are then open for recycle.

From this point of, the router now points to wrong or invalid neighbor.

The patch attached added isrouter chech to disable the deletion of timeout neigbor router entries.

Stian Sebastian Skjelstad <mywave>
Fri 19 Jun 2015 04:16:02 PM UTC, comment #1: 

Thanks Stian.

I think in general the ->isrouter field protects that router entry. The only time I see this could fail is if we get a RA message, but then router does not respond to probe messages (highly unlikely).

So I think as a safety measure we should add to nd6_free_neighbor_cache_entry() a check to remove a router if referenced.

Ivan Delamer <idelamer>
Group Member
Fri 19 Jun 2015 08:27:05 AM UTC, original submission:  

When creating a IPv6 router, it will first create a neightbor and reference that with a pointer later:

inside nd6_new_router():
default_router_list[router_index].neighbor_entry = &(neighbor_cache[neighbor_index])


However, if neighbor cache is exhausted or entry times out it will be removed, but nd6_free_neighbor_cache_entry() has no knowledge of the default_router_list[].


I suggest that neighbor_cache[] should also contain a link back to default_router_list[], and invalid the neighbor_entry pointer if entry is deleted (and hence kill the route entry), or the possibility to delete neighbor_cache[] entries that are routers should be removed.

One thing to consider too in this situation is that a router (gw) might have been added statically by the user. In that case, a FLAG should be set that makes it impossible to recycle a neighboor_cache/router entry if created by the user unless explicit deleted... or user needs to check every now and then that his router/neigboor entry still exists...


I can create suggestion patches

Stian Sebastian Skjelstad <mywave>

 

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

Attached Files

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by goldsimon (Updated the item)
  • -email is unavailable- added by idelamer (Posted a comment)
  • -email is unavailable- added by mywave (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 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-03-06 goldsimon StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2015-08-25 goldsimon SummaryIPv6 router / neightbor relationship is not always consistent IPv6 router / neighbor relationship is not always consistent
    2015-06-19 idelamer Severity3 - Normal 2 - Minor
        StatusNone Confirmed
        Assigned toNone idelamer
    2015-06-19 mywave Attached File- Added 0001-Do-not-ever-free-neighbor_cache-entries-that-are-rou.patch, #34259

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code