TR064Utils - Neues HelperModul für TR064 und FritzBox

Begonnen von JoWiemann, 22 Juni 2015, 17:27:06

Vorheriges Thema - Nächstes Thema

JoWiemann

Hallo,

habe mal angefangen ein HelperModul, angelehnt an die HttpUtils oder FritzBoxUtils, zu schreiben. Doku fehlt leider noch, aber im Source ist ein Beispielaufruf hinterlegt.

Bitte ausgiebig begutachten, testen verändern. Soll halt mal ein Anfang sein.

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

Markus Bloch

Hallo Jörg,

finde ich grundsätzlich schick. Ich würde dir aber noch folgende Infos mit auf den Weg geben:

- Bitte beachte, dass Authentifizierung bei TR-064/... immer optional ist. Viele Parameter benötigen keine Authentifizierung. Generell ist die Vorgehensweise hier immer: Man setzt den eigentlichen Request ab, sollte eine Unauthorized kommen, so erstellt man den Auth-String und sendet den Request erneut mit dem Auth-String und bekommt dann die gewünschte Antwort

- Bitte versuche auf XML::LibXML zu verzichten. Eine gut design'te Regexp tut es hier auch.

- Die Parameter würde ich alle ohne "tr064_" Präfix wählen.

- ich würde die notwendigen TR-064 Parameter und HttpUtils Parameter in einem Hash unterbringen der dann direkt an HttpBlockingGet weitergereicht wird. So hat man mehr Flexibilität im Überschreiben von HTTP und TR-064 Parametern. Desweiteren Könnte man so ohne weiteres auch Non-Blocking HTTP anbieten

Viele Grüße

Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

JoWiemann

Hallo Markus,

danke für das Feedback. Werde mich dann mal auf den Weg machen und weiter bauen....

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

carlos

Warum machst du das eigentlich nicht mit SOAP::Lite wie in diesem Beispiel:

#!/usr/bin/perl -w

use strict;
use warnings;

use SOAP::Lite;

# consts
use constant {
   FRITZ_USER  => "dslf-config",
   FRITZ_PASS  => "your-password-goes-here",
   BASIC_URI   => "urn:dslforum-org:service:",
   BASIC_PROXY => "http://fritz.box:49000/upnp/control/deviceinfo",
   HTTPS_PROXY => "https://fritz.box:",
};

# zunächst fordern wie wie im ersten Beitrag den Security Port an
my $s = SOAP::Lite
      -> uri('urn:dslforum-org:service:DeviceInfo:1')
      -> proxy('http://fritz.box:49000/upnp/control/deviceinfo')
      -> getSecurityPort();

my $port = $s->result;
print "Using TCP port $port for Fritzbox access.\n";

# jetzt müssen wir die Zertifikatsüberprüfung abschalten
BEGIN {
   $ENV{PERL_LWP_SSL_VERIFY_HOSTNAME}=0;
}

undef $s;

# hier die Abfrage der externen IP
$s = SOAP::Lite
    -> uri(BASIC_URI . "WANPPPConnection:1")
    -> proxy(HTTPS_PROXY . $port . "/upnp/control/wanpppconn1", ssl_opts => [ SSL_verify_mode => 0 ] )
    -> getExternalIPAddress()

print "External IP is currently: " . $s->result . "\n";

# dieser Code authentifiziert an der Box
sub SOAP::Transport::HTTP::Client::get_basic_credentials {
    return FRITZ_USER => FRITZ_PASS;
}


Das funktioniert gut, damit habe ich schon einige Calls  von hier getestet:
http://avm.de/service/schnittstellen/
getestet.

Gruß
Carlos
FHEM svn auf Intel NUC mit proxmox,1 UDOO, 3 Raspberry Pi, signalduino, nanoCUL, div. Homematic Komponenten, toom Baumarkt Funksteckdosen, einige sonoffs, hue, shelly

JoWiemann

Hallo Carlos,

mit den HttpUtils kann man halt auch non Blocking arbeiten. Fhem soll halt nicht ausgebremst werden. Sobald mit Blocking alles funktioniert werde ich auf non Blocking umstellen.

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

JoWiemann

Zitat von: Markus Bloch am 22 Juni 2015, 17:42:58

- Bitte versuche auf XML::LibXML zu verzichten. Eine gut design'te Regexp tut es hier auch.

