From: Alex Elder <elder@linaro.org>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Network Development <netdev@vger.kernel.org>,
"bjorn.andersson@linaro.org" <bjorn.andersson@linaro.org>,
Florian Fainelli <f.fainelli@gmail.com>,
Jakub Kicinski <kuba@kernel.org>
Subject: Re: Port mirroring, v2 (RFC)
Date: Tue, 18 Jan 2022 11:37:05 -0600 [thread overview]
Message-ID: <c9db7b36-3855-1ac1-41b6-f7e9b91e2074@linaro.org> (raw)
In-Reply-To: <YeLk3STfx2DO4+FO@lunn.ch>
On 1/15/22 9:14 AM, Andrew Lunn wrote:
>> 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
>
next prev parent reply other threads:[~2022-01-18 17:37 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-14 14:47 Port mirroring (RFC) Alex Elder
2021-12-14 18:27 ` Andrew Lunn
2021-12-14 22:55 ` Alex Elder
2021-12-15 9:18 ` Andrew Lunn
2021-12-15 14:47 ` Alex Elder
2021-12-15 17:42 ` Andrew Lunn
2021-12-20 19:27 ` Alex Elder
2021-12-15 20:12 ` Florian Fainelli
2021-12-20 19:51 ` Alex Elder
2021-12-15 17:48 ` Florian Fainelli
2021-12-20 19:41 ` Alex Elder
2021-12-15 23:33 ` Jakub Kicinski
2021-12-20 20:17 ` Alex Elder
2022-01-14 16:50 ` Port mirroring, v2 (RFC) Alex Elder
2022-01-14 17:03 ` Alex Elder
2022-01-14 20:46 ` Andrew Lunn
2022-01-14 21:12 ` Alex Elder
2022-01-18 18:07 ` Jakub Kicinski
2022-01-18 18:14 ` Alex Elder
2022-01-15 15:14 ` Andrew Lunn
2022-01-18 17:37 ` Alex Elder [this message]
2022-01-18 18:30 ` Jakub Kicinski
2022-01-18 18:33 ` Alex Elder
2022-01-26 23:37 ` IPA monitor (Final RFC) Alex Elder
2022-01-26 23:43 ` Alex Elder
2022-02-02 0:19 ` Andrew Lunn
2022-02-02 0:41 ` Alex Elder
2022-02-02 19:05 ` Andrew Lunn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c9db7b36-3855-1ac1-41b6-f7e9b91e2074@linaro.org \
--to=elder@linaro.org \
--cc=andrew@lunn.ch \
--cc=bjorn.andersson@linaro.org \
--cc=f.fainelli@gmail.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).