EdT13EXkCaGIemo93nZCT/N93WlgwmBHmDF/RMhqiKliCwcq5S7pm6 gnM+iegd2pIATpkbr5W7+TB+dYD5M8+ChjzJ1ToJJ8OAT1euND2gAAyIiTL4nA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1775662326; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=DLI7hVD+k4dR3F4L744RhouuSMUNUCYZHFu64uftYVY=; b=gybCRWqJbXkZU/qG5dT+ER/4caZ7nOrSrs4gMH5CrYMAbrzP6mZB18Ao5LN/3z8nXMCksV KE2UhPtOexCLGjPvh5FeuYQ2P0yzNADcoEiT6QeNkRvhzr3lrlM5+rDxtAqryrGiy8K/bO NXve3LEKP2jCy/7k1KmYUKdqCl3LYipfYEa0eksM5bUcOHWcHq22AV4rAYuqG8VHdYo0jY nnk/tGuN9F4MUyzuKMd4gWlGEB1HgR9lKFW8Cqczr/WCn0zwezG6CJMDJD3ooykvRKMZf9 yyRLBRZ5U4T79iZdscn2QhmMg1WXPlZHi5xcygghMt3/StxzebRarSA6wk2kqg== Received: from smtpclient.apple (ns1.oxydns.net [45.32.91.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: zlei/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4frRrN3whXz1kg; Wed, 08 Apr 2026 15:32:04 +0000 (UTC) (envelope-from zlei@FreeBSD.org) Content-Type: multipart/signed; boundary="Apple-Mail=_CD540EA1-41DD-46EB-972D-B114ED7AEB3C"; protocol="application/pgp-signature"; micalg=pgp-sha512 List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.10\)) Subject: Re: FreeBSD guest on Linux KVM, some vtnet(4) packets don't arrive From: Zhenlei Huang In-Reply-To: Date: Wed, 8 Apr 2026 23:31:53 +0800 Cc: net@freebsd.org Message-Id: <28495B68-0BD1-4372-806C-C766DBCB8410@FreeBSD.org> References: To: Lexi Winter X-Mailer: Apple Mail (2.3696.120.41.1.10) --Apple-Mail=_CD540EA1-41DD-46EB-972D-B114ED7AEB3C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Apr 8, 2026, at 10:38 PM, Lexi Winter wrote: >=20 > hello, >=20 > i'm using FreeBSD main: >=20 > FreeBSD 16.0-CURRENT #0 main-n284768-e6eba5076929: Mon Mar 30 16:07:28 = UTC 2026 > = root@releng3.nyi.freebsd.org:/usr/obj/usr/src/powerpc.powerpc64/sys/GENERI= C64 >=20 > as a qemu (KVM) guest on a Linux host: >=20 > Linux 6.18.21-0-lts #1-Alpine SMP 2026-04-07 10:34:29 ppc64le >=20 > on the Linux side, qemu is configured to provide a tap interface to = the > guest: >=20 > qemu-system-ppc64 \ > -smp cpus=3D176,sockets=3D2,cores=3D22,threads=3D4 \ > -accel kvm -M pseries -m 8g -nographic -serial mon:stdio \ > -drive file=3D/vm/ppc64-main/root.img,format=3Draw,if=3Dvirtio \ > -netdev tap,id=3Dnet0,ifname=3Dvm-ppc64-main,script=3Dno,downscrip= t=3Dno \ > -device virtio-net-pci,netdev=3Dnet0 >=20 > the tap interface looks fine: >=20 > 10: vm-ppc64-main: 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 >=20 > on the FreeBSD side, the vtnet interface also looks fine: >=20 > vtnet0: flags=3D1008843= metric 0 mtu 1500 > = options=3Dcc00ba > ether 52:54:00:12:34:56 > inet6 fe80::2%vtnet0 prefixlen 64 scopeid 0x1 > media: Ethernet autoselect (10Gbase-T ) > status: active > nd6 options=3D821 >=20 > on the host, i can ping fe80::2%vm-ppc64-main: >=20 > PING fe80::2%vm-ppc64-main (fe80::2%10): 56 data bytes > 64 bytes from fe80::2: seq=3D0 ttl=3D64 time=3D14.833 ms > 64 bytes from fe80::2: seq=3D1 ttl=3D64 time=3D12.524 ms So the traffic with link-local addresses looks good. >=20 > then i configured an IP address on lo0 on the guest: >=20 > lo0: flags=3D1008049 metric 0 = mtu 16384 > options=3D680003= > 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=3D21 >=20 > a route exists for this on the host: >=20 > 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 ? >=20 > when trying to ping this address, on the host, i can see ICMP packets = leaving > the tap interface: >=20 > 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 >=20 > but these packets never arrive on the guest; tcpdump shows nothing. >=20 > 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. >=20 > does anyone have any ideas what might be causing this? Does `netstat -sp ip6` and `netstat -sp icmp6` show anything unusual ? Best regards, Zhenlei --Apple-Mail=_CD540EA1-41DD-46EB-972D-B114ED7AEB3C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQRj28YmNowGX1isJg7GJJ6Jgbd0XwUCadZ06V8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0NjNE QkM2MjYzNjhDMDY1RjU4QUMyNjBFQzYyNDlFODk4MUI3NzQ1RgAKCRDGJJ6Jgbd0 Xz7qAP9QZVFG6HGgNQ9OybIg0DwAvn5dehsRolkTJ6d5tthWuwD/QeoexfmqSWHW SdB65xIe44dZQ/oy8GMU4s0PhOpeEQA= =APpb -----END PGP SIGNATURE----- --Apple-Mail=_CD540EA1-41DD-46EB-972D-B114ED7AEB3C--