On Sep 27, 2025, at 12:37 PM, Michael Tuexen <[email protected]> wrote: > >> On 27. Sep 2025, at 18:26, John Nielsen <[email protected]> wrote: >> >>> On Sep 26, 2025, at 3:44 PM, Michael Tuexen >>> <[email protected]> wrote: >>> >>>> On 26. Sep 2025, at 20:52, John Nielsen <[email protected]> wrote: >>>> >>>>> On Sep 26, 2025, at 1:46 AM, Michael Tuexen >>>>> <[email protected]> wrote: >>>>> >>>>>> >>>>>> On 26. Sep 2025, at 02:58, John Nielsen <[email protected]> wrote: >>>>>> >>>>>> Not sure if this is a known issue or even an issue on the FreeBSD side >>>>>> but decided to ask here first. I’m happy to put in a bug report if >>>>>> appropriate. >>>>>> >>>>>> I have a hypervisor machine running Arch Linux with KVM, Qemu and >>>>>> libvirtd. The machine has a Chelsio T520-CR adapter. I recently began >>>>>> passing through virtual functions of the NIC to several of the guests I >>>>>> run on the hypervisor. One of the guests runs Windows 11, and the change >>>>>> was seamless. Two of the guests are running FreeBSD (14.3 or so). On >>>>>> each of them the VFs were readily identified and configured (using DHCP >>>>>> in one case), and ping and ARP appeared to work fine. However, TCP and >>>>>> UDP traffic to the guests never received a response. After some >>>>>> head-scratching and troubleshooting I discovered that running “ifconfig >>>>>> cxlv0 -rxcsum” immediately allowed traffic to flow as expected. >>>>> >>>>> I don't have access to such a network card. Just to be clear: you are >>>>> running the “ifconfig cxlv0 -rxcsum” command inside the guest running >>>>> FreeBSD, right? >>>> >>>> Yes. >>>> >>>>> What is the peer, when you mention TCP and UDP do not work? Is it the >>>>> host running Linux? Is it another VM? Is it some external host? >>>> >>>> My laptop on the same subnet primarily, but. Also tested from another >>>> physical machine running FreeBSD. >>> OK. That does not seem to be related to what I initially thought. >>> >>> Could you run >>> tcpdump -i outgoing_interface -w laptop.pcap >>> on your laptop and >>> tcpdump -i cxlv0 -w vm.pcap >>> on your vm at the same time and try to do some TCP based communication. >>> Maybe two times, one time with ifconfig cxlv0 rxcsum and one time with >>> ifconfig cxlv0 -rxcsum. >>> >>> If you are fine with doing the measurements, you can send the .pcap files >>> to [email protected] <mailto:[email protected]>. >>> >>> At least I would like to understand what is going on. >> >> Thank you, I sent you those packet captures under separate cover. > Thanks I got the email and sent a response. >> >> From what I can tell so far the VM does receive incoming packets even when >> rxcsum is enabled, and the checksums appear correct at least according to >> tcpdump. But something prevents the packets from being processed or sent up >> the stack. The VM’s sshd never generates a SYN/ACK in response to a >> connection attempt. A DNS query from the VM looks like it gets a response on >> the wire but the response doesn’t make it to the process doing the query. > Yes, I agree. For whatever reason the packets received, but are not delivered > to > the transport stack. I would like to figure out where the packets are dropped > or > stored and not processed further. I > sent you some suggestions to try. I hope we can figure out where the problem > is > related. > In addition to what I suggested, you might want to provide the output of > netstat -s > from before and after running the experiment.
Thanks again Michael for your help pinpointing the issue. For the archives, this is now being tracked under https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=289907 . JN
