The handling of ifup event in case of snooping config was missing.
Note: ifup event is generated only for l3 interface, so, say ethx is
member of br-y which has proto none. In this case if ethx link goes
down and comes up again, IPTV will not work without a mcast reload.
From the look of it this will be the case in old version as well and
at the moment I don't know how this can be handled but considering this
is a remote scenario in my opinion I don't think the risk is too high.
I would continue to look for a solution ofcourse.
Modifying the lookup method for forwarding multicast packets enables
forwarding on both tagged and untagged upstream interfaces.
I have tested:
- forwarding of traffic in untagged interface.
- forwarding of traffic on tagged interface.
- response to queries in above scenarios by upstream server.
- forwarding of unsolicited joins and leaves to upstream server.
I cannot see a fault at the moment
- Default filter value updated as per requirements.
- Logic added to modify filter ip address as accepted in /var/mcpd.conf
in broadcom.sh
Noticed one hard coding in qos, fixed that too.
In the default config that is generated by the mcast manager,
after support for MLD config via bbf was added the name of section
was updated. This caused unwanted behaviour when config addition
were made by the bbf on top of default config. Updated the default
config igmp snooping section name to resolve that.
The option max_groups is not really needed in the uci, hence,
removed. Also, max_membership and max_msf are set internally
by mcpd so no need to echo them seperately.
