netdev - tc - mirred ingress not supported at the moment

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 14 Aug 2019 11:25:25 +0200
From:   Martin Olsson <martin.olsson+netdev@...torsecurity.com>
To:     Cong Wang <xiyou.wangcong@...il.com>
Cc:     netdev <netdev@...r.kernel.org>
Subject: tc - mirred ingress not supported at the moment

Hi Cong!

Ah sorry.
Already implemented. Great!

Hmmm. Then why don't the manual at
https://www.linux.org/docs/man8/tc-mirred.html to reflect the changes?
That was the place I checked to see if ingress was still not implemented.
In the commit you point at, the sentence "Currently only egress is
implemented" has been removed.

Question:
Is there any form of performance penalty if I send the mirrored
traffic to the ingress queue of the destination interface rather than
to the egress queue?
I mean, in the kernel there is the possibility to perform far more
actions on the ingress queue than on the egress, but if I leave both
queues at their defaults, will mirrored packets to ingress use more
CPU cycles than to the egress destination, or are they more or less
identical?

Question 2:
Given the commit
https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/?id=5eca0a3701223619a513c7209f7d9335ca1b4cfa,
how can I see in what kernel version it was added?

/Martin

Den tis 13 aug. 2019 kl 18:47 skrev Cong Wang <xiyou.wangcong@...il.com>:
>
> On Tue, Aug 13, 2019 at 4:05 AM Martin Olsson
> <martin.olsson+netdev@...torsecurity.com> wrote:
> > Q1: Why was 'ingress' not implemented at the same time as 'egress'?
>
> Because you are using an old iproute2.
>
> ingress support is added by:
> https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/?id=5eca0a3701223619a513c7209f7d9335ca1b4cfa
>
>
> > 2)
> > Ok, so I have to use 'egress':
> > # tc filter add dev eno2 parent ffff: prio 999  protocol all matchall
> > action mirred egress redirect dev mon0
>
>
> So you redirect packets from eno2's ingress to mon0's egress.
>
>
> >
> > Since the mirred action forces me to use 'egress' as the direction on
> > the dest interface, all kinds of network statistics tools show
> > incorrect counters. :-(
> > eno2 is a pure sniffer interface (it is connected to the SPAN dest
> > port of a switch).
> > All packets (matchall) on eno2 are mirrored to mon0.
> >
> > # ip -s link show dev eno2
> >     ...
> >     ...
> >     RX: bytes  packets  errors  dropped overrun mcast
> >     13660757   16329    0       0       0       0
> >     TX: bytes  packets  errors  dropped carrier collsns
> >     0          0        0       0       0       0
> > # ip -s link show dev mon0
> >     ...
> >     ...
> >     RX: bytes  packets  errors  dropped overrun mcast
> >     0          0        0       0       0       0
> >     TX: bytes  packets  errors  dropped carrier collsns
> >     13660757   16329    0       0       0       0
> >
> > eno2 and mon0 should be identical, but they are inverted.
>
> Yes, this behavior is correct. The keyword "egress" in your cmdline
> already says so.
>
> >
> > Q2: So... Can the 'ingress' option please be implemented? (I'm no
> > programmer, so unfortunetly I can't do it myself).
>
> It is completed, you need to update your iproute2 and kernel.
>
> Thanks.