Johnny Billquist <bqt@softjar.se> writes:

> Greg Troxel wrote:
>> Johnny Billquist <bqt@softjar.se> 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
>>>interfaces...)
>>
>> 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
machine's interface.

> 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
        address: aa:00:00:fa:00:04
        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
        address: aa:00:00:f9:00:04
        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.