Enertex IP Router Inbetriebnahme Probleme

[enertegus]

Dann check doch mal die Antwort, kann ja wohl nicht sein Ernst sein, oder?

Nun nicht mein ernst, sondern der Standard wird so sein.

[saft6luck]

Kannst Du das evtl. etwas genauer spezifizieren wo Du hin willst oder wo Du das Problem siehst?

Ich will eine kompetente Antwort auf meine Frage.

Natürlich ist es falsch, eine Tunnel-Adresse mit unpassender Adresse zu verwenden. Das mag meist funktionieren, leider aber nicht immer. Sollte man das nicht wissen wenn man mal einen Router entwickelt hat?


Beispiel:
Segmente 1.x.x und 2.x.x, Enertex-Router auf 1.1.0 und Tunnel 15.15.11. Programmieren über ETS4 und Tunnel -> Geräte im Segement 2.x.x sind nicht programmierbar.

... sondern der Standard wird so sein.

Nein, ist er nicht.

[salixer]

Antwort aus dem Gedächtnis, ohne dass ich das im Einzelnen noch einmal nachgeschlagen habe:
1. Der Standard schweigt sich über die Vergabe der Tunneladressen aus
2. Jedes Telegramm, das über den Tunnel rein kommt, wird auch auf die Linie des Routers geschrieben. Deswegen ist es prinzipiell egal, welche Adresse der Tunnel hat.
3. In unserem Router gibt es eine Möglichkeit das Verhalten aus Punkt 2 dahingegen zu ändern, dass nur Telegramme auf die Linie des Routers geschrieben werden, die auch ein passende Zieladresse der Linie haben
4. In der ETS4 kann man für jede Linie eine "Verbindung" konfigurieren, daher erübrigt sich das von dir erwähnte Problem, dass mit einer unpassenden Tunneladresse die Geräte auf einer anderen Linie nicht programmiert werden können.

[saft6luck]

1. Der Standard schweigt sich über die Vergabe der Tunneladressen aus

Was willst du denn hiermit sagen? Bist du wirklich der Meinung, man ignoriert die Topologie weil der Standard nicht vorschreibt wie man die Tunneladresse ändert? Die zu verwendenden Adressen einer Topologie sind auf jedenfall für alle Geräte (und somit auch für Tunnel) spezifiziert.

2. Jedes Telegramm, das über den Tunnel rein kommt, wird auch auf die Linie des Routers geschrieben. Deswegen ist es prinzipiell egal, welche Adresse der Tunnel hat.

Wenn der Tunnel die Adresse vorgibt und jedes Telegramm mit dieser Adresse gesendet wird, wie empfängst du dann die Antworten? Einfach mal die Topologie außer acht lassen? Ich hatte ein Beispiel angegeben.

3. In unserem Router gibt es eine Möglichkeit das Verhalten aus Punkt 2 dahingegen zu ändern, dass nur Telegramme auf die Linie des Routers geschrieben werden, die auch ein passende Zieladresse der Linie haben

Was es dann nicht einfacher macht, oder? Wo ist das denn eigentlich beschrieben?

4. In der ETS4 kann man für jede Linie eine "Verbindung" konfigurieren, daher erübrigt sich das von dir erwähnte Problem, dass mit einer unpassenden Tunneladresse die Geräte auf einer anderen Linie nicht programmiert werden können.

Du meinst also, ich soll einfach einen anderen Zugangspunkt verwenden und gut ist? Ist dann für dieses Problem eine Lösung, wenn die anderen Zugangspunkte nicht schon belegt sind. Man könnte aber auch das Routing verwenden oder es einfach richtig machen.

BTW sogar in der ETS kann man die Tunneladresse ändern, wie im Standard definiert, weil man eben nicht immer einfach jede x-beliebige Adresse verwenden kann.

[salixer]

BTW sogar in der ETS kann man die Tunneladresse ändern, wie im Standard definiert

Ich habe doch nie behauptet, dass man die Adresse nicht setzen kann. Man kann alle Tunneladressen ändern (PID_ADDITIONAL_INDIVIDUAL_ADDRESSES).

[saft6luck]

Ich habe doch nie behauptet, dass man die Adresse nicht setzen kann. Man kann alle Tunneladressen ändern (PID_ADDITIONAL_INDIVIDUAL_ADDRESSES).

Du hast behauptet, man könne jede Tunneladresse verwenden. Das impliziert für dich, dass man auch keine explizite Möglichkeit zur Konfiguration benötigt.

Klar ist, dass die Tunneladresse zum Segment passen muss, um jegliche Probleme auszuschließen. Daher sind mir auch die angegebenen Möglichkeiten für eine Konfiguration nicht ausreichend!

Testweise habe ich die Tunneladressen in der ETS4 umgestellt. Dies war aber extrem aufwendig (PA des Tunnels umstellen, dann von anderem Gerät belegen, nächsten Tunnel umstellen, den dann auch belegen etc.) und zudem oft begleitet von Fehlermeldungen der ETS, dass der Speicher nicht geschrieben werden konnte. Hierzu gibt es auch keine Anleitung!

Am nächsten Tag dann über telnet ausgelesen und alle waren wieder bei 15.15.x.

Offensichtlich seht Ihr eben die Notwendigkeit zur Konfiguration noch nicht einmal. (Ist das denn überhaupt getestet?)

Also, ja, bitte implementiert eine Möglichkeit die PAs der Tunnel konsistent und dauerhaft zu konfigurieren (IMHO vorzugsweise über telnet). Und ja, mir ist bewusst, dass es wohl keine IP- oder MAC-abhängige Konfiguration sein wird, aber auch zufällig vergeben ist ein Anfang.

[QuisaZaderak]

Hallo zusammen,

man kann doch ohne Probleme die Adresse eines jeden Tunnels per Telnet setzen?!?

(aus dem Kopf, kann es gerade nicht live testen)
Um z.B. Tunnel 3 auf 1.1.250 zu setzen: (Dez->Hex)

telnet <IP>
tunnel 3 0101FA

Habe damals beim Einrichten alle 5 Tunnel sauber auf 1.1.x Adressen gezogen. Trotz zig Reboots in der zwischenzeit bleiben die Adressen konstant erhalten...

Gruß

Manuel

[saft6luck]

man kann doch ohne Probleme die Adresse eines jeden Tunnels per Telnet setzen?!?

(aus dem Kopf, kann es gerade nicht live testen)
Um z.B. Tunnel 3 auf 1.1.250 zu setzen: (Dez->Hex)

telnet <IP>
tunnel 3 0101FA

Habe damals beim Einrichten alle 5 Tunnel sauber auf 1.1.x Adressen gezogen. Trotz zig Reboots in der zwischenzeit bleiben die Adressen konstant erhalten...

Die Lachnummer schlecht hin!

Das geht tatsächlich, vielen Dank Manuel!
Z.B. Tunnel 2 auf 14.14.240 (die ersten beiden Stellen sind HEX einstellig und dann die Gerätenummer HEX zweistellig)

ert> tunnel 2 EEF0
Tunnel 2: closed
KNX address: 14.14.240
IP control endpoint: 0.0.0.0:0


Jetzt wäre es noch schön, wenn man da auch die IP Adresse des Gerätes angeben könnte, das diesen Tunnel vorzugsweise bekommen soll.

[salixer]

Um z.B. Tunnel 3 auf 1.1.250 zu setzen: (Dez->Hex)

telnet <IP>
tunnel 3 0101FA

Das ist ei undokumentiertes Feature aus der Entwicklung, das in der Anwendung halt nichts für den normalen Nutzer ist. Ich habe hier ja bereits geschrieben, das wir eine Konfiguration der Tunneladressen über Telnet nachreichen können (und zwar ohne Hex). Ach ja: 1.10.240 -> 1af0

Trotz zig Reboots in der zwischenzeit bleiben die Adressen konstant erhalten...

So soll es ja auch sein

[Tessi]

Offenbar kommen jene Nutzer, die Kenntnis von diesem Feature bekommen haben, aber schon jetzt gut damit zurecht.

[QuisaZaderak]

So soll es ja auch sein

Und das ist auch gut so...

Mein Kommentar

Trotz zig Reboots in der zwischenzeit bleiben die Adressen konstant erhalten...

war bezogen auf...

Am nächsten Tag dann über telnet ausgelesen und alle waren wieder bei 15.15.x.

[saft6luck]

Und das ist auch gut so...
...
Mein Kommentar
...
war bezogen auf...

Und was willst du damit nun sagen?

Wenn man die undokumentierte Funktion verwendet, dann funktioniert es auch?

[kaih]

Nicht notwendiger Weise. Unser Router kann auch Zeroconf, d.h. wenn kein DCHP Server vorhanden und der PC direkt per LAN Stecker am Router (crossover-Kabel nicht notwendig) verbunden ist, kann man den Bus auch so programmieren.

Lang lang ist´s her...
jetzt wollte ich mich noch mal versuchen.

Muss ich für die erste Parametrierung nicht erst mal über DHCP zugreifen (ist ja Werkseinstellung) um dann die Konfiguration auf Zeroconf um zu stellen?

Gruß
Kai

[saft6luck]

Muss ich für die erste Parametrierung nicht erst mal über DHCP zugreifen (ist ja Werkseinstellung) um dann die Konfiguration auf Zeroconf um zu stellen?

Nein, Zeroconf wird ja nur gemacht, wenn der DHCP nicht antwortet/vorhanden ist.

[salixer]

Muss ich für die erste Parametrierung nicht erst mal über DHCP zugreifen (ist ja Werkseinstellung) um dann die Konfiguration auf Zeroconf um zu stellen?

Ja. Dann stell aber gleich auf feste IP. Zeroconf ist meiner persönlichen Meinung nach immer Mist.