none
HttpWebRequest bekommt Timeout wenn über IP-Adresse RRS feed

  • Frage

  • Es hört sich zunächst alles etwas komplex an. Wir haben eine Software geschrieben (C#) in der wir per HttpWebRequest Daten von einem Server abfragen. Dies funktioniert an 4 Standorten hervorragend.

    An einem Standort bekommen wir ständig Verbindungsabbrüche zwischen den Clients und dem Server. Ich habe mit dem Hersteller der Serversoftware gesprochen und der meinte, es gäbe keine Fehler die auf dem Server zu sehen wären. Daher habe ich das Programm dann direkt auf dem Server installiert um Probleme mit Switch, etc. auszuschließen.

    Rufe ich im Programm nun per IP-Adresse (die eigene IPv4-Adresse) die Daten auf, bekomme ich die Fehler ebenfalls.

    Rufe ich im Programm nun aber über den Eintrag "localhost" die Daten auf, läuft alles fehlerfrei.

    Das bedeutet ja, dass der Fehler irgendwo in den Layern 1 bis 3 zu suchen sein müsste. Ansonsten haben wir aber eigentlich an dem Server keine Verbindungsprobleme irgendeiner anderen Art. Firewall ist testweise abgeschaltet worden, bringt aber keine Verbesserung. Antivirusprogramm ist genauso eingestellt wie an den anderen Servern und ich wollte das jetzt zum Testen nicht komplett deinstallieren (deaktivieren reicht ja meist nicht).

    Wir haben an dem Server 2 Netzwerkports (HP Ethernet 1Gb 2-port 332i Adapter). Nur an der ersten ist ein Kabel angeschlossen.

    Da hier auch Hyper-V läuft für zwei kleine Win7 Maschinen gibt es eine weitere Verbindung (LAN - Virtuelles Netzwerk) die den ersten Port "überschreibt". Sprich hier ist nur das "Protokoll für Microsoft virtueller Netzwerk-Switch" aktiv.

    Der virtuelle Netzwerkswitch führt dann zu folgendem Ergebnis:

    C:\Users\Administrator>ipconfig /all

    Windows-IP-Konfiguration

       Hostname  . . . . . . . . . . . . : DC-HER-HAU-248
       Primäres DNS-Suffix . . . . . . . : apo104
       Knotentyp . . . . . . . . . . . . : Hybrid
       IP-Routing aktiviert  . . . . . . : Nein
       WINS-Proxy aktiviert  . . . . . . : Nein
       DNS-Suffixsuchliste . . . . . . . : apo104
                                           apo101
                                           apo102
                                           aposoft
                                           apo201
                                           apo202
                                           apo302
                                           asa
                                           asa.xxx

    Ethernet-Adapter LAN-Verbindung 4:

       Verbindungsspezifisches DNS-Suffix:
       Beschreibung. . . . . . . . . . . : LAN - Virtuelles Netzwerk
       Physikalische Adresse . . . . . . : 94-57-A5-8F-E5-4C
       DHCP aktiviert. . . . . . . . . . : Nein
       Autokonfiguration aktiviert . . . : Ja
       IPv4-Adresse  . . . . . . . . . . : 192.168.100.1(Bevorzugt)
       Subnetzmaske  . . . . . . . . . . : 255.255.255.0
       Standardgateway . . . . . . . . . : 192.168.100.254
       DNS-Server  . . . . . . . . . . . : 192.168.100.1
       NetBIOS über TCP/IP . . . . . . . : Aktiviert

    Tunneladapter isatap.{589EDDA5-88D7-4A6C-BCFF-54EF9D2BA5FF}:

       Medienstatus. . . . . . . . . . . : Medium getrennt
       Verbindungsspezifisches DNS-Suffix:
       Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter #2
       Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP aktiviert. . . . . . . . . . : Nein
       Autokonfiguration aktiviert . . . : Ja

    Tunneladapter Teredo Tunneling Pseudo-Interface:

       Medienstatus. . . . . . . . . . . : Medium getrennt
       Verbindungsspezifisches DNS-Suffix:
       Beschreibung. . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
       Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP aktiviert. . . . . . . . . . : Nein
       Autokonfiguration aktiviert . . . : Ja

    Ich wüßte ehrlich gesagt langsam nicht mehr wo ich noch nach dem Fehler suchen sollte. Auch an den funktionierenden Servern haben wir Hyper-V im Einsatz und da haben wir auch keine Probleme oder besonderen Netzwerkkonfigurationen.

    Jemand eine Idee?

    Freitag, 17. November 2017 07:54

Antworten

  • > Rufe ich im Programm nun per IP-Adresse (die eigene IPv4-Adresse) die Daten auf, bekomme ich die Fehler ebenfalls.

    netsh trace start capture=yes tracefile=xyz.cap
    Programm starten, Fehler erzeugen/abwarten.
    netsh trace stop

    Dann xyz.cap in Netmon/Wireshark öffnen - was findest Du an Kommunikation? Und was ist "die Fehler" überhaupt?

    • Als Antwort markiert Marcel Gpunkt Montag, 27. November 2017 14:23
    Freitag, 17. November 2017 09:20

Alle Antworten

  • > Rufe ich im Programm nun per IP-Adresse (die eigene IPv4-Adresse) die Daten auf, bekomme ich die Fehler ebenfalls.

    netsh trace start capture=yes tracefile=xyz.cap
    Programm starten, Fehler erzeugen/abwarten.
    netsh trace stop

    Dann xyz.cap in Netmon/Wireshark öffnen - was findest Du an Kommunikation? Und was ist "die Fehler" überhaupt?

    • Als Antwort markiert Marcel Gpunkt Montag, 27. November 2017 14:23
    Freitag, 17. November 2017 09:20
  • Hm, ok, damit muss ich wohl bis nach Feierabend warten. Da ist zuviel Traffic auf der Leitung (ist ein Application-Server).

    Der Fehler lautet meist: "Die Verbindung wurde unerwartet geschlossen."

    Ab und zu aber auch, dass kein Stammelement vorhanden ist (die Antwort kommt im XML-Format) oder noch einige andere Fehlermeldungen. Diese deuten dann aber alle auf Timeouts des Request hin.

    Ich mache den Trace mal heute Abend oder Sonntag, wenn nicht mehr soviel auf Leitung liegt und melde mich dann nochmal.

    Freitag, 17. November 2017 12:06
  • Ok, habe herausgefunden woran es liegt.

    Es war nicht das Netzwerk und es war keine Einstellung am Server. Es war die Serverapplikation, diese hat den Port geschlossen, bzw. den Server dicht gemacht. Habe ein Ticket beim Softwarehersteller geöffnet. Aber trotzdem danke.

    Montag, 27. November 2017 14:23