encoding für web und telnet

Begonnen von justme1968, 05 August 2013, 12:26:48

Vorheriges Thema - Nächstes Thema

rudolfkoenig

Dieser patch ist aber noch nicht ganz ok, nach connect muss ich zweimal return tippen, um zu meinem Prompt zu kommen. Habs erstmal nicht eingecheckt.

Das Problem hat hier vermutlich damit zu tun, dass telnet.pm im Normalfall kein Telnet Protokoll spricht, sondern nur einen dummen socket anbietet.

Erst beim gesetzten Passwort faengt telnet.pm an telnet Escape-Sequenzen zu versenden, um das Echo abzuschalten.

justme1968

ich verwende telnet immer ohne prompt weil der beim copy und paste ziemlich im weg ist und war schon drauf und dran einen patch zu bauen den prompt abzuschalten.

das man jetzt zwei mal return drücken muss statt ein mal ist mir noch gar nicht aufgefallen.

es hat tatsächlich mit den iac sequenzen zu tun. aber nicht damit das es zu wenig sind sondern eine mehr als vorher. fhem sendet ja jetzt am anfang dem client das er auf binär umschalten muss. dafür sendet der client am anfang eine bestätigung. da fhem das telnet im line mode betreibt wird die bestätigung von client an fhem mit dem ersten return gesendet. d.h. d.h. das erste return sendet nicht wirklich eine leere nachricht sondern enthält die unsichtbare bestätigung.

wenn du die drei zeilen        if( $cmd =~ s/\xff(\xfb|\xfd)(.)// ) {
          #syswrite($hash->{CD}, sprintf("%c%c%c", 255, (ord($1)==253?251:253), ord($2)));
        }
die in meinem patch vor dem latin1ToUtf8 stehen etwas weiter nach vorne genau zwischen    $gotCmd = 1;
    if($cmd) {
schiebst müsste es wieder passen mit dem prompt nach dem ersten return.

edit: und als patch.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

rudolfkoenig

> ... müsste es wieder passen mit dem prompt nach dem ersten return.

Stimmt, obwohl ich es noch nicht verstehe wieso.

Beim analysieren ist mir aber aufgefallen, dass ich in diesem Form das encoding patch (noch) nicht akzeptieren kann, und habe es deswegen erstmal komplett entfernt.

Grund: telnet.pm sendet mit dem encoding Patch direkt nach dem connect ein Telnet-Kommando (==Escape-Sequenz) um auf Binaer zu schalten, und dies wird etliche Clients (FHEM2FHEM, manche mobile Frontends, fhem.pl im client mode) verwirren.
Ich gebe zu, das ist (teilweise) auf meinem Mist gewachsen, da ich die einfache Socket Verbindung telnet genannt habe, ist aber nunmal so. Bisher hat telnet nur dann Escape-Sequenzen verschickt, wenn Passwort aktiviert war, was auch nicht konsequent ist.

Folgendes ist mein Vorschlag, vielleicht hast du aber was besseres:

- ein Attribut, was gesetzt sein muss, um einem telnet Instanz zu erlauben, telnet-Befehle zu schicken, dieses Attribut wird mit passwort automatisch aktiviert. Was default sein soll, ist mir noch nicht klar.

- FHEM2FHEM bzw. "fhem.pl in client-mode" muss das parsen von escape Sequenzen beigebracht werden, und damit zusammen auch das verstehen/senden von Passwoertern. Sinnvoll waere auch die Unterstuetzung von SSL.

Kommt auf meine TODO Liste, wird aber ein bisschen dauern.

justme1968

ich denke es ist schade die encoding patches wieder raus zu nehmen:

- der patch für die ausgabe verwendet keine iac kommandos und ändert auch am verhalten nichts so lange nicht per attribut oder kommando auf latin1 geschaltet wird. d.h es sind mit keinem client probleme zu erwarten.

- der patch für die eingabe sendet ein iac kommando an den client. die iac kommandos sind seit etwa 30 jahren standardisiert. es sollte auf der welt keinen telnet client geben der sie nicht unterstützt (im schlimmsten fall ignoriert). auch hier sollten keine probleme mit dem client zu erwarten sein.

ich würde die encoding geschichten auch ungern an das password knüpfen. beides hat nicht wirklich etwas miteinander zu tun ausser das für das password auch iac sequenzen verwendet werden (wenn auch andere: um das echo zu unterdrücken)

die iac sequenz für den binary mode sollte im übrigen nicht mehr probleme machen als die für das password. wenn ein client das eine kann kann er auch das andere. das schlimmste ist das er antwortet er untersütz binary nicht. dann geht halt die eingabe von umlauten nicht.

mein vorschlag:

- den ausgabe patch unverändert drin zu lassen. er sendet keine iac kommandos und wird jetzt schon erst dann aktiv wenn man das encoding explizit setzt.

- den eingabe patch so abändern das das iac kommando für binary nur dann gesendet wird wenn das encoding attribut überhaupt gesetzt ist oder wenn das encoding kommando verwendet wird. damit wäre auch die eingabe rückwärtskompatibel so lange man das encoding nicht verwendet.

ich filtere die iac kommandos für binary und die antwort darauf jetzt schon raus. damit sollte fhem2fhem direkt schon gehen. mit der obigen änderung aber auf jeden fall.

auf die todo list würde ich dann das 'richtige' iac handling sezten und vor allem einen character mode für telnet damit man z.b. mit den cursor tasten in der history zurück gehen kann und eine zeile editieren kann.

die passwörter sind eigentlich ganz normale in band daten. die iac kommandos nicht. der zusammenhang ist nur das echo abschalten. das wäre bei fhem2fhem fast egal.

ssl könnte man auch komplett ausserhalb sehen wenn man direkt ein IO::Socket::SSL verwendet.

edit: es gibt zwar einen standard um tls innerhalb der telnet session zu starten (so wie es für imap auch zwei versionen gibt - direkt auf einem ssl soket oder mit start tls). das unterstützt aber tatsächlich fast kein client weil der standart noch relativ 'neu' ist und es zu der zeit schon ssh gab das telnet im prinzip völlig verdrängt hat.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

justme1968

der vorschlag von oben als patch. so lange nicht das encoding per attribut oder kommando gesetzt wird ist alles beim komplett beim alten.

ich kann mir zwar keinen client vorstellen der mit dem binary mode probleme hat. aber wenn du ganz sicher gehen willst würde es so gehen.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

rudolfkoenig

Ich will vor dem Anwenden dieser Patch wenigstens FHEM2FHEM und fhem.pl anpassen, damit beim gesetzten Attribut diese beiden keine Probleme bekommen.

justme1968

meiner meinung nach gehört jede anpassung in das telnet modul. es sollte für sender und empfänger transparent sein.

für den fall ohne passwort sollte das schon so sein. das iac do binary das die server seite sendet wird von der client seite gelesen und verworfen.

da das password handling eine art sonderfall ist muss man das gleiche da eventuell noch mal tun.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

rudolfkoenig

Habs (wieder) eingespielt.

fhem.pl in Kommando-Mode kann es inzwischen filtern (genauso wie die Passwort-Zeile), FHEMWEB & Blocking.pm muesste noch angepasst werden, aber damit warte ich solange, bis es jemanden stoert :)

justme1968

sehr schön. ich hatte es schon sehr vermisst. und inzwischen die eingabe sogar noch mehr als die ausgabe.

kann man eigentlich ein list auf einen raum machen?
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

rudolfkoenig