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

[Peter Maydell]

(adding the relevant people to the cc list)

On Thu, 25 Mar 2021 at 17:26, Howard Spoelstra <hsp.cat7@gmail.com> wrote:
>
> 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(+)
>