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>
Subject: Re: Port mirroring (RFC)
Date: Mon, 20 Dec 2021 13:27:58 -0600 [thread overview]
Message-ID: <c71f1f98-13cc-ff82-7bf5-2c733de9ab2b@linaro.org> (raw)
In-Reply-To: <Yboo9PtNslU+Y4te@lunn.ch>
On 12/15/21 11:42 AM, Andrew Lunn wrote:
>>> Do you have netdevs for the modem, the wifi, and whatever other
>>> interfaces the hardware might have?
>>
>> Not yet, but yes I expect that's how it will work.
>>
>>> To setup a mirror you would do something like:
>>>
>>> sudo tc filter add dev eth0 parent ffff: protocol all u32 match u32 0 0 action mirred egress mirror dev tun0
>>
>> OK so it sounds like the term "mirror" means mirroring using
>> Linux filtering. And then I suppose "monitoring" is collecting
>> all "observed" traffic through an interface?
>
> Yes, that seems like a good description of the difference.
>
>> If that's the case, this seems to me more like monitoring, except
>> I suggested presenting the replicated data through a separate
>> netdev (rather than, for example, through the one for the modem).
>
> The wifi model allows you to dynamical add netdev on top of a physical
> wireless LAN chipset. So you can have one netdev running as an access
> point, and a second netdev running as a client, both sharing the
> underlying hardware. And you should be able to add another netdev and
> put it into monitor mode. So having a dedicated netdev for your
> monitoring is not too far away from what you do with wifi.
It sound to me like WiFi monitoring mode could very much be
a model that would work. I need to spend some time looking
at that in a little more detail. I don't think there's any
reason the "dedicated" netdev couldn't be created dynamically.
I'll come back again after I've had a chance to look at these
suggestions (yours and others'), possibly with something closer
to a design to follow.
Thank you very much, this is a promising lead.
-Alex
>> If it makes more sense, I could probably inject the replicated
>> packets received through this special interface into one or
>> another of the existing netdevs, rather than using a separate
>> one for this purpose.
>
>>> Do you have control over selecting egress and ingress packets to be
>>> mirrored?
>>
>> That I'm not sure about. If it's possible, it would be controlling
>> which originators have their traffic replicated.
>
> You need this if you want to do mirroring, since the API requires to
> say if you want to mirror ingress or egress. WiFi monitoring is less
> specific as far as i understand. It is whatever is received on the
> antenna.
>
>> I don't think it will take me all that long to implement this, but
>> my goal right now is to be sure that the design I implement is a good
>> solution. I'm open to recommendations.
>
> You probably want to look at what wifi monitor offers. And maybe check
> with the WiFi people what they actually think about monitoring, or if
> they have a better suggestion.
>
> Andrew
>
next prev parent reply other threads:[~2021-12-20 19:28 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 [this message]
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
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=c71f1f98-13cc-ff82-7bf5-2c733de9ab2b@linaro.org \
--to=elder@linaro.org \
--cc=andrew@lunn.ch \
--cc=bjorn.andersson@linaro.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).