buglwIP - A Lightweight TCP/IP stack - Bugs: bug #49125, Need a way to iterate multicast...

 
 

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

bug #49125: Need a way to iterate multicast groups for MAC filtering

Submitted by:  Daniel Elstner <danielk>
Submitted on:  Mon 19 Sep 2016 02:42:14 AM UTC  
 
Category: NoneSeverity: 3 - Normal
Item Group: Feature RequestStatus: Fixed
Privacy: PublicAssigned to: None
Open/Closed: ClosedPlanned Release: None
lwIP version: git head

Mon 19 Sep 2016 10:33:12 AM UTC, comment #3:

Applied, thanks

Dirk Ziegelmeier <dziegel>
Project Member
Mon 19 Sep 2016 08:08:14 AM UTC, comment #2:

Thanks for the quick response! The attached patch improves upon the fix by changing the delete behavior: The group to be deleted should be removed from the list before invoking the filter callback, so the list always reflects the desired memberships.

(file #38547)

Daniel Elstner <danielk>
Mon 19 Sep 2016 06:49:18 AM UTC, comment #1:

I was thinking about linking these lists to netif a few weeks before. Problem is that you then add a pointer to each netif for the list head, and I guess there will mostly be only one netif with multicast groups in practice ("uplink").

So yes, you always need to check the netif pointer when iterating, too.

Dirk Ziegelmeier <dziegel>
Project Member
Mon 19 Sep 2016 02:42:14 AM UTC, original submission:

In my Ethernet interface code, I am implementing the MLD MAC filter callback in order to reconfigure the hardware address matching of the MAC controller.

Although I got it working in principle, the implementation is unnecessarily complicated because the API does not provide a way to iterate over all multicast groups of a netif. My hardware supports multicast address filtering by means of matching a hash, and the hash is a function of all multicast addresses I want to match. This means that using the current API, I need to keep track of added/removed IPv6 multicast addresses, essentially duplicating information that the MLD implementation already keeps track of. This wastes memory and complicates the code.

Actually even with table-based address matching hardware, it would be necessary to keep track of added groups just to know which table indices they occupy. So this is not limited to hashing.

Simply making the "mld_group_list" variable public would already be enough to fix this, since it is easy enough to skip over other netifs while iterating. If that's considered too internal to expose, the MLD code could perhaps be changed to store the groups directly in the netif struct.

The same considerations would also apply to IGMP. Interestingly, there is this comment in the IGMP code:

  • igmp group structure - there is
  • a list of groups for each interface
  • these should really be linked from the interface, but
  • if we keep them separate we will not affect the lwip original code
  • too much

I'd say linking the groups from the interface would make life a lot easier for anyone implementing the MAC filter callbacks.

Daniel Elstner <danielk>

 

Attached Files

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by dziegel (Posted a comment)
  • -unavailable- added by danielk (Submitted the item)
  •  

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

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 7 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 19 Sep 2016 10:33:12 AM UTCdziegelStatusNone=>Fixed
      Open/ClosedOpen=>Closed
    Mon 19 Sep 2016 10:24:43 AM UTCdziegelStatusFixed=>None
      Open/ClosedClosed=>Open
    Mon 19 Sep 2016 08:08:14 AM UTCdanielkAttached File-=>Added 0001-Bug-49125-addendum-Remove-group-from-list-before-cal.patch, #38547
    Mon 19 Sep 2016 06:49:18 AM UTCdziegelStatusNone=>Fixed
      Open/ClosedOpen=>Closed

    Back to the top


    Powered by Savane 3.1-cleanup1