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

Submitter:  Daniel Elstner <danielk>
Submitted:  Mon 19 Sep 2016 02:42:14 AM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  Feature Request Status:  Fixed
Privacy:  Public Assigned to:  None
Open/Closed:  Closed Planned Release:  None
lwIP version:  git head

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

Applied, thanks

Dirk Ziegelmeier <dziegel>
Group administrator
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>
Group administrator
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>

 

(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 dziegel (Posted a comment)
  • -email is unavailable- added by danielk (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-09-19 dziegel StatusNone Fixed
        Open/ClosedOpen Closed
    2016-09-19 dziegel StatusFixed None
        Open/ClosedClosed Open
    2016-09-19 danielk Attached File- Added 0001-Bug-49125-addendum-Remove-group-from-list-before-cal.patch, #38547
    2016-09-19 dziegel StatusNone Fixed
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-caa5.
    Corresponding source code