ETS Auswahl der Tunnel PA

[larsrosen]

iGude,

bei der ETS5 konnte ich ja den Tunnel für die Diagnose oder Verbindung direkt auswählen.
Die ETS6 hat jetzt den BUG (Feature) dies selbstständig zu tun. Ich kann zwar noch das Geräte auswählen, nicht aber den Tunnel.
Das Problem ist nur, wenn man eine Visu oder Co auf dem selben Tunnel hat(man bzw. ich weiß nicht welchen die ETS sich nimmt) wird die ETS beim reconnect rausgeschmissen.

Klaus Gütter
Bin ich Blind oder kann man den Tunnel wirklich nicht mehr wählen?

[Klaus Gütter]

Du bist nicht blind. Aber ich sehe das Problem dabei nicht.

[larsrosen]

Das Problem habe ich aktuell bei nem Kunden.
Der HS hängt an einer Tunneladresse vom ISE Remote.

Wenn ich mit der ETS Diagnose mich drauf schalte, wird die Diagnose nach ein paar Minuten nicht mehr mit Daten versorgt, da der HS scheinbar den Tunnel zurück erobert hat.

[DirtyHarry]

Im Endeffekt das gleiche Problem, das auch Roman hier beschreibt.

[Klaus Gütter]

Wenn der HS einen Tunnel belegt hat, kriegt die ETS einfach einen anderen. Das könnte also nur passieren, wenn der HS in dem Moment, wo sich die ETS verbindet, "seinen" Tunnel gerade nicht belegt hat. Und "Tunnel klauen" geht nicht.

Ich sehe das Problem also immer noch nicht.

[frankthegreat]

Hab auch das Problem mit den Tunneln. Obwohl ich beim 1.Mal der ETS einen festen Tunnel zuweise, greift sie sich beim nächsten Mal einen anderen.
Dann kommt es teilweise zu "Streitigkeiten", weil diese Tunnel schon anderen Geräten fest zugewiesen sind.

Also ich sehe da schon ein Problem

[larsrosen]

Muss ich jetzt echt wieder ein Featurewunsch schreiben für etwas was wieder ins alte geändert werden soll?

Es gibt scheinbar bei mehreren Leuten das Problem.
Mit der alten Funktion ging es ohne Probleme.
Was genau war denn der Grund es zu ändern?

[BadSmiley]

Anmerkung dazu von mir und zu dem Beitrag von damals. Ich habe mir gira über das Thema gesprochen. Dort wäre das Problem bekannt und die Empfehlung war "nehmen sie für den hs den letzten Tunnel. Die ets fängt immer von vorne an zu zählen". Das habe ich gemacht, war aber seit dem nicht mehr in den betroffenen Anlagen. Damals klappte das augenscheinlich. Aber ich müsste das mal wieder öfter testen.

[DirtyHarry]

Habe mal mit der ETS 5 getestet, bewusst den Tunnel des HS zu nutzen (wie anderswo schon geschrieben, S1 ist Secure in Betrieb genommen, Tunnel ist jedoch unsecure). Habe kurz vorher am HS geschaltet, "klauen" lies sich der Tunnel da nicht (die kurze Fehlermeldung könnte hier etwas aussagekräftiger sein, im Detail findet man den korrekten Grund: Belegt).
Wie es aussieht, wenn schon länger kein Datenverkehr mehr vom/zum HS war, kann ich nicht sagen. Theoretisch sollte das ja eigentlich egal sein. Wenn der HS einen Neustart macht, geht das aber (wie zu erwarten) problemlos.

Bleiben für mich noch die Fragen offen: Arbeitet die ETS6 anders und könnte den Tunnel trotz aktivem HS übernehmen und wie sieht es bei einem Secure-Tunnel aus?

Sollte das die ETS6 genauso machen und der Secure-Tunnel auch keinen Unterschied machen, wäre es für mich grundsätzlich Ok. Wobei ich manuelle Wahlmöglichkeiten zu irgendwelchen Automatiken schon gut finde...

[Klaus Gütter]

Die ets fängt immer von vorne an zu zählen"

Nein, da muss ich dich korrigieren.

Wenn ein Client von einem IP-Interface einen Tunnel anfordert, gibt es zwei Möglichkeiten:

1. "Ich bin eine Visu und möchte ganz speziell den Tunnel mit dieser Adresse. Und nebenbei, hier ist das Passwort."
2. "Mir doch egal, ich bin die ETS. Gib mir einfach irgendeinen Tunnel. Und nebenbei, ich habe das Master-Passwort"

Der Vorteil von 2 für die ETS ist, dass sie (bzw. der Benutzer) sich nicht darum kümmern muss, welche Tunnel evtl. schon belegt sind, das wird alles von IP-Interface gemanagt. Problematisch ist das nur, wenn die Visu später kommt und die ETS schon eine Verbindung hat und wie der Zufall so will genau die, die die Visu braucht.

Der Algorithmus, wie das IP-Interface im Fall 2 einen Tunnel zuteilt, ist nicht festgelegt. Offenbar wählt das IP-Interface, das Gira hier meint, den ersten freien Tunnel von unten gezählt. Vielleicht gibt es Interfaces mit anderen Strategien - schlau wäre z.B. "Moment, die Client-IP-Adresse kenne ich doch, die hatte vorhin den Tunnel#3; wenn der noch frei ist, kriegt der Client den wieder".

[BadSmiley]

Nein, da muss ich dich korrigieren.

Die Aussage ist nicht von mir, die ist vom gira Support. Da wurde wenigstens mal gesagt dass dies kein Problem ist.
Ich sage ja, ich habe es um gestellt aber noch nicht weiter verfolgt ob es was ändert. Gefühlt ist das Problem auch nur bei secure s1 Tunnel Verbindungen vorhanden. Da einige Kollegen geschrieben haben, der hs kann auch unsichere Tunnel Verbindungen und da berichtet niemand von solchen Problemen?