[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Yboo9PtNslU+Y4te@lunn.ch>
Date: Wed, 15 Dec 2021 18:42:12 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Alex Elder <elder@...aro.org>
Cc: Network Development <netdev@...r.kernel.org>,
"bjorn.andersson@...aro.org" <bjorn.andersson@...aro.org>
Subject: Re: Port mirroring (RFC)
> > 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.
> 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
Powered by blists - more mailing lists