Wed, Jun 22, 2016 at 02:21:29PM CEST, [email protected] wrote: >On Wed, 2016-06-22 at 12:55 +0200, Jiri Pirko wrote: >> Wed, Jun 22, 2016 at 12:25:15PM CEST, [email protected] wrote: >> >Before the commit 0dfe17823945 ("net: vlan: goto another_round >> >instead of calling __netif_receive_skb"), on tagged skb ingress, >> >ptype specific protocol matches were delivered only to the >> >related vlan device, if any. >> >After said commit, jumping back to the 'another_round' label, allows >> >the later ptype specific check to match both orig_dev and skb->dev, >> >delivering the skb to both the vlan device and the underlying >> >device. >> >This cause i.e. packet sockets bound to a specific protocol type on >> >one of said devices to receive also frames really targeting the >> >other device. >> >This commit resets orig_dev before performing another round due to >> >vlan processing, allowing the skb to be delivered once again only >> >to the vlan specific ptypes. >> >> I don't get why vlan should behave differently in this comparing to >> other stacked devices like bond/team/br etc. >> >> Could you please explain? > >vlan behavior has changed with the commit 0dfe17823945 (which is old, >but still...), this patch is trying to restore the old one. > >The new behavior fouls existing applications which where expecting ptype >specific match to be delivered only on the relevant device.
The patch only unified the behaviour so everyone know what to expect regardless of the device type. > >AFAIC jumping back to the 'another_round' is possible for team, bond, >macvlan, macsec and ipvlan device, beyond vlan devices. I think the >latter should be treated differently, beyond history reasons, because >the vlan device processing, stripping the vlan tag, actually changes the >ethernet type present into the ethernet header in respect to the wire >packet layout; strict match on that value should give different results >before and after vlan stripping. The vlan header stripping happens before all of this, either in HW or skb_vlan_untag, so you can never match on that.
