On Sun 08 Apr 2007 at 09:39:01 -0400, Greg Troxel wrote:
> So you have an emulator program, and it opens a /dev/tap, and
> reads/writes packets and makes those appear to show up/come from the
> emulated network interface on the PDP-10?

Partly. What it was originally doing was to use /dev/bpf to do that.
That works fine if the emulator wants to communicate with other hosts
that are actually on the wire. BPF sees packets that come in from the
wire and optionally (default on; BIOCSSEESENT; apparently undocumented)
the packets that the host sends to the wire. Packets injected into BPF
are sent to the wire only, not to the host.

My intention was to add /dev/tap to this scenario in order to add the
missing part: packets from the emulator to the host.

> Then on the host are you bridging /dev/tap0 to a regular ethernet?

That is another scenario I have been considering, but I rejected it so
far because it is more than a "small change". It would be the better
thing to do in the long run though (assuming that all systems that have
tap also have bridge, otherwise it is not much help)

> I think you are saying that if you then run 'tcpdump -i tap0' on the
> host, then packets from host to emulator and emulator to host are
> printed by tcpdump.  But, without -p, then the packets from the host
> towards the emulator are apparently not received.

Yes. In the emulator -> host direction, that is. There are currently
none in the other.

> I suggest adding a printf to the emulator when reading packets from the
> tap device.

It has full debugging options for both directions, indeed. I could see
packets going out of the emulator, I could see then in /dev/tap
(tcpdump), and yet the telnet connection was "frozen".

> 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).

> Setting promiscuous mode will call net/if.c:ifpromisc which will call
> net/if_ethersubr.c:ether_ioctl which will call tap_init.
> 
> tap_init calls tap_start, and that seems to introduce an extra wakeup
> and OACTIVE flag, and that seems wrong.  Try removing the tap_start call
> from tap_init and rebuilding the host kernel.

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.

tap0: flags=8c43<UP,BROADCAST,RUNNING,OACTIVE,SIMPLEX,MULTICAST> mtu 1500
	address: f2:0b:a4:7d:17:04
	media: Ethernet autoselect
	inet 10.0.0.12 netmask 0xffffff00 broadcast 10.0.0.255
	inet6 fe80::f00b:a4ff:fe7d:1704%tap0 prefixlen 64 scopeid 0x4

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