LAN-Verbindungsproblem bei Programmübertragung

Habe mich jetzt, als Neuling beim Programm über LAN aufspielen, rund 1 Tag durch die Netzwerk-Forenpunkte gelesen, aber leider keine Lösung gefunden, welche zu meinem Problem gepaßt hätte.

Meine Situation - LAN mit Thomson-TG789 (eingestellter Adressraum zur "freien Vergabe" 050 bis 100), Anschlüsse mit Kabel.

PC: 10.0.0.1 = fixe IP-Adresse / 255.255.255.0 = Subnetzmaske / 10.0.0.138 = Std-Gateway

LOGO 24CE (0BA8 - FS01, Firmware 1.82.01): 10.0.0.4 = IP-Adresse (gibt's sonst nicht mehr im LAN) / 255.255.255.0 = Subnetzmaske / 10.0.0.138 = Std-Gateway

Zusatz: Die IP 10.0.0.4 wurde deswegen gewählt, weil hier das Netzwerkkabel von einem funktionierenden "Sicherungs-PC" (mit dieser IP) abgezogen und an dieLogo angesteckt wurde.

LSC Vers. 8.2.0, als Admin gestartet (bereits beim PC als Admin angemeldet), Hardwaretyp "0BA8.Standard" ausgewählt, WIN 7.1 (32bit).

Situation:

1) Die Logo ist "leer" (neu), kein Programm drauf

2) Pings funktionieren, "PC -> Logo" und "Logo -> PC"

3) Alle Diagnostics, durchgeführt auf der Logo, sind positiv

4) Die LAN-LED leuchtet grün und blinkt manchmal gelb

5) Anwahl der Logo vom Firefox zeigt Webserver-Anmeldeseite (Sprachen lassen sich umstellen, jedoch versuchte Anmeldung endet mit der Meldung "Webserver ist deaktiviert".

PROBLEM: Jeder Versuch zum Verbindungsaufbau aus der LSC heraus endet jedoch mit der Meldung "Kein Zugriff auf das Remote-Gerät möglich", siehe Anhang nach Drücken von Knopf "Test".

PS: Das LAN mit dem Adressbereich "10.0.0" wurde nicht auf z.B. "192.168.0" umgestellt, denn damit müssten viele, vorhandene Geräte (PC's, Drucker, Plotter, Router) umgestellt werden, und das wäre bei vielen Geräten ein nicht zu unterschätzender Aufwand (z.B. bei Druckern nur über Neuinstallation möglich, etc.). Und ob das tatsächlich DIE Ursache sein sollte, wage ich nach o.a. Punkten 1) - 5) sowieso zu bezweifeln?

Vielen Dank für eventuelle Tipps im voraus.

Habe jetzt "spaßhalber" alles auf einem "alten" Toshiba-Notebook, ebenfalls WIN7.1, etc., installiert und dieses an's LAN angeschlossen. Und siehe da, es läuft alles.

Der einzige Einstellungsunterschied bei TCP/IP ist, dass beim "nicht funktionierenden" PC (DELL) ein "Virtual PC-Netzwerkfiltertreiber" mit aktiviert ist (da drauf ist noch ein Virtual XP-System). Der ist es aber auch nicht, denn testweise mal den deaktiviert, alles beim alten = Remote-Gerät weiter nicht erreichbar.

Es bliebe theoretisch also nur die Hardware der Netzwerkkarte und deren Treiber!?

Mit dieser Situation kann ich zwar im Moment leben, da aber der "Endausbau vor Ort" in einigen Monaten mit einem identen DELL-PC als Zugang erfolgen soll, und ich nicht weiß ob's nicht mit anderen Fabrikaten(?) ähnliche Probleme gibt, wäre ich für eventuelle Tipps betreffend Ursache trotzdem dankbar.

Das LAN-Kabel selbst ist ja nicht an einer IP-Adresse gebunden, physikalisch können auch mehrere Adressen gleichzeitig genutzt werden. Wenn am PC eine feste IP-Adresse vorgeben ist, kann man in den Eigenschaften weitere IP-Adressen mit eigener Subnet-Adresse eintragen, z.B. IP 192.168.0.250 Subnet 255.255.255.0 Gateway ist egal, dann kann man auf eine Logo8 mit Werkseinstellung IP 192.168.0.3 Subnet 255.255.255.0 zugreifen. Falls es an den Adressen liegen sollte, wäre das dann behoben.

Kürzlich hatte ich selbst das Problem, dass ich über Ping oder Webserver an die Logo kam, allerdings hatte ich eine andere Fehlermeldung beim Übertragungsversuch. Die Lösung fand ich im Forum, musste eine ältere Treiberversion für die LAN-Karte auswählen, dann funktionierte die Übertragung wieder.

M.f.G. Scorp

P.S. Nie nach Fehlern suchen, die zum Problem passen müssen. Letztendlich findet die Behebung an einer Stelle statt, die vorher über jeden Zweifel erhaben war. 

Vielen Dank für die Tipps.

@sneumann: Eine Firewall läuft auf dem Dell, die hat aber im Gegensatz zum Toshiba gar nicht reagiert.

@Scorp und ixo65: An den IP-Adressen liegt's sicher nicht, mit dem Toshiba funktionierts ja (und nur der hat logischerweise eine andere IP als der Dell).

Mir ist "heute" jedoch ein 2.ter (nachfolgend zum Firewall-Verhalten) Punkt aufgefallen:

Am Toshiba werden die lsc-Dateien mit dem Typ "LOGO!Soft Comfort Drawing" dargestellt, am Dell jedoch einfach als "LSC-Datei" (obwohl auch dort ein Doppelklick die Software startet und die Datei lädt).

Das wäre für mich ein Hinweis darauf, dass irgendetwas im Zug der Softwareinstallation daneben gegangen ist. Und das würde ja auch dem PS von Scorp entsprechen. D.h. ich werde in den nächsten Tagen am Dell mal alle LSC deinistallieren, die Registry säubern und die LSC 8.2 neu draufsetzen.

Berichte danach ob das was gebracht hat.

1) Firewall - schalte sie am Dell einfach mal ganz ab -  dann kannst sie ganz sicher ausschliessen, habe schon erlebt das die manchmal ganze heimlich still und leise Verbindungen verbieten und man manuell eine Ausnahme hinzufügen muss.  Ping und http sind davon normalerweise nicht betroffen weil eben normalerweise diese protokolle/ports immer erlaubt sind.

2) Falscher Dateityp: Ich zweifle daran Dateitypen interessieren normalerweise eh nur das Betriebssystem - Wenn ein Programm einen Dateityp öffnen kann, kann er normalerweise damit auch alle Funktionen des Programms damit ausführen.

3) Uninstall & Reinstall ist immer eine Möglichkeit :) Grad bei der LSC ist das ja kein Hexenwerk. Beim TIA würde ich es mir zweimal überlegen - unglaubliche bloatware.

Neuinstallation hat funktioniert.

- LSC deinstalliert (inkl. händischem Löscher alter Benutzereinträge, ..); Neustart

- Registry säubern (da gibt's einige Tools, welche sich gegenseitig ergänzen); Neustart

- LSC 8.2 neu installiert; Neustart

Und siehe da, es funktioniert problemlos.

PS: Ob die Neustarts alle notwendig waren weiß ich nicht, ist aber eine alte Angewohnheit aus früheren Windows-Zeiten.

PS @sneumann:

zu 1) ich habe 2 Benachrichtungsbenen am Win-Firewall (1 x die normale MS-Firewallmeldung plus einen "Aufsatz", welcher bei jeder neuen Verbindung - LAN + Netz - um Erlaubnis nachfragt). Zumindest der "Aufsatz" meldete sich bisher verlässlich. So auch bei der ersten Verbindungsaufnahme nach Neuinstallation.

zu 2) Der fehlende Dateityp war sicher nicht die Ursache des Verbingungsproblems, er war aber ein Hinweis, dass auch noch anderes bei der Installation daneben gegangen sein könnte. Was ja offensichtlich der Fall war.

Und nochmals vielen Dank für alle Tipps, auch wenn das PS von Scorp der Ausschlaggebende gewesen sein dürfte.