Re: FreeBSD guest on Linux KVM, some vtnet(4) packets don't arrive

Zhenlei Huang <[email protected]>
Newsgroups gmane.os.freebsd.devel.net
Message-ID <[email protected]>

> On Apr 8, 2026, at 10:38 PM, Lexi Winter <[email protected]> wrote:
> 
> hello,
> 
> i'm using FreeBSD main:
> 
> FreeBSD 16.0-CURRENT #0 main-n284768-e6eba5076929: Mon Mar 30 16:07:28 UTC 2026
> [email protected]:/usr/obj/usr/src/powerpc.powerpc64/sys/GENERIC64
> 
> as a qemu (KVM) guest on a Linux host:
> 
> Linux 6.18.21-0-lts #1-Alpine SMP 2026-04-07 10:34:29 ppc64le
> 
> on the Linux side, qemu is configured to provide a tap interface to the
> guest:
> 
> qemu-system-ppc64 \
> 	-smp cpus=176,sockets=2,cores=22,threads=4 \
> 	-accel kvm -M pseries -m 8g -nographic -serial mon:stdio \
> 	-drive file=/vm/ppc64-main/root.img,format=raw,if=virtio \
> 	-netdev tap,id=net0,ifname=vm-ppc64-main,script=no,downscript=no \
> 	-device virtio-net-pci,netdev=net0
> 
> the tap interface looks fine:
> 
> 10: vm-ppc64-main: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
>    link/ether ae:dc:d8:39:be:fa brd ff:ff:ff:ff:ff:ff
>    inet6 fe80::acdc:d8ff:fe39:befa/64 scope link proto kernel_ll
>       valid_lft forever preferred_lft forever
>    inet6 fe80::1/64 scope link
>       valid_lft forever preferred_lft forever
> 
> on the FreeBSD side, the vtnet interface also looks fine:
> 
> vtnet0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
>        options=cc00ba<TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWTSO,LINKSTATE,TXCSUM_IPV6,HWSTATS>
>        ether 52:54:00:12:34:56
>        inet6 fe80::2%vtnet0 prefixlen 64 scopeid 0x1
>        media: Ethernet autoselect (10Gbase-T <full-duplex>)
>        status: active
>        nd6 options=821<PERFORMNUD,AUTO_LINKLOCAL,STABLEADDR>
> 
> on the host, i can ping fe80::2%vm-ppc64-main:
> 
> PING fe80::2%vm-ppc64-main (fe80::2%10): 56 data bytes
> 64 bytes from fe80::2: seq=0 ttl=64 time=14.833 ms
> 64 bytes from fe80::2: seq=1 ttl=64 time=12.524 ms

So the traffic with link-local addresses looks good.

> 
> then i configured an IP address on lo0 on the guest:
> 
> lo0: flags=1008049<UP,LOOPBACK,RUNNING,MULTICAST,LOWER_UP> metric 0 mtu 16384
>        options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
>        inet 127.0.0.1 netmask 0xff000000
>        inet6 ::1 prefixlen 128
>        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
>        inet6 fd00:0:0:1::b prefixlen 128
>        groups: lo
>        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
> 
> a route exists for this on the host:
> 
> fd00:0:0:1::b via fe80::2 dev vm-ppc64-main proto bird metric 32 pref medium

Just to confirm, do you have a reverse route on the guest ?

> 
> when trying to ping this address, on the host, i can see ICMP packets leaving
> the tap interface:
> 
> 15:34:39.106898 IP6 fd00:0:0:1::12 > fd00:0:0:1::b: ICMP6, echo request, id 49664, seq 3, length 64
> 15:34:40.106951 IP6 fd00:0:0:1::12 > fd00:0:0:1::b: ICMP6, echo request, id 49664, seq 4, length 64
> 
> but these packets never arrive on the guest; tcpdump shows nothing.
> 
> however, 'netstat -in' shows that the packets *are* arriving on the guest,
> since Ipkts increments for each ICMP packet.  it seems like they're just
> getting lost somewhere in the network stack. (Ierrs/Oerrs is zero.)

That puzzled me a bit. If the net stack sees the arriving packets, then tcpdump shall
intercept them correctly.

> 
> does anyone have any ideas what might be causing this?

Does `netstat -sp ip6` and `netstat -sp icmp6` show anything unusual ?

Best regards,
Zhenlei
signature.asc (application/pgp-signature, 358 B)
-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQRj28YmNowGX1isJg7GJJ6Jgbd0XwUCadZ06V8UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0NjNE
QkM2MjYzNjhDMDY1RjU4QUMyNjBFQzYyNDlFODk4MUI3NzQ1RgAKCRDGJJ6Jgbd0
Xz7qAP9QZVFG6HGgNQ9OybIg0DwAvn5dehsRolkTJ6d5tthWuwD/QeoexfmqSWHW
SdB65xIe44dZQ/oy8GMU4s0PhOpeEQA=
=APpb
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.