ssh lag mit wlan Verbindung

Hi,

ich habe folgendes Problem:

Ich habe einen Raspberry Pi 3 B+ und einen Zero W, beide wurden mit dem Raspberry Pi Imager installiert mit dem jeweils empfohlenen OS (Raspberry Pi OS 32 & 64 bit). Bei beiden wurde mein lokales (2,4GHz) WLAN eingerichtet, außerdem ein Nutzer mit SSH Zugriff (falls wichtig: per ed25519 Key).

Bei beiden habe ich extreme Lags auf der SSH Console, die die Benutzung nahezu unmöglich machen, machmal klappt der Connect auch gar nicht erst (Konsole hängt im Deadlock).

Client OS ist ein Manjaro.

Folgendes habe ich bereits versucht (habe schon viele ähnliche Threads gefunden):
- Netzteil Leistung überprüft
- WLAN Power save mode deaktiviert
- SSH Server: UseDNS no & ClientAliveInterval 300
- IPv6 deaktiviert
- Namensauflösung geprüft (obwohl ich auch per IP das gleiche Problem habe)
- Load geprüft, beide Pis langweilen sich, außerdem habe ich die GUI deaktiviert (switch to multiuser.target)

Ich bin mir ziemlich sicher, dass es irgendwas mit dem SSH Server ist, denn:
- Ping zeigt auch über längerem Zeitraum keine Auffälligkeiten
- Netstat zeigt zwar einige Paket drops, aber nicht besorgniserregend viele
- Ich habe auf der lokalen Konsole Updates über WLAN installiert, was problemlos geklappt hat
- Ich habe einen Apache auf dem Pi installiert und den kann ich per http problemlos über WLAN abfragen
- Networkmanager Log zeigt nichts auffälliges (heult nur rum dass er keine IPv6 Adresse konfigurieren kann, was ich ja selbst abgeschaltet habe)

Und jetzt kommt das ganz kuriose:
- Wenn ich die LAN Buchse (beim 3B+) verbinde, dann klappt auch SSH problemlos und zwar NICHT nur über LAN, sondern auch über die IP auf dem WLAN Adapter
- Letzteres klappt auch weiterhin problemlos, selbst wenn ich die Routen über den LAN Adapter zur Sicherheit entferne (obwohl die ja ein source setting haben)
- Erst wenn ich physisch das Kabel entferne fängt auch die WLAN Verbindung wieder an zu laggen...

Hat irgendwer eine Idee? Ich bin mit meinem Latein ziemlich am Ende.

Quote from hyle

Wie, bzw. womit? Welche Netzteile verwendest Du denn?

Was ist der Client, von dem aus Du Dich per SSH verbindest?

Ich hatte zuerst ein 0815 USB Netzteil, da hat der Raspi an der GUI direkt gemeckert, dass er zu wenig Strom bekommt (obwohl an sich alles lief, mal vom geschilderten Problem abgesehen).

Jetzt nutze ich ein Netzteil, was ich damals extra zu dem Raspi gekauft hatte, 5V 2.5A, das Gemecker ist damit auch verschwunden, aber das SSH Problem immernoch da.

Habe außerdem ein 120W PD-fähiges Netzteil versucht, selbes Ergebnis wie das Raspi Netzteil.

Client ist ein Manjaro Linux.

Also das ist das PD Netzteil: https://www.amazon.de/dp/B09WD21LLP?tag=psblog-21 [Anzeige]

Was das Raspi Netzteil angeht: Ich hab keine Ahnung mehr wo ich das damals bestellt habe, aber jedensfalls im gleichen Shop wie den Raspi 3B+ auch, wurde speziell dazu angeboten und ich habe den Pi damals auch problemlos damit betrieben (mit älterem OS natürlich, damals noch ohne den Imager, per dd installiert und manuell eingerichtet; ob ich damals LAN oder WLAN genutzt habe weiß ich allerdings auch nicht mehr, vermute eher LAN da ich das bevorzuge, aber beim aktuellen Projekt brauche ich WLAN only).

