Re: [PATCH 00/10] Fixes for DP8393X SONIC device emulation

[Finn Thain <fthain@telegraphics.com.au>]

On Sun, 15 Dec 2019, Finn Thain wrote:

> I test the qemu build like this,
> 
> qemu-system-m68k -M q800 -m 512M -serial none -serial mon:stdio -g 800x600x4
> -net nic,model=dp83932,addr=00:00:00:01:02:03
> -net bridge,helper=/opt/qemu/libexec/qemu-bridge-helper,br=br0
> -append "fbcon=font:ProFont6x11 console=tty0 console=ttyS0 ignore_loglevel"
> -kernel vmlinux-4.14.157-mac-backport+
> -initrd /mnt/loop/install/cdrom/initrd.gz
> 
> You can obtain this kernel binary from the linux-mac68k project on 
> sourceforge. (I usually use a mainline Linux build but it makes no 
> difference.)
> 

One difficulty with testing these patches with Linux guests is some old 
bugs in drivers/net/ethernet/natsemi/sonic.c that can cause tx watchdog 
timeouts on real hardware.

I have some patches for that driver which may be useful when testing 
QEMU's hw/net/dp8393x.c device. (I've pushed those patches to my github 
repo.)

The second obstacle I have involves testing the dp8393x device with a 
bridge device on a Linux/i686 host.

Running tcpdump in the Linux/m68k guest showed these two ping packets from 
the host,

00:15:28.480164 IP 192.168.66.1 > 192.168.66.111: ICMP echo request, id 23957, seq 11, length 64
        0x0000:  0800 0702 0304 fe16 d9ae 6943 0800 4500  ..........iC..E.
        0x0010:  0054 ff4d 4000 4001 359a c0a8 4201 c0a8  .T.M@.@.5...B...
        0x0020:  426f 0800 4243 5d95 000b a0cc f65d cfee  Bo..BC]......]..
        0x0030:  0600 0809 0a0b 0c0d 0e0f 1011 1213 1415  ................
        0x0040:  1617 1819 1a1b 1c1d 1e1f 2021 2223 2425  ...........!"#$%
        0x0050:  2627 2829 2a2b 2c2d 2e2f 3031 3233 3435  &'()*+,-./012345
        0x0060:  3637 33e0 14c7                           673...
00:15:29.341601 IP truncated-ip - 52 bytes missing! 192.168.66.1 > 192.168.66.111: ICMP echo request, id 23957, seq 12, length 64
        0x0000:  0800 0702 0304 fe16 d9ae 6943 0800 4500  ..........iC..E.
        0x0010:  0054 ff4e 4000 4001 3599 c0a8 4201 c0a8  .T.N@.@.5...B...
        0x0020:  426f 0800 d61a 5d95 000c a0cc f65d        Bo....]......]

Sniffing br0 on the host shows no sign of the truncated packet at all 
which leaves a gap in the packet sequence numbers captured on the host. 
Weird.

When I log the calls to,

static ssize_t dp8393x_receive(NetClientState *nc, const uint8_t * buf,
                               size_t pkt_size)

the corresponding pkt_size values look like this,

pkt_size 98
pkt_size 42

So this seems to show that the bug is not in dp8393x. Possibly not in 
QEMU?

I don't see any options in 'man brctl' that might explain why the host and 
guest see different packets. I guess I'll have to find a way to avoid 
using bridge interfaces (?)