Re: [PLUG] IPv6 TCP connect timeout puzzler
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 -> A TCP SYN-ACK reply, but host A > > apparently doesn't recognize it as valid (although, in wireshark they > look > > reasonable to an eyeball), because the connect syscall never returns > (until > > it times out), and the A -> B ACK handshake is never sent. Works fine for > > ssh -4. If A and C are the same host, I see the same behavior. Another > > wrinkle: if A is also a kvm guest of C, I don't see the SYN-ACK, just the > > SYN. The kvm clients are connected via a network bridge on C, e.g. "brctl > > show" sees N+1 real ethernet interfaces eth0, ... ethN, and the M+1 > > virtual interfaces associated with the kvm guests: vnet0 ... vnetM. There > > are no netfilter rules to be seen on any of the hosts involved. > > > > Oh, and A can ping6 B, and vice versa, just fine. I'm only seeing this > > weirdness with TCP. > > > > Anybody have any thoughts? This is violating my expectations. > > That is weird. Weirder still is the fact that I can duplicate those > symptoms on my Mac that's hosting a Linux VM using the UTM hypervisor. > ssh -6 fails but ping6 succeeds. > Thankfully, it isn't a local distortion zone effect then, if you can duplicate it. I am not sure who to even ask about it. Seems like a kernel thing if the connect(2) syscall is timing out. > > -- > Paul Heinlein > heinl...@madboa.com > 45°22'48" N, 122°35'36" W >
Re: [PLUG] IPv6 TCP connect timeout puzzler
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: > > > 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 valid (although, in wireshark they > > look > > > reasonable to an eyeball), because the connect syscall never returns > > (until > > > it times out), and the A -> B ACK handshake is never sent. Works fine > for > > > ssh -4. If A and C are the same host, I see the same behavior. Another > > > wrinkle: if A is also a kvm guest of C, I don't see the SYN-ACK, just > the > > > SYN. The kvm clients are connected via a network bridge on C, e.g. > "brctl > > > show" sees N+1 real ethernet interfaces eth0, ... ethN, and the M+1 > > > virtual interfaces associated with the kvm guests: vnet0 ... vnetM. > There > > > are no netfilter rules to be seen on any of the hosts involved. > > > > > > Oh, and A can ping6 B, and vice versa, just fine. I'm only seeing this > > > weirdness with TCP. > > > > > > Anybody have any thoughts? This is violating my expectations. > > > > That is weird. Weirder still is the fact that I can duplicate those > > symptoms on my Mac that's hosting a Linux VM using the UTM hypervisor. > > ssh -6 fails but ping6 succeeds. > > > > -- > > Paul Heinlein > > heinl...@madboa.com > > 45°22'48" N, 122°35'36" W > > >
Re: [PLUG] IPv6 TCP connect timeout puzzler
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. 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 > > reasonable to an eyeball), because the connect syscall never returns > (until > > it times out), and the A -> B ACK handshake is never sent. Works fine for > > ssh -4. If A and C are the same host, I see the same behavior. Another > > wrinkle: if A is also a kvm guest of C, I don't see the SYN-ACK, just the > > SYN. The kvm clients are connected via a network bridge on C, e.g. "brctl > > show" sees N+1 real ethernet interfaces eth0, ... ethN, and the M+1 > > virtual interfaces associated with the kvm guests: vnet0 ... vnetM. There > > are no netfilter rules to be seen on any of the hosts involved. > > > > Oh, and A can ping6 B, and vice versa, just fine. I'm only seeing this > > weirdness with TCP. > > > > Anybody have any thoughts? This is violating my expectations. > > That is weird. Weirder still is the fact that I can duplicate those > symptoms on my Mac that's hosting a Linux VM using the UTM hypervisor. > ssh -6 fails but ping6 succeeds. > > -- > Paul Heinlein > heinl...@madboa.com > 45°22'48" N, 122°35'36" W >
Re: [PLUG] trying to simplify my Linux operating system graphics components
Hello, Additional side note on zoom. You can run it just through the browser instead of their application. You get most of the same features. pwa.zoom.us Just when joining a meeting it will ask to launch the app but below there is a launch in browser option. They are actually discontinuing the app for chrome os. On Wed, Sep 7, 2022, 23:04 American Citizen wrote: > To all: > > It's been a really bumpy ride activating the appropriate video drivers > for my Nvidia GEForce 710T vga card. > > Here's what lsmod shows now > > owner@localhost:~> lsmod | grep nv > nvidia_drm 69632 6 > nvidia_modeset 1204224 16 nvidia_drm > nvidia_uvm 1130496 0 > nvidia 35471360 845 nvidia_uvm,nvidia_modeset > drm_kms_helper303104 1 nvidia_drm > drm 630784 10 drm_kms_helper,nvidia,nvidia_drm > > so my system is now running with native Nvidia drivers (signed, btw) > > What is missing is the fact that the OpenSuse Leap 15.4 is using signed > kernel modules, and my HP 420 Workstation is a UEFI system, expecting > signing keys before enabling kernel modules, and having to manually sign > modules eluded me. > > Worse, Nvidia listed the WRONG driver to download the G06 series > although their website says G06 for the 710T card, but an error message > from the kernel during boot time, lecturing me that I could NOT install > the 515 series drivers, caused me to go back and drop back down to the > legacy 471.141 series. Fortunately I had installed the Nvidia repository > so I could make the change under openSuse's yast2 program or zypper. > > btw: trying to do the native Nvidia install forces the UEFI user to > enter both a public and private key and I have NO idea where they are > stored, although running the mokutil --list-all is useful, but still > doesn't tell you where the keys are. > > I had to reboot, but then enter the UEFI firmware, remove the G06 key > and install the G05 key. After all this, I was able to bring up Leap > 15.4 without a hitch, so I am running nvidia modules directly now > > All this is like a gob-smacker, to someone who's never done this before > (me) so I had to work my way through all of this carefully. > > Thanks for all the replies, they are appreciated! > > - Randall > > >
Re: [PLUG] IPv6 TCP connect timeout puzzler
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 valid (although, in wireshark they look reasonable to an eyeball), because the connect syscall never returns (until it times out), and the A -> B ACK handshake is never sent. Works fine for ssh -4. If A and C are the same host, I see the same behavior. Another wrinkle: if A is also a kvm guest of C, I don't see the SYN-ACK, just the SYN. The kvm clients are connected via a network bridge on C, e.g. "brctl show" sees N+1 real ethernet interfaces eth0, ... ethN, and the M+1 virtual interfaces associated with the kvm guests: vnet0 ... vnetM. There are no netfilter rules to be seen on any of the hosts involved. Oh, and A can ping6 B, and vice versa, just fine. I'm only seeing this weirdness with TCP. Anybody have any thoughts? This is violating my expectations. That is weird. Weirder still is the fact that I can duplicate those symptoms on my Mac that's hosting a Linux VM using the UTM hypervisor. ssh -6 fails but ping6 succeeds. -- Paul Heinlein heinl...@madboa.com 45°22'48" N, 122°35'36" W
[PLUG] IPv6 TCP connect timeout puzzler
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 reasonable to an eyeball), because the connect syscall never returns (until it times out), and the A -> B ACK handshake is never sent. Works fine for ssh -4. If A and C are the same host, I see the same behavior. Another wrinkle: if A is also a kvm guest of C, I don't see the SYN-ACK, just the SYN. The kvm clients are connected via a network bridge on C, e.g. "brctl show" sees N+1 real ethernet interfaces eth0, ... ethN, and the M+1 virtual interfaces associated with the kvm guests: vnet0 ... vnetM. There are no netfilter rules to be seen on any of the hosts involved. Oh, and A can ping6 B, and vice versa, just fine. I'm only seeing this weirdness with TCP. Anybody have any thoughts? This is violating my expectations. -- Russell Senior russ...@personaltelco.net
