57_Calendar - mal wieder Probleme beim Abruf der Kalenderdaten

[LaLeLu]

So, ich habe die Ursache bei mir gefunden.
Als ich fhem zum Raspberry umzog, funktionierte das Senden von (Google-)Emails mittels DebianMail nicht. Es verursachte die Fehlermeldung:
    "invalid SSL_version specified at /usr/share/perl5/IO/Socket/SSL.pm line 332"

Nach einer Anleitung habe ich folgendes mit Erfolg geändert:
In der Datei    /usr/share/perl5/IO/Socket/SSL.pm

ersetzte ich die Zeile 1490
       m{^(!?)(?:(SSL(?:v2|v3|v23|v2/3))|(TLSv1[12]?))$}i
durch:
       m{^(!?)(?:(SSL(?:v2|v3|v23|v2/3))|(TLSv1[12]?))}i

Danach funktioniert der Versand der Emails. In meiner Logdatei konnte ich aber rekonstruieren, dass ab diesem Zeitpunkt der Abruf des Google-Kalenders mittels 57_Calendar nicht mehr funktioniert.
Nachdem ich heute die Änderung zurückgenommen habe, funktioniert der Abruf des Google-Kalenders, aber wie zu Erwarten das Senden der Google-Mails nicht mehr.

Leider verstehe ich zu wenig von den Zusammenhängen, dass ich wirklich weiß, was ich da tue.
Ich hoffe, dass dies zur Klärung beiträgt und dass auch mir geholfen werden kann. Falls ich für dieses Problem besser einen neuen Thread eröffne, sagt es mir bitte.

[betateilchen]

wie hast Du denn das SSL Paket auf den Raspberry installiert?

[LaLeLu]

Mein Vorgehen war:

lt.: http://www.fhemwiki.de/wiki/E-Mail_senden#Raspberry_Pi

   sudo apt-get update
   sudo apt-get install sendEmail
in der 99_myUtils folgende Unterroutine einfügen:

Code Auswählen Erweitern

sub
DebianMail
{
my $rcpt = shift;
my $subject = shift;
my $text = shift;
my $ret = "";
my $sender = "Email\@gmail.com";
my $konto = "Email\@gmail.com";
my $passwrd = "pwegal123";
my $provider = "smtp.gmail.com";
Log 1, "sendEmail RCP: $rcpt";
Log 1, "sendEmail Subject: $subject";
Log 1, "sendEmail Text: $text";

$ret .= qx(sendEmail -f '$sender' -t '$rcpt' -u '$subject' -m '$text' -s '$provider':587 -xu '$konto' -xp '$passwrd' -o tls=yes);
$ret =~ s,[\r\n]*,,g;    # remove CR from return-string
Log 1, "sendEmail returned: $ret";
}


Der Test durch Eingabe in Terminal möglich:
sendEmail -f 'plalelula@gmail.com' -t 'peter.kansy@gmail.com' -u 'Test' -m 'Testbody' -s 'smtp.gmail.com' -xu 'plalelula@gmail.com' -xp 'pwegal123' -o tls=yes

Anmerkung: Ich habe im Code  tls=no auf tls=yes geändert.

[LaLeLu]

Vielleicht habe ich falsch geantwortet:


Vor dem gerade beschriebenen Vorgehen habe ich durchgeführt:



########################################################################################################
## Raspberry Pi   Allgemein
##
## Das Debian-System allgemein auf den neuesten Stand bringen:
## (hier nur als allgemeine Beschreibung eingefügt)
## sudo apt-get update
## sudo apt-get upgrade
## sudo apt-get autoremove
## Die erste Anweisung holt sich ein Verzeichnis der aktuelle Pakete, die zweite Anweisung lädt neuere Versionen
## runter und installiert sie. Die letzte Anweisung sorgt dafür, dass unbenötigte Packete deinstalliert werden.
########################################################################################################

[rudolfkoenig]

@betateilchen: kannst du bitte bestaetigen, dass du HTTPS (und nicht HTTP) benoetigst? Diese Schicht kenne ich nicht so genau, kann aber vorstellen, dass in so einem Fall shutdown kontraproduktiv ist. Erklaert immer noch nicht, wieso alt tut, und neu nicht oder wieso es bei anderen tut und bei dir nicht.
@LeLeLu: um das Problem zu verstehen wuerde ich in SSL.pm den String ausgeben

[LaLeLu]

@LeLeLu: um das Problem zu verstehen wuerde ich in SSL.pm den String ausgeben

Sorry, aber der Hinweis ist mir zu knapp. Soll ich tracen?
Als Gegenleistung kann ich gerne mal eine knifflige Excel-Frage beantworten

[betateilchen]

@betateilchen: kannst du bitte bestaetigen, dass du HTTPS (und nicht HTTP) benoetigst?

Ich benötige https nicht, aber Google will es so Die URL der privaten ICAL Adresse ist immer eine https Adresse. Und dann passieren beim Aufruf oft auch noch 30x-redirects von Google-Seite.
Aber es erklärt nicht nur nicht, warum es bei "alt" tut und bei "neu" nicht mehr, sondern auch nicht, warum es bei "neu" manchmal (auf bestimmten Plattformen) tut und auf anderen nicht.

