WebSocket via DevIO?

Begonnen von KernSani, 06 April 2020, 07:43:45

Vorheriges Thema - Nächstes Thema

KölnSolar

#60
Oh Mann, Rudi.

Und wenn man nicht mehr weiter weiß, macht man ein update u. shutdown/restart.

Und dann klappts auch. Ich spekuliere: die httputils wurde auch erneuert. Ich hatte aber immer nur DevIo aus dem SVN manuell geladen.  :-\

Ich kann Dir aber schon einmal
Zitat
ZitatZitat

Abgesehen davon wuesste ich nicht, warum Ping/etc das Modul interessieren sollte.

Das sehe ich dann, wenn es mal mit dem Modul klappt.... ;)
beantworten: nach 20s sendet der Server einen ping. Ohne ein pong des FHEM-client schließt er die Verbindung. FHEM schickt zwar den Pong, die Verbindung wird aber trotzdem vom Server geschlossen. (möglicherweise, weil es nicht "masked" gesendet wurde ?

Trotz richtiger Daten, löst das simple_write auch ein disconnect aus. Mit Wireshark konnte ich feststellen, dass der Unterschied darin liegt, dass wir "unmasked" senden. Hier hab ich was gefunden, dass es zwingend erforderlich wäre.

Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

rudolfkoenig

ZitatIch spekuliere: die httputils wurde auch erneuert.
Ja, die Aenderung ist fuer websocket relevant.

KölnSolar

Während Du geantwortet hast, hatte ich getestet, den Post editiert... Ich wiederhol dann mal meine unschöne Feststellung als trigger für einen change im Thread,

Trotz richtiger Daten, löst das simple_write auch ein disconnect aus. Mit Wireshark konnte ich feststellen, dass der Unterschied darin liegt, dass wir "unmasked" senden. Hier hab ich was gefunden, dass es zwingend erforderlich wäre. Gar nicht gut . >:(

Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

rudolfkoenig

Danke fuer die Recherche. Ich habe die Begruendung gelesen: entweder waren das Anfaenger, oder sie haben was in der Begruendung nicht erwaehnt.

Wie auch immer, ich habe jetzt die DevIo Routinen so umgestellt, dass alles maskiert gesendet wird.
FHEM und echows kommt damit zurecht, sol.eet.energy ist immerhin nicht sofort beleidigt, und wartet auf mehr Daten.

KölnSolar

#64
Danke für die Implementierung. Ich hatte mit größeren Schwierigkeiten gerechnet, weil wohl auch die in Perl enthaltene "rand" nicht den Anforderungen genügen soll.(Stichwort füge ich später aus dem RFC hinzu)Nicht im RFc, sondern in CPAN steht zum in Protocol::Websocket verwendeten Modul:
Zitatcryptographically-secure replacement for Perl's built-in rand function

Mittlerweile hatte ich auch noch weiter recherchiert: In der RFC6455(Ich editier hier gleich noch den Link rein) steht auch, dass der Client IMMER maskiert senden muss. Der Server nicht. Die Begründung steht dort auch genau beschrieben.

Und funktionieren tut es leider auch nicht.  :'( Aber nachdem ich Deinen Fehler korrigiert habe, klappt es. Dass ich das noch erleben darf. 8)
Spaß beiseite. Bei der Längenberechnung ist noch etwas faul. Bei der Länge > 125 u. < 65536 muss das erste byte chr(0xFE) lauten(ich guck da auch nochmal im RFC warum).

Einen Wunsch habe ich noch: Nachdem ich gestern überfliegend im RFCxxx geblättert habe, ist mir auch untergekommen, dass bei einem close immer ein Statuscode mitgegeben wird. Das Log zeigt auch die payload von 2 bytes an
2020.06.03 18:39:19 5: Websocket msg: OP:8 LEN:2 MASK:0 FIN:1Wireshark zeigt den sogar anStatus code: Invalid frame payload data (1007) Wenn wir den Statuscode noch mitprotokollieren könnten ?

Danke&Grüße
Markus

Edit: das pong geht auch noch in die Hose. Nach 20s Nichtstun closed der Server die Verbindung wg. des "unzulässigen" pongs.

Edit2:
Zitatframe-payload-length    = ( %x00-7D )
                            / ( %x7E frame-payload-length-16 )
                            / ( %x7F frame-payload-length-63 )
                            ; 7, 7+16, or 7+64 bits in length,
                            ; respectively
also doch bei Maskierung:
0x80-FD  f. < 125    (richtig implementiert)
0xFE       f. > 125 u. < 65536 (noch falsch)
0xFF       f. > 65536 (noch falsch)
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

rudolfkoenig

ZitatIn der RFCxxx(Ich editier hier gleich noch den Link rein)
Der Link zu rfc6455 steht in DevIo.pm/DevIo_DecodeWS() als Kommentar.
Meine Bemerkung von vorhin bezog sich auf deren Begruendung fuer die Notwendigkeit der Mask bei Clients.

ZitatBei der Länge > 125 u. < 65536 muss das erste byte chr(0xFE) lauten(ich guck da auch nochmal im RFC warum).
Brauchst Du nicht, liegt daran, dass mein Kopfrechnen mich bei 0x7e|0x80 im Stich gelassen hat.
Danke fuer den Hinweis, habs korrigiert.

ZitatWenn wir den Statuscode noch mitprotokollieren könnten ?
Habs gemacht, jetzt sagt sol.eet.energy, wenn ich ihm "list" schicke:
2020.06.03 20:07:01.300 5: Websocket msg: OP:8 LEN:35 MASK:0 FIN:1
2020.06.03 20:07:01.300 5: Websocket close, reason: 1000 (normal) Error: Please provide valid JSON.


rudolfkoenig

ZitatEdit: das pong geht auch noch in die Hose. Nach 20s Nichtstun closed der Server die Verbindung wg. des "unzulässigen" pongs.
wsecho hat nix gegen meinen pongs. Was passt denn deinem Server nicht?

KölnSolar

Mann bist Du fix....

ZitatA Pong frame sent in response to a Ping frame must have identical
   "Application data" as found in the message body of the Ping frame
   being replied to.
steige noch nicht ganz hinter Dein .WSBUF  :-[
Ich gucke Wireshark....
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

rudolfkoenig

Zitatsteige noch nicht ganz hinter Dein .WSBUF  :-[
Das sollst Du auch nicht.

Habe DevIo_Ping() hinzugefuegt (tut nur bei websocket was), und ich gebe die Ping/Pong Application-Data jetzt auch aus.
Pong hat auch vorher Application Data brav zurueckgeschickt.
Gibt es einen Hinweis, dass Ping Application Data enthaelt (siehe LEN: bei OP:9)?

KölnSolar

Wireshark sagt. 1. ping -> korrekter pong; 2. ping -> nichts passiert; nach 20s dann das close m. 1011(internal server  :-\)

FHEM.WSBUS: connected:empty, 1. ping:irgendwas, wird nach dem pong nicht gelöscht

Kannst Du damit was anfangen ? Oder soll ich was in Devio loggen, um dem Fehlerchen auf die Schliche zu kommen ?

edit:Und schon wieder warst Du zu schnell für mich. Hole mir die aktuelle DevIo........
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

KölnSolar

2020.06.03 21:09:42 3: [EE2] sol_local defined with host: Domain port: 9124
2020.06.03 21:10:02 4: [EE2] sol_local  Attempting to open websocket by DevIo
2020.06.03 21:10:02 3: Opening sol_local device ws:Domain:9124
2020.06.03 21:10:02 5: HttpUtils url=http://Domain:9124/
2020.06.03 21:10:02 4: [EE2] sol_local  what happens after opendevio ?
2020.06.03 21:10:02 4: IP: Domain -> IPofDomain
2020.06.03 21:10:02 5: HttpUtils request header:
GET / HTTP/1.1
Host: Domain:9124
User-Agent: fhem
Accept-Encoding: gzip,deflate
Sec-WebSocket-Key: AhWXoKfADXSTAplbMuBq6g==
Upgrade: websocket
Sec-WebSocket-Version: 13
Connection: Upgrade

2020.06.03 21:10:02 4: http://Domain:9124/: HTTP response code 101
2020.06.03 21:10:02 5: HttpUtils http://Domain:9124/: Got data, length: 0
2020.06.03 21:10:02 5: HttpUtils response header:
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: A5/ORmKJaBb+JjARcWiGFZQ/D9E=
Date: Wed, 03 Jun 2020 19:10:02 GMT
Server: Python/3.5 websockets/7.0
2020.06.03 21:10:02 5: [EE2] sol_local InitFn called from websocket DevIo
2020.06.03 21:10:02 3: sol_local device opened
2020.06.03 21:10:02 4: [EE2] sol_local - connecting to Websocket successful
2020.06.03 21:10:22 5: Websocket msg: OP:9 LEN:4 MASK:0 FIN:1
2020.06.03 21:10:22 5: Websocket ping: ‡...Oë
2020.06.03 21:10:22 4: [EE2] sol_local received websocket data: ><
2020.06.03 21:10:42 4: [EE2] sol_local received websocket data: ><
2020.06.03 21:11:02 4: [EE2] sol_local received websocket data: ><
2020.06.03 21:11:02 1: ws:Domain:9124 disconnected, waiting to reappear (sol_local)
2020.06.03 21:11:02 4: [EE2] sol_local websocket-connection seems to be closed

Ich seh da jetzt nix. Nach 20s der 1.ping(der pong erfolgt wohl korrekt). Nach weiteren 20s wird der ping nicht erkannt, was weitere 20s später zum close führt.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

rudolfkoenig

Da war noch eine Zeile vor dem Umbau uebrig, hat Aerger verursacht, falls ping Daten enthaelt.
Sollte jetzt behoben sein.

KölnSolar

Prima, jetzt klappts auch mit dem pong.

Und mein Modul liefert zyklisch readings.  8)

:-* :-* :-*

Die Tage knöpfe ich mir dann das SamsungAV vor...
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

KölnSolar

So ganz konnte ich doch noch nicht abschalten.  ::)

Im SamsungAV gebe ich beim websocket-upgrade-request einen Pfad und Parameter im header mit. Wie mach ich das denn bei DevIo_OpenDev()-websocket ?  :-\
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

rudolfkoenig

Habe DevIo erweitert:
- Pfad wird ab sofort weitergegeben:
  $hash->{DeviceName} = "wss:echo.websocket.org:443/hello";
- header kann man uebergeben:
  $hash->{header} = { "User-Agent", "FHEM!" };