Network error reading channel

[dudax]

Guten Morgen,
wie in einem anderen Thread beschrieben, habe ich ein Verbindungsproblem mit dem Schachserver:
viewtopic.php?t=188154

Ohne die Verwendung von Timezeal ist die Verbindung stabil - mit Timezeal bricht die Verbindung nach kurzer Zeit mit der Fehlermeldung 'Network error reading channel' ab.

Lokale IP der VM - 192.168.178.39
Schachserver IP - 54.39.129.129
Server Port - 5000
Timeseal Port - 5001

Bei Verbindung:

Code: Alles auswählen

~# ss -nt dport = :5000
State            Recv-Q            Send-Q                          Local Address:Port                           Peer Address:Port            Process            
ESTAB            0                 0                              192.168.178.39:54700                         54.39.129.129:5000                              

Code: Alles auswählen

~# ss -nt dport = :5001
State            Recv-Q            Send-Q                          Local Address:Port                           Peer Address:Port            Process            
ESTAB            0                 0                              192.168.178.39:57232                         95.130.164.41:5001                               
ESTAB            0                 0                                   127.0.0.1:42127                             127.0.0.1:5001                               

Nach Verbindungsabbruch:

Code: Alles auswählen

~# ss -nt dport = :5000
State             Recv-Q             Send-Q                         Local Address:Port                         Peer Address:Port            Process             

Code: Alles auswählen

~# ss -nt dport = :5001
State                 Recv-Q            Send-Q                       Local Address:Port                         Peer Address:Port            Process            
CLOSE-WAIT            0                 0                                127.0.0.1:42127                           127.0.0.1:5001                               

Meine Netzwerkkenntnisse sind bestenfalls als Grundkenntnisse zu bezeichnen.
Für Tipps und Hinweise besten Dank im Voraus.

[mat6937]

... - mit Timezeal bricht die Verbindung nach kurzer Zeit mit der Fehlermeldung 'Network error reading channel' ab.

Lokale IP der VM - 192.168.178.39
Schachserver IP - 54.39.129.129
Server Port - 5000

Wie kurz ist die Zeit bis zum Abbruch?
Funktioniert nach dem Abbruch der Verbindung _mit Timezeal_, der Portscan:

Code: Alles auswählen

nc -zv 54.39.129.129 5000 5001
# oder
nping -c 3 --tcp --flags syn --delay 500ms -g 12345 -p 5000,5001 54.39.129.129
# oder
nping -c 3 --tcp --flags syn,ecn,cwr --delay 500ms -g 12346 -p 5000,5001 54.39.129.129

noch?

[dudax]

Wie kurz ist die Zeit bis zum Abbruch?
Funktioniert nach dem Abbruch der Verbindung _mit Timeseal_, der Portscan noch

Der Zeitraum ist unterschiedlich lang ca. 2 bis 5 Minuten.
Den Status von Timeseal kann ich bis zum Verbindungsabbruch in der Konsole des Programms prüfen - 'Timeseal 1 on' wird angezeigt.

Hier die Ausgabe nach Verbindungsabbruch:

Code: Alles auswählen

~# nc -zv 54.39.129.129 5000 5001
fics.freechess.org [54.39.129.129] 5000 (?) open
fics.freechess.org [54.39.129.129] 5001 (?) open

Code: Alles auswählen

~# nping -c 3 --tcp --flags syn --delay 500ms -g 12345 -p 5000,5001 54.39.129.129

