lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Mon, 10 Feb 2020 16:34:00 +0200
From:   Ido Schimmel <idosch@...sch.org>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     netdev <netdev@...r.kernel.org>
Subject: Re: VLAN retagging for packets switched between 2 certain ports

On Thu, Feb 06, 2020 at 11:32:52AM +0200, Vladimir Oltean wrote:
> On Thu, 6 Feb 2020 at 11:02, Vladimir Oltean <olteanv@...il.com> wrote:
> >
> > Hi netdev,
> >
> > I am interested in modeling the following classifier/action with tc filters:
> > - Match packets with VID N received on port A and going towards port B
> > - Replace VID with M
> >
> > Some hardware (DSA switch) I am working on supports this, so it would
> > be good if I could model this with tc in a way that can be offloaded.
> > In man tc-flower I found the following matches:
> >        indev ifname
> >               Match on incoming interface name. Obviously this makes
> > sense only for forwarded flows.  ifname is the name of an interface
> > which must exist at the time of tc invocation.
> >        vlan_id VID
> >               Match on vlan tag id.  VID is an unsigned 12bit value in
> > decimal format.
> >
> > And there is a generic "vlan" action (man tc-vlan) that supports the
> > "modify" command.
> >
> > Judging from this syntax, I would need to add a tc-flower rule on the
> > egress qdisc of swpB, with indev swpA and vlan_id N.
> > But what should I do if I need to do VLAN retagging towards the CPU
> > (where DSA does not give me a hook for attaching tc filters)?
> >
> > Thanks,
> > -Vladimir
> 
> While I don't want to influence the advice that I get, I tried to see
> this from the perspective of "what would a non-DSA device do?".
> So what I think would work for me is:
> - For VLAN retagging of autonomously forwarded flows (between 2
> front-panel ports) I can do the egress filter with indev that I
> mentioned above.
> - For VLAN retagging towards the CPU, I can just attach the filter to
> the ingress qdisc and not specify an indev at all. The idea being that
> this filter will match on locally terminated packets and not on all
> packets received on this port.
> Would this be confusing?

Why don't you just use "skip_hw" flag? The filter will not be installed
in hardware and will only match locally received packets. Isn't this
what you want?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