Bug with Windows tap network when running qemu-system-ppc with Mac OS 9 guest

[Howard Spoelstra]

Hi,

When running qemu-system-ppc with Mac OS guest, the guest crashes when
using a tap network connection. Openvpn 2.4.9-I601-win10 is installed
with TAP-Windows 9.24.2. A tap connection called TapQemu is bridged
with the default ethernet connection. It gets activated when I start
qemu.

To reproduce, compile qemu-system-ppc from current source and run:

qemu-system-ppc.exe ^
-L pc-bios ^
-M mac99 ^
-m 128 ^
-sdl -serial stdio ^
-boot c ^
-drive file=C:\Mac-disks\9.2.img,format=raw,media=disk ^
-device sungem,netdev=network01 -netdev tap,ifname=TapQemu,id=network01

I bisected to the commit below. Thanks for looking into this.

Best,
Howard

969e50b61a285b0cc8dea6d4d2ade3f758d5ecc7 is the first bad commit
commit 969e50b61a285b0cc8dea6d4d2ade3f758d5ecc7
Author: Bin Meng <bmeng.cn@gmail.com>
Date:   Wed Mar 17 14:26:29 2021 +0800

    net: Pad short frames to minimum size before sending from SLiRP/TAP

    The minimum Ethernet frame length is 60 bytes. For short frames with
    smaller length like ARP packets (only 42 bytes), on a real world NIC
    it can choose either padding its length to the minimum required 60
    bytes, or sending it out directly to the wire. Such behavior can be
    hardcoded or controled by a register bit. Similarly on the receive
    path, NICs can choose either dropping such short frames directly or
    handing them over to software to handle.

    On the other hand, for the network backends like SLiRP/TAP, they
    don't expose a way to control the short frame behavior. As of today
    they just send/receive data from/to the other end connected to them,
    which means any sized packet is acceptable. So they can send and
    receive short frames without any problem. It is observed that ARP
    packets sent from SLiRP/TAP are 42 bytes, and SLiRP/TAP just send
    these ARP packets to the other end which might be a NIC model that
    does not allow short frames to pass through.

    To provide better compatibility, for packets sent from QEMU network
    backends like SLiRP/TAP, we change to pad short frames before sending
    it out to the other end, if the other end does not forbid it via the
    nc->do_not_pad flag. This ensures a backend as an Ethernet sender
    does not violate the spec. But with this change, the behavior of
    dropping short frames from SLiRP/TAP interfaces in the NIC model
    cannot be emulated because it always receives a packet that is spec
    complaint. The capability of sending short frames from NIC models is
    still supported and short frames can still pass through SLiRP/TAP.

    This commit should be able to fix the issue as reported with some
    NIC models before, that ARP requests get dropped, preventing the
    guest from becoming visible on the network. It was workarounded in
    these NIC models on the receive path, that when a short frame is
    received, it is padded up to 60 bytes.

    The following 2 commits seem to be the one to workaround this issue
    in e1000 and vmxenet3 before, and should probably be reverted.

      commit 78aeb23eded2 ("e1000: Pad short frames to minimum size (60 bytes)")
      commit 40a87c6c9b11 ("vmxnet3: Pad short frames to minimum size
(60 bytes)")

    Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
    Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
    Signed-off-by: Jason Wang <jasowang@redhat.com>

 net/slirp.c     | 10 ++++++++++
 net/tap-win32.c | 10 ++++++++++
 net/tap.c       | 10 ++++++++++
 3 files changed, 30 insertions(+)