Da die alte Mitgliederkarte schon lange nicht mehr vom Entwickler gepflegt wird und mit der kommenden Umstellung auf php 8.x überhaupt nicht mehr funktionieren wird, habe ich mich für eine andere Lösung über Geonames.com entschieden. Die Karte bietet mehr Features, einen integrierten Event-Kalender und POI-Marker, ist also um einiges komfortabler und flexibler. Leider lassen sich die Daten aus der alten Karte nicht in die Neue übernehmen, wobei dort aber auch fast 50 falsche Einträge (mitten im Meer, der Wüste und sonstwo, wo sicherlich keiner wohnt) gesetzt worden sind. Daher würde ich gerne alle bitten, die weiterhin auf der Benutzerkarte verzeichnet sein wollen, in UCP (User Control Panel) den eigenen Standort durch Eingabe des Landes und der Postleitzahl neu zu setzen.
Die Karte kann über diesen Link oder über einen Klick auf das Icon in der Navbar des Forums aufgerufen werden.
---
As the user map has not been maintained by the developer for a long time and will no longer work...
Probably a question for Fred, but very happy for anyone to comment.
Attached is a small section that describes how the UK telex system interprets the various states of the S and R wires on telex lines - this I think is important for UK FSG to work with I-Telex.
Sadly programming is well beyond my grasp - I am still developing a single to double current converter with Jeff, but would also still like to see a direct implementation within I-Telex.
What other areas of development are a problem from making this easy to solve?
Bei Tests ist mir aufgefallen, daß iTelex einen clientseitigen Verbindungsabbruch nicht korrekt ausführt. Die Verbindung wird seitens iTelex als verbunden gehalten und läuft dann auf einen Timeout.
SYN ->
ACK
-> RST
...
Zwischenzeitliche erneute Verbindungsanfragen werden zwar angenommen, aber sofort mit einem iTelex-Baudot-Paket OCC beantwortet und dann geschlossen.
Letzteres Verhalten ist gewollt, aber ersteres nicht. Erste Sichtung des IP-Stacks zeigt, daß offenbar ein RST-Paketflag eingehend überhaupt nicht behandelt wird. :wat:
nachdem ich den Bufferoverflow in i-Telex offenbar gefunden und behoben habe, will ich mir die defekte Implementierung des TCP-Handshakes beim Verbindungsabbau ansehen. Der Fehler tritt nur dann auf, wenn i-Telex die Verbindung schliesst, nicht im umgekehrten Fall.
Das ist auch der Grund warum die Webseiten der Karte so lahm sind, hier kommen nach meiner Analyse 2 Themen zusammen:
1. Der Webserver sendet connection: close im HTTP-Header mit, damit wird angezeigt daß nach diesem Element die Verbindung geschlossen wird und nicht über den gleichen socket weitere Daten ausgetauscht werden.
2. Der Webserver beendet dann nach Auslieferung eines Elementes die Verbindung durch senden von FIN, ACK (schliessen des sockets). Der Browser bestätigt mit ACK, beendet seinerseits die Verbindung durch schliesssen seines sockets und sendet damit seinerseits FIN, ACK, was der IP-Stack im i-Telex mit ACK zu bestätigen hat. Diese Bestätigung fehlt, sodaß clientseitig mehrere Retransmissions...
ich schraube gerade an meinem T1000 mit piTelex herum, an der Tastaturwahllogik. Wenn man z.B. mit Tastaturwahl eine nicht existierende Nummer wählt oder der angewählte besetzt ist, schaltet der FS bei piTelex einfach ab. Wie macht das i-Telex? In der Gesamtbeschreibung steht nur
Wenn die gerufene Stelle frei ist, läuft diese an und die Verbindung ist hergestellt. Wenn die gerufene Stelle besetzt ist, schaltet sich der eigene Fernschreiber wieder ab.
Ich weiß aber, dass es diverse Fehlercodes gibt und i-Telex auch einige davon umsetzt. Über den i-Telex-Quellcode bin ich zu folgenden Vermutungen gelangt. Das Ganze habe ich mit der Anleitung der T1000 abgeglichen, dort stehen kurze Beschreibungen einiger Fehler drin.
Fehlermeldung | Funktion i-Telex | Beschreibung in Anleitung T1000
-|-
occ | Gehende TCP-Verbindung zu Teilnehmer kann nicht hergestellt werden | Teilnehmer besetzt
nc | ModRuhe ( Nicht mehr über den Remoteserver verbunden ) | Leitung bzw. Vermittlung...
habe gerade softwaremäßig ein kleines Problemchen, das möglicherweise aus einem Missverständnis meinerseits der i-Telex-Spezifikation resultiert. Dort steht zum Acknowledge-Paket ja, dass damit grundsätzlich die Zahl der empfangenen Zeichen dem Anderen mitgeteilt werden soll, damit dieser einschätzen kann, wie viel noch auszudrucken ist.
Das interpretiere ich erstmal so, dass ich meine aktuelle Druck-Pufferlänge übermittle. Wenn sich also jemand zu mir verbindet und das erste Baudot Data oder Direct Dial sendet, drucke ich Datum/Uhrzeit und sende das erste Acknowledge-Paket mit einem Wert von 24, da Datum/Uhrzeit ja noch zu drucken sind.
Jetzt steht in der Spezifikation bei Acknowledge ganz unten noch folgendes (frei übersetzt):
Anmerkung: Normalerweise druckt die gerufene i-Telex-Station nach dem Einschalten des Fernschreibers das aktuelle Datum und die aktuelle Uhrzeit. Um anzuzeigen, dass es Daten zum Ausdrucken gibt, beginnt das erste Acknowledge-Paket nicht...
I like the lock feature but I think it is not working in the manner that I am attempting to use it.
I have three ports set up. Port 31 is the main port for my station. Calls to 80003, which is my teletype model 32, normally go to port 31. Port 33 is my Lorenz 15c. Port 34 is the serial port.
I am away from home. I did not want the teletypes pulling current while I am away, so I unplugged them from the I-Telex ports, pressed the lock button for ports 31 and 33 and headed out of the house. I set up forwarding order so when locked they would call 34, which is my serial port. I also set up the main 80003 number to call 34 instead of 31. This way I can check message when I am away! It is a very nice feature.
Some of it working. But there are problems:
1. One user tried calling me and reported that he is getting “OCC Occupied”. I will find out what number he tries calling. Also I do not know this message, so I have asked for more information.
Schon mehrfach wurden Wünsche geäußert, dass ankommende Anrufe auf Klingeln, Meldelampen etc. angezeigt werden sollen.
Mancher hat vielleicht schon selbst was ähnliches gebaut (LED abgegriffen oder mein Tipp: Bei der TW39-Karte die Relais-Spule anzapfen), aber alle diese Lösungen sind mit Nachteilen verbunden (beim Relais beispielsweise die Auslösung auch bei abgehenden Anrufen).
Folgende bessere Lösungen sind für mich für die Signalisierung vorstellbar:
a) Einer der Anschlüsse des Programmier-Steckverbinders der TW39- sowie ED1000-Karte (gg. auch Seriell) wird als Ausgang geschaltet und bei ankommenden Anrufen getriggert.
Vorteil: Individuelle Signalisierung je Endgerät möglich.
Nachteil: Selbstbau der Hardware erforderlich (ist aber nur ein Schalttransistor und ein Relais, ggf. reicht auch ein Halbleiterrelais).
Nachteil: Signalisierung wird auch bei internen Verbindungen ausgelöst.
b) Einer der Anschlüsse des Programmier-Steckverbinder der Ethernet-Karte wird als Ausgang...
wie ist denn im originalen i-Telex die Logik hinter der Datumsmeldung im ASCII-Modus? Mit Datumsmeldung meine ich das Banner mit Datum und Uhrzeit, das vom Angewählten gedruckt wird.
Bei piTelex ist es aktuell so, dass das Banner generell dann gedruckt wird, wenn der Modus feststeht (Baudot oder ASCII) und ein Empfangstimeout passiert (wenige 100 ms).
Bei normalen Baudot-Telex-Verbindungen gibt es keine Probleme, weil der Angewählte i.d.R. das Banner abwartet.
Bei den automatischen ASCII-Meldungen, die man über den Teilnehmerserver abonnieren kann, schreibt die Gegenstelle ja sofort los. Mit der aktuellen piTelex-Implementierung gibt es meist kein Problem. Geht aber mal ein IP-Paket verloren, vergeht einige Zeit bis zur Retransmission, und die reicht um den Bannerdruck anzustoßen. Die weiteren Sendedaten vermischen sich dann schön damit.
Jetzt könnte man ja den Timeout einfach erhöhen. Andererseits sagt die i-Telex-Spezifikation, dass das Ganze so falsch läuft,...
Ich habe da so eine Idee, die mir im Hirn herumspukt. Da ich nun einen Lochstreifenstanzer mit RS232 Anschluß habe, kann ich demnächst viele schöne ASCII-Art Bilder nach BAUDOT -Art konvertieren.
Ich fände einen Dienst der, ähnlich wie der DWD Wetter Server, angerufen werden kann und ein Menu präsentiert, wo man die Bilder auswählen und lokal ausdrucken kann, toll.
Wäre sowas technisch machbar?
Ich hätte Lust, sowas mittelfristig technisch umzusetzen, könnte mir jemand der Spur nach erklären, ob und wie ich sowas machen muss?
Das i-Telex arbeitet beim Senden der eingetippten Daten wie folgt:
Es werden alle in der eingenen Station eingegebenen Zeichen (5-Bit-Codes) zunächst gespeichert und bei bestimmten Bedingungen dann als ein Datenblock ausgesendet.
Die Anzahl der gesendeten Zeichen wird summiert.
Ein Datenblock wird ausgesendet, wenn eine der folgenden Bedingungen erfüllt ist:
a) seit dem letzten eingegebenen Zeichen sind 0,8 Sekunden vergangen
oder b) es sind mehr als 20 Zeichen gepuffert
oder c) die Anzahl per Ack-Telegramm als gedruckt bestätigten Zeichen ist gleich der Summe der gesendeten Zeichen.
Somit sind Ack-Telegramme tatsächlich optional und dienen nicht der Verhinderung des Überlaufens des Puffers beim Empfänger, sondern dem optimierten Senden der 5-Bit-Daten durch den Sender.
Der Empfänger sendet die Ack-Telegramme mindestens alle 1,5 sekunden, jedoch auch sofort wenn der Empfangspuffer leer ist.
Ich wollte insgesamt vermeiden, dass sinnlos Übertragungs-Overhead verursacht wird (und der...
ich beschäftige mich gerade zwangsläufig wieder mit SQL.
Die Datenbank SQLlite ist ja zukünftig Bestandteil des Teilnehmerserver und soll ebenfalls zukünftig in meinem
Abo Dienst eine Rolle spielen. Ich habe hier mal ein nettes PDF zum Thema SQLlite und Syntax verlinkt.
One of the biggest problems with getting I-Telex to take off in the UK is the lack of an interface that works with British machines.
I know there was some development work carried out for a double current interface - I have seen the schematics on Sourceforge.
I see some problems with the concept - I-Telex should be a one box solution, at present there is no dual rail power supply for the machine interface.
I think it would be possible to modify the existing power supply board to give two voltage multiplier chains - this should then allow for maybe 60-0-60 for the signalling supply (the people I have spoken to so far regarding possible new subscribers always come back to British Teleprinters use 80-0-80v - I think that this is not really needed, we are not running long distance lines for our purposes, but I do appreciate that the higher voltage is needed to allow for a quick and positive operation of the receive magnets.
Da es mir im Sommer in meiner Werkstatt (wo das i-Telex steht) häufig zu warm war und ich deshalb meistens im Homeoffice-Büro gesessen habe, habe ich nie mitbekommen, was das i-Telex so treibt.
Deswegen habe ich mir ein Tool geschrieben, das die Ausgaben der seriellen Schnittstelle der i-Telex-Karte (Ethernet-Karte) protokolliert, anzeigt und auch die übertragenen Daten analysiert und im Klartext anzeigt. Man kann also auf dem PC alles mitlesen, was das i-Telex sendet oder empfängt.
Da ich neben dem i-Telex keinen PC stehen habe, habe ich die serielle Schnittstelle über einen USB-Server mit Seriell-USB-Wandler mit meinem PC im Büro verbunden und kann mich dann sozusagen über Remote-USB verbinden.
Eine andere Alternative wäre ein Seriell/Telnet-Wandler (z.B. mit einem Arduino). Aber dafür muss ich in dem Tool noch Telnet implementieren. Das funktioniert im Moment noch nicht.
Das Programm läuft nur unter Windows (Linux- und Mac-User, sorry! :D )
Das EXE-File liegt im...
Da ich bisher nur einen Fernschreiber am i-Telex hatte, ist mir das nicht aufgefallen, aber wenn ich jetzt ein zweites öffentliches Gerät am gleichen i-Telex betreiben will, braucht ich ja eine öffentliche Extension-Nummer. Dabei ist mir aufgefallen, dass die sich über die Funktion Client-Update gar nicht aktualisieren lässt. Also wenn ich an der lokalen Konfiguration irgendetwas ändere, dann muss ich jedesmal um eine manuelle Korrektur des Server-Eintrags bitten.
Könnte man das nicht erweitern, so dass beim Client_Update optional die Extension-Nummer mit gesendet werden kann? Auch wenn die aktuelle Client-Software das vielleicht noch nicht nutzt.
In WinTlx könnte ich das jetzt schon gebraucht, um damit meine Arduino-Implementierung zu testen.
Oder spricht da technisch was dagegen, was ich übersehen habe?
Ich habe mir mal Gedanken gemacht, wie man eine sichere Authentifizierung beim jedem i-Telex-Anruf realisieren könnte.
Nachdem ich einige selbstausgedachte Verfahren durchgespielt habe, bin ich eigentlich immer wieder beim Private/Public-Key-Verfahren gelandet.
Damit die i-Telex-Karte nicht mit RSA/DNS-Verschlüsselung belastet wird (das schafft die nicht), könnte man den Teilnehmer-Server für die Key-Berechnungen nutzen.
Praktisch könnte das folgendermaßen aussehen:
Wenn der Server die Verschlüsselung übernimmt, braucht man eigentlich nur einen Key, der auf dem Server gespeichert wird. Das ist dann ein Zwischending aus Public und Private Key.
Bei einem Anruf lässt sich der Anrufer vom Server ein mit seinem Key verschlüsseltes Anmeldetoken erzeugen, mit dem er sich beim angerufenen System authentifiziert. Das Token bleibt auf dem Server gespeichert.
Das angerufene System schickt den verschlüsselten Token zum Server, dieser entschlüsselt das Token mit dem Key des Teilnehmers,...
ich habe jetzt mal über Telnet die Protokollausgabe der i-Telex-Karte auf meinem Arbeitsrechner dauerhaft mitlaufen lassen. Um zu schauen, was da so passiert.
Dabei fällt mir auch, dass die Software alle 10 Minuten einen Neustart macht. Ist das normal?
Da ich es unpraktisch finde, dass ich die i-Telex-Debug-Ausgaben nur am seriellen Port der i-Telex-Karte abgreifen kann, habe ich mir jetzt einer Arduino Wemos D1 angeschlossen. Das ist ein Arduino mit integriertem WLAN.
Damit kann man mit ein paar Zeilen Code die serielle Schnittstelle über Telnet weiterleiten und sich dann z.B. mit Tera Term oder Windows TELNET draufschalten.
Auf die Schnelle hat es eben noch nicht am seriellen Port der TW39-Spez-Karte funktioniert, aber vielleicht habe ich da noch den Hardware-Handshake aktiviert. Das sollte eigentlich genauso funktionieren.
Also nochmal, das ist keine i-Telex WLAN-Anbindung. Es geht nur um den Zugriff auf die seriellen Schnittstellen.
Die Kosten für die Elektronik sind minimal. Beim Chinamann bezahlt man ca. 6 Euro für den Wemos D1 und noch mal 2-3 Euro für den TTL/Seriell-Wandler. Im Prinzip könnte man das auch in das i-Telex-Gehäuse einbauen, aber dann braucht man einen Wemos mit Antennenanschluss um die WLAN-Antenne...
ich möchte gerne die 40 mA zum FSG mit einem Atmel-Controller (ADC-Eingang 0..5V) messen.
Mit möglichst wenig Schaltungsaufwand. Das muss ja nicht auf's Zehntelmilliampere genau sein.
Ich bräuchte möglichst eine fertige Schaltung, die ich nachbauen kann. Keine Hinweise, wie man das prinzipiell machen würde. ;)
Man könnte ja direkt am Lastwiderstand messen, aber dann hat man das Problem mit der Spannungumkehr.
Also wäre es wohl ein einfachsten vor dem Relais einen Messwiderstand einzuschleifen und dort zu messen.
Oder wie macht man das am sinnvollsten?
eine DSL Anbieter, wie z.B, Deutsche Glasfaser bieten DSL mit reinen IP6 stack an.
Also kein dual stack mit IP4 und IP6 .... sondern nur IP6.
Welche Konsequenzen hätte dies für das iTELEX Netzwerk via Internet.
Können die iTELEX Anschlusse noch auf den Teilnehmerservern eingetragen, bzw. die DNSNamen aufgelöst werden ?
Ich habe da ein Problem die Limitierung zu verstehen.
Ich benötige manchmal eine Einrichtung, mit dr man sich zu Testzwecken selber anrufen kann. Mmomentan muss ich das umständlich über Telnet vom seriellen Teil afu den Hauptanschluss tun. Das it jeoch keine echte Simulation eines von aussen kommenden Anrufs. Irgendwie habe ich in Erinnerung, dass es ein solches Interface irgendwo geben soll, aber meine Suche im Forum und meinen Telex blieb leider erfolglos. Vielleicht nahm ich nicht die richtigen Suchbegriffe.
Da bereits mehrere Anwender mit der Abfrage der Daten einzelner Teilnehmer nicht auf Anhieb klar gekommen sind, gibt es ab heute was neues:
Die Daten (IP-Adresse, Hostname, Port, Durchwahl) zu jeder registrierten Nummer kann auch im Ascii-Format abgefragt werden.
Dazu folgendes tun:
A) bei sonnibs.no-ip.org den Port 11811 öffnen (eigentlich bei allen Teilnehmerservern, sobald Version 722 installiert ist).
B) den Text q781272 senden (auf das q achten, Nummern sind mindestens 5 stellig)
C) Folgende Zeilen empfangen (Beispiel)
ok
781272
Fred, Braunschweig T100
1
sonnibs.no-ip.org
134
33
+++
Alle Zeilen sind mir CR+LF getrennt.
Bedeutung der Zeilen:
ok <-- Datensatz gefunden
781272 <-- sicherheitshalber nochmal die gefundene Nummer
Fred, Braunschweig T100 <-- Name (rein informativ)
1 <-- Typ (siehe unten)
sonnibs.no-ip.org <-- Adresse, hier kann auch eine IP in der Form 95.90.186.198 stehen
134 <-- Port-Nummer
33 <-- Durchwahl
+++ <-- Ende-Kennzeichnung
Moin,
zur verschlüsselten Kommunikation werden Serverzertifikate genutzt.
Damit es zu keinen Problemen kommt, sollte bei der Beantragung auf einige Einstellung geachtet werden.
Für SSL/TLS Verschlüsselung ->
Anwendungsfall : Serverzertifikat
Schlüssellänge : mindestens 2048 bit
Laufzeit : sollte gültig sein 2 - 4 Jahre und zur Laufzeithälfte erneuern.
Signaturalgorithmus : sha256rsa
Servername / URL : CN
Servername / URL : Alternative Subject Name (ASN) wird auch Alternative Antragsteller Name genannt
Wichtig ist, dass das Zertifikat auf die Domäne ausfgestellt ist, dessen Webseite aufgerufen werden soll.
Um RFC konform zu sein (chrome kontrolliert das, IE nicht) muß der Eintrag des CN im ASN wiederhalt werden.
Ist man nicht RFC konform, gibt es Fehlermeldung bei einigern Browsern oder Programmen.
In ASN können noch weitere Einträgen hinzugefügt werden... z.B. IP Adresse.
Du darfst keine neuen Themen in diesem Forum erstellen. Du darfst keine Antworten zu Themen in diesem Forum erstellen. Du darfst deine Beiträge in diesem Forum nicht ändern. Du darfst deine Beiträge in diesem Forum nicht löschen. Du darfst keine Dateianhänge in diesem Forum erstellen.