[LaLeLu]

 

wie hast Du denn das SSL Paket auf den Raspberry installiert?

Hier jetzt hoffentlich die richtige Antwort:
Ich hatte schon Deinem Tipp (aus diesem Forum) folgend libwww-perl installiert:
root@FHEMRPI:/usr/share/perl5/IO/Socket# sudo apt-get install libwww-perl
Reading package lists... Done
Building dependency tree       
Reading state information... Done
libwww-perl is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.

Damit müsste die richtige ssl.pm installiert sein?

[betateilchen]

Heute hab ich mal mit unseren Crypto-Spezialisten gesprochen, dabei kam folgendes raus:  Es gab/gibt wohl Probleme mit einer bestimmten Version der SSL-Bibliotheken unter Linux, die zu genau solchen Problemen in der https-Kommunikation führen können. Empfohlen wird ein Downgrade der libssl von Version 1.0.1 (falls installiert) auf 1.0.0.

Jetzt muss ich mal suchen, ob ich irgendwo die passenden Pakete für mein Beaglebone finde, dann kann ich weitertesten.

[rudolfkoenig]

Sorry, aber der Hinweis ist mir zu knapp. Soll ich tracen?

Ich meinte in der Zeile 1490 in SSL.pm (vor dem erwaehnten regexp-check) die Zeile

Code Auswählen Erweitern

print "SSL: $_\n";
einfuegen, und fhem mit

Code Auswählen Erweitern

attr global logfile -
im terminal starten.
Bei mir kommen dann fuer jede telnet/FHEMWEB Verbindung zwei Zeilen:

Code Auswählen Erweitern

SSL: SSLv23
SSL: !SSLv2


[LaLeLu]

Danke Rudolf!

das Ergebnis ist gleich Deinem. Ich poste mal die Meldungen bis Calendar. Vielleicht hilft dies:

pi@FHEMRPI~ $ sudo /etc/init.d/fhem start Starting fhem...
2014.02.01 17:56:37.083 1: Including fhem.cfg
2014.02.01 17:56:37.673 2: Perfmon: ready to watch out for delays greater than one second
2014.02.01 17:56:37.847 2: eventTypes: loaded 1774 events from ./log/eventTypes.txt
2014.02.01 17:56:37.986 3: Opening myCUL device /dev/ttyACM0
2014.02.01 17:56:38.180 3: myCUL device opened
2014.02.01 17:56:38.305 3: myCUL: Possible commands: BCFiAGMRTVWXefmltux
2014.02.01 17:56:38.451 1: HMLAN_Parse: myHMLAN new condition disconnected
2014.02.01 17:56:38.453 3: Opening myHMLAN device 192.168.2.34:1000
2014.02.01 17:56:38.481 3: myHMLAN device opened
2014.02.01 17:56:38.485 1: HMLAN_Parse: myHMLAN new condition init
2014.02.01 17:56:39.083 3: WEB: port 8083 opened
2014.02.01 17:56:39.128 3: WEBphone: port 8084 opened
2014.02.01 17:56:39.137 3: WEBtablet: port 8085 opened
2014.02.01 17:56:39.312 3: telnetPort: port 7072 opened
2014.02.01 17:56:39.318 1: Including ./PKDevices.cfg
2014.02.01 17:56:39.370 3: FHEM2FHEM opening FB2RPi at 192.168.2.1:7072
2014.02.01 17:56:39.375 3: FHEM2FHEM device opened (FB2RPi)
SSL: SSLv23
SSL: !SSLv2
2014.02.01 17:56:40.195 1: Calendar FHEMKalender: Could not retrieve file at URL
2014.02.01 17:56:42.854 3: [HourCounter] HourCounter_Initialize.156 Init Done with Version 0.99.d - 03.12.2013 (john)
2014.02.01 17:56:42.856 2: [Kueche_Licht_HC] HourCounter_Define.165 parameters: Kueche_Licht_HC HourCounter Kueche_Licht.on Kueche_Licht.off

[cornelius fillmore]

Bedeutet dies nun das die Google-Kalender Abfragen wieder funktionieren?

Oder was muss der Laie nun tun, das es funktioniert?

[betateilchen]

Bei mir funktionieren die G-Calendar auf zwei von drei Systemen nur deshalb, weil ich im 57_Calendar die HttpUtils nicht mehr verwende.

Die Lösung mit noshutdown hat auch nicht dauerhaft funktioniert, dadurch ergaben sich reproduzierbare Probleme an anderen Stellen.

[cornelius fillmore]

Bei mir funktionieren die G-Calendar auf zwei von drei Systemen nur deshalb, weil ich im 57_Calendar die HttpUtils nicht mehr verwende.

Wie hast du dies denn gemacht?
Bitte Info

[betateilchen]

einfach nachlesen, das steht im vierten oder fünften Beitrag dieses Threads.