TCP-Handshake in i-Telex "kaputt"

[ProgBernie]

Moin,

nachdem ich den Bufferoverflow in i-Telex offenbar gefunden und behoben habe, will ich mir die defekte Implementierung des TCP-Handshakes beim Verbindungsabbau ansehen. Der Fehler tritt nur dann auf, wenn i-Telex die Verbindung schliesst, nicht im umgekehrten Fall.
Das ist auch der Grund warum die Webseiten der Karte so lahm sind, hier kommen nach meiner Analyse 2 Themen zusammen:

1. Der "Webserver" sendet "connection: close" im HTTP-Header mit, damit wird angezeigt daß nach diesem Element die Verbindung geschlossen wird und nicht über den gleichen socket weitere Daten ausgetauscht werden.
2. Der Webserver beendet dann nach Auslieferung eines Elementes die Verbindung durch senden von "FIN, ACK" (schliessen des sockets). Der Browser bestätigt mit ACK, beendet seinerseits die Verbindung durch schliesssen seines sockets und sendet damit seinerseits FIN, ACK, was der IP-Stack im i-Telex mit ACK zu bestätigen hat. Diese Bestätigung fehlt, sodaß clientseitig mehrere Retransmissions erfolgen bis der IP-Stack im i-Telex offenbar aufgibt und mit RST die Verbindung zwangsweise trennt.

Am ersten Punkt kann man nichts drehen, die Struktur ist mit Sicherheit nicht darauf ausgelegt, die Verbindung für mehrere Requests zu halten. Die Verzögerung dadurch ist wegen der relativ geringen Anzahl an Elementen auf den ausgelieferten Webseiten eher gering.
Der zweite Punkt führt zu langen Wartezeiten beim Aufbau der Seiten, denn es handelt sich hier um Zeiten im Bereich 15s. Gemessen dauert der Aufruf der Sartseite bis alles sich wieder beruhigt hat 25s, davon ist nur ein Teil am Browser für den Benutzer sichtbar, der Rest erfolgt im Hintergrund, blockiert aber Ressourcen.

Das gleiche tritt bei telnet auf und vermutlich auch beim i-Telex-Protokoll auf Port 134.

[FredSonnenrein]

Über dieses Problem bin ich bereits vor 8 Jahren gestolpert und habe mit extrem begrenztem Wissen (vorsichtig ausgedrückt) buxfixes versucht.
Die meisten davon sind mit // HACK Son gekennzeichnet. Möglicherweise habe ich manches verschlimmbessert.

An den Leser des Quellcodes von net/tcp.c und .h:
Das "OverflowTest" diente auch mal zum Erkennen von Puffer-Overflow...

[ProgBernie]

Ich habe den bereits im chat von mir verdächtigten Teil jetzt mal probeweise eingebaut, das scheint sehr gut zu funktionieren. Jedenfalls kann ich jetzt viel weniger Protokollungereimtheiten ausmachen, das scheint die richtige Richtung zu sein. Auch sind die Seiten jetzt schneller abgerufen (wo vorher oft noch die Uhr drehte).

Auch hierfür meinen patch:

Code: Alles auswählen

diff --git a/system/net/tcp.c b/system/net/tcp.c
index 90f3309..2438603 100644
--- a/system/net/tcp.c
+++ b/system/net/tcp.c
@@ -33,6 +33,7 @@
 ///         (z.B. bei Abfrage von checkip.dyndns.com) noch auslesbar sind.
 /// \date	12-11-2012: Fred Sonnenrein: GetSocketData liefert vernünftigen Rückgabewert, wenn mehr Daten im Fifo als
 ///         im Puffer Platz sind.
+/// \date	15-07-2020: Bernd Laengerich: Korrektur TCP-Handshake Verbindungsabbau
 //****************************************************************************/
 /*
  *  This program is free software; you can redistribute it and/or modify
@@ -362,6 +363,15 @@ void tcp( int packet_lenght, char * ethernetbuffer)
 
 		if ( TCP_packet->TCP_ControllFlags == ( TCP_FIN_FLAG | TCP_ACK_FLAG) )
 		{
+			// 20201016 BLH fix missing ACK?
+			if ( TCP_sockettable[ socket ].ConnectionState == SOCKET_WAIT2FIN )
+			{
+				TCP_sockettable[ socket ].AcknowledgeNumber = ntohl ( TCP_packet->TCP_SequenceNumber ) + 1;
+				MakeTCPheader( socket, TCP_ACK_FLAG, 0 , ( MAX_RECIVEBUFFER_LENGHT - Get_Bytes_in_FIFO ( TCP_sockettable[ socket ].fifo ) ) , ethernetbuffer );
+				TCP_sockettable[ socket ].Timeoutcounter = 0 ;
+				TCP_sockettable[ socket ].ConnectionState = SOCKET_NOT_USE ;
+			}
+			// 20201016 BLH fix missing ACK?
 			if ( TCP_sockettable[ socket ].ConnectionState == SOCKET_WAIT2FINACK )
 			{
 				TCP_sockettable[ socket ].AcknowledgeNumber = ntohl ( TCP_packet->TCP_SequenceNumber ) + 1;

Das ganze sollte noch beobachtet werden, alle Browser und IP stacks verhalten sich leicht unterschiedlich und je nach Netzwerk kommen da auch noch unterschiedliche Zeiten hinzu, die ebenfalls verschiedenes Verhalten bewirken können.

Ich habe mich im code an den copy&paste-Stil gehalten, da sehr viele Teile exakt identisch sind und manchmal nur einzelne Zeilen unterschiedlich, könnte man den ganzen codeabschnitt deutlich kompakter schreiben, wenn man wenige Verzweigungen zulassen würde. Allerdings könnte der flache code um wenige Mikrosekunden schneller sein...

[FredSonnenrein]

Ich habe Bernds Zuarbeit mal eingepflegt, wer mag kann sich die aktuelle Hex hier ziehen und auch mit Testen...

https://svn.code.sf.net/p/itelex/code-0/trunk/main.hex

[ProgBernie]

Fred,

hast Du die Version auch im Test? Kannst Du bzgl. der Webseiten etwas dazu sagen?

[FredSonnenrein]

Ja, ich habe den Eindruck dass der Seitenaufbau jetzt "flüssiger" ist.

[ProgBernie]

Ok, zumindest keine Verschlechterung. Ich fürchte es gibt nicht viele weitere Tester die etwas dazu beitragen.

[FredSonnenrein]

Ok, zumindest keine Verschlechterung. Ich fürchte es gibt nicht viele weitere Tester die etwas dazu beitragen.

Wahrscheinlich weil kaum jemand diese technischen Details nachvollziehen möchte. Ich möchte auch zunächst in begrenzen Kreis testen, bevor ich bei solchen "tiefgehenden" Änderungen ins breite Feld streue.

[detlef]

Ok, zumindest keine Verschlechterung. Ich fürchte es gibt nicht viele weitere Tester die etwas dazu beitragen.

Ich würde schon gerne mittesten, habe es aber zeitlich noch nicht geschaft, meine Ethernetkarten zu aktualisieren.

[detlef]

Ich habe jetzt mal eine Ethernetkarte mit der Testversion aktualisiert.
Kann es sein, dass das Verbindungsende ein Problem macht?

Ich kann jetzt nur mit WinTlx testen, weil ich gerade nur eine TW39-Karte habe, aber wenn ich da einen Disconnect mache, bleibt der Fernschreiber an. Er scheint nicht mitzubekommen, dass die Verbindung beendet wurde.

Mit der Version 837 der anderen Ethernetkarte, geht der Fernschreiber sofort aus, wenn ich einen Disconnect mache.