Subject: Re: /dev/tap and tcpdump don't go together very well? [conclusion & diff]
To: Rhialto <>
From: Quentin Garnier <>
List: current-users
Date: 04/08/2007 22:39:27
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Apr 08, 2007 at 10:08:47PM +0200, Rhialto wrote:
> Possible conclusions from this thead:
> - It may make sense to allow opening /dev/tap write-only. All packets
>   written from the kernel side should be dropped (and sent to bpf).
>   See attached diff. That plus opening /dev/tap O_WRONLY keeps the
>   OACTIVE off and tcpdump sees some icmp6 packets that apparently get
>   sent.

I'm not sure it actually makes sense to do that.  The philosophy of
tap(4) is to have a virtual Ethernet device.  If it is opened by a
process, then said process is the backend of the interface;  it's up to
it to tell whether it wants frames or not, I don't see why the kernel
would have to outsmart it.  Granted, explicitely opening the device only
for writing can be considered enough of a hint, but it still feels a bit

If you're going to use bpf(4) to read packets coming "out" the
interface, then why not using bpf(4) to write "incoming" frames?

In that case, the API that you're missing is something that does "create
a tap interface and tell me its unit, but don't open it".  Or, simpler,
a way of closing /dev/tap (lack of unit number is important) without
destroying the device.

> - Maybe tap should silently never set the IFF_PROMISC flag since it
>   already is, and setting it has unexpected side effects.
>   See diff, but untested.

The fact that it doesn't affect its operation doesn't mean it will
always be the case;  you could imagine having a filter in the write
handler...  It might actully provide a way to test multicast stuff or
whatnot.  The initial idea is that for all intents and purposes, it is
an Ethernet device.

> - Other (hardware) interfaces should be able to change their MAC address
>   too.

That's a different issue.  I agree that the way it is done in tap(4) is
far from ideal.

Quentin Garnier - -
"You could have made it, spitting out benchmarks
Owe it to yourself not to fail"
Amplifico, Spitting Out Benchmarks, Hometakes Vol. 2, 2005.

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

Version: GnuPG v1.4.6 (NetBSD)