Diskussionsvorschlag für eine i-telex Authentifizierung

[Paul]

Wiederholte Anfragen von der gleichen IP könnte man aber serverseitig sehr leicht abfangen können.

Werden sie aber im Moment noch nicht, weil ich das nur irgendwann mal als Experiment eingebaut und mit einer config Option wieder deaktiviert hatte.

[Paul]

Das würde ich dann zusammen mit dem Cache einbauen, ich bin aber immer noch nicht überzeugt, dass die Centralex Variante nicht effizienter und einfacherer zu implementieren ist....

[FredSonnenrein]

Hallo Paul,

Was haltet ihr denn davon das über das Centralex laufen zu lassen?
[...]
Das ist natürlich keine vollständige Definition, das Prinzip sollte aber denke ich mal klar werden.

Ich muss gestehen, dass es mir noch nicht ganz klar ist.
Fragen:
a) Wie überprüft der Centralex die "Identität" eines Anrufers? Über die Pin bei RemAuth?
b) Schritt 3: Wer erhält die Nummer des Angerufenen? Der Angerufene? Der weiß doch wer er ist...
c) Schritt 5-8: Der Angerufene hat doch vorher selbst die Verbindung zum Centralex geöffnet. Warum tut er dies nochmal?
d) Schritt A: Wieso sollte der Angerufene in diesem Schritt auflegen?
e) Wie läuft das Verfahren, wenn der Anrufer das neue Protokoll nicht beherrscht? (Alte Software).
f) Wie läuft das ganze, wenn es nicht nur einen Centralex-Server gibt und die Anwender an verschiedenen Servern lauschen?

Das mit der IP war ja der ursprünglich Plan, dabei gibt es aber leider folgendes Problem:
entweder muss der Anrufer seine Nummer mitschicken (selbes Problem mit dem update aller ITelexe)
oder ich muss im Teilnehmerserver alle Einträge durchgehen und die IP vergeleichen, oder wenn der Client mit einem Hostnamen eingetragen ist ein nslookup machen.

Das mit der Nummer mitschicken hatte ich auch schon angedacht:
- Mit einer aktualisierten I-Telex-Software wird die Hauptrufnummer in einem zusätzlichen Datenpaket mitgeschickt.
- Falls dieses nicht ankommt, wird die erste empfangene Ziffernfolge im Text als Nummer ausgewertet. Diese sollte ja der Hauptrufnummer oder einer Durchwahl entsprechen.
Ja, dies bedingt dass erstmal die Verbindung zustande kommt. Sie kann dann aber durch den Angerufenen getrennt werden, wenn die Authentifizierung ein 'negativ' ergibt.
Außerdem könnten bei Authentifizierungen ohne bekannte Hauptrufnummer erstmal nur die Einträge mit IP-Adresse (statt hostnamen) durchgegangen werden.

[Paul]

Erstmal zum Verständniss: Ich schlage nicht vor, dass jeder neue Client eine Standleitung bei einem Cnetralex Server haben soll.

Stattdessen soll man, wenn man sich beim Centralex authentifiziert hat (Durch eine Standleitung oder Aufbauen eine Verbindung zum Server + RemAuth Packet) ein RemPromptCall
schicken können, um einen Anruf an die Nummer in dem Packet zu starten.

Das Centralex öffnet dann eine Verbindung mit der angerufenen Nummer (wenn diese nicht zufälligerweise eine Standleitung auf dem selben Server hat) und schickt auch ein RemPromptCall Packet.

Dieses fordert den Client auf eine Verbindung mit einem Centrale Server aufzubauen.

Im Nachhinein ist es wahrscheinlich Sinnvoll dieses mit einem anderen Packet, bswp.
RemReqConnect [länge=0] zu ersetzen (b).
Ich dachte mir nur, dass man so weniger neue Packete hätte.

Der Angerufene Client ist dann entweder ein neuer Client, erkennt das Packet, schickt ein RemAck zurück und trennt, oder er erkennt das Packet nicht.

In dem Fall müsste man mal gucken, wie genau das ITelex dann reagiert, aber sobald der centralex Server erkennt,
dass der Client das neue Protokoll nicht unterstützt wird die Verbindung offen gehalten und zum Anrufer durchverbunden (e),
(Evtl. könnte man das auch über das "Version" Packet lösen).

Das Trennen und Wiederaufbauen der Verbindung ist nötig, da sonst jeder ein "RemPromptCall/RemReqConnect" Packet an einen neuen Client schicken könnte
und dann Nummer und Pin des Clients in einem RemAuth Packet zurückbekommen würde... (c)

Wenn der Angerufene Client das Packet erkannt und die Verbindung getrennt hat meldet er sich danach bei seinem Centralex Server an und authentifiziert sich mit Nummer und Pin (a).
Damit die Schritte ab A stattfinden können müssen der centralex Server vom Anrufer und vom Angerufenen entweder der selbe Server sein, oder der Server des Anrufenden muss erfahren, dass der Angerufene Client auf einem anderen Server verbunden ist. Das zu lösen sollte möglich sein, ich bin aber noch nicht ganz sicher, wie man das am besten umsetzt (f).

d) Schritt A: Wieso sollte der Angerufene in diesem Schritt auflegen?

Das würde es erlauben eine art "blacklist" zu implementieren, die Anrufe von bestimmten Nummern sofort ablehnt.

[detlef]

Also das klingt jetzt schon sehr kompliziert. Verstanden habe ich es noch nicht. Kannst du das noch mal verständlicher erklären?
Was ist ein RemPromptCall, RemReqConnect, RemAuth Packet?
Außerdem würde mich interessieren, wo genau der Vorteil gegenüber dem von Fred vorgeschlagenen Verfahren ist.

[detlef]

Wie viele LED hast du auf dem Board?
Ist die IC Fassung bestückt?

9 LEDs, Fassung bestückt. Ich habe ja auch die internen 80er-Adresse belegt. Aber ein Lauflicht habe ich da noch nicht gesehen.

[FredSonnenrein]

Eigentlich müsste ein Lauflicht erscheinen. Warum es bei dir nicht erscheint, kann ich nicht feststellen.
Leuchten den LED bei Benutzung der Funktionen des "Messgeräts" auf? Wenn dies auch nicht der Fall ist, dann sind vielleicht die LED falsch herum eingelötet...

[detlef]

Ich habe mich bisher mit dem Zusatzfunktionen noch wenig beschäftigt. Ich schaue mir das mal in Ruhe.
Wenn da normalerweise ständig ein Lauflicht durchläuft, bin ich aber ganz froh, dass das bei mir nicht passiert.

[DF3OE]

Eigentlich kommt das Lauflicht nur ein mal beim Einschalten.
Kann aber sein, dass die Programmierung des Chips einen "Knacks" hat, wie beim
Jochen.

[ProgBernie]

Bei mir kommt als Lichtorgel nur gelb-grün-blau, rot fehlt. LED ist OK, Widerling ebenfalls, Verbindungen alle OK bis zum Atmel PIN 3 und Kathode auf Masse...