BK9100 Blinkcode 6x / 2x beim Booten mit aktiver LAN-Verbindung - angeblicher IP-Konflikt

sbzt

Level-2
Beiträge
16
Reaktionspunkte
1
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

ich versuche gerade, einen betagteren BK9100 in eine bestehende Anlage einzubinden. Dabei bin ich auf ein Problem gestoßen, das ich so in der Form bei den bisher von mir verbauten BK9100 (garantiert eine höhere zweistellige Zahl) noch nie hatte.

Beim Starten mit aktiver Ethernet-Verbindung erhalte ich einen I/O-Error über die LED. Erst ein "wildes" Blinken (Impulse kaum zählbar, aber ich glaube, das dient nur zur generellen Fehlersignalisierung?), dann 6x und dann 2x. Wenn ich die Tabelle hier richtig interpretiere (die 2x sind dann wohl das "Fehlerargument"?) meckert er mutmaßlich "IP-Adresse bereits im Netzwerk vorhanden", wobei die Tabelle da an der Stelle irgendwie verdammt unübersichtlich ist.

Aber das würde einigermaßen zum Fehlerbild passen.
Tatsache ist nämlich, dass das nur passiert, wenn das Netzwerk beim Booten schon steckt.



Interessante Fakten:

Ja, die gewünschte IP-Adresse (Digits 1-3 per KS2000 konfiguriert, viertes per DIP-Schalter) ist natürlich frei. Erwartungsgemäß antwortet mir kein anderes Gerät auf einen Ping.

Steckt man den BK nach dem Booten ans Netzwerk, taucht der Fehler nicht auf und er lässt sich völlig problemlos ansprechen (Gegencheck: Ja, dann erhalte auch eine Ping-Antwort - falls die Frage auftaucht, ob ich vielleicht einfach generell keine Antworten bekomme und womöglich doch ein Teilnehmer mit der IP im Netz ist).
Kommunikation mit der KS2000 läuft dann völlig problemlos.

Tatsächlich taucht das Problem aber nur auf, wenn er Zugriff auf die bauseitige Infrastruktur hat. Wenn ich ihn einfach nur mit einem autarken Switch verbinde und den dann mit nichts anderem, passiert es nicht. Wenn dieser Switch dann wiederum am bauseitigen Netzwerk steckt, schon (also keine skurrile Chipsatz-Inkompatibilität zwischen dem BK und dem ZTE-Switch im Serverschrank).

Der BK läuft aktuell noch völlig "frei" und ist in kein TC-Projekt eingebunden, das nach dem Bootvorgang unmittelbar auf ihn zugreifen wollen würde.

Auf eine andere, ebenfalls freie IP zu wechseln, bringt ebenfalls nichts.

Ein weiterer BK aus vermutlich der gleichen Charge, den ich dann stattdessen testweise eingebaut habe, hat exakt das gleiche Problem.

Ich muss demnächst mal den schon länger verbauten (aber trotzdem tendentiell neueren) BK9100 resetten, der schon länger aktiv in die Anlage eingebunden ist und schauen, was der macht.


Hat jemand eine zündende Idee? Gestern war es dann schon wieder Richtung 20 Uhr und ich habe beschlossen, das Ganze zu vertagen. Der nächste Step wäre jetzt mal, mich mit einem Network-Tap dazwischenzuklemmen und mal zu schauen, was der BK beim Booten so alles wissen will und wer ihm da was vermeintlich antwortet...
 
Zuletzt bearbeitet:
Könnte sein, dass ein Device mit der IP im Netz ist, aber ping blockiert. Ist bei den meisten Servern zum Beispiel Standard.

Wenn es autark läuft, muss da ja was sein 🤔.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Foto habe ich gerade keins, die DIPs stehen der gewünschten Adresse 192.168.192.134 entsprechend (2, 3, 8 ON, sonst nichts).

Das entsprechende VLAN in dem sich die SPS-Technik befindet "gehört sozusagen mir" und wurde letztes Jahr nach meinen Vorgaben eingerichtet. Der DHCP kann nicht reinspucken, dieser vergibt nur bis .127.

Ich weiß hard- und softwaretechnisch genaustens über dies Netz Bescheid. Es gibt eine einzige weitere Person, der an den Switches etwas anfassen darf (und mich davon in Kenntnis setzt).

Der IP-Scan mit NirSoft WirelessNetworkWatcher (Übrigens eine wahnsinns Softwareschmiede! Der hat unendlich viele praktische Tools...) fördert genau die Teilnehmer zutage, die ich im Netzwerk erwarten würde.

Vorn dran hängt halt eine zentrale Sonicwall, weil es eine an eine Behörde angegliederte Versammlungsstätte ist, "mein" VLAN wird darüber verwaltet und diese stellt auch den DHCP-Server und Internetzugang bereit. Ich hab gerade die Befürchtung, dass die irgendwas seltsames zurückschickt, wenn der BK eine wie auch immer geartete Abfrage auf diese Adresse schickt und die ja nicht belegt ist. Wobei ich im BK die Firewall nicht als Gateway eingetragen habe (nur auf den Fehler hin mal probehalber - ändert aber nichts).

Nmap kann ich mal testen, habe ich noch nicht genutzt. Gehen damit umfangreichere Tests als mit dem o.g. Tool, Advanced IP Scanner, dem Scanner von NetSetMan etc.?
 
Vorn dran hängt halt eine zentrale Sonicwall, weil es eine an eine Behörde angegliederte Versammlungsstätte ist, "mein" VLAN wird darüber verwaltet und diese stellt auch den DHCP-Server und Internetzugang bereit. Ich hab gerade die Befürchtung, dass die irgendwas seltsames zurückschickt, wenn der BK eine wie auch immer geartete Abfrage auf diese Adresse schickt und die ja nicht belegt ist. Wobei ich im BK die Firewall nicht als Gateway eingetragen habe (nur auf den Fehler hin mal probehalber - ändert aber nichts).

Nmap kann ich mal testen, habe ich noch nicht genutzt. Gehen damit umfangreichere Tests als mit dem o.g. Tool, Advanced IP Scanner, dem Scanner von NetSetMan etc.?
Also DHCP hat nichts mit nem Gateway zu tun. Befindet sich im Netzwerksegment ein DHCP-Server, dann antwortet er auch. Wenn es ein "vernünftiger" DHCP-Server ist, dann kannst du bestimmte MAC-Adressen sperren. Andere Möglichkeit sind auch Sperren in der Firewall oder ACLs im Switch.

Zu Nmap gibt's auch Zenmap als grafische Oberfläche.
Da du ja mit VLAN arbeitest, hat der Switch bestimmt auch die Möglichkeit nen Mirrorport zu aktivieren. Da kannst du mit Wireshark mal den Datenverkehr zu deinem Controller anzuschauen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Also Nmap hat wie erwartet keine Auffälligkeiten ergeben. Auf der entsprechenden IP antwortet mir der (nach dem Booten erst ans Netzwerk angeschlossene und dann einwandfrei funktionierende) Buskoppler. Die unmittelbar folgende, ebenfalls getestete und ebenfalls vom BK "abgelehnte" IP liefert wie erwartet keinerlei Antwort an Nmap, egal mit welcher Scanmethode.

Das mit dem DHCP und Gateway war anders gemeint, das sind natürlich zwei paar Stiefel. Es käme ja die Möglichkeit in Betracht, dass die IP irgendwie schon per DHCP-Server vergeben worden wäre. Die gewünschte IP liegt aber außerhalb der DHCP-Range, da kann sich also schon mal gar nichts in die Quere kommen.

Dann hatte ich mal bei einer Inbetriebnahme das Thema, dass ich mit meinem GLT-Netz per Kabel und zusätzlich mit dem Haus-WLAN zwecks Internetzugang verbunden war. Aus irgendeinem Grund habe ich dann - woher auch immer - beim Netzwerkscan auf jede Ping-Anfrage eine Antwort erhalten. Es gab also angeblich 254 Hosts im Netzwerk. Natürlich gab es die nicht. Ich kann es mir nur so erklären, dass entweder Windows da irritiert war aufgrund der zwei Schnittstellen und/oder die Anfragen warum auch immer über das Gateway gingen und daher Quatsch zurückkam. Daher der Hinweis, dass im BK gar kein Gateway eingetragen ist, weil der nicht auf andere Subnetze zugreifen können muss. Somit ist das auch nicht plausibel.

Ich glaube immer noch an einen einen Bug des alten BK, alles andere ergibt keinen Sinn. Es ist schlicht kein Gerät im Netzwerk vorhanden, dass die IP belegt. Das ist ein Fakt. Die IP ist frei, Punkt.

Wenn heute noch Zeit bleibt, drösel ich a) das Netzwerk mal weiter auf und klemme mich b) mal mit dem passiven Network-Tap dazwischen, das geht schneller als ein Portmirroring aufzusetzen.

Ich halte euch auf dem Laufenden.
 
Mal ganz blöd ins Blaue geschossen.
Du schreibst, dass der Effekt bei zwei Buskopplern auftritt und bei den anderen nicht. Wie sieht es denn mit der Firmwareversion aus? Falls die beiden eine andere Firmware haben würde ich mal da ansetzen und die angleichen.
 
Zurück
Oben