handle_rx() dispatched to igmp_packet_handler() on the destination
address alone, so an ordinary IGMPv3 report off the wire reached the
handler and could write a table entry whether or not anyone had asked
for snooping. The STP branch right above it is gated on stpEnabled;
this brings the IGMP branch in line.
Snooping state lived only in the per-port registers, and the receive
path cannot afford to read one per packet, so the flag shadows it:
igmp_enable() sets it, igmp_setup() clears it, and igmp_setup() runs
from both the boot path and "igmp off".
While here, igmp off becomes an explicit subcommand instead of the
fall-through, and an unrecognised igmp subcommand prints the usage
line rather than silently turning snooping off.
Six bytes of BANK1 and one of xdata, no internal RAM.
igmp_setup() writes the per-port IGMP configuration twice, once with the
value spelled out and once with the same number assembled from the
constants: IGMP_MAX_GROUP | IGMP_PROTOCOL_ENABLE | IGMP_FLOOD is exactly
0x00ff7c15. The second loop carries the comment block explaining the bit
layout, so the literal one is the one to drop.
Today the cost is one redundant register write, because REG_SET is not a
single statement and the unbraced loop body only ever reaches index
machine.max_port + 1. Once the macro is wrapped it becomes one redundant
write per port on every boot and on every "igmp off", which is what makes
this worth removing rather than leaving.
Fifty nine bytes of BANK1 on SWTGW218AS, nothing anywhere else.
SDCC rejects memset() on the generic &entry pointer (error 78,
incompatible types). The ipmc/l2mc table entries are __xdata; pass an
explicit (__xdata uint8_t *) so the call resolves.
This adds an implementation for trapping IGMP packets to the CPU
which will identify IGMPv1/2/3 packets, but handle only v3.
The implementation then inserts/updates/deletes L3 MC entries
in the L3 lookup table. The entries consist of an Ipv4
Destination IP (the IPv4 MC address), a Source IP (0.0.0.0) and
a Portmask. Note that this implementation is not VLAN aware,
as there is no hardware support in the device.
An alternative strategy is to control switching of the L2-MC packets
in which the IPv4-MC packets are transported (dst-MaC is
01:00:5e:xx:yy:zz, with xx:yy:zz corresponding to bits in the Ipv4-MC
address). This will allow to use VLAN-aware packet switching. While
code support is there for table insert/update/deletes, some further
L2 configuration is missing.
There is no support for IPv6 MC, yet.
d00f
bloqaudio
logicog
René van Dorst