Telexforum.de

MCMLXXV hat geschrieben: ↑Di 25. Jul 2023, 18:04 Ich weiß nur, dass ich bei den ersten Versuchen bei allem was dahinter kam nur Fehlermeldungen bekam. Als ich den Neustart ausgeführt habe hat das dann zumindest funktioniert. Andere Fehler die mir damals aufgefallen sind sind mittlerweile erledigt.

Wenn das so wäre, dann würde sich Linux nicht als Server-Betriebssystem eignen.
Ich denke, dass die Fehlermeldungen andere Ursachen hatten.

Ich weiß halt nur, dass es dann gut war....

Ich habe jetzt mit Jochen zusammen ein paar Tests gemacht. Die Software und die Konfiguration scheinen ok zu sein.
Jochen geht von einem Hardwaredefekt am Ö-AGT aus.

Ich werde dazu morgen nochmal ein paar Messungen machen.

Achso, und nicht den Master-Branch verwenden sondern Testing. Muss man natürlich wissen, dass es den gibt.

detlef hat geschrieben: ↑Di 25. Jul 2023, 22:34 Achso, und nicht den Master-Branch verwenden sondern Testing. Muss man natürlich wissen, dass es den gibt.

Das Release Management hat auch noch Entwicklungspotenzial

obrecht hat geschrieben: ↑Di 25. Jul 2023, 23:07

detlef hat geschrieben: ↑Di 25. Jul 2023, 22:34 Achso, und nicht den Master-Branch verwenden sondern Testing. Muss man natürlich wissen, dass es den gibt.

Das Release Management hat auch noch Entwicklungspotenzial

Ich habe heute morgen gemessen und das sieht für mich nach einem Baudratenproblem aus. Das piTelex sendet nur mit der halben Baudrate zum lokalen FS. Das erklärt auch, warum zwei Zeichen gedruckt werden. Wenn ich die Baudrate auf 100 einstelle, dann klappt es mit dem Empfangen. Aber vermutlich wird dann zu schnell gesendet. Ich habe die Info an Jochen geschickt. Das muss es sich mal anschauen.

Ich habe nochmal eine Frage wegen der Porteinstellung in piTelex. Ich habe das vermutlich schonmal gefragt, aber schon wieder vergessen.
Ich kann ja in der Konfiguration nur einen TCP- Port angeben. Das ist der lokale Port vom piTelex aber das ist ja dann auch der Port, der an den Tln-Server gesendet wird. Also müssen der interne Port des piTelex und der öffentliche Port des Routers immer identisch sein, oder?

Der Port ist ja nur wichtig für eingehende Verbindungen.
Wenn der extern eingerichtete (und auch dem TNS bekannte) Port am Router auf einen internen anderen umgesetzt wird, und piTelex auf den intern eingestellten lauscht, sollte das funktionieren. Allerdings müsstest du dann alle Verbindungen zwischen deinen Lokalen Maschinen entweder auch über den TNS laufen lassen so dass sie wie externe Verbindungen aussehen, oder du müsstest in der 'userlist.csv' dein lokales Verzeichnis mit lokalen Adressen und Ports vorhalten.

Was ich jetzt nicht genau weiß ist, wie das TNS Update bei DynIP funktioniert, wo piTelex ja selbst seine Verbindungsdaten an den TNS liefert. Möglicherweise wird da der intern eingestellte Port geliefert, und das wäre dann ein KO Kriterium...

obrecht hat geschrieben: ↑Mi 26. Jul 2023, 10:44 Was ich jetzt nicht genau weiß ist, wie das TNS Update bei DynIP funktioniert, wo piTelex ja selbst seine Verbindungsdaten an den TNS liefert. Möglicherweise wird da der intern eingestellte Port geliefert, und das wäre dann ein KO Kriterium...

So ist das. Der in piTelex konfigurierte Port wird an den Tln-Server übermittelt und von ihm als öffentlicher Port verwendet. Deswegen müssen die Ports beim piTelex wohl zwigend identisch sein. Beim i-Telex ist der interne Port immer fest auf 134 und man kann den öffentlichen Port konfigurieren. Also im Prinzip genau andersrum.

Eigentlich vergebe ich meine öffentlichen Ports gerne selber und das sind nicht unbedingt die Ports, die lokal verwendet werden. Und wenn ich mehrere piTelex laufen habe, dann hätte ich gerne auf allen den gleichen lokalen Port. So wie das i-Telex immer die 134 verwendet. Ich habe ja hier auch noch die ganzen Dienste laufen. Und noch einige weitere Portfreigaben auf dem Router. Ich brauche da etwas Systematik, sonst blicke ich nicht mehr durch.

Aber ok, ist jetzt nicht soo entscheidend. Man kommt ja auch so zurecht.