Starting Nping 0.7.94SVN ( https://nmap.org/nping ) at 2023-11-01 08:49 CET
SENT (0.0235s) TCP 192.168.178.39:12345 > 54.39.129.129:5000 S ttl=64 id=62347 iplen=40  seq=2303202717 win=1480 
RCVD (0.1371s) TCP 54.39.129.129:5000 > 192.168.178.39:12345 SA ttl=49 id=0 iplen=44  seq=3203275249 win=64240 <mss 1452>
SENT (0.5241s) TCP 192.168.178.39:12345 > 54.39.129.129:5001 S ttl=64 id=62347 iplen=40  seq=2303202717 win=1480 
RCVD (0.6422s) TCP 54.39.129.129:5001 > 192.168.178.39:12345 SA ttl=52 id=0 iplen=44  seq=4260356874 win=64240 <mss 1452>
SENT (1.0252s) TCP 192.168.178.39:12345 > 54.39.129.129:5000 S ttl=64 id=62347 iplen=40  seq=2303202717 win=1480 
RCVD (1.1371s) TCP 54.39.129.129:5000 > 192.168.178.39:12345 SA ttl=49 id=0 iplen=44  seq=3218915166 win=64240 <mss 1460>
SENT (1.5279s) TCP 192.168.178.39:12345 > 54.39.129.129:5001 S ttl=64 id=62347 iplen=40  seq=2303202717 win=1480 
RCVD (1.6462s) TCP 54.39.129.129:5001 > 192.168.178.39:12345 SA ttl=52 id=0 iplen=44  seq=4276040564 win=64240 <mss 1460>
SENT (2.0281s) TCP 192.168.178.39:12345 > 54.39.129.129:5000 S ttl=64 id=62347 iplen=40  seq=2303202717 win=1480 
RCVD (2.1344s) TCP 54.39.129.129:5000 > 192.168.178.39:12345 SA ttl=49 id=0 iplen=44  seq=3234487390 win=64240 <mss 1460>
SENT (2.5292s) TCP 192.168.178.39:12345 > 54.39.129.129:5001 S ttl=64 id=62347 iplen=40  seq=2303202717 win=1480 
RCVD (2.6462s) TCP 54.39.129.129:5001 > 192.168.178.39:12345 SA ttl=52 id=0 iplen=44  seq=4291663130 win=64240 <mss 1460>
 
Max rtt: 118.165ms | Min rtt: 106.191ms | Avg rtt: 114.051ms
Raw packets sent: 6 (240B) | Rcvd: 6 (276B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 2.68 seconds

Code: Alles auswählen

~# nping -c 3 --tcp --flags syn,ecn,cwr --delay 500ms -g 12346 -p 5000,5001 54.39.129.129

Starting Nping 0.7.94SVN ( https://nmap.org/nping ) at 2023-11-01 08:49 CET
SENT (0.0262s) TCP 192.168.178.39:12346 > 54.39.129.129:5000 SEC ttl=64 id=43161 iplen=40  seq=4282311345 win=1480 
RCVD (0.1374s) TCP 54.39.129.129:5000 > 192.168.178.39:12346 SAE ttl=49 id=0 iplen=44  seq=1128548917 win=64240 <mss 1452>
SENT (0.5263s) TCP 192.168.178.39:12346 > 54.39.129.129:5000 SEC ttl=64 id=43161 iplen=40  seq=4282311345 win=1480 
RCVD (0.6364s) TCP 54.39.129.129:5000 > 192.168.178.39:12346 SAE ttl=49 id=0 iplen=44  seq=1136361456 win=64240 <mss 1460>
SENT (1.0272s) TCP 192.168.178.39:12346 > 54.39.129.129:5000 SEC ttl=64 id=43161 iplen=40  seq=4282311345 win=1480 
RCVD (1.1374s) TCP 54.39.129.129:5000 > 192.168.178.39:12346 SAE ttl=49 id=0 iplen=44  seq=1144188904 win=64240 <mss 1460>
SENT (1.5282s) TCP 192.168.178.39:12346 > 54.39.129.129:5001 SEC ttl=64 id=43161 iplen=40  seq=4282311345 win=1480 
RCVD (1.6429s) TCP 54.39.129.129:5001 > 192.168.178.39:12346 SAE ttl=49 id=0 iplen=44  seq=3272296212 win=64240 <mss 1452>
SENT (2.0297s) TCP 192.168.178.39:12346 > 54.39.129.129:5000 SEC ttl=64 id=43161 iplen=40  seq=4282311345 win=1480 
RCVD (2.1400s) TCP 54.39.129.129:5000 > 192.168.178.39:12346 SAE ttl=49 id=0 iplen=44  seq=1159852689 win=64240 <mss 1460>
SENT (2.5307s) TCP 192.168.178.39:12346 > 54.39.129.129:5001 SEC ttl=64 id=43161 iplen=40  seq=4282311345 win=1480 
RCVD (2.6453s) TCP 54.39.129.129:5001 > 192.168.178.39:12346 SAE ttl=49 id=0 iplen=44  seq=3287960317 win=64240 <mss 1460>
 
Max rtt: 610.154ms | Min rtt: 110.190ms | Avg rtt: 195.157ms
Raw packets sent: 6 (240B) | Rcvd: 6 (276B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 2.68 seconds

[dudax]

Lokale IP der VM - 192.168.178.39
Schachserver IP - 54.39.129.129
Server Port - 5000
Timeseal Port - 5001

Bei Verbindung:

Code: Alles auswählen

~# ss -nt dport = :5001
State            Recv-Q            Send-Q                          Local Address:Port                           Peer Address:Port            Process            
ESTAB            0                 0                              192.168.178.39:57232                         95.130.164.41:5001                               
ESTAB            0                 0                                   127.0.0.1:42127                             127.0.0.1:5001                               

Mal laut gedacht ... das hier als Peer Adress:Port 95.130.164.41:5001 ausgegeben wird, ist okay?
Die IP 95.130.164.41 wird sonst nirgends angezeigt.

[dudax]

Hier mal die Mail vom FICS Support (USA):

Connections to FICS are via port 5000 or port 23. That is true whether you
are using timeseal or not. So, make sure you are trying to connect to port
5000. If that does not work, try port 23.

If you still have problems connecting, write back, and tell us your handle
and your IP address.

Wenn ich Timeseal auf Port 23 einstelle, sofortiger Verbindungsabbruch.
Timeseal auf Port 5000, nach kurzer Zeit Verbindungsabbruch <1 Minute.

Und wenn ich dem Support meine IP mitteilen würde, macht doch wohl wenig Sinn. Ich habe ja keine feste IP. Das mag in USA wohl anders sein.

[dudax]

Ich bin dabei die Ursache des Problems einzukreisen.
Nun habe ich das Schachprogramm auf einem Debian Rechner installiert. Das Schachprogramm läuft mit Timeseal seit über einer Stunde stabil. Der Rechner ist über LAN mit dem Router verbunden.

Offensichtlich haben die Verbindungsabbrüche ihre Ursache in der VM oder dem WLAN.

[dudax]

Nachdem ich nun ein langes LAN Kabel besorgt habe, konnte ich feststellen, das Schachprogramm und Timeseal funktionieren in der VM fehlerfrei. Die Verbindung mit Timeseal und dem Schach-Server ist stabil.

Die Ursache für das Problem ist also eindeutig in der WLAN Verbindung zu suchen.
Wenngleich ich es nicht verstehe, denn die betreffenden Ports sind offen, die Ping-Werte offensichtlich gut.

[mat6937]

Die Ursache für das Problem ist also eindeutig in der WLAN Verbindung zu suchen.

Dann teste mal wie stabil die Wlan-Verbindung ist, mit z. B.:

Code: Alles auswählen

tcpdump -vvveni <wlan-Interface> ether proto 0x888e

Wenn damit nichts zu erkennen ist, kannst Du auch mit wpa_cli und einem "action file", die Zustände "connected" und "disconnected" des wpa_supplicant, überwachen. Siehe die manpage für wpa_cli.

[dudax]

Die Ursache für das Problem ist also eindeutig in der WLAN Verbindung zu suchen.

Dann teste mal wie stabil die Wlan-Verbindung ist ...

Der Netzwerkadapter der VM ist als Bridge-Netzwerk mit automatischer Erkennung eingerichtet.
Die Diagnose muss also auf dem Host-System (macOS) erfolgen.
Kann ich nachher mal machen. Bin mir jedoch ziemlich sicher, die WLAN-Verbindung ist stabil.
Mal laut gedacht, kann der Fehler auch an der Schnittstelle liegen?

[mat6937]

Mal laut gedacht, kann der Fehler auch an der Schnittstelle liegen?

Ja, das kann er.
Gibt es evtl. Möglichkeiten, die Schnittstelle zu optimieren bzw. ist es eine andere "Schnittstelle", wenn statt der Wlan-Verbindung eine Kabelverbindung benutzt wird? Wenn ja, was ist der Unterschied?

[dudax]

Mal laut gedacht, kann der Fehler auch an der Schnittstelle liegen?

Ja, das kann er.
Gibt es evtl. Möglichkeiten, die Schnittstelle zu optimieren bzw. ist es eine andere "Schnittstelle", wenn statt der Wlan-Verbindung eine Kabelverbindung benutzt wird? Wenn ja, was ist der Unterschied?

Ich kann da nichts groß optimieren. Folgende Einstellungen kann ich wählen:





Ich habe die Einstellung NAT und Host-Only mal getestet. Bei beiden Einstellungen Verbindungsabbruch nach < 1 Minute.

Hier die Ausgabe von tcpdump in macOS:

Code: Alles auswählen

 % sudo tcpdump -vvveni en1 ether proto 0x888e
...
tcpdump: listening on en1, link-type EN10MB (Ethernet), snapshot length 524288 bytes
^C
0 packets captured
157 packets received by filter
0 packets dropped by kernel

Wenn damit nichts zu erkennen ist, kannst Du auch mit wpa_cli und einem "action file", die Zustände "connected" und "disconnected" des wpa_supplicant, überwachen.

Das Tool ist in macOS standardmäßig nicht enthalten.