Diskussionsvorschlag für eine i-telex Authentifizierung

Fachforen für Entwickler und Bastler
Benutzeravatar

Paul
Rank 1
Rank 1
Beiträge: 20
Registriert: Fr 26. Mai 2017, 23:03
Hauptanschluß: 41235c bhf d

Re: Diskussionsvorschlag für eine i-telex Authentifizierung

#21

Beitrag: # 13077Beitrag 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.
Benutzeravatar

Paul
Rank 1
Rank 1
Beiträge: 20
Registriert: Fr 26. Mai 2017, 23:03
Hauptanschluß: 41235c bhf d

Re: Diskussionsvorschlag für eine i-telex Authentifizierung

#22

Beitrag: # 13078Beitrag 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....
Benutzeravatar

FredSonnenrein
Founder
Founder
Beiträge: 2317
Registriert: Fr 3. Jun 2016, 13:49
Wohnort: Braunschweig
Hauptanschluß: 8579924 hawe d

Re: Diskussionsvorschlag für eine i-telex Authentifizierung

#23

Beitrag: # 13079Beitrag FredSonnenrein »

Hallo Paul,
Paul hat geschrieben: Di 4. Jun 2019, 18:01 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?
Paul hat geschrieben: Di 4. Jun 2019, 19:01 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.
Grüße,
Fred Sonnenrein, Braunschweig
i-Telex 952741 (Lo133), 8579924 (T100s), 781272 (T100), 792911 (T68d) oder 531072 (T.typ.72)
Bei besetzt oder gestört bitte 531002 versuchen.
Benutzeravatar

Paul
Rank 1
Rank 1
Beiträge: 20
Registriert: Fr 26. Mai 2017, 23:03
Hauptanschluß: 41235c bhf d

Re: Diskussionsvorschlag für eine i-telex Authentifizierung

#24

Beitrag: # 13095Beitrag 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.
Benutzeravatar

Topic author
detlef
Rank 12
Rank 12
Beiträge: 3542
Registriert: Do 28. Mär 2019, 09:10
Wohnort: Marburg
Hauptanschluß: 7822222 hael d

Re: Diskussionsvorschlag für eine i-telex Authentifizierung

#25

Beitrag: # 13096Beitrag 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.
Gruß, Detlef

i-Telex: 7822222 (T1000), 114288 (F1300), 211230 (T100Z), 96868 (T37), 24394 (T68d)
Konferenzdienst: 11160 / 11161, Rundsender: 11162 / 11163 , Baudot-Bilder: 11166
Chat-GPT: 11168, Mail- und Fax-Dienst: 11170 / 11171, hist. Auskunft 1987: 40140, Wetterdienst: 717171
Benutzeravatar

Topic author
detlef
Rank 12
Rank 12
Beiträge: 3542
Registriert: Do 28. Mär 2019, 09:10
Wohnort: Marburg
Hauptanschluß: 7822222 hael d

Re: Diskussionsvorschlag für eine i-telex Authentifizierung

#26

Beitrag: # 13101Beitrag detlef »

FredSonnenrein hat geschrieben: Mo 3. Jun 2019, 17:37 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. :wat:
Gruß, Detlef

i-Telex: 7822222 (T1000), 114288 (F1300), 211230 (T100Z), 96868 (T37), 24394 (T68d)
Konferenzdienst: 11160 / 11161, Rundsender: 11162 / 11163 , Baudot-Bilder: 11166
Chat-GPT: 11168, Mail- und Fax-Dienst: 11170 / 11171, hist. Auskunft 1987: 40140, Wetterdienst: 717171
Benutzeravatar

FredSonnenrein
Founder
Founder
Beiträge: 2317
Registriert: Fr 3. Jun 2016, 13:49
Wohnort: Braunschweig
Hauptanschluß: 8579924 hawe d

Re: Diskussionsvorschlag für eine i-telex Authentifizierung

#27

Beitrag: # 13103Beitrag 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...
Grüße,
Fred Sonnenrein, Braunschweig
i-Telex 952741 (Lo133), 8579924 (T100s), 781272 (T100), 792911 (T68d) oder 531072 (T.typ.72)
Bei besetzt oder gestört bitte 531002 versuchen.
Benutzeravatar

Topic author
detlef
Rank 12
Rank 12
Beiträge: 3542
Registriert: Do 28. Mär 2019, 09:10
Wohnort: Marburg
Hauptanschluß: 7822222 hael d

Re: Diskussionsvorschlag für eine i-telex Authentifizierung

#28

Beitrag: # 13105Beitrag 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. :hehe:
Gruß, Detlef

i-Telex: 7822222 (T1000), 114288 (F1300), 211230 (T100Z), 96868 (T37), 24394 (T68d)
Konferenzdienst: 11160 / 11161, Rundsender: 11162 / 11163 , Baudot-Bilder: 11166
Chat-GPT: 11168, Mail- und Fax-Dienst: 11170 / 11171, hist. Auskunft 1987: 40140, Wetterdienst: 717171
Benutzeravatar

DF3OE
Founder
Founder
Beiträge: 3067
Registriert: Di 7. Jun 2016, 09:45
Wohnort: Edemissen - Blumenhagen
Hauptanschluß: 925302 treu d
Kontaktdaten:

Re: Diskussionsvorschlag für eine i-telex Authentifizierung

#29

Beitrag: # 13108Beitrag DF3OE »

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

925302 treu d - T1000Z (Hauptanschluss)
55571 fvler a - T100S
210911za hmb d - T150 (Werkstatt)
218308 test d - T1000S/LS (Werkstatt)
925333 =treu d (Minitelex Sanyo SF100) defekt
Fax G2/G3: 05176-9754481 (Sanyo SF100 Thermofax) defekt
Benutzeravatar

ProgBernie
Rank 5
Rank 5
Beiträge: 422
Registriert: Sa 27. Okt 2018, 17:51
Hauptanschluß: 898906 laeng d

Re: Diskussionsvorschlag für eine i-telex Authentifizierung

#30

Beitrag: # 13114Beitrag 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...
Gruß Bernd
--
Fernschreibstelle Labenz
898906 laeng d
Antworten

Zurück zu „Entwickler-Ecke“