- Die Parameter würde ich alle ohne "tr064_" Präfix wählen.

- ich würde die notwendigen TR-064 Parameter und HttpUtils Parameter in einem Hash unterbringen der dann direkt an HttpBlockingGet weitergereicht wird. So hat man mehr Flexibilität im Überschreiben von HTTP und TR-064 Parametern. Desweiteren Könnte man so ohne weiteres auch Non-Blocking HTTP anbieten


Hallo Markus,

habe diese drei Hinweise umgesetzt.

Anbei die überarbeitete Version.

Grüße Jörg

Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

JoWiemann

Hallo,

neues Update:

warnings bereinigt und etwas optimiert.

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

JoWiemann

Hallo,

und jetzt werden auch noch Services ohne Anmeldung unterstützt. Geprüft wird zunächst, ob die Abfrage ohne Anmeldung funktioniert, wenn ja, dann Ergebnis, wenn nein, dann mit Anmeldung.

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

Markus Bloch

Hallo Jörg,

sieht schon echt super aus. Gute Arbeit!

Eine Frage. Wie kommst du auf:

my $pattern = "\<BODY\>\<H1\>(401 Unauthorized)\<\/H1\>\<BR\>";

  return(undef, $data) unless($data =~ m/$pattern/sg);


?

Normalerweise müsste in diesem Fall auch $hash->{code} eq "401" sein und es müsste normalerweise eine SOAP Challenge Response kommen. So kenne ich es von Huawei Geräten zumindest. Leider fehlt mir aktuell mal wieder die Zeit das genauer mit meiner FritzBox auszutesten und zu probieren. Wir nutzen dieses Protokoll bei uns auf Arbeit an DSL-Routern um Parameter zu setzen und auszulesen (keine Funktionsaufrufe, so wie du das aktuell machst). Dort ist es so das beim Parameter lesen dies ohne Authentifizierung direkt möglich ist und beim schreiben anschließend ein SOAP Challenge Message kommt (mit HTTP Code 200).

Gruß
Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

JoWiemann

Hallo Markus,

ich habe einfach mit einigen Services/Actions getestet, die ohne Anmeldung aufgerufen werden. Als XML kam halt immer folgendes zurück:

<HTML><HEAD><TITLE>401 Unauthorized (ERR_ACCESS_DENIED)</TITLE></HEAD><BODY><H1>401 Unauthorized</H1><BR>ERR_ACCESS_DENIED<HR><B>Webserver</B> Tue, 23 Jun 2015 20:52:24 GMT</BODY></HTML>

Das mit $hash->{code} eq "401" kannte ich nicht. Ich taste mich einfach immer mehr in das Thema rein. (Ich war halt als Entwickler nur in der Zeit von 1992 bis 1995 mit Assembler, Cobol und Fortran tätig und nutze Fhem einfach um meine grauen Zellen zu trainieren).

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

Markus Bloch

Hallo Jörg,

ich habe heute mal auf Arbeit nochmal genauer geschaut, wie wir bei uns TR-064 ansprechen. Wie bereits gesagt, feuern wir einen Request erstmal auf doof auf das Opfer. Sollte es sich dagegen wehren, gibt es eine Response mit 401 Unauthorized. In diesem Falle wird auch ähnlich wie bei der FritzBox ein kleines HTML ausgeliefert. Das Interessante an der Antwort ist aber der Header. Dieser enthält ein WWW-Authenticate Header mit einer Digest-Challenge. Anschließend setzen wir den selben Request nochmal ab samt HTTP Digest Authentifikation-Header. Wir machen also keine Authentifizierung auf SOAP Basis im SOAP Header, so wie es aktuell in deinem Modul implementiert ist, sondern eine HTTP Digest Authentifizierung.

Mit der korrekten Authentifizierung erhalten wir dann auch direkt die entsprechende SOAP Response auf unsere Anfrage.

Ob dieses Szenario so auch für die FritzBox gilt ist natürlich fraglich. Auf Arbeit kann ich es leider aktuell nicht testen wie sich andere DSL-Router bei der Authentifizierung verhalten, ob sie auch HTTP Authentifizierung können. Es könnte nämlich sein, dass der jetztige Mechanismus in deinem Modul eine AVM-spezifische Herangehensweise ist.

