Subject: Re: /dev/tap and tcpdump don't go together very well?
To: Johnny Billquist <email@example.com>
From: Greg Troxel <firstname.lastname@example.org>
Date: 04/10/2007 10:33:55
Johnny Billquist <email@example.com> writes:
> Greg Troxel wrote:
>> Johnny Billquist <firstname.lastname@example.org> writes:
>>>When doing stuff like Olaf is doing here, changing the MAC address
>>>might be desireable (in his case if he wants his PDP-10 to run TOPS-20
>>>with DECnet enabled, since DECnet wants specific MAC addresses on
>> I don't think the tap's Ethernet address is relevant. The PDP-10's
>> emulated Ethernet interface (how modern to plug one of those in, instead
>> of CHAOSnet or an IMP....) will have an address, but that's controlled
>> entirely within the emulator. Packets with that source address are
>> generated, and then written to /dev/tapN to make them show up on the
>> virtual interface on the host.
> Are you suggesting that we'll always be in promiscous mode then?
See at end.
> I'm not just thinking of source address information, but also
> reception of packets from the outside destined to the virtual machine.
This is why you want to use a bridge to connect the physical Ethernet to
the virtual Ethernet that has the tap0 (on the host) and the emulated
> A PDP-10 can be running both DECnet and TCP/IP, in which case you'll
> want it's ethernet address to show up in other machines arp tables as
> well, and so on.
Sure, and bridging will do this. Ethernet packets are created within
the emulator, and written into /dev/tap. They then appear on tapN (the
struct ifnet side), as if they had been received from a hardware
interface. So the source and destination addresses have already been
set by the emulator. Those packets then get bridged.
> And maybe you'd like to dedicate a specific ethernet
> interface to the virtual machine, so that it's actually directly
> hooked into the physical network. So you'd really need the ability to
> change the mac address of specific interfaces.
Yes, but not of any interface on the *host*.
This is exactly what I (and many others) are doing on Xen, except that
instead of tap there are a pair of interfaces xvifN.M on the host (dom0)
and xennetM on the emulated machine (domU). Essentially the equivalent of
tap is inside this, so that when the domU sends a packet it appears to
be received on the xvif interface on the dom0.
On my dom0:
xvif6.0: flags=8963<UP,BROADCAST,NOTRAILERS,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
inet6 fe80::a800:ff:fefa:4%xvif6.0 prefixlen 64 scopeid 0x12
On my domU:
xennet0: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet [redacted] netmask 0xffffff00 broadcast [redacted]
inet6 fe80::a800:ff:fef9:4%xennet0 prefixlen 64 scopeid 0x2
inet6 [redacted] prefixlen 64
The MAC address for xennet0 is set in a xen config file, and the address
on xvif6.0 is apparently made up from that.
I have a bridge configured on the dom0, with a real interface and all
the xvifN.0 for the domUs.
On a real machine on the same ethernet, the xennet0 MAC address shows up
in ARP tables.
I think this is exactly how a PDP-10 emulator should work, except that
xennet0 is whatetever Ethernet interface that plugs in to the PDP-10 and
as seen by TOPS-20, xvif is tap, and instead of a xen hypervisor the
emulator passes packets.
So, with a bridge, yes all interfaces will be in promiscuous mode. But
this shouldn't really matter.