hallo Allerseits!
ich versuche nun schon seit Wochen das Fhem auf meinem RASPI zu aktualisieren.
Leider scheitert in letzter Zeit ein Update immer mit o.a. Fehlermeldung.
Der Update startet zunächst fehlerfrei:
2015.02.19 20:43:18 1: UPD ./CHANGED
2015.02.19 20:43:18 1: UPD ./configDB.pm
2015.02.19 20:43:19 1: UPD ./fhem.pl
2015.02.19 20:43:19 1: UPD FHEM/00_CUL.pm
2015.02.19 20:43:20 1: UPD FHEM/00_FBAHA.pm
2015.02.19 20:43:20 1: UPD FHEM/00_HMLAN.pm
2015.02.19 20:43:20 1: UPD FHEM/00_HXB.pm
aber irgendwann kommt es zur Fehlermeldung:
2015.02.19 20:44:49 1: http://fhem.de/fhemupdate/FHEM/98_logProxy.pm: Can't connect(1) to http://fhem.de:80: IO::Socket::INET: connect: timeout
2015.02.19 20:44:49 1: 192.168.178.222:1000 disconnected, waiting to reappear (HMLAN)
2015.02.19 20:44:49 1: HMLAN_Parse: HMLAN new condition disconnected
2015.02.19 20:44:49 1: 192.168.178.222:1000 reappeared (HMLAN)
2015.02.19 20:44:49 1: HMLAN_Parse: HMLAN new condition init
FHEM ist danach natürlich nicht mehr zu gebrauchen und ich muss ein Backup einspielen. Bei zweimaligem fehlerhaften Versuch hintereinander (ohne shutdown restart) ist auch die automatische Sicherung im /var/fhem/restoreDir/<datum> nicht mehr zu gebrauchen. :(
Im dmesg finde ich folgende Meldungen:
[430507.063740] smsc95xx 1-1.1:1.0 eth0: link down
[430509.240422] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1
[430527.706037] smsc95xx 1-1.1:1.0 eth0: link down
[430542.370308] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
[430542.502069] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
[430542.504269] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[430573.340851] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Es sieht alles danach aus als würde der http download per perl das Netzwerkinterface zum abschmieren bringen.
Seltsamerweise habe ich die Probleme mit apt-get update / upgrade und während des normalen Betriebs nicht.
Hat von Euch irgend jemand eine Idee was da schief geht?
Danke und Gruß
Peter
Also spontan fällt mir nur ein: Netzteil?
Was hast Du für einen Raspi?
Welches Netzteil?
Gruß Otto
Ein RASPBerry B+ an einem 2A Netzteil. Das sollte eigentlich reichen.
Wie gesagt, apt-get geht fehlerfrei. Dabei dürften die Datenmengen bei apt eher größer sein.
Zitat von: ventusfahrer am 19 Februar 2015, 21:19:03
...FHEM ist danach natürlich nicht mehr zu gebrauchen und ich muss ein Backup einspielen....
Wieso das denn?
Das vorherige hat geklappt, was nicht mehr kommt wird auch nicht geändert.
Einfach ein shutdown restart von fhem und es läuft weiter!?
lass mich raten - Du hast eine Fritzbox als Verbindung ins Internet?
Zitat von: ventusfahrer am 19 Februar 2015, 22:31:04
Ein RASPBerry B+ an einem 2A Netzteil. Das sollte eigentlich reichen.
Wie gesagt, apt-get geht fehlerfrei. Dabei dürften die Datenmengen bei apt eher größer sein.
Die rote LED an Deinem Raspi blinkert manchmal oder ist die immer an?
Deine SD Karte ist keine aus den im Netz reporteten die Probleme machen?
@betateilchen: Warum hast Du die Fritzbox in Verdacht?
Ich habe auch Raspi und Fritzbox läuft astrein...
Gruß Otto
Zitat von: Otto123 am 20 Februar 2015, 18:09:54
@betateilchen: Warum hast Du die Fritzbox in Verdacht?
Ich habe auch Raspi und Fritzbox läuft astrein...
Gruß Otto
Das ist so eine Art Hassliebe ;D
Zitat von: Otto123 am 20 Februar 2015, 18:09:54
@betateilchen: Warum hast Du die Fritzbox in Verdacht?
Eigene Erfahrungen, insbesondere in Kombination mit Unitymedia bzw. KabelBW
http://forum.fhem.de/index.php/topic,28299.msg256360.html
Irgendwie hat's mich jetzt auch erwischt :(
2015-02-20 20:17:08 Global global UPD docs/commandref.html
2015-02-20 20:17:11 Global global UPD docs/commandref_DE.html
2015-02-20 20:17:15 Global global http://fhem.de/fhemupdate/docs/commandref_DE.html: Can't connect(1) to http://fhem.de:80: IO::Socket::INET: connect: timeout
Nach mehreren versuchen ist es dann aber doch komplett durchgelaufen.
Übrigens tut bei mir auch eine Fritz!Box (7490 DSL/VDSL) ihren Dienst. ???
OT-Frage: Was wäre denn die (oder eine gute) Alternative? DSL-Modem und WLAN-Router getrennt? Wenn ja, was ist da jeweils empfehlenswert?
Ich behaupte mal, die "Verbindung ins INET" ist nicht das maßgebliche Problem; schliesslich hat es ja bei mehreren vorher problemlos geklappt und tritt nicht immer (aber häufiger?) auf.
Da ein Timeout auftritt, könnte es auch an anderen Stellen liegen...
- an der Update-Funktion in FHEM
- an den Antwortzeiten von fhem.de
Du versuchst nicht zufälligerweise per UMTS zu updaten oder?
Hi auch ich habe bei einer Neu Installation auf dem neuen Raspberry Pi 2 dasselbe Phänomen ich nutze keine Fritzbox sondern einen DLINK Rrouter und auch bei mir ist das Problem wenn ich ein frisches FHEM 5.6 aufsetze und als erstes ein update durchführen möchte keine chance, bisher irgendwann willkürlich stoppt das update auch bei mir.
Wenn ich dann manuell die aktuellen dateien aus dem svn trunk mit denen auf dem server ersetze und fhem dann neustarte werden die module auch mit den aktuellen revisions-nummern geladen tippe ich dann um es nochmal zu überprüfen update check ein zeigt er mir dieselben updates wieder hat das noch jemand kann man das irgendwie richtig machen?
Zitat von: speex am 22 Februar 2015, 17:29:01
tippe ich dann um es nochmal zu überprüfen update check ein zeigt er mir dieselben updates wieder
Das ist völlig normal. Da in diesem Fall aber die aktuelle update.pm verwendet wird, solltest Du probieren, ob das Verbindungsproblem dann immer noch besteht.
Das Verbindungsproblem bleibt leider.
Gibt es hier neuigkeiten?
Auf meinem Raspberry PI 2 ist es mir bisher noch nicht einmal gelungen erfolgreich ein update einzuspielen.
Bisher übertrage ich die updates immer manuell aus dem SVN, ist dieses vorgehen Grundsätzlich kein problem denn mich störrt es schon das aus bisher für mich unerfindlichen Gründen das nicht funktioniert.
Auf meinem Intel NUC läuft das bei mir problemlos.
Unitymedia und einen TP-Link Router verwende ich noch.
Zugriffsrechte der Dateien sind mit Benutzer fhem und der Gruppe dialout belegt und zudem beschreibbar?
Ich hatte ebenfalls eine timeout-Meldung bei vergessener Anpassung von Rechten nach dem Umzug einer bestehenden Konfiguration und war erst verwirrt, da ein Rechtefehler hätte angezeigt werden sollen. Es lag letztlich an dieser, meiner Nachlässigkeit.
Vielen Dank für deinen Tipp, das hab ich ausser acht gelassen, jetzt funktionierts.
Nach meinem Umzug von Raspbery B+ auf RB2 ist dies mein einziges Problem:
Zitathttp://fhem.de/fhemupdate/controls_fhem.txt: Can't connect(1) to http://fhem.de:80: IO::Socket::INET: connect: Network is unreachable
Was habt Ihr / Wie mit den Rechten gemacht?
# Benutzer fhem, Gruppe dialout für alle Dateien rekursiv im FHEM-Installationsverzeichnis - wenn nicht geändert - setzen
chown -R fhem:dialout /opt/fhem
# alle Dateien im FHEM-Installationsverzeichnis zusätzlich mit dem Schreibattribut versehen; kann man davon übrigens nicht welche ausnehmen? Das ist so eigentlich nicht die feine Art.
chmod -R a+w /opt/fhem
habe nun auch die Rechte wie oben geschrieben angepasst.
Aber bei mir funktioniert das update noch immer nicht!
Can't connect(1) to http://fhem.de:80: IO::Socket::INET: connect: timeout
kann das an meiner Internetverbindung liegen? Beim update läuft mal mehr, mal weniger durch, bis diese Meldung erscheint.
Oder kann die Zeit bis zum timeout erhöt werden?
Gleiches Problem bei mir.
2015-05-08 10:45:19 Global global UPD www/images/default/remotecontrol/black_btn_SLOW_FORWARD.png
2015-05-08 10:45:19 Global global UPD www/images/default/remotecontrol/black_btn_SLOW_REWIND.png
2015-05-08 10:45:19 Global global UPD www/images/default/remotecontrol/black_btn_STATUS.png
2015-05-08 10:45:23 Global global http://fhem.de/fhemupdate/www/images/default/remotecontrol/black_btn_STATUS.png: Can't connect(1) to http://fhem.de:80: IO::Socket::INET: connect: timeout
Angeschlossen ist es direkt am Kabel Deutschland. Vielleicht mag der Webserver fhem.de die vielen Anfragen nicht?
Hallo,
ich habe in letzter Zeit auch immer wieder diese Abbrüche, allerdings schmiert mir FHEM danach nicht komplett ab ... obwohl bei den letzten Problemen dachte ich, das die Ursache beim schreiben der LOG-Dateien auf die SD Karte liegt.
Ich bin gerade dabei diese auf einen USB Stick zu verlegen, auch mit mäßigen Erfolg :-[
Zitat von: Brunni link=34076.msg292866#msg292866 date=1431074886
Angeschlossen ist es direkt am Kabel Deutschland. Vielleicht mag der Webserver fhem.de die vielen Anfragen nicht?
Nein. Wenn ich zeitgleich auf der Maschine via script mit wget alle Daten hole, werden diese korrekt ausgeliefert.
Gruß Thorsten
Hallo,
kann man das Fhem Update auch manuell machen? ich bekomme immer folgende fehlermeldung...
2015.08.02 23:06:16 1: http://fhem.de/fhemupdate/demolog/eventTypes.txt: Can't connect(1) to http://fhem.de:80: IO::Socket::INET: connect: timeout
vorher liest er aber ein haufen Dateien aus...
Einfach mehrfach probieren, irgendwann läuft es schon durch. :-[
jetzt habe ich das Problem das mir Fehm mir meine ganzen Sensoren, Wetter und Spritpreise aktualisiert aber nicht fhem direckt...
habe in die Komandezeile update eingegeben aber da pasiert das oben geschilderte prozedere und mehr nicht....
Nur mal als Idee:
Weiß jemand, wie bei Euch das "TimeOut" hochgedreht werden könnte?
Grad ein update auf einem meiner Raspi eingeworfen - klappt einwandfrei.
Ja ich weiß, hilft nicht viel aber ein -- geht bei mir nicht hilft zur Hilfe genau so viel/wenig.
"Update manuell" wäre die Dateien aus dem SVN holen und selbst kopieren.
und wie komme ich an die daten vom SVN?
also bei mir wird immer an einer anderen stelle bekomme ich ein Timeout und das Update bricht ab :(
Zitat von: Ger-Gilias am 05 August 2015, 18:15:02
und wie komme ich an die daten vom SVN?
Müsste ich jetzt auch die SuFu anwerfen und mich durch die Beiträge suchen.
Warten oder selbst suchen, es gibt Beiträge im Forum dazu.
Nach dem SVN Problemen muss mein PI auch ein komplettes update fahren. Nach mehreren Connection timeout Problemen habe ich eben das update mit verbose 5 laufen gelassen. Dabei ist mir die folgende Meldung aufgefallen, bevor das Update stoppt!
2015.08.11 09:18:40 5: Triggering global (1 changes)
2015.08.11 09:18:40 4: HttpUtils url=http://fhem.de/fhemupdate/www/images/openautomation/phone_ring_in.svg
2015.08.11 09:18:40 5: Notify loop for global UPD www/images/openautomation/phone_ring_in.svg
2015.08.11 09:18:40 5: Cmd: >{Log('1','UPD www/images/openautomation/phone_ring_in.svg')}<
2015.08.11 09:18:40 1: UPD www/images/openautomation/phone_ring_in.svg
2015.08.11 09:18:40 4: http://fhem.de/fhemupdate/www/images/openautomation/phone_ring_in.svg: HTTP response code 200
2015.08.11 09:18:40 4: HttpUtils http://fhem.de/fhemupdate/www/images/openautomation/phone_ring_in.svg: Got data, length: 2917
2015.08.11 09:19:02 4: Connection accepted from FHEMWEB:127.0.0.1:55104
2015.08.11 09:19:02 4: HTTP FHEMWEB:127.0.0.1:55104 GET /fhem/rss/FrameRSS.jpg
2015.08.11 09:19:02 4: 2225:FHEMWEB:127.0.0.1:55104: /fhem/rss/FrameRSS.jpg / RL:5945 / image/jpeg; charset=utf-8 / /
2015.08.11 09:19:02 4: HTTP FHEMWEB:127.0.0.1:55104 GET /fhem/rss/.directory
2015.08.11 09:19:02 4: 2225:FHEMWEB:127.0.0.1:55104: /fhem/rss/.directory / RL:689 / text/html; charset=utf-8 / /
Es wird eine WEb Verbindung aufgebaut und dann bricht das update einfach ab!
Ich weiß es hilft nicht viel, bei denen wo es nicht geht.
Aber bei mir läuft das Update einwandfrei, gerade probiert Raspi B+ dauert ca. 8,5 min.
Kein Fehler, kein Timeout, kein Fehler im Log. Ok war ein leeres System...
Vielleicht ist das ja auch mal eine Idee:
- System shutdown
- fhem.cfg austauschen gegen leere
- neu starten,
- update machen,
- shutdown,
- produktive fhem.cfg wieder rein,
- start
Gruß Otto
ich habe mein Fhem komplett neu aufgesetzt, noch nichts in der fhem.cfg eingegeben. Da ich bevor ich das System aufsetze immer erst update aber es geht einfach nicht... habe jetzt mal 3 Tage gewartet und den Pi in den Schrank verbannt und heute neu versucht aber immer noch kein Erfolg gehabt :(
Nur mal für die Ursachenforschung:
Kannst Du den Pi zu einem anderen Anschluß (z.B. einem Freund) mit einem anderen Internetanbieter bringen und dort testen?
Wenn es dann funktioniert, liegt es an dem Anschluß (bzw. dem Anbieter, Router etc.). Wenn es die gleichen probleme gibt, dann an der Konfig des Pi. Wobei .. ich würde an Anschlußprobleme Tippen. Nur ist "Tippen" kein Beweis ....
Zitat von: Ger-Gilias am 11 August 2015, 15:56:47
ich habe mein Fhem komplett neu aufgesetzt, noch nichts in der fhem.cfg eingegeben. Da ich bevor ich das System aufsetze immer erst update aber es geht einfach nicht... habe jetzt mal 3 Tage gewartet und den Pi in den Schrank verbannt und heute neu versucht aber immer noch kein Erfolg gehabt :(
Letztens hatte einer vergessen das default Gateway in der IP Konfiguration einzutragen. Nur mal so ...
Gruß Otto
Hm, interessanter weise ist es so, dass durchaus Dateien auf den neuesten Stand gebracht werden, sie tauchen allerdings trotz allem immer noch in der Liste auf.
Habe ich auch schon versucht aber das gleiche...
Mein Zugang ins Netz geht über FritzBox -> KD Model -> Internet
habe aber den Pi bereits schon direckt an das Moden gehängt und es da versucht das gleiche... Auch bei meinen Eltern und bei meinen Schwiegerletner versucht kein Erfolg :(
EDIT Was ich auch nicht verstehe ist warum FHEM auch alle Bilder usw. updatet...
Du hastalso "Kabel-Deutschland"?
Haben Deine Eltern/Schwiegereltern den gleichen Anbieter?
Und .. macht das "KD Model" den Zugang incl. "ppoE-Einwählen"?
(Muß allerdings zugestehen, das meine letzte KabelDeutschland Einrichtung etwas her ist)
P.S. gehst Du über wlan oder über ethernet ins Netz?
Zitat von: Wernieman am 11 August 2015, 18:59:14
Du hastalso "Kabel-Deutschland"?
Haben Deine Eltern/Schwiegereltern den gleichen Anbieter?
Und .. macht das "KD Model" den Zugang incl. "ppoE-Einwählen"?
(Muß allerdings zugestehen, das meine letzte KabelDeutschland Einrichtung etwas her ist)
P.S. gehst Du über wlan oder über ethernet ins Netz?
nein die einen Telekom und die anderen Versatel...
Habe es über Wlan und Ethernet versucht beides das gleiche.
Was das Modem macht keine Ahnung habe die Fritzbos dran angeschlossen und gehe über die Fritzbox ins Inet wie oder was da genau eingestellt ist kann ich nicht sagen :D
Ich häng mit meinem RasPi am Switch --> FB7390 --> Kabel-BW-Modem und das update klappt einwandfrei.
Ich bezweifle das FHEM schuld ist lasse mich aber gerne eines besseren belehren ;)
Edith nachträglich: FritzOs 06.23
Hm, hatte vorher die 6390 und nun die 6490, Fritz OS6.22. eMule und Torrents sind gesperrt. Keine Portfreigaben.
Hallo ich muss leider auch berichten das bei mir das update nicht mehr will trotz anpassung der entsprechenden Rechte.
Ich hol es mir jetzt manuell aus dem SVN trunk...
Zitat von: Ger-Gilias am 11 August 2015, 16:57:37
EDIT Was ich auch nicht verstehe ist warum FHEM auch alle Bilder usw. updatet...
deshalb (http://forum.fhem.de/index.php/topic,39552.msg320639.html#msg320639)
Zitat von: speex am 11 August 2015, 19:46:08
Hallo ich muss leider auch berichten das bei mir das update nicht mehr will trotz anpassung der entsprechenden Rechte.
Ich hol es mir jetzt manuell aus dem SVN trunk...
und wie machst du das? habe es schon versucht ging aber auch nicht....
Zitat von: Puschel74 am 11 August 2015, 19:31:46
Ich bezweifle das FHEM schuld ist lasse mich aber gerne eines besseren belehren ;)
Ich auch...
Zitat von: speex am 11 August 2015, 19:46:08
Hallo ich muss leider auch berichten das bei mir das update nicht mehr will trotz anpassung der entsprechenden Rechte.
Ich hol es mir jetzt manuell aus dem SVN trunk...
Na das nenn ich mal eine Fehlerbeschreibung ::)
Ich musste keine Rechte entsprechend anpassen und das update klappt.
Wie soll da jemand helfen wenn man noch nichtmal durch Glaskugelschrubben erahnen kann was jemand vielleicht oder doch nicht oder etwa irgendwie gemacht haben könnte.
Edith: Genial finde auch die "Anpassungen" die kursieren damit das update vielleicht doch klappt - ungetestet und einfach per Forum verteilt ;D
http://forum.fhem.de/index.php/topic,39837.0.html (http://forum.fhem.de/index.php/topic,39837.0.html)
Gespannt was Rudi dazu sagt - evtl. ist die Anpassung ja richtig aber der Forenbereich ist definitiv falsch.
hier das gleiche Problem: an wechselnder Stelle den Fehler
Can't connect(1) to http://fhem.de:80: IO::Socket::INET: connect: No route to host
vor 2 Wochen Rpi mit Rhaspbian neu aufgesetzt (nach 1,5 Jahren fhem-pause), fhem.cfg noch recht minimal. Kein einziges fhem-update ging durch.
Kabelbw mit Fritzbox 6360 (ipv6 :( ), Rpi per lan.
Google-Nameserver im Rpi eingetragen - erfolglos.
1x update per svn. Direkt danach wollte das update in Fhem trotzdem komplett alles nochmal holen. Bis zur Fehlermeldung eben..
Zitat von: SonnenSimon am 11 August 2015, 21:41:21
Google-Nameserver im Rpi eingetragen - erfolglos.
Das ist ne coole Idee. Habe ich auch als "Tuning des eigenen Internet" im Internet gefunden und probiert. Nach zwei Tagen hatte ich ständig capcha Abfragen von Google wenn ich was gesucht habe. Keine Ahnung was FHEM update daraus macht.
Ansonsten scheint mir, als ob sich das "update geht nicht" Problem auf "Kabel Internet" konzentriert.
Gruß Otto
Mein Kabel-BW-Modem ist eine FB6340 und dahinter eine FB7390.
Hintergrund ist Sipgate resp. Telefonie über einen frei wählbaren SIP-Anbieter daher die 7390 hinter der Kabel-BW-FB.
Und weil mir die 6340 von Kabel-BW "aufgezwungen" wurde für den "schnelleren" Zugang ::)
stimmt ja Puschel, eigentlich weiß ich doch das Du auch Kabel hast 8)
Vielleicht gibt es ja eine Kombination von ... - ich habe keine Ahnung war irgendwie nur laut gedacht. ::)
Jetzt nochmal gelesen:
ZitatCan't connect(1) to http://fhem.de:80: IO::Socket::INET: connect: No route to host
Klingt nach manueller IP Konfig und Gateway nicht in der IP Konfig eingetragen - aber hatte ich schon gesagt 8)
Gruß Otto
ZitatKlingt nach Gateway nicht in der IP Konfig eingetragen
Und jetzt bin ich ganz fies :P
Mein Musik-RasPi, der auch als Test-RasPi für FHEM herhalten muss, hat in der
/etc/network/interfaces
genau folgendes eingetragen:
auto lo
iface lo inet loopback
iface eth0 inet dhcp
allow-hotplug wlan0
iface wlan0 inet manual
wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
iface default inet dhcpW-Lan ist aussen vor da ich keinen W-Lan-Stick angeschlossen habe - der RasPi ist einzig per Lan an den Switch angeschlossen - der Switch an die 7390 und diese an die 6340 und dann geht es ab zu Kabel-BW.
Zitat von: Puschel74 am 11 August 2015, 23:01:35
iface eth0 inet dhcp
Du bist nicht fies, Du bist nur gut!
DHCP macht ja alles richtig - normalerweise. Aber viele trauen dem DHCP nicht und machen lieber IP per Hand :)
Und dann vergessen sie die Hälfte.
Ich editiere mal meinen Beitrag 8)
Ok, mein Somfy-RasPi ist zwar per W-Lan angebunden aber dennoch per DHCP.
Der einzige RasPi mit fixed-IP ist der in der Firma - und auf dem läuft ein uralt FHEM da nie up-ge-datet (oder ge-up-datet ??? ) wird/wurde.
Sorry aber - - ich könnte das mal umstellen auf meinem Test-RasPi aber ich frag mich was das bringen soll.
Die benötigten Einstellungen auf einem Rechner, egal ob per DHCP oder per fixedIP und egal ob RasPi oder PC oder Laptop oder egal was, lassen sich doch nachlesen und wenn der eigentliche Internetzugang klappt müsste doch auch das update klappen?
"No route to host"
Das hört sich wirklich nach Netzwerkproblemen an.
Zu Deutsch: Es müste auserhalb von FHEM debugt werden.
1. Steht was in den Logfiles?
2. Was sagt ein parallellaufender ping?
3. was sagt ifconfig/route etc. .....
Edit:
P.S. den Vorschlag, nicht nur ein mal ein update zu Probieren sondern mehrmals ist doch eigentlich prinzipiell nicht schlecht? Warum wurde er eigentlich gleich "verrissen"? Ohne Ordentliche Begründung?
Mir kam grad: macht Fhem vielleicht für jede Datei eine extra Verbindung auf?
Denn das timeout/no route to host könnte ein Schutz der Provider gegen DDNS-Attacken (Distributed denial of service) sein, der dann anspringt?
Das würde auch die Captchas bei anschließenden Google-Suchen erklären und dass der Fehler nie an exakt der gleichen Stelle auftritt..
Dann wäre das Problem zwar tatsächlich außerhalb von Fhem, aber doch von Fhem verursacht..
.. es wurde (eine Seite vorher) auch geschrieben, das es auch bei einem TELEKOM-Anschluß auftritt und dort existiert so etwas nicht. Jedenfalls hätte ich es sonst schon längst gemerkt .. ;o)
Hallöchen,
die Problematik: in meinem ursprünglichen Hardware Setup hatte ich einen Router D-Link DIR-300 von Unitymedia, Raspi2 genommen FHEM ohne probleme Installiert und in Betrieb genommen und auch updates gemacht einwandfrei, irgendwann wollte ich wieder ein Update machen ging es nicht mit dem "IO::Socket-Fehler" im Updateprozess daraufhin hatte ich den damaligen vermeintlichen Bugfix mit der Anpassung der "dial-out" rechte vorgenommen und dann ging es auch über einen gewissen zeitraum funktionierte aber kurz vor der umstellung auf meinen neuen Router (TP-Link Archer C2) auch nicht mehr. Daher bin ich auch etwas ratlos und weiss nicht wo ich nach fehlern suchen soll, inzwischen ist mein Setup um den neuen Router ergänzt und es funktioniert auch alles tadellos bis auf das FHEM update...
Adressen zuweisen übernimmt der DHCP-Server des TP-Link Archer der hinter dem Technicolor TC7200 von Unitymedia hängt, so war es auch vorher mit dem D-Link Router.
Mag jemand, der das Update Problem hat, testweise mal versuchen die mtu size runterzusetzen und dann das Update noch einmal laufen lassen?
Ich vermute, dass Raspbian dazu folgende Syntax hat (habe keinen Pi im Zugriff):
sudo /sbin/ifconfig eth0 mtu 1000
Kann man nachher wieder mit 1500 zurücksetzen.
/Uli
Falls ein anderes Interface als eth0 für den Internetzugang genutzt wird, dann natürlich das angeben...
Vermutlich wirst du hier
http://forum.fhem.de/index.php/topic,39923.0.html (http://forum.fhem.de/index.php/topic,39923.0.html)
eher Tester finden.
Hallo,
ich hatte das Problem auch schon, habe aber dann aber im Raspian in /etc/hosts einen festen Eintrag gesetzt (zum Test der Ip-Adresse ein ping auf fhem.de):
fhem.de 82.165.184.33
Danach war das Problem behoben.
Evtl. hilft das ja bei euch auch, Michael
kann es sein das das problem ganz wo anders liegt?
KabelBW z.b. biegt diverse anfragen auf einen eigenen proxy um. auch http zu google oder dns auf die google name server.
diesese proxies sind leider alles andere als transparent.
wenn es hilft direkt auf die ip zuzugreifen wäre das ein Indiz dafür.
gruss
andre
Insofern nicht, das bei mindestens einer "Probleminstallation" dieses auch bei anderen Providern, wie z.B. Telekom, aufgetreten ist, laut seiner Aussage.
Sonst hätte ich auch schon auf Kabelprovider als Problem getippt
Ich hatte das Problem ursprünglich auch bei der Telekom als Provider, bei mir zu Hause habe ich nun KabelBW (Unitymedia), da ist es kein Problem.
Leider kann ich mich nicht daran erinnern ob der Fehler von Anfang an oder erst nach einer Weile auftrat.
Zitat von: Michael70 am 21 August 2015, 08:11:53
Hallo,
ich hatte das Problem auch schon, habe aber dann aber im Raspian in /etc/hosts einen festen Eintrag gesetzt (zum Test der Ip-Adresse ein ping auf fhem.de):
fhem.de 82.165.184.33
Danach war das Problem behoben.
Evtl. hilft das ja bei euch auch, Michael
Danke für diesen Tipp jetzt hand endlich fhem das update gemacht...
Leider immer noch der gleiche Fehler. >:(
Austausch des Netzteils hat nichts gebracht.
Setzen des /etc/hosts Eintrags hat nichts gebracht (hätte mich auch schwer gewundert).
Bei mir läuft der Update allerhöchstens für 100 Files, dann kommt der Fehler, manchmal auch schon nach 15.
Heute Abend habe ich mir aus den Informationen von "update check" ein bash-script gebastelt, das den Download per wget durchführt.
Dier Download per wget läuft fehlerfrei auf dem RASPI - nur der fhem basierte Download hat diese Probleme
Nach dem ersten Test (bash für jedes File eine wget <url> -O <destinationDir/file>) habe ich noch einen zweiten Test gemacht
indem ich wget nur einmal mit der -i option aufgerufen habe, um eine ähnliche Situation wie in fhem hinzubekommen (Prozess der den Download macht wird nicht immer neu gestartet).
Auch dieser Download war erfolgreich:
FINISHED --2016-02-12 20:39:57--
Total wall clock time: 1m 39s
Downloaded: 1706 files, 23M in 32s (739 KB/s)
Wie gesagt - mit fhem ist manchmal schon nach 15 Files Schluss.
Ich vermute fast, dass es da eine Unverträglichkeit von perl auf dem Raspi gibt.
Gruß
Prüfe mal die Dateirechte der Dateien die aktualisiert werden sollen!