Gruß
Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

JoWiemann

Hallo Markus, AVM hat ungefähr vor zwei Jahren die Authentifizierung auf Grund von Angreifbarkeit aus dem Netz bei aktivierter Fernwartung überarbeitet. Es gab dazu auch mal einen Artikel in der C't.


Grüße Jörg

Gesendet von iPhone mit Tapatalk
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

Markus Bloch

Hallo Jörg,

wolltest du nochmal eine neue Version bereit stellen? Wie willst du dann eigentlich generell mit dem Modul weiter verfahren (Stichwort: einchecken)?

Gruß
Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

JoWiemann

Hallo Markus,

danke für die Nachfrage. Im Moment bin ich beruflich wieder stärker eingespannt. Von daher bleibt privat einiges erst einmal liegen. Die Frage, die ich mir stelle ist, ob das Modul zur Anwendung kommen wird und sich damit ein einchecken lohnt. Ich werde, wenn ich wieder etwas mehr Zeit habe, daran weiter arbeiten. Einfach um zu lernen.

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

rudolfkoenig

#14
Da angeblich via TR064 die Spannungsdaten der DECT Geraete zu finden sind (was mit dem aktuellen FBAHAHTTP Interface nicht mehr geht), habe ich das Modul von Jo umgebaut auf nonblocking, und ich habe auch ein primitives "Frontend" (s.u) dazugebaut, damit man einfacher experimentieren kann. Falls niemand ein Veto einlegt, werde ich es einchecken. Folgende "Doku" steht am Anfang des Moduls:

Zitat# Examples, result is written into the FHEM-log
# { setKeyValue("TR064_user", "replaceMe") }
# { setKeyValue("TR064_password", "replaceMe") }
#
# { TR064Cmd("DeviceInfo:1", "GetSecurityPort") }
# { TR064Cmd("WANCommonInterfaceConfig:1", "GetCommonLinkProperties") }
# { TR064Cmd("Time:1", "GetInfo") }
# { TR064Cmd("X_AVM-DE_OnTel:1", "GetPhoneBook", {NewPhonebookID=>0}) }
# { TR064Cmd("X_AVM-DE_Homeauto:1", "GetGenericDeviceInfos", {NewIndex=>0}) }
TR064Cmd ist zum Experimentieren in der FHEM-Kommandozeile gedacht, Module sollten TR064_Action direkt aufrufen. Wie man das macht, sieht man in TR064Cmd.

Das Ergebnis fuer den Homeauto Aufruf schaut so aus:
2017.11.14 19:53:48.847 1: $VAR1 = {
          'NewHkrIsValid' => 'INVALID',
          'NewFunctionBitMask' => '896',
          'NewAIN' => '08761 0002049',
          'NewTemperatureIsValid' => 'VALID',
          'NewHkrIsEnabled' => 'DISABLED',
          'NewSwitchIsValid' => 'VALID',
          'NewHkrReduceVentilStatus' => 'CLOSED',
          'NewTemperatureCelsius' => '205',
          'NewHkrSetTemperature' => '0',
          'NewHkrIsTemperature' => '0',
          'NewPresent' => 'CONNECTED',
          'NewTemperatureIsEnabled' => 'ENABLED',
          'NewHkrReduceTemperature' => '0',
          'NewSwitchLock' => '0',
          'NewSwitchState' => 'ON',
          'NewMultimeterPower' => '5757',
          'NewFirmwareVersion' => '03.87',
          'NewHkrSetVentilStatus' => 'CLOSED',
          'NewHkrComfortTemperature' => '0',
          'NewSwitchIsEnabled' => 'ENABLED',
          'NewProductName' => 'FRITZ!DECT 200',
          'NewHkrComfortVentilStatus' => 'CLOSED',
          'NewDeviceName' => 'Fernseher',
          'NewDeviceId' => '16',
          'NewMultimeterEnergy' => '2860049',
          'NewMultimeterIsValid' => 'VALID',
          'NewSwitchMode' => 'MANUAL',
          'NewMultimeterIsEnabled' => 'ENABLED',
          'NewManufacturer' => 'AVM',
          'NewTemperatureOffset' => '0'
        };

Wer mir zeigt, wo man da die Spannungsdaten findet, der wird gelobt :)