SSH Client ist wie gesagt ein Linux Laptop mit Manjaro als Distribution.

Der Router (Fritzbox 7490) ist im gleichen Raum ca. 2m entfernt.

Angeschlossen ist gar nichts weiter. Vorhin hatte ich zur Einrichtung noch TV/HDMI + USB Dongle für Maus/Tastatur dran. Aktuell nur Strom und temporär LAN Kabel, wenn ich wieder was ausprobieren will, da WLAN alleine ja nicht klappt.

Es läuft auch nicht wirklich was darauf, ein Apache zu Testzwecken, aber auch nur weil das Problem schon davor bestand. Und wie gesagt habe ich sogar schon auf multiuser (nur Konsole) gewechselt, um wirklich jede unnötige Last zu reduzieren.

OS ist auf einer 64GB SD card (SanDisk Ultra XC1) installiert.

Quote from Bernd666

Moin hfi,

es kommt keine Fehlermeldung bzw. kommt überhaupt eine Meldung bei deinem Client?
Hast du schon mal ssh -v user@rpi probiert? Da kommen dann viele Debugmeldungen.

73 de Bernd

-v zeigt nichts auffälliges soweit ich das beurteilen kann, mit -vvv bekomme ich während der Lags immer mal wieder die folgenden Logzeilen:

debug3: obfuscate_keystroke_timing: starting: interval ~20ms
debug3: obfuscate_keystroke_timing: stopping: chaff time expired (0 chaff packets sent)

Ohne -v bekomme ich keine Fehlermeldungen, nein.

Quote from rpi444

Poste mal, ohne und mit Lan-Kabel, von deinem PI (mit dem sshd) die Ausgaben von:

Code

ip n s
ip a
ip r

Nur WLAN:

ip n s
192.168.1.111 dev wlan0 lladdr 4c:49:6c:9c:dd:17 REACHABLE 
192.168.1.1 dev wlan0 lladdr 7c:ff:4d:43:dd:e0 STALE

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether b8:27:eb:87:b2:b2 brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether b8:27:eb:d2:e7:e7 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.3/24 brd 192.168.1.255 scope global dynamic noprefixroute wlan0
       valid_lft 862432sec preferred_lft 862432sec

default via 192.168.1.1 dev wlan0 proto dhcp src 192.168.1.3 metric 600 
192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.3 metric 600

WLAN + LAN:

192.168.1.1 dev eth0 lladdr 7c:ff:4d:43:dd:e0 REACHABLE 
192.168.1.111 dev eth0 lladdr 4c:49:6c:9c:dd:17 REACHABLE 
192.168.1.1 dev wlan0 lladdr 7c:ff:4d:43:dd:e0 STALE 
192.168.1.111 dev wlan0 lladdr 4c:49:6c:9c:dd:17 STALE

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether b8:27:eb:87:b2:b2 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.2/24 brd 192.168.1.255 scope global dynamic noprefixroute eth0
       valid_lft 863953sec preferred_lft 863953sec
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether b8:27:eb:d2:e7:e7 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.3/24 brd 192.168.1.255 scope global dynamic noprefixroute wlan0
       valid_lft 862300sec preferred_lft 862300sec

default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.2 metric 100 
default via 192.168.1.1 dev wlan0 proto dhcp src 192.168.1.3 metric 600 
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.2 metric 100 
192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.3 metric 600

Ja, in der Tat scheint da was über eth0 zu laufen:

00:33:19.684319 b8:27:eb:87:b2:b2 > 4c:49:6c:9c:dd:17, ethertype IPv4 (0x0800), length 166: (tos 0x10, ttl 64, id 13860, offset 0, flags [DF], proto TCP (6), length 152)
    192.168.1.3.22 > 192.168.1.111.59788: Flags [P.], cksum 0x844d (incorrect -> 0xe2d2), seq 60:160, ack 1, win 623, options [nop,nop,TS val 1713976588 ecr 307078672], length 100
00:33:19.753468 b8:27:eb:87:b2:b2 > 4c:49:6c:9c:dd:17, ethertype IPv4 (0x0800), length 278: (tos 0x10, ttl 64, id 13861, offset 0, flags [DF], proto TCP (6), length 264)
    192.168.1.3.22 > 192.168.1.111.59788: Flags [P.], cksum 0x84bd (incorrect -> 0x2a6d), seq 160:372, ack 1, win 623, options [nop,nop,TS val 1713976657 ecr 307078731], length 212
    
...

ssh -T scheint keinen Unterschied zum machen, bzw. doch, damit komme ich dann scheinbar gar nicht mehr bis zu einer Shell

Manjaro: OpenSSH_9.9p2, OpenSSL 3.4.1 11 Feb 2025
Pi: OpenSSH_9.2p1 Debian-2+deb12u5, OpenSSL 3.0.15 3 Sep 2024

Quote from rpi444

Wenn >/= 9.5 dann versuch mal auf dem Client, mit der Option "ObscureKeystrokeTiming no"

Jetzt dachte ich schon das war es, da ich gerade bestimmt 30s oder so ohne jegliche Lags auf der Shell arbeiten konnte.

Aber scheinbar sind die Lags immernoch da, ich habe aber den Eindruck, dass es schon etwas besser geworden ist.

Manjaro ssh client: OpenSSH_9.9p2, OpenSSL 3.4.1 11 Feb 2025

Die systctl Optionen habe ich mal live gesetzt, hat aber am tcpdump nichts geändert, SSH (mit LAN über WLAN IP) geht auch nach wie vor.

sysctl net.ipv4.conf.all
net.ipv4.conf.all.accept_local = 0
net.ipv4.conf.all.accept_redirects = 1
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.all.arp_accept = 0
net.ipv4.conf.all.arp_announce = 0
net.ipv4.conf.all.arp_evict_nocarrier = 1
net.ipv4.conf.all.arp_filter = 1
net.ipv4.conf.all.arp_ignore = 0
net.ipv4.conf.all.arp_notify = 0
net.ipv4.conf.all.bc_forwarding = 0
net.ipv4.conf.all.bootp_relay = 0
net.ipv4.conf.all.disable_policy = 0
net.ipv4.conf.all.disable_xfrm = 0
net.ipv4.conf.all.drop_gratuitous_arp = 0
net.ipv4.conf.all.drop_unicast_in_l2_multicast = 0
net.ipv4.conf.all.force_igmp_version = 0
net.ipv4.conf.all.forwarding = 0
net.ipv4.conf.all.igmpv2_unsolicited_report_interval = 10000
net.ipv4.conf.all.igmpv3_unsolicited_report_interval = 1000
net.ipv4.conf.all.ignore_routes_with_linkdown = 0
net.ipv4.conf.all.log_martians = 0
net.ipv4.conf.all.mc_forwarding = 0
net.ipv4.conf.all.medium_id = 0
net.ipv4.conf.all.promote_secondaries = 0
net.ipv4.conf.all.proxy_arp = 0
net.ipv4.conf.all.proxy_arp_pvlan = 0
net.ipv4.conf.all.route_localnet = 0
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.secure_redirects = 1
net.ipv4.conf.all.send_redirects = 1
net.ipv4.conf.all.shared_media = 1
net.ipv4.conf.all.src_valid_mark = 1
net.ipv4.conf.all.tag = 0

hfi@gropi:~ $ uname -a
Linux gropi 6.12.25+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.12.25-1+rpt1 (2025-04-30) aarch64 GNU/Linux 

hfi@gropi:~ $ whoami
hfi

hfi@gropi:~ $ echo $SHELL
/bin/bash