Re: FreeBSD guest on Linux KVM, some vtnet(4) packets don't arrive
Michael Tuexen <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.net |
|---|---|
| Message-ID | <[email protected]> |
> On 11. Apr 2026, at 14:09, Michael Tuexen <[email protected]> wrote: > >> On 10. Apr 2026, at 23:34, Adrian Chadd <[email protected]> wrote: >> >> On Fri, 10 Apr 2026 at 13:40, Michael Tuexen >> <[email protected]> wrote: >>> >>>> On 10. Apr 2026, at 12:21, Lexi Winter <[email protected]> wrote: >>>> >>>> Lexi Winter wrote in <[email protected]>: >>>>> the problem seems to be due to choice of cipher: >>>>> >>>>> % ssh [email protected] [email protected] >>>>> Fssh_ssh_dispatch_run_fatal: Connection to fd00:0:0:1::b port 22: message authentication code incorrect >>>>> >>>>> % ssh [email protected] [email protected] >>>>> Last login: Fri Apr 10 08:17:20 2026 from tansy.le-fay.org >>>>> >>>>> if AES is broken, that would also explain why TLS doesn't work. >>>>> >>>>> unfortunately while trying to rebuild world i ran into an unrelated >>>>> panic[0], so i'll need to find a workaround for that before i can >>>>> test more. >>>> >>>> i was able to cross-build current main (82ff1c334b97) on another system >>>> and copy it over, which seems to have fixed the issue with TLS and SSH. >>>> >>>> i need to do some final setup on the VM and then i'll try to do some >>>> more testing for the original vtnet/tcpdump problem, which is still >>>> present. >>> Hi Ivy, >>> >>> is this really a vtnet/tcpdump problem? On my PPC64 VM, tcpdump does not >>> show any packets on vtnet0 or lo0. On bare metal, tcpdump does not show >>> any packets on lo0 or bge2. >>> >>> So I guess, this has nothing to do with vtnet. >> >> There's likely a bunch of weird broken stuff that we need to fix. >> >> I'm pretty sure tcpdump worked fine in December last year on >> ppc64le/ppc64be since I was doing >> general fixing of stuff there. >> >> Let's file some ppc64 bugs and get them triaged/debugged. I bet the >> "why's tcpdump not working?" >> problem is triagable with dtrace/fbt points. > Some more testing: > 1. 15.0 shows the same behavior as CURRENT > 2. It is not that tcpdump is not working at all, it just shows the > packets in a batch after some time. Use ping -s 16000 127.0.0.1 > and you see what I mean. Just using ping requires you to wait > substantially longer. > So it seems that tcpdump gets the packets on PPC64 only when some > buffer is full. Using --immediate as a command line argument of tcpdump works around the problem. Best regards Michael > > Best regards > Michael >> >> >> >> -adrian > >