Port nicht erzeugt

[TurboMagic]

Hallo,

eine Anwendung von mir ermöglicht es optional per DataSnap (das ist es glaube ich) eine externe Anwendung anzubinden.
Den zu benutzenden Port kann man konfigurieren.

Bei einem Kunden scheint es aber den Port nicht zu erzeugen, auch nicht, wenn ich eine andere Nummer wähle.
Netstat -p TCP zeigt beide getestete Ports nicht an. Andere von der Anwendung erzeugte (nicht DataSnap)
Ports zeigt Netstat als "Established" an, wie es sein soll.

Windows Firewall ist aus (alles rot in den EInstellungen), Firewall Service davon läuft aber noch und kann
ich nicht stoppen, obwohl der Kunde angeblich als Administrator angemeldet ist. Lt. Kunde nutzt er auch nur
die Windows Firewall.

Schaue ich mit ipconfig /all nach bekomme ich einen verbundenen Ethernet Adapter, einen nicht verbundenen
W-Lan Adapter, 2 VM Ware virtual Adapter und noch irgendwas das nicht verbunden ist.

Naja, nicht ganz einfach, da es ein spanisches Windows ist und ich kein Spanisch kann

Aber: was könnte sonst noch das Erzeugen eines Server Ports verhindern?

[Michael II]

Windows Firewall Log geprüft?
Hast du Zugriff auf den Code beim Listen-Schritt? Wird evt. der Socket an einen "falschen" Adapter gebunden?
Nebenbei: Wenn netstat viele Verbindungen anzeigt, dann übersieht man ab und zu einen Eintrag. netstat -aon | findstr /r :<portnummer> (also nicht nach Protokoll sondern Port filtern).

[himitsu]

Wenn nichts explizit vorgegeben ist, bindet es sich eigentlich an alle aktiven Adapter.

Das Problem kennen wir noch nicht.
Sollte der Port bereits belegt sein, dann gibt es im Programm normal eine Exception und der Server Service/Dienst raucht ab.


Ja, Firewall, Defender und Anderes läuft mit noch höheren Rechten ... die kann absichtlich normal nichtmal ein Admin abschießen.
Und bei einigen System-Diensten/-Prozessen wird auch noch Windows fast augenblicklich runtergefahren, falls man es doch mal schafft.

[Kas Ob.]

Hi,

Download ApiMonitor from http://www.rohitab.com/apimonitor (HTTP link as HTTPS usually and many times misconfigured at their part)

Only select API functions from (as shown in the screenshot )
Networking -> Windows Socket 2 -> ws2_32.dll
-> wsock32.dll

To be clear not all functions there are needed, you only need "bind" and "listen" and ("closesocket")
Also as i have no idea what DataSnap you referring to, but in some cases a "client" will use WinINet or WinHTTP, but these should not be your concern with opening ports, only if you found some missing API connections or more complex API calling like they are not coming form you application (the report will show the stack call for each API) as these client providers use the API internally and might be messing up your reports, or might no sense from first look.

After using these you should have a detailed error and response from bind and listen API call, like the socket handle is invalid as this means there was another API already destroyed the handle hence you need to expand on them or add CloseHandle to the report to track the handles.

[TurboMagic]

Interesting tools, some idea worth to investigate! Thanks!

[TurboMagic]

Hallo,

ich habe nun versucht eine Firewall Logaufzeichnung zu machen. Hat irgendwie nicht geklappt.
Aber eine Aufzeichnung mit dem interessanten API Monitor habe ich anfertigen können.
Ich habe dazu die ganze "Networking" Kategorie angekreuzt.

Angefügt habe ich zwei Screenshots. Diese zeigen alle bind Aufrufe, weil die nach
meinem Wissenstand die relevanten sind. Richtig?

Ok, es gibt noch einen Bind zu Port 3050, einer Firebird DB, der klappt aber.

Gerade der erste Screenshot zeigt den Bind für Port 1025, welches der Port ist, der bei
mir für die nicht funktionierende Funktionalität eingestellt ist und der lt. netstat -p TCP nicht
erzeugt wird.

Wenn ich das Log richtig interpretiere liefern diese bin Aufrufe aber 0 als Rückgabewert, was m.W.
"OK" bedeutet.

Nur was bedeutet das für mich?

[Kas Ob.]

Zitat von TurboMagic:

Angefügt habe ich zwei Screenshots. Diese zeigen alle bind Aufrufe, weil die nach
meinem Wissenstand die relevanten sind. Richtig?

bind is relevant of course, but i don't see successful or failed listen !
https://learn.microsoft.com/en-us/wi...insock2-listen

Zitat von TurboMagic:

Nur was bedeutet das für mich?

There is something bugging me in the second screenshot shot, you can see the bind call internally calling ntohs and return 82, while you mentioned port 1025 (which is showing in the first screenshot), is that a simple test, or there is something is missing here.

As i don't have your library of DataSnap to compare with working one, you should repeat the same API usage report between the failed one and successful, and see if there is something.
From what i see all the functions in both screenshots were OK, yet both do show that the opening port process was repeated, hinting there was a failure somewhere, yet there is no failed API per see !!

If i am to guess, your bug is completely have nothing to do with socket handling, it could be firewall or may be an event in a DataSnap class, in all cases you should have received an event or some error for that socket like an event triggered, (the one with success bind which is all of them, they all did bind yet repeated it on the same port), i don't see closesocket being called, try to catch the moment when your application decided to reopen the port, use logging for the relevant events.

[TurboMagic]

Hallo,

bevor ich anfange in meinem Anwendungsquellcode weiter nach dem Fehler zu suchen hier
noch ein Log Auszug mit dem Listen Aufruf. Sieht für mich erstmal ok aus. Rückgabewert
ist 0.

Oder sieht da jemand was verdächtiges?

[Kas Ob.]

Zitat von TurboMagic:

Hallo,

bevor ich anfange in meinem Anwendungsquellcode weiter nach dem Fehler zu suchen hier
noch ein Log Auszug mit dem Listen Aufruf. Sieht für mich erstmal ok aus. Rückgabewert
ist 0.

Oder sieht da jemand was verdächtiges?

Listen is success here in the screenshot, hence in TCPView listening status for the port should be visible just like netstat.exe, if there are not visible as open ports and listening then something is broken in the network interface, like there is broken virtual adapter for faulty VPN software.
Once the port have a listening status, firewalls will not close or hide it, they will just intercept the traffic and block them, traffic here does include the SYN for establishing the connection, in other words there should be listening ports.

Check the existed network adapters.

[TurboMagic]

Hallo,

ich komme jetzt endlich wieder zu weiteren Tests.
Ich habe in meinen DataSnap/Webbroker Code weitere Logmeldungen eingebaut und
mal beide Teile die einen Socket erzeugen können sollen getestet:

a) das Rest API um welches es eigentlich geht. Es erzeugt auch auf meinem PC
den eingestellten Port nicht, auch nicht wenn man einstellt, dass der ohne HTTPS
erzeugt werden soll.

b) eine einfache Statuswebseite, in keinem Fall auf Port 80.

Der Port 80 aus b) wird in meinem Fall erzeugt, der Port aus a) nie, sagt jedenfalls
netstat -p TCP auf einer Admin Konsole.
Nur komme ich auf Port 80 nicht mit dem Webbrowser drauf, egal ob ich HTTPS an oder aus habe.

Die Anwendung ist mit 10.3.3 erstellt und der Teil hatte schon mal funktioniert.
Als OpenSSL DLLs sind die libeay32.dll und ssleay32.dll im ANwendungsverzeichnis.
Beide in V1.0.2j. Ja, das sind nicht mehr die neuesten, sollten aber doch TLS 1.2 unterstützen.

Mir gehen gerade die Ideen aus.

Hier mal der zum Starten benutzte Code:

Delphi-Quellcode:

  if FMyServiceEnabled and (not FRESTServer.Active) then
  begin
    FRESTServer.Bindings.Clear;
    FRESTServer.DefaultPort := FMyServicePort;
    FRESTServer.Active      := True;

    log.Send(LevelBlue, cCategory, 'REST Server gestartet. Port: ' + FMyServicePort.ToString);
  end;

  if FStatusWebsite and (not FWebServer.Active) then
  begin
    FWebServer.Bindings.Clear;
    FWebServer.DefaultPort  := FStatusPort;
    FWebServer.Active       := True;

    log.Send(LevelBlue, cCategory, 'Web Server gestartet. Port: ' + FStatusPort.ToString);
  end;

FRestServer und FWebServer sind jeweils: TIdHTTPWebBrokerBridge