BCM Master kommunizieren mit Slaves immer über das Port:3543. Innerhalb eines Netzwerkes muss ein Nachweis über die Funktion eigentlich nie geführt werden. Es funktioniert einfach.
Anders ist die Sachlage dann, wenn der Slave in einem entfernten Netzwerk erreicht werden muss. Hierzu muss der Router im entfernten Netzwerk korrekt konfiguriert worden sein. Wie kann das nachgewiesen werden, wenn auf diesem Port kein WebInterface mit einem Browser aufgerufen werden kann ?

Funktionalität
Der Router in entfernten Netzwerk muss eine Weiterleitung aktiviert haben, die bei Zugriffen auf die externe (öffentliche) IP-Adresse des Routers, das Port:3543 auf intern Port:3543 + IP Adresse des lokalen Master weiterleitet. Ein lokaler Master existiert immer dann, wenn mehr als eine Zentrale in der entfernten Anlage "enthalten" ist. Prüfung
Wie aus der Darstellung zu erkennen ist, gibt es zwei Weiterleitungen:

• Port:10000 --> Port:80 kann mit dem Browser getestet werden, weil hier ein Web Interface antwortet.
  Port:3543 --> Port:3543 kann mit dem Browser nicht getestet werden. Auch ein PING auf extIP:3543 bringt keine Aussage !

Man muss das TelNet Protokoll bemühen um eine korrekte Aussage machen zu können. Ein kleines, kostenloses Werkzeug das diesen Zugriff sehr einfach realisiert ist PuTTY. Hier die portable Version, die ohne Installation auch von USB Stick aus läuft!

In diesem kleinen Video zeige ich den Anwendung. Video, weil es einfacher zu dokumentieren geht...

Seiteneffekte
Sollte der Test aus einem Firmennetzwerk heraus vorgenommen werden, so kann es sein das der Zugriff über das Port:3543 aus dem Firmennetzwerk heraus schon gesperrt ist. Also erst diesen Umstand prüfen, bevor wo anders Fehler zugewiesen werden !

Andere Konfiguration
(keine)


Schlagworte:
Thema: {xFileDownload} {xVideoTutorial} {xTool}
Projektschritt: {xProgrammierung} {xBetrieb}
Artikel Zentralen: xGRµZENP

Böse Falle !
Leider musste ich heute schmerzhaft lernen. Der Nachweis das man mit dem Programm PuTTY (Protokoll=TELNET) vom lokalen Computer aus auf den entfernten SLAVE zugreifen kann, stellt noch nicht sicher dass auch der MASTER aus diesem Netzwerk auf den SLAVE zugreifen kann ! Warum ?
Weil der Computer von dem der Test aus gelaufen ist, in der Regel über DHCP automatisch die korrekte IP Adresse des DNS Servers bezieht und so PuTTY auch die dynDNS auflösen kann. Das kann der Master mit falscher DNS IP Adresse nicht und der meckert auch nicht wenn eine funktionslose IP Adresse eingetragen ist (leider).
Die Grafik zeigt die Situation und welche potentiellen Fehlerursachen durch ein postives Testergebnis ausgeschlossen werden.

Abhilfe:
Also in diesem Fall auf dem Computer mit dem Befehl ipconfig /all im WINDOWS cmd Fenster die IP Adresse des DNS ermitteln. Wird mit aufgelistet und dann über das WebInterface der Zentrale korrigieren.


Schlagworte:
LinkedTo: {xGRLink} {xDocVar_NO} {xDocPS4_NO} {xDocPS5_NO}
Thema: {xFehlerbild} {xVideoTutorial}
Projektschritt: {xGRPrjSt} {xProgrammierung xPS4} {xBetrieb xPS5}
Artikel Zentralen: {xGRµZENP}

Warum es dennoch nicht funktioniert
Wenn in der betroffenen Slave Zentrale die Option gesetzt ist, welche diese Zentral zu einem MASTER macht, dann kann der ECHTE MASTER nicht auf diese Zentrale als SLAVE zu greifen. Die betroffene Option ist hier unter "[ ] Zentrale als Master aktivieren" zu finden: Die Option darf beim SLAVE logischerweise nicht aktiviert sein ! Eine Prüfung setzt voraus, dass man auf das WebInterface des SLAVE, über dessen eigene IP Adresse zugreifen kann.

PuTTY Test teilweise erfolgreich
Eine weitere Verfeinerung der Problemlage ergibt sich dann, wenn der PuTTY Test zum Teil erfolgreich ausgeführt werden kann. Im Bild ist ein Laptop mit PuTTY (A) bezeichnet und dessen externer Test auf den Slave kann erfolgreich ausgeführt werden. Dennoch kann sich der MASTER nicht mit dem Slave verbinden.

Der mit PuTTY (B) bezeichnete Laptop muss ebenfalls einen erfolgreichen Test ausführen können erst dann kann auch der MASTER den Slave erreichen. Im Rahmen der Fehlersuche reicht es leider nicht das der MASTER ins Internet greifen kann um z.B. Freischaltecodes zu aktivieren.

Wenn der mit PuTTY (B) bezeichnete Laptop sich selbst erfolgreich ins Internet verbinden kann (Zugriff auf z.B. Google) reicht das auch noch nicht den Fehler einzugrenzen. Als Ursache für den nicht erfolgreichen PuTTY (B) Test muss man dann noch die Firewall überprüfen und klären ob eventuell das Port :3543 für abgehende Verbindungen gesperrt ist.