Subject: Re: /dev/tap and tcpdump don't go together very well?
To: Greg Troxel <>
From: Rhialto <>
List: current-users
Date: 04/08/2007 16:53:09
On Sun 08 Apr 2007 at 16:21:48 +0200, Rhialto wrote:
> On Sun 08 Apr 2007 at 09:39:01 -0400, Greg Troxel wrote:
> > In src/sys/dev/if_tap.c, see tap_dev_read.  The call to bpf_tap looks
> > normal relative to other drivers.
> Doesn't this placement of bpf_tap() in tap_dev_read() mean that only
> packets that are actually read by the program are sent to bpf, rather
> than the ones that are sent by the kernel? (I think this is a
> side-issue, if one at all).
> It seems to make no difference. I see however that OACTIVE is set all
> the time (at least when I look), also when it is working.
> 	address: f2:0b:a4:7d:17:04
> 	media: Ethernet autoselect
> 	inet netmask 0xffffff00 broadcast
> 	inet6 fe80::f00b:a4ff:fe7d:1704%tap0 prefixlen 64 scopeid 0x4

Ah, of course! OACTIVE is on precisely because the emulator never reads
from /dev/tap! This could be a very nasty memory leak, if these packets
get to hang on the queue indefinitely.

I was thinking that (as I expected) there were no packets from the
kernel via tap to the emulator, because none showed up in tcpdump. But
that is only because the emulator doesn't try to read them... This
should be improved somehow, I think.

I can't see in if_tap.c where packets get put on the queue. If the
network code does that itself, should that not also be where bpf_tap()
should be called? (It looks like that is in ifq_enqueue() in

___ Olaf 'Rhialto' Seibert      -- You author it, and I'll reader it.
\X/ rhialto/at/        -- Cetero censeo "authored" delendum esse.