[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Bug with Windows tap network when running qemu-system-ppc with Mac OS 9
From: |
Howard Spoelstra |
Subject: |
Bug with Windows tap network when running qemu-system-ppc with Mac OS 9 guest |
Date: |
Thu, 25 Mar 2021 18:19:07 +0100 |
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(+)
- Bug with Windows tap network when running qemu-system-ppc with Mac OS 9 guest,
Howard Spoelstra <=
- Re: Bug with Windows tap network when running qemu-system-ppc with Mac OS 9 guest, Peter Maydell, 2021/03/25
- Re: Bug with Windows tap network when running qemu-system-ppc with Mac OS 9 guest, Bin Meng, 2021/03/25
- Re: Bug with Windows tap network when running qemu-system-ppc with Mac OS 9 guest, Howard Spoelstra, 2021/03/26
- Re: Bug with Windows tap network when running qemu-system-ppc with Mac OS 9 guest, Bin Meng, 2021/03/26
- Re: Bug with Windows tap network when running qemu-system-ppc with Mac OS 9 guest, Howard Spoelstra, 2021/03/26
- Re: Bug with Windows tap network when running qemu-system-ppc with Mac OS 9 guest, BALATON Zoltan, 2021/03/26
- Re: Bug with Windows tap network when running qemu-system-ppc with Mac OS 9 guest, Jason Wang, 2021/03/26
- Re: Bug with Windows tap network when running qemu-system-ppc with Mac OS 9 guest, Bin Meng, 2021/03/26
- Re: Bug with Windows tap network when running qemu-system-ppc with Mac OS 9 guest, Howard Spoelstra, 2021/03/26
- Re: Bug with Windows tap network when running qemu-system-ppc with Mac OS 9 guest, BALATON Zoltan, 2021/03/26