Projekt piTelex - Vorstellung

[obrecht]

Um die reine i-telex-Funktion zu testen, kannst du hilfsweise auch das modul ED1000 disablen und nur über SCREEN arbeiten. Die Doku zu dem Modul ist relativ ausführlich. Mit screen hast du sozusagen einen "software-Fernschreiber". Dann musst du allerdings setzen

Code: Alles auswählen

  "wru_replace_always": true,          # du hast ja keinen Hardware-KG
  "continue_with_no_printer": true,    # du hast ja keinen Drucker

Das löst zwar dein ED1000 Problem nicht, aber vielleicht kommst du ja wenigstens ein Stück weiter so ?

[detlef]

Klar, wenn ich ED1000 ganz rausnehme oder enable auf false setzte, dann sind die Fehlermeldungen weg. Aber das hilft mir ja nicht weiter.

Ich will ja nicht ein System, das mit Tricks und Kniffen irgendwie gerade so läuft. Ich möchte, dass es so läuft, wie es beschrieben ist.
Mit Kommentaren in der telex.json, mit Zugriff auf die IOs und natürlich mit einem funktionierenden Audio-Adapter für ED1000. Sonst kann ich ja auch WinTlx nehmen.

Nichts davon funktioniert im Moment.

[obrecht]

Sonst kann ich ja auch WinTlx nehmen.

Jein.... wenn du das i-telex-Verhalten von piTelex testen willst, hilft dir WinTlx nicht, aber das screenbasierte 'kastrierte' piTelex vielleicht schon. Deshalb hatte ich das vorgeschlagen.

Heißt natürlich nicht, dass der Rest nicht auch laufen sollte

[detlef]

Ok, das erste Problem mit commentjson hat sich geklärt. Ich hatte das ja nur mit dem fehlerhaften telex.json getestet. Und da wird dermaßen mit Log-Ausgaben erschlagen, dass man den Fehler nicht sieht. In diesem Fall der Komma-Fehler. Ich habe jetzt, nachdem der Komma-Fehler draussen ist, commentjson wieder aktiviert. Und das funktioniert jetzt. Das hilft jetzt nicht wesenlich weiter, aber gibt etwas vertrauen, dass hier Python-mäßig überhaupt was funktioniert.

Das Screen-Device funktioniert wie gesagt. Ich kann damit rauswählen. Reinwählen funktioniert nicht. Wenn ich das mit i-Telex versuche, bekomme ich ein "nc". continue_with_no_printer steht auf true. Wenn die eingehende Verbindung funktionieren würde, dann könnte ich vielleicht zumindest das WinTlx/piTelex-Problem debuggen.

Muss man noch irgendwo was angeben, damit eingehende Verbindungen funktionieren? Im Log-File finde ich nichts. Kann man irgendwo das Log-Level erhöhen?

[obrecht]

Für's Reinwählen muss das piTelex einen Eintrag im Teilnehmerserver haben, und natürlich, wenn das piTelex von "draußen" erreichbar sein soll, ggf die zugehörige Portweiterleitung im Router/Firewall (Standardport von piTelex ist TCP/2342).

Oder die Daten (IP-Adresse und Portnummer) der piTelex-Installation müssten in einem lokalen Verzeichnis Deiner i-Telex-Installation eingetragen werden, damit dein i-Telex das piTelex findet (wie das geht, damit kenne ich mich nicht aus...). Von piTelex zu piTelex geht das mit der userlist.csv, das ist sozusagen das lokale Telefonbuch von pTelex mit Vorrang vor Einträgen im TlnSrv.

LogLevel kannst du erhöhen. Siehe https://github.com/fablab-wue/piTelex/wiki/SW_DebugLog

[detlef]

Für's Reinwählen muss das piTelex einen Eintrag im Teilnehmerserver haben, und natürlich, wenn das piTelex von "draußen" erreichbar sein soll, ggf die zugehörige Portweiterleitung im Router/Firewall (Standardport von piTelex ist TCP/2342).

Ich habe hier zwei i-Telex-System und ganz viele Dienst laufen. Ich weiß schon wie das eingerichtet werden muss.
WinTlx bekommt ja auch eine TCP/IP-Verbindung, aber piTelex beendet sie sofort wieder.

[detlef]

Jetzt muss ich mich auf meinen alten Tage noch mit Python beschäftigen. Das wollte ich eigentlich vermeiden. Ich hasse diese Sprache.

Ich habe im Quelltext nachverfolgt, warum eine TCP-Verbindung zustande kommt und dann piTelex die Verbindung sofort beendet.
Meiner Meinung nach ein Bug im Selbsttest (Selbstanruf). Da wird nämlich nur geprüft, ob man mit der eigenen IP-Nummer angerufen wird. Es erfolgt dann zwar noch ein Test auf das Selbsttest Magic Packet, aber der ist wirkungslos. Die Verbindung wird trotzdem beendet. Immer wenn man sich mit der eigenen IP-Nummer anruft. Wenn ich mich selber zum Testen anrufe, dann tue ich das immer mit der gleichen (externen) IP-Nummer.

Ich habe das hier mal korrigert und jetzt klappt das.

Der Fehler ließ sich übrigens durch Verändern ein Einrückung im Quelltext korrigieren und es würde mich nicht wundern, wenn er genau dadurch reingekommen ist. Und das ist genau das, was ich an Python hasse.

[obrecht]

Ich habe hier zwei i-Telex-System und ganz viele Dienst laufen. Ich weiß schon wie das eingerichtet werden muss.

Sorry, das hatte ich auch nie bezweifelt

[obrecht]

Jetzt muss ich mich auf meinen alten Tage noch mit Python beschäftigen. Das wollte ich eigentlich vermeiden. Ich hasse diese Sprache.

Ich habe im Quelltext nachverfolgt, warum eine TCP-Verbindung zustande kommt und dann piTelex die Verbindung sofort beendet.
Meiner Meinung nach ein Bug im Selbsttest (Selbstanruf). Da wird nämlich nur geprüft, ob man mit der eigenen IP-Nummer angerufen wird. Es erfolgt dann zwar noch ein Test auf das Selbsttest Magic Packet, aber der ist wirkungslos. Die Verbindung wird trotzdem beendet. Immer wenn man sich mit der eigenen IP-Nummer anruft. Wenn ich mich selber zum Testen anrufe, dann tue ich das immer mit der gleichen (externen) IP-Nummer.

Ich habe das hier mal korrigert und jetzt klappt das.

Der Fehler ließ sich übrigens durch Verändern ein Einrückung im Quelltext korrigieren und es würde mich nicht wundern, wenn er genau dadurch reingekommen ist. Und das ist genau das, was ich an Python hasse.

Kannst du deine Änderung näher erläutern (diff oder so)?

[detlef]

Kannst du deine Änderung näher erläutern (diff oder so)?

Es geht um diese Stelle hier in txDevITelexSrv.py.

vorher:

Code: Alles auswählen

if client_address[0] == self.ip_address:
           data = client.recv(128)
           if data == selftest_packet:
               # Signal self-test thread that we received the packet
               self.selftest_event.set()
           client.close()
           continue

jetzt

Code: Alles auswählen

if client_address[0] == self.ip_address:
           data = client.recv(128)
           if data == selftest_packet:
               # Signal self-test thread that we received the packet
               self.selftest_event.set()
               client.close()
               continue

Wobei ich noch nicht weiß, ob meine Änderung wirklich korrekt funktioniert, denn jetzt klaut sich die client.recv(128)-Anfrage möglicherweise die ersten empfangenen Bytes. Die sind dann wohl weg.

Das Problem tritt nur auf, wenn die IP-Adresse des Anrufers gleich der eigenen ist. Aber wenn ich über die externe IP anrufe, dann ist das immer der Fall, wenn sich beide hinter dem gleichen Router befinden. In diesem Fall wurde der Anruf als Selbstest interpretiert und die Verbindung geschlossen.

Einmal bei Copy&Paste nicht aufgepasst und der Programmcode ist kaputt. Eine Spezialität von Python.