svn commit: r361944 - in head/sys/dev/virtio: . network

[Tom Jones]

On Mon, Jun 08, 2020 at 09:51:36PM +0000, Jessica Clarke wrote:
> Author: jrtc27
> Date: Mon Jun  8 21:51:36 2020
> New Revision: 361944
> URL: https://svnweb.freebsd.org/changeset/base/361944
> 
> Log:
>   virtio: Support non-legacy network device and queue
>   
>   The non-legacy interface always defines num_buffers in the header,
>   regardless of whether VIRTIO_NET_F_MRG_RXBUF, just leaving it unused. We
>   also need to ensure our virtqueue doesn't filter out VIRTIO_F_VERSION_1
>   during negotiation, as it supports non-legacy transports just fine. This
>   fixes network packet transmission on TinyEMU.
>   
>   Reviewed by:	br, brooks (mentor), jhb (mentor)
>   Approved by:	br, brooks (mentor), jhb (mentor)
>   Differential Revision:	https://reviews.freebsd.org/D25132
> 
> Modified:
>   head/sys/dev/virtio/network/if_vtnet.c
>   head/sys/dev/virtio/network/if_vtnetvar.h
>   head/sys/dev/virtio/virtio.c
>   head/sys/dev/virtio/virtqueue.c
> 

Hi Jessica,

After updating my current bhyve vm today (on a 12.1 host), networking no longer
works. Reverting this commit seems to resolve the issue. I think vtnet is not
passing enough data up to the ip layer.

If I capture on the tap interface for the vm I see arp requests and arp
replies, however kern.msgbuf is full of: 

<5>arp: short packet received on vtnet0

and netstat does not see any replies to arp requests:

root at freebsd-current:~ # netstat -s -p arp
arp:
        11 ARP requests sent
        0 ARP requests failed to sent
        0 ARP replies sent
        0 ARP requests received
        0 ARP replies received
        0 ARP packets received
        24 total packets dropped due to no ARP entry
        2 ARP entrys timed out
        0 Duplicate IPs seen

If I set up an arp entry manually I can see ICMP echo requests and responses on
the tap interface, but the vm does not see the responses. 

root at freebsd-current:~ # netstat -s -p ip
ip:
        7 total packets received
        0 bad header checksums
        0 with size smaller than minimum
        7 with data size < data length
        0 with ip length > max ip packet size
        0 with header length < data size
        0 with data length < header length

The line

        7 with data size < data length

makes me think that vtnet is truncating packets. 

markj pointed me at this bug in irc which might also be related:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247242

- Tom