netdev - Re: mac addresses of local interfaces do not obey setageing 0

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-prev] [day] [month] [year] [list]

Date:	Thu, 17 Feb 2011 10:56:07 +0100
From:	David Lamparter <equinox@...c24.net>
To:	Veaceslav Falico <vfalico@...hat.com>
Cc:	Stephen Hemminger <shemminger@...tta.com>, netdev@...r.kernel.org,
	bridge@...ts.linux-foundation.org
Subject: Re: mac addresses of local interfaces do not obey setageing 0

On Tue, Feb 15, 2011 at 10:25:38AM -0800, Stephen Hemminger wrote:
> On Wed, 9 Feb 2011 19:17:52 +0100
> Veaceslav Falico <vfalico@...hat.com> wrote:
> 
> > Hello,
> > 
> > I have a host and a VM inside this host bridged. I've set ageing_time and
> > forward_delay to 0 and trying to capture all the traffic that goes through that
> > bridge from my VM, but it fails to capture the traffic that has dst ether
> > address the same as the hosts address (i.e. I can't capture the traffic to the
> > host).
> > 
> > From the code, I see that br->ageing_time doesn't really work with local mac
> > addresses - has_expired() function never says that a local interface mac address
> > is expired, because it verifies if fdb->is_static is set and returns right away.
> > 
> > Is this the desired behaviour? If so, is there a way to capture packets with
> > destination to a local interface from another interface?
> > 
> > I've also done a small patch and it seems to fix the situation, but I am not
> > sure if it's the right way to do it.
> 
> No.
> Local addresses should never age.
> 
> The proper way to capture packet is to us AF_PACKET or tc actions.

If you really want to use a bridge for this kind of traffic capturing,
you can attach one side of a veth pair as third interface to the bridge,
clear off all the mac addresses (and have no higher-layer addresses on
the bridge either) and use the other side of the veth pair for your
host. Since the "far" side of the veth is not on the bridge, the bridge
will not treat its address any special.

(This is somewhat of a funny hack though. Use AF_PACKET really...)


-David


Content of type "application/pgp-signature" skipped