Manipulating link address on Ethernet interfaces

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?

-- 
Quentin Garnier - cubecubidou.net - cubeNetBSD.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.