TCP-Handshake in i-Telex "kaputt"
Verfasst: Do 16. Jul 2020, 08:29
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.
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.