On Sat, Apr 03, 2021 at 07:14:56PM +0200, Oleksij Rempel wrote:
> Am 03.04.21 um 16:49 schrieb Andrew Lunn:
> >> @@ -31,6 +96,13 @@ static struct sk_buff *ar9331_tag_xmit(struct sk_buff *skb,
> >> __le16 *phdr;
> >> u16 hdr;
> >>
> >> + if (dp->stp_state == BR_STATE_BLOCKING) {
> >> + /* TODO: should we reflect it in the stats? */
> >> + netdev_warn_once(dev, "%s:%i dropping blocking packet\n",
> >> + __func__, __LINE__);
> >> + return NULL;
> >> + }
> >> +
> >> phdr = skb_push(skb, AR9331_HDR_LEN);
> >>
> >> hdr = FIELD_PREP(AR9331_HDR_VERSION_MASK, AR9331_HDR_VERSION);
> >
> > Hi Oleksij
> >
> > This change does not seem to fit with what this patch is doing.
>
> done
>
> > I also think it is wrong. You still need BPDU to pass through a
> > blocked port, otherwise spanning tree protocol will be unstable.
>
> We need a better filter, otherwise, in case of software based STP, we are leaking packages on
> blocked port. For example DHCP do trigger lots of spam in the kernel log.
I have no idea whatsoever what 'software based STP' is, if you have
hardware-accelerated forwarding.
> I'll drop STP patch for now, it will be better to make a generic soft STP for all switches without
> HW offloading. For example ksz9477 is doing SW based STP in similar way.
How about we discuss first about what your switch is not doing properly?
Have you debugged more than just watching the bridge change port states?
As Andrew said, a port needs to accept and send link-local frames
regardless of the STP state. In the BLOCKING state it must send no other
frames and have address learning disabled. Is this what's happening, is
the switch forwarding frames towards a BLOCKING port?
