Just to follow up, I don't know why it had the effect I was seeing with TCP
dump, but I did finally locate some network filtering in libvirt and
observed that I saw the problem with Debian Buster as the hypervisor, but
not with Debian Bullseye, and also noticed that Bullseye had a file:
On Fri, Sep 9, 2022 at 7:34 AM Paul Heinlein wrote:
> On Fri, 9 Sep 2022, Russell Senior wrote:
>
> > I'm seeing bizarre behavior: host A initiates an ssh -6 to host B; host B
> > is a qemu-kvm guest of a kvm host, C. Tcpdump (on the initiating host A
> > shows A -> B TCP SYN packet, and a B ->
I don't think so. The initiating host gets the SYN-ACK like it should, just
nothing happens to it.
On Fri, Sep 9, 2022 at 11:43 AM Tomas Kuchta
wrote:
> Could the issue be that the ssh response is on ipv4, not on ipv6 as
> expected?
>
> -T
>
> On Fri, Sep 9, 2022, 10:34 Paul Heinlein wrote:
>
Could the issue be that the ssh response is on ipv4, not on ipv6 as
expected?
-T
On Fri, Sep 9, 2022, 10:34 Paul Heinlein wrote:
> On Fri, 9 Sep 2022, Russell Senior wrote:
>
> > I'm seeing bizarre behavior: host A initiates an ssh -6 to host B; host B
> > is a qemu-kvm guest of a kvm host, C.
On Fri, 9 Sep 2022, Russell Senior wrote:
I'm seeing bizarre behavior: host A initiates an ssh -6 to host B; host B
is a qemu-kvm guest of a kvm host, C. Tcpdump (on the initiating host A
shows A -> B TCP SYN packet, and a B -> A TCP SYN-ACK reply, but host A
apparently doesn't recognize it as
I'm seeing bizarre behavior: host A initiates an ssh -6 to host B; host B
is a qemu-kvm guest of a kvm host, C. Tcpdump (on the initiating host A
shows A -> B TCP SYN packet, and a B -> A TCP SYN-ACK reply, but host A
apparently doesn't recognize it as valid (although, in wireshark they look
