Re: Port mirroring, v2 (RFC)

On 1/15/22 9:14 AM, Andrew Lunn wrote:

quoted

Below I will describe two possible implementations I'm considering.
I would like to know which approach makes the most sense (or if
neither does, what alternative would be better).

Hi Alex

Another corner of the kernel you could look for inspiration is usbmon.

https://www.kernel.org/doc/html/latest/usb/usbmon.html

Yes this looks very similar.  However IPA only carries
network traffic, unlike USB.  The "peripherals" (packet
sources) are all generating IP packets.

This is similar to your misc char device, but it is actually
implemented as a pseudo filesystem. It is intended for libpcap based
applications and i've used it with tcpdump and wireshark. So exactly
your use cases.

I suppose I could represent each possible source of packets
with a file system entry.  But that would require the IPA
driver to parse the received data and buffer each packet
separately (with others from its source).  Kind of messy.

I feel like it would be much better to just have one interface,
and have the filtering software exclude things that aren't
interesting.

Because it is not a network device, the extra header does not cause
problems, and there is no confusion about what the 'monitoring' netdevs
are good for.

Yes, agreed.

Since you are talking 5G and WiFi, you have a lot of packets
here. Being able to use BPF with libpcap is probably useful to allow
filtering of what packets are passed to user space. I've never looked
at how the BPF core is attached to a netdev. But i suspect your extra

I haven't either.  But this too is something I've generally
thought I'd have to investigate.

header could be an issue. So you are going to need some custom code to
give it an offset into the packet to the Ethernet header?

Yes I think so.  No Ethernet header though.

Humm, actually, you called the IPA the IP accelerator. Are these L2
frames or L3 packets? Do you see 3 or even 4 MAC addresses in an
802.11 header? Two MAC addresses in an 802.3 header? etc.

L3 packets.  Except they are truncated if they're long, and they
have a metadata header prepended.

No MAC addresses, no 802.11 header.  Generally speaking, these
packets will start with 4 or 6 as the upper nibble of the first
byte (IP packet).  And of course, this follows the fixed-length
32-byte "status" header.

Here's are IPv4 and IPv6 ICMP examples.

00: 45 00 00 54 ac 5a 40 00 40 01 be 3c c0 00 00 02

10: 08 08 08 08 08 00 10 cf 11 c0 00 03 4f f4 e6 61

20: ac 14 08 00 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13

30: 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23

40: 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33

50: 34 35 36 37


00: 66 00 00 00 00 40 3a 70 26 07 77 00 00 00 00 2d

10: 00 00 00 01 08 08 08 08 26 07 fb 90 99 41 19 56

20: 00 c0 00 00 02 00 00 00 81 00 13 1f 11 c0 00 03

30: 4f f4 e6 61 ac 14 08 00 08 09 0a 0b 0c 0d 0e 0f

40: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f

50: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f

60: 30 31 32 33 34 35 36 37



I'm basically ready to go on this, either way (using a
misc device, or--preferably--using a netdev).

I'm just trying to avoid getting that fully working,
then learning when I submit patches that someone thinks
it's the wrong way to go about it.

If a netdev is acceptable, my remaining issues are:
- Whether/how to avoid having the device be treated
  as if it needed support from the network stack
  (i.e., as a "real" network interface, serving to
  send and receive packets).
- Similar, whether there are special configuration
  options that should be used, given the device's
  purpose.
- What to call this functionality.  I'll avoid "mirror"
  and will try to come up with something reasonable,
  but suggestions are welcome.

Thanks.

					-Alex

        Andrew