Tue 17 Jul 2007 09:09:38 AM UTC, comment #2:
Some of the changes can be done for 1.3.0, since there are bugs fix, or coding styles. I will check in them in a first step. For the others, they need more tests. I hope to find time for them in the end of the week, or next week... I take this bug (I can test it, of course, if there is no objection)...
>NOTES: This only implements "host" function
ok
>Interface should be up before joining groups
ok. About one of the last change for link up/down, I think we also have to resend reports when the link change to "up"
>Removed igmp_init() from tcpip_thread() function and force users to call after netif_add() [Perhas there is a better solution]
I will look your change, since some init are need to be done in "the good order" (but which one ? :) )
>Reworked igmp.c to allow for different group list per interface. [This required adding a igmp_group_list to the netif structure (netif.h).]
ok (but need to study that)
>Reworked igmp.c so debug reporting was formatted like other lwip files. [I hope don't offended anyone.]
ok (will be check in for 1.3.0)
>Reworked igmp.c so all function names all begin with "igmp".
ok (will be check in for 1.3.0)
>netif_add() now initializes igmp_mac_filter to NULL [as well as the new field igmp_group_list.]
ok (just have to see if it's done at the "good" time (before low_level_init). The netif change is not attached. The last you post on the mailing list is good?
>igmp_joingroup() now checks to make sure you only add multicast addresses to the list.
ok (will be check in for 1.3.0) since it was a bug
>Added group_state member DEAD_MEMBER to separate groups that are being initialized to those that are stale. [This allow correct building of hash key as we may not deleting records]
ok (but need to study that)
>Removed igmp_mac_filter() to allrouters group. [I don't think this needed in V2]
Not ok, since, like we have talk on the mailing list, some switchs/routers doesn't use 224.0.0.1, but 224.0.0.2. I suppose it's due to a problem in their RFC interpretation, but on the field, we have to accept both to receive query messages. My experience with industrial switchs/routers using IGMP is this is a "component" not always very well implemented, where the field sometimes a better "rule" than the RFC (always in draft for memory). Since let receive 224.0.0.2 packets is not a big problem, I think we have to let receive
>In igmp_input(), changed igmp_lookup_group() to igmp_lookfor_group. [If it's not for us, we don't want it!]
ok, this is a bug for me (to fix in 1.3.0)
>igmp_leavegroup() can now delete memory used by the group.
Use LWIP_IGMP_FREE_GROUPS to enable this feature
If there is a problem with memory (and there is one in IGMP), I'm in flavor to fix it without any options. Of course, it depend of the way to do it. I would like to use memp rather than mem to allocate igmp_group structs.
|