Basilisk II with "tun" interface uses Ethernet/MAC address 00:00:00:00:00:00, affecting bridging

[dcoshea]

With 1c9b21f plus a fix for issue #153 running on CentOS 7, when .basilisk_ii_prefs is configured with ether tun, packets are sent with Ethernet/MAC address 00:00:00:00:00:00. This can be seen when running Wireshark on the tun0 interface, or when changing DEBUG to 1 in BasiliskII/src/Unix/ether_unix.cpp, in which case output like the following is produced:

Connected to host network interface: tun0
Ethernet address 00 00 00 00 00 00

In my case, I have used the etherconfig setting to override the default tun interface configuration script so I can configure it manually.

If I configure the tun0 interface with an IP address, I can ping the host from the guest and vice versa without any problems. The arp command on the Linux host shows that the guest's IP address has been associated with 00:00:00:00:00:00.

However, if I bridge the tun interface using brctl addif _bridge-interface_ tun0 and configure an IP on bridge-interface:

• I can no longer ping the host from the guest or vice versa: Linux no longer seems to add 00:00:00:00:00:00 to its ARP table.

• When I attach a VM running Windows NT Server 4 to the same bridge, I can't ping between that VM and the Basilisk II guest either. When I ran Wireshark, I could see that Windows NT wasn't responding to the ARP requests.

I note that ether_init() in BasiliskII/src/Unix/ether_unix.cpp is responsible for selecting the Ethernet/MAC address, and that for the net_if_type == NET_IF_TUNTAP case it falls back to this case:

} else
	ioctl(fd, SIOCGIFADDR, ether_addr);

where ether_addr is just a 6-byte buffer. This doesn't seem to match the usual usage of SIOCGIFADDR from my brief investigation of it, but perhaps this works with the sheep_net device.

When I modified the code to treat NET_IF_TUNTAP the same as NET_IF_ETHERTAP (i.e. to construct a MAC address of the form FE:FD:xx:xx:xx:xx where xx:xx:xx:xx is the process ID), it resolved the issues I experienced when bridging - I could ping between the host and guest, and between the guest and my Windows NT Server 4 VM.

I couldn't easily find any reference indicating that the address 00:00:00:00:00:00 is reserved, but it's certainly used by some software to indicate an absence of a MAC address, and if you were to run multiple instances of Basilisk II bridged onto the same network it wouldn't be very useful if they both had the same MAC address, so using a more meaningful MAC address seems like a good idea.

[dcoshea]

When Basilisk II and a Windows NT Server 4 VM were both attached to the same bridge, this issue also affected AppleTalk communication between the two - a non-zero Ethernet/MAC address was required before this could be established.