TCP-Handshake in i-Telex "kaputt"

[ProgBernie]

Wenn beim Beenden einer TCP-Verbindung ein FIN gesendet wird, warum ist dann der dämliche DOTNET TCP-Stack nicht in der Lage, mich über die Beendigung der Verbindung zu informieren? Es gibt keinen Event, wenn die Gegenseite die Verbindung schließt.

Normalerweise[TM] bekommt man beim read() auf einen socket ein EOF, wenn dieser (von der Gegenstelle) geschlossen wird. Macht Bill Dot.Net das nicht so?

Diese .net-Bibliotheken sind aber auch großer Mist, ich erinnere mich an eine längere Fehlersuche in dem blöden .net-Basic-Programm was ich geerbt habe. Ein data provider lieferte auf eine query in der Weiterverarbeitung unerklärliche Fehler der Art "ist keine Instanz vom Typ x". Längeres Suchen und haufenweise logs brachten mich dann zu der Erkenntnis, daß an dieser Stelle der Microsoft data provider in manchen Situationen:
- keine (erwartete) DataRow zurückliefert
- nicht "DbNull" zurückliefert
- nicht "Nothing" zurückliefert
- keine Exception wirft
sondern eine Instanz vom Typ Exception als Rückgabewert zurückgibt! WTF?

[BjoernS]

Wenn beim Beenden einer TCP-Verbindung ein FIN gesendet wird, warum ist dann der dämliche DOTNET TCP-Stack nicht in der Lage, mich über die Beendigung der Verbindung zu informieren? Es gibt keinen Event, wenn die Gegenseite die Verbindung schließt.

Nach dem, was ich bisher so gelesen habe, ist das wieder mal ein Fall von „Feature statt Bug“, im Feld er Unixartigen verhält sich das API-technisch nicht anders. Eigentlich besteht eine TCP-Verbindung aus zwei Verbindungen, eine pro Richtung, die unabhängig voneinander geschlossen werden können. Wenn z.B. ein Client seine Anfrage an den Server komplett übermittelt hat, kann er schon schließen, während der Server den Rückkanal erst schließt, wenn er die Antwort in Ruhe übertragen hat.

Dem Entwurf der Eltern von TCP nach ist es scheinbar so gedacht, dass ich beim Kanal von fern zu mir aktiv lesen muss, wenn ich mich für Daten von dort interessiere. Wenn ich nicht lese, ist mir der Zustand egal

Jeden weiteren Komfort muss die nächsthöhere Schicht übernehmen.

Habe mal interessehalber mal ein bisschen gelesen, wie das in der MS-Welt so abläuft, vielleicht hilft dir das.

(Lustig wird es, zumindest im TCP/IP-Stack von Linux, wenn sich bei mir als Server jemand verbinden will, er aber bevor ich angenommen habe schon wieder schließt ... den Fall habe ich beim Testen schon unabsichtlich provoziert, den muss man auch abfangen, sonst schmiert ggf. der Programmteil ab.)

Grüße


Björn

[ProgBernie]

Nach dem, was ich bisher so gelesen habe, ist das wieder mal ein Fall von „Feature statt Bug“, im Feld er Unixartigen verhält sich das API-technisch nicht anders.

So wirklich anders scheint es auch nicht zu sein. Von https://docs.microsoft.com/de-de/dotnet ... cketFlags_

"Wenn Sie einen Verbindungs orientierten Socket verwenden, liest die Receive-Methode so viele Daten wie verfügbar, bis zu der Anzahl der Bytes, die durch den size-Parameter angegeben werden. Wenn der Remote Host die Socket Verbindung mit der Shutdown-Methode herunterfährt und alle verfügbaren Daten empfangen wurden, wird die Receive-Methode sofort abgeschlossen und gibt NULL Bytes zurück."

Hier gibt es also nicht wie bei Uinx die Rückgabewerte -1, 0 und >0 für EOF, nix da und Daten empfangen. Die 0 für nix da wird über eine Exception abgebildet.

Dem Entwurf der Eltern von TCP nach ist es scheinbar so gedacht, dass ich beim Kanal von fern zu mir aktiv lesen muss, wenn ich mich für Daten von dort interessiere. Wenn ich nicht lese, ist mir der Zustand egal

So ist es. Sockets arbeiten mit 2 streams und streams können Daten jeweils nur in eine Richtung transportieren. So ergibt sich der "halb-geschlossene" Zustand des sockets wenn einer der streams geschlossen wird. Der wird auch tatsächlich benutzt, z.B. sendet Firefox in einer connection den GET-Request für favicon.ico als letztes und schliesst dabei seine Richtung. Der Server weiß daher bereits daß keine weiteren Anfragen mehr kommen können. Er kann aber ohne Probleme noch megabyteweise Daten senden.

[ProgBernie]

Ich wollte mal ein Statusupdate zu meiner Karte geben:

Code: Alles auswählen

SystemStartZeit = 16.07.2020 16:15:45, ResetFlag = 05

Das ist der Zeitpunkt als ich die Karte nach Abschluß der Pentests wieder ins Rack gesetzt habe.