When checking for a new root, a root_bridge with the same priority as STP_I will never be adopted as cmpMAC always returns 0.
This PR fixes this bug by changing the comparison of MACs to what was intended
We use the SoC's UUID to generate a fixed MAC for a particular
switch device. The MAC generated uses a Realtek prefix and then
is followed by 3 bytes genertaed from the first 3 bytes of the
UUID xored with the last byte in order to prevent being able
to deduce the UUID from the public MAC.
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.
This reads RSTP configuration packages and updates the
state information about the believed Root-bridge. New
RSTP packages are sent with the updated information.