Subject: Re: Manipulating link address on Ethernet interfaces
To: None <tech-net@netbsd.org>
From: Quentin Garnier <cube@cubidou.net>
List: tech-net
Date: 03/24/2006 12:04:53
--as/zY73XizXOsAht
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 24, 2006 at 10:42:50AM +0100, Quentin Garnier wrote:
[...]
> [...]  Yes, using tap(4) and bridge(4)
> for that purpose is possible;

Actually, that part is not entirely true, because of the way bridge(4)
works.

The reason why this comes up now is because someone wanted to use
dhclient with a fake MAC address.  It was suggested to combine tap(4)
and bridge(4) to achieve this, but it doesn't work.

dhclient(8) uses bpf(4) to listen on the interfaces it works on, and
expects to receive the DHCPOFFER through it.  However, in the said
setup, the tap interface never actually sees the packet.

The main ethernet interface receives a packet.  Then it goes to
ether_input, which in turn calls bridge_input.  The latter observes
that the destination address is the one of one of its members, and
therefore the packet must be handled locally.  As the packet never
actually enters tap0, it never goes through bpf(4).

One way to solve this is to have bridge(4) call bpf_mtap() on behalf
on its member interface, which wouldn't be too hard to do, but I'm not
sure if that's really something we want.  I think bpf(4) is meant to
show whatever was or is about to be on the wire, not something the
kernel made up.

It is a valid setup;  it should be possible to use dhclient that way.
Any idea what to do?  Should a PR be filled?

--=20
Quentin Garnier - cube@cubidou.net - cube@NetBSD.org
"When I find the controls, I'll go where I like, I'll know where I want
to be, but maybe for now I'll stay right here on a silent sea."
KT Tunstall, Silent Sea, Eye to the Telescope, 2004.

--as/zY73XizXOsAht
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)

iQEVAwUBRCPSVNgoQloHrPnoAQKU2Qf/TxkU7yilGtp6qpTlk0h8vLHprp7LsGTD
l+Fo4YOcpNk+j7OVQ8YG5sTxOs4tzabpcL0E65p3izHbAmLAYeA3HJRIPArsXEYc
0v++1jkI6Kt0/4KBAzBs8Kcy9Z4+XYPfGdOZilXYebzbO20b2eBzN+Ujug4J+OmY
cL7EDkRxhLdT33ycu/t+RKIwyLOVeOzFbiht1+4PRphkiuY1IM5ocHcb+G8/RTmD
rVGmdUdTYOzVnmCorl2IrV1AK6dDVTY5vWpU5NdOsFqEMSPiWXZ2rdWiaIQFTJij
vNC52bdaF+NuQog3BTn4U3kjwmO4DXVP+CdigHR6MRqP413Mk6y8oA==
=V5bO
-----END PGP SIGNATURE-----

--as/zY73XizXOsAht--