Subject: Re: /dev/tap and tcpdump don't go together very well? [conclusion & diff]
To: Rhialto <rhialto@falu.nl>
From: Quentin Garnier <cube@cubidou.net>
List: current-users
Date: 04/08/2007 22:39:27
--pOIQYeSHfrmgxbKS
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:
>=20
> Possible conclusions from this thead:
>=20
> - 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
hackish.

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.

--=20
Quentin Garnier - cube@cubidou.net - cube@NetBSD.org
"You could have made it, spitting out benchmarks
Owe it to yourself not to fail"
Amplifico, Spitting Out Benchmarks, Hometakes Vol. 2, 2005.

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

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

iQEVAwUBRhlS/9goQloHrPnoAQLkLgf6A7V9ClKzW9l1AGkZUEvPbaZ9fDXG/DTE
zH93sbfWxfZQOgXnRzB3aG+msVHK0rYGomK1KglDVYXBIADQ3n1t02m3a8J3XkLt
Vcb0kxGlZABoRN7X0+2IA8emfJoREja5CZwPQ1n6yfMS8l32xGqVeP867ISJhHSe
epKdiBf4IBB6u2QRC/D0CL3GBHxzVYIcFpBpB61xsSYe+0VZFSj9GlOpRe3hpikf
C1DSAeB4vmG3db1YnoRl8ZT6bFUPhkQ5zFmb9Zy2am6PA4nqiXKtoiuWu6LDxAWW
CJRCwgjMU6iVFeo1pgF56cjLoolUrBRmP0fYofjr1lwFeoSL7oOe6g==
=AB7I
-----END PGP SIGNATURE-----

--pOIQYeSHfrmgxbKS--