Hallo,
Vorliegende Konfiguration:
FHEM neueste Version mir RPI3 neuestes Linux , Wifi und Bluetooth angeschaltet.
RPI steht in einer netzfreien Umgebung und soll Daten loggen über dblog.
Zugang zum RPI3 über WIFI und einen Mobiles Hotsport eines PCs.
Habe folgendes Phänomen entdeckt.
Zugang zum RPI über Wifi funktioniert prima.
Sobald ich den PC herunterfahre bekomme ich folgende Nachricht im Logfile:
sudo: Hostname xxx kann nicht aufgelöst werden: Verbindungsaufbau abgelehnt
sudo: Hostname xx kann nicht aufgelöst werden: Die Wartezeit für die Verbindung ist abgelaufen
FHEM arbeitet anscheinend nachdem ich mit den PC vom FHEM getrennt habe auch nicht weiter. Keine Einträge mehr in dblog. FHEM hat zu diesem Zeitpunkt auch keinen Internetzugang mehr. Der WIFI-Zugang des RPI ist natürlich auch weg, das gesamte Netzwerk ist für den RPI weg.
Wie kann ich gewährleisten, dass FHEM weiter arbeitet und die Daten Logged? Es scheint, dass das Logging auch eingestellt wird, wenn die Wifi/Netzwerkverbindung weg ist.
Hoffe, ich habe verständlich beschrieben, wo mein Thema ist. Wo muss ich suchen?. Wifi? Wer bringt diese Meldung?
xxx ist der Hostname des RPI3
Du wirst wohl einen lokalen DNS aufsetzen müssen. Ansonsten blockiert FHEM bei der DNS Abfrage.
Grüße
Hi, hast du mir einen Tip, wie ich dies machen kann? Danke für die schnelle Antwort.
Installiere Dir einen kleinen DNS Server auf dem Pi und Stelle in FHEM global das Attribut dnsServer auf 127.0.0.1
Aktuell gehe ich davon aus das Du ein Modul hast welches Daten von draussen holen will.
Hi, ja, das Wetter Modul. Wenn ich das Wetter Modul abschaltet, habe ich dann weiterhin das Thema?
Das könnte ich eventl abschalten, wenn ich beim Aufsetzen des DNS Servers ein Thema bekomme.
Hast du einen Link, mit dem man gut geführt einen DNS Server aufbauen kann?
Sorry für die vielen Fragen, ich hatte alles überlegt und gut vorbereitet, jetzt überrascht mich diesem Problem.
Danke für die Hilfe
Wenn Du das Wetter abschaltet sollte er nicht mehr blockieren.
Such Mal im Netz nach pdns oder powerdns.
Moin,
warum betreibst du einen FHEM Server ohne Netzzugang
ZitatRPI steht in einer netzfreien Umgebung und soll Daten loggen
und erwartest mit dem Wettermodul irgendwelche Daten?
Was FHEM mit seinen ganzen Webdiensten macht ohne ein Netzwerk? da hilft doch auch kein pseudo DNS?!
Ich würde wenigsten den Spieß umdrehen und auf dem Pi ein "leeres Netzwerk" lassen. Also ihn zum Wifi AP machen. Oder der LAN Schnittstelle vorgaukeln sie sei angeschlossen. Mit einem LAN "Nullmodemstecker" - ich habe leider den richtigen Begriff nicht parat.
Edit: Ein RJ45 Stecker mit Brücken von 1-3 und 2-6
Sowas brauchte man früher bei allen Serversystemen um die offline überhaupt installieren zu können.
Hab ich aber bei einem Pi auch noch nie probiert.
Gruß Otto
Hallo Otto und Cooltux,
danke für die Antworten. Ich hab mir das mit dem DNS Server auf dem RPI mal angesehen.
Ich empfinde den Eingriff jetzt in letzter Sekunde als sehr gefährlich. Dann geht möglicherweise kein Zugriff mehr. Ist meine Einschätzung da korrekt und hab ich einfach zu viel Angst. Mein Zeitfenster läuft heute Abend leider ab.
Ich hab zwar viel getestet, leider aber nicht alles, wie man sieht. Irgendwo hat der RPI immer seine DNS bekommen.
Ich habe jetzt mal das Wettermodul inactive = 1 gesetzt und den Laptop ausgeschaltet. Ich hoffe, FHEM logged weiter.
Ja Otto, es klingt nicht direkt einsichtig Wettermodul und kein Internet un aktiv:
Ich habe folgende Überlegung:
Ich gebe dem Raspberry zeitweise Internet über den mobilen Hotspot des PCs. Sobald FHEM in diesem Zeitraum ein Update des Wettermodules macht.. gerne...
Wenn FHEM kein Internet hat, so soll es dann keinen Update machen, aber es soll ich nicht selbst blockieren, was es aktuell macht. Schreibt keine Daten in dblog. Was mich auch wundert. Dieses Problem ist sofort da, wenn man dem Laptop abschaltet (sichtbar im Log), nicht erst , wenn FHEM einen Update machen will.
Wie gesagt mach ihn zum AP, deine Angst verstehe ich. Aber so geht es ja auch nicht.
https://www.raspberrypi.org/documentation/configuration/wireless/access-point.md
Zitat von: Otto123 am 16 März 2019, 11:42:25
Wie gesagt mach ihn zum AP, deine Angst verstehe ich. Aber so geht es ja auch nicht.
https://www.raspberrypi.org/documentation/configuration/wireless/access-point.md
Allerdings wird er dann eher nie (Wetter)Daten holen können...
...weil er sich ja nicht mehr mit dem WLAN-AP des Notebooks verbindet!?
Evtl. einfach einen kleinen echten AP ("billiger" Repeater, manche können auch AP).
Entweder dann gleiche SSID wie das Notebook-Netz und dann beim Einschalten des Notebooks den AP aus und umgekehrt...
...oder den AP an das Notebook und dann versuchen zu konfigurieren, dass das Notebook die Internetverbindung auch für andere Rechner im Netz (AP per Netzwerkkabel) zur Verfügung stellt, vielleicht kann das dann der AP auch nutzen/Routen und den PI so ins Internet "lassen", wenn eben eines "da ist" aber zumindest "immer" ein Netzwerk zur Verfügung stellen (global dnsServer dann eben auf den AP), damit fhem zumindest nicht blockiert...
Gruß, Joachim
naja eigentlich hat das System ja seinen loopback Adapter 127.0.0.1 damit hat er eigentlich ein Netzwerk.
Insofern war meine Idee vielleicht nicht die richtige Richtung.
ich habe keine Ahnung von dblog, aber wie ist denn der Zugriff konfiguriert? Muss man diesen vielleicht einfach auf localhost 127.0.0.1 umkonfigurieren?
Hallo, kann ich noch eine Sache nachfragen hinsichtlich der Lösung von Joachim?
ich hab im Bestand einen Wifi Router, Huwai HUAWEI E5577CS LTE WLAN Router, Schwarz (wahrscheinlich ein Vorgänger). Dafür hab ich aber keine gültige Datenkarte und damit keinen Internetzugang.
Hilft folgendes:
Ich konfiguriere die WIFI Verbindung des Raspberry so, dass diese zuerst auf das Notebook und den dort verfügbaren mobilen Hotsport mit Internetzugang.
Falls das Notebook nicht da ist, fällt der Raspberry auf diesen Huwai Hotspot zurück. Hat zwar Kontakt zum Hotsport, aber kein Internet. Den Huwai Hotspot lasse ich immer eingeschaltet.
Ich will damit nur erreichen, dass ich FHEM nicht blockiert? Dies möchte ich nur, im Falle dass FHEM sich trotz inactivem Wettermodul trotzdem blockiert.
Hi, hab dies mal getestet mit dem Hotspot. Ist nicht die Lösung.
Es hat den Eindruck, dass ich auch bei existierendem Netzwerk und funktionierenden Internetzugang im Logfile diese Fehlermeldung bekomme:
sudo: Hostname vagabundi kann nicht aufgelöst werden: Die Wartezeit für die Verbindung ist abgelaufen
sudo: Hostname vagabundi kann nicht aufgelöst werden: Die Wartezeit für die Verbindung ist abgelaufen
sudo: Hostname vagabundi kann nicht aufgelöst werden: Die Wartezeit für die Verbindung ist abgelaufen
sudo: Hostname vagabundi kann nicht aufgelöst werden: Die Wartezeit für die Verbindung ist abgelaufen
sudo: Hostname vagabundi kann nicht aufgelöst werden: Die Wartezeit für die Verbindung ist abgelaufen
Irgendwie habe ich hier dblog weiterhin in Verdacht. Auch pushover ist ein Kandidat. Pushover steht auf "connected", obwohl ich es inactive"1" geschaltet habe. Einfach löschen möchte ich es auch nicht.
FHEM hängt sich nicht "mehr" auf bzw. blockiert sich. FHEM schreibt munter weiterhin in dblog, trotz der Fehlermeldungen. Aber schreibt auch das Logfile voll, alle paar Minuten. Wie bekomme ich die Ursache für diese "sudo" Fehler- Nachrichten
Wer oder was ist "vagabundi"?
Hast du "attr global dnsServer" gesetzt?
Hast du irgendwelche Module, die zyklisch (im passenden Zeitintervall) irgendwas von "vagabundi" lesen wollen?
Wie hast du "pushover" deaktiviert?
Laut commandref gibt es kein "set inactive" (oder so)...
Gleiches für Weather...
Gruß, Joachim
Hi MadMax,
danke für die Antworten und Fragen:
vagabundi ist der Linux-"Name" meines RPI3, der mit mir morgen mitgeht.
pi@vagabundi
attr global dnsServer habe ich nicht gesetzt. Muss ich dies, auf welche Adresse?
Vom "Vagabundi" lese ich nur mit "Heidisql" vom Laptop, was wieder zu dblog passen würde.
Aber der Fehler tritt auch auf, wenn ich den Laptop aus habe.
Pushover ist deaktiviert mit disable "1", ist aber weiterhin "connected".
weather auch disable "1", hat auch seit heute 10:00 Uhr keine Daten mehr geholt, ich glaube dies können wir ausschliessen.
Vielleicht solltest du mal dein "Setup" etwas erläutern.
Also welche Systeme (mit welchen IPs/Namen) sind beteiligt...
...und wer holt Daten von wem oder schreibt Daten wohin (und wozu)...
Und: "wer" ist dann ab und an nicht verfügbar (z.B. Notebook) und "wer" ist geplant ohne Internet zu sein (von Zeit zu Zeit)...
das Attribut dnsServer setzt man normalerweise eben auf einen lokalen DNS, damit im Falle einer fehlenden Internetverbindung (und somit zugriff auf externe DNS) fhem nicht blockiert sollte eine Namensauflösung benötigt werden.
Weil selbst mit NonBlockingHTTP-Funktionen die DNS-Abfrage blockierend ist...
...wie das in deinem Falle am besten eingestellt wird: keine Ahung. Evtl. wie von CoolTux vorgeschlagen...
EDIT: frägst/schreibst du irgendwo Daten ab/hin und benutzt den "Rechnernamen"? Kannst du das in IP ändern? Dann braucht es keinen DNS und es wird (zumindest dafür) nicht blockieren...
Gruß, Joachim
Hi, danke Madmax,
hier noch die Konstellation:
RPI (vagabundi) ist zu 80% standalone, loggt Daten und hat Wifi offen.
Auf dem Laptop habe ich einen Mobilen Hotspot, auf den sich der RPI einwählt, sobald dieser Hotsport da ist und Internet hat.
Ansonsten , ohne Internet macht der Laptop keinen mobilen Hotsport auf, verständlicherweise.
Der Laptop vergibt IP Adresse an RPI und damit bekommt man Zugang zum RPI (Vagabundi) über Wifi.
Der Laptop bekommt über viele Wege Internet. Auch Wifi oder auch LAN, oder mobiler Hotspot (Smarttphone).
RPI ist absolut autonom, hat auch seine dblog onboard. Nur zum betrachten der Sql Datenbank verwende ich Heidisql von Windows aus. (sporadisch, auch über Wifi).
Zitatdas Attribut dnsServer setzt man normalerweise eben auf einen lokalen DNS, damit im Falle einer fehlenden Internetverbindung (und somit zugriff auf externe DNS) fhem nicht blockiert sollte eine Namensauflösung benötigt werden.
Weil selbst mit NonBlockingHTTP-Funktionen die DNS-Abfrage blockierend ist...
...wie das in deinem Falle am besten eingestellt wird: keine Ahung. Evtl. wie von CoolTux vorgeschlagen...
Ich verstehe den Vorschlag von Cooltux nicht.
Wenn das wirklich alles ist, woher kommen dann die Logeinträge!?
"Irgendwer" muss doch (als sudo/root) lokal über den Namen (vagabundi) irgendwelche Daten abfragen (oder schreiben wollen)!?
Der Name "vagabundi" kann natürlich (vors. die Konstellation ist korrekt beschrieben) nur "aufgelöst" werden, wenn das Notebook läuft (weil dort ja dann DHCP und verm. DNS [für lokal] läuft)...
Wenn du rauskriegst "wer" das macht, dann umstellen auf IP (127.0.0.1 weil es ja "er selbst" ist) und dann sollten zumidest diese Einträge nicht mehr kommen (und evtl. fhem auch nicht mehr hängen trotz ohne Netz)...
Der Vorschlag von CoolTux: lokal (auf vagabundi) einen DNS installieren (und minimal konfigurieren) und dann eben das Attribut dnsServer auf 127.0.0.1 (also lokal vagabundi / "localhist") setzen. Damit greift dann fhem immer über diesen DNS zu und bekommt immer Antwort...
(weil läuft ja lokal auf dem selben PI / vagabundi)
Gruß, Joachim
Hallo, ich kann mir nur vorstellen, dass dies Heidisql ist, der da zugreift. Eine Erklärung hab ich aber nicht!
Heidisql kommt als sudo/root rein auf den vagabundi. Aber warum eigentlich sudo/root und nicht auch sudo/pi?
Es kann ja nur sein, dass der Zugriffprozess von Heidi irgendwas hinterlässt , obwohl der Laptop schon weg ist.
Ich kann ja einen lokalen DNS, ich springe über meinen Schatten.
Falls dies in den nächsten 2 Stunden nicht funktioniert, gibt es dann einen Weg zurück?
Ich bin aktuell in keinem festen Netzwerk mehr, muss alles über mobilen Hotspot arrangieren.
Die Gefahr, dass ich da auf die Nase falle ist gegeben. Deshalb die Frage nach dem Weg zurück.
Also nach dieser Einstellungen den DNS Server installieren Korrekt:
ZitatWie gesagt mach ihn zum AP, deine Angst verstehe ich. Aber so geht es ja auch nicht.
https://www.raspberrypi.org/documentation/configuration/wireless/access-point.md
Warum sollte ein Zugriff von extern einen Eintrag in fhem hinterlassen, der auf Namensauflösungsprobleme hindeutet!?
Macht keinen Sinn...
(weil die Namensauflösung ja "dort" passieren muss)
Mit "sudo/root" habe ich gemeint, dass "irgendetwas" root Rechte braucht (oder zumindest so eingerichtet ist) und das mittels "sudo" erledigt...
Sudo landet immer bei "root"... ;)
Aber das mit den DB-Zugriffen hast du dann noch nicht entsprechend erläutert (als ich nachgefragt hatte)...
...wenn nicht alles/alle Zugriffe klar sind ist auch schwer zu helfen...
Gruß und viel Erfolg, Joachim
Hallo MadMax:
..wenn nicht alles/alle Zugriffe klar sind ist auch schwer zu helfen...
danke für den Hinweis.
Und wie steht es damit aus?
function {`sudo /opt/fhem/lescan.sh 7C:2F:80:D1:89:44`}
Ich hab einen Bluetooth Tag, den ich damit auf "Presence" prüfe. Kann dies dies Ursache sein.. sudo ist schon mal drin...
Danke für die Unterstützung.
Eher unwahrscheinlich...
Weil das nix mit Netzwerk und DNS etc. ist...
Gruß, Joachim
Hallo Uwe,
ich würde auch den Vorschlag von Joachim umsetzen und alle Zugriffe von Namen auf IP Adresse umstellen. Dann braucht es kein DNS nach innen.
Ein DNS der am Ende zwar da ist aber nichts auflöst bringt eigentlich auch nichts.
Viele Erfolg
Otto
Hallo Otto und MadMax,
danke für den tollen Support.
ich würde auch den Vorschlag von Joachim umsetzen und alle Zugriffe von Namen auf IP Adresse umstellen.
Gerne mache ich das, und wenn ich die ganze Nacht investiere.
Aber ich weiss nicht , welche Zugriffe. Alles was ohne Netzwerk frunktioniert (genau da treten ja die Fehler auf), kann nichtb das Thema sein:
Temperatur, GPS-Maus.
Dieser Pushover ist weiterhin connected, obwohl ich ihn inaktiv 1 habe. Wetter habe ich stillgelegt. kann es also nicht sein.
Könnt ihr mir bitte noch etwas näher erläutern, was es heisst, Namen auf IP Adressen umlegen.
Ich meine keine Namen verwendet zu haben.. (? Pushover?)
Alle Hostnamen wie vagabundi. Die Namen in Nachrichten und so spielen keine Rolle.
Mit der Definition kannst Du deine Installation durchsuchen:
define c_grep cmdalias grep .* AS {qx(grep -i \'$EVENT\' *.cfg FHEM/99*.pm)}
Danach geht grep vagabundi in der FHEM Kommandozeile, wenn er was findet wird es gelistet.
Gruß Otto
Leider ist da nichts, oder bin ich falsch?
Zitatfhem.cfg:attr global title Vagabundi
fhem.cfg:define N.Present_Vagabundi notify BluetoothAnwesend:presence.* {\
fhem.cfg: fhem("msg Anwesenheit beim Vagabundi anwesend");;\
fhem.cfg: fhem("msg Anwesenheit beim Vagabundi abwesend");;\
fhem.cfg:setuuid N.Present_Vagabundi 5c838126-f33f-813e-ee2c-e5691eea8f6fcf5a
fhem.cfg:attr N.Present_Vagabundi DbLogExclude .*
fhem.cfg:attr N.Present_Vagabundi alias Schickt msg an Mobil, dass wir anwesend sind
fhem.cfg:attr N.Present_Vagabundi room Anwesenheit
Hatte auch schon DBlog in Verdacht:
Internals:
COLUMNS field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
CONFIGURATION /opt/fhem/db.conf
DEF /opt/fhem/db.conf .*:.*
FUUID 5c76fb21-f33f-813e-3909-f55a73fc661728ad
MODE synchronous
MODEL MYSQL
NAME DBLogging
NR 14
NTFY_ORDER 50-DBLogging
PID 603
REGEXP .*:.*
STATE connected
TYPE DbLog
UTF8 0
VERSION 3.13.1
dbconn mysql:database=fhem;host=localhost;port=3306
dbuser fhemuser
HELPER:
COLSET 1
DEVICECOL 64
EVENTCOL 512
OLDSTATE connected
READINGCOL 64
TYPECOL 64
UNITCOL 32
VALUECOL 128
Helper:
DBLOG:
state:
DBLogging:
TIME 1552721436.85929
VALUE connected
READINGS:
2019-03-16 03:00:19 reduceLogState reduceLogNbl finished. Rows processed: 0, deleted: 0, updated: 0, time: 0.00sec
2019-03-16 22:04:45 state connected
cache:
index 0
Attributes:
DbLogSelectionMode Exclude/Include
DbLogType Current/History
room LOGGING,hidden
und hast Du noch andere Scripts? das /opt/fhem/lescan.sh sah nicht danach aus, aber ich weiß es ja nicht.
In /opt/fhem/db.conf ?
dbconfig Inhalt:
%dbconfig= (
connection => "mysql:database=fhem;host=localhost;port=3306",
user => "fhemuser",
password => "xxxx",
# # optional enable(1) / disable(0) UTF-8 support (at least V 4.042 is neces$
# utf8 => 1
);
alles andere ist raus
hab leider das Thema immer noch mit dem Fehler in der Logdatei, ca. minütlich.
Erste Frage, kann ich diese Fehlermeldung einfach ausschalten?
sudo: Hostname xxxx kann nicht aufgelöst werden
Zwischenzeitlich hab ich mir leider auch noch den SSH Zugang zum Raspberry zerstört. Bei den vielen Tests und Modifikationen, den Fehler wegzubringen :'( :'(
Der Raspberry zeigt sich nicht mehr am Port 21, 22. Ich hab wohl einen Fehler in ein Konfigurationsfile gebaut, wahrscheinlich auch durch ein sehr instabiles Internet bedingt.
Ich habe physikalisch einen Zugriff auf den Raspberry und müsste über einen Windows PC eine Konfigurationsfile modifizieren.
Zugriff auf denRraspberry mit Lan auf FHEM habe ich, auch mit Heidisql. FHEM läuft prächtig.
Ich hab keinen Zugriff mit Filezilla (mölgicherweise weiss ich nur nicht wie). Jedoch der ursprüngliche Zugang ist versperrt.
Mein Gedanke war:
1. backup der atuellen Flashkarte machen (kriegt ich hin auf dem PC).
2. mit einem Windowsprogramm (???? 8) ??? Zugriff auf den Inhalt des Linux Image bekommen.
3. Konfigurationsfile modifizieren und dann wieder los auf den Raspberry
Gibt es da noch einen weitere Möglichkeit?
Hab das Thema mit dem gesperrten Zugang zu ssh selbst gelöst. Für alle, die ein ähnliches Thema haben:
Es gibt ein ganz tolles Porgramm namens
ext2 Volume manager
Ganz einfaches Programm, das einem ermöglicht, die Files auf der Raspberry Flashkarte direkt im Windows PC mit Notepad zu lesen, modifizieren und zurückzuschreiben. Super.
Also Karte aus dem Raspberry in den Windows PC stecken, ext 2 Volume manager laden (kostenlos). Man hat dann die Flashkarte im Windows System gemounted und kann mit dem Windows File explorer das defekte File suchen, modifizieren mit Notepad , sichern, Karte zurück in den Raspberry. Booten, fertig.
Ich hatte mir übrigends die /etc/ssh/sshd_config zerschossen.
Mein Thema mit sudo: Hostname xxxx kann nicht aufgelöst werden ist damit nicht gelöst.
Aktuell verzögert es fast jeden Linux Befehl um ca. 10 Sekunden. Hat jemand noch ne Idee.
mach mal ein
cat /etc/hosts
und poste die Ausgabe hier
Hallo Cooltux, danke
pi@vagabundi:~ $ cat /etc/hosts
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
127.0.1.1 raspberrypi
# 192.168.137.9 vagabundi.mshome.net vagabundi
Zur Erklärung: Der RPI meldet sich "zeitweise" am Hotspot des Laptops an. (immer wenn ich da bin und der Laptop eingeschaltet ist). Laptop Hotspot vergibt IP Adressen im Bereich 192.168.137.xxx. Laptop gibt Internet an RPI über der Hotspot weiter, wenn er selbst am Internet ist, ansonsten macht der Laptop den Hotspot gar nicht auf. Sobald dies der Falle ist, meine ich keine Fehlermeldungen mehr zu bekommen.
Meine Idee ist einen Huwai Hotspot (anstelle des Laptops) , den ich aktuell habe, aber ohne Datenvorrat, als Router zu verwenden (wie heute den Laptop)
Der Huwai soll einige Dinge machen:
1. DNS vergeben, dann sollte die Fehlermeldung auf dem RPI weg sein.
2. Zugang auf den raspberry mittels IPAD zu gewährleisten (geht dies?) Ist praktischer als immer den Laptop..
3. Internetzugang für den Raspberry bereitstellen, wenn ich Datenkarte aufgeladen habe.
Sind meine Ideen umsetzbar und realistisch.
127.0.1.1 raspberrypi
# 192.168.137.9 vagabundi.mshome.net vagabundi
Das bitte ändern in
# 127.0.1.1 raspberrypi
192.168.137.9 vagabundi.mshome.net vagabundi
Und dann testen und beobachten.
Hallo cooltux,
danke für den Vorschlag. Ich habe es in der entsprechenden config geändert.
Aktuell habe ich ja 2 Zugänge einmal über Lan mit fester IP auf dem Laptop und dem RPI im Raum 192.168.138.xxx
Und zusätzlich den Wifi über den im Laptop eingebauten Hotspot, hier vergibt der Laptop IPs im Raum 192.168.137.xxx
Beide funktionieren mit den alten Einstellungen , jedoch kommt diese Flut der Fehlermeldung, wie halt schon seit Tagen.
Kann ich die Fehlermeldung abschalten. verbose?
Sobald ich die vorgeschlagenen Änderungen eingebaut habe kommt folgenden Effekt auf dem Wifi Zugang, den ich eigentlich nutzen will:
1. Anmeldung über SSH möglich
2. Das wars aber auch schon.
3. Return bringt den Effekt, dass sich SSH wieder anmeldet, nach "Wartezeit" Weiter kann man SSH über Wifi nicht mehr bedienen.
Über LAN tauchte der Effekt nicht auf.
Ich hab die Änderungen wieder mit SSH über LAN rückgängig gemacht, über Wifi hätte ich das file nicht editieren mehr können.
Ohne restart läuft jetzt SSH über wifi auch wieder und auch FHEM
Ich kann die Wifi IP des RPI auf dem Laptop Hotspot nicht festschreiben, aktuell ist es die 192.168.137.72.. (nur zur Info). Nach jedem restart gibt es eine Neue.
Hast du noch einen Tip?
Moin,
ich habe das hier gefunden:
ZitatDebian than ubuntu choose to define 127.0.1.1 for mapping the ip of your host_name in case that you have no network
The host_name matches the hostname defined in the "/etc/hostname".
Mir war dieser Eintrag irgendwie völlig unklar:
Zitat127.0.1.1 raspberrypi
Bei mir ist der auch überall gesetzt, aber immer mit dem wirklichen Hostnamen!? Das dort noch der Originalname steht ist sicher falsch. Ob es ein Problem ist weiß ich nicht.
Wie hast Du den Namen von vagabundi geändert?
Gruß Otto
Hi Otto,
meine Unterlagen sagen folgendes:
a. sudo nano /etc/hosts jetzt den Namen hinter 127.0.1.1 ändern auf den neuen Namen: Vagabundi
b. Dann alten mit dem neuen Hostnamen ersetzen:
c. sudo nano /etc/hostname auch hier den neuen Namen "Vagabundi" eingeben.
Jetzt die Änderungen übernehmen: sudo /etc/init.d/hostname.sh
So hab ich es geändert.
Danke für die Hilfe.
ich mache das immer einfach nur mit sudo hostnamectl neuerName
Hi, Otto,
danke für den Hinweis. Ich könnte mir gut vorstellen, dass hier der Hund begraben liegt.
Aber wie gehe ich jetzt vor, ohne dass ich mir den Zugang wieder verbaue?
aktuell sieht es so aus:
pi@vagabundi:~ $ cat /etc/hosts
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
127.0.1.1 raspberrypi
# 192.168.137.9 vagabundi.mshome.net vagabundi Vagabundi kommt gar nicht vor.
dann gibt es noch :
pi@vagabundi:~ $ cat /etc/hostname
vagabundi Dies könnte der Schlüssel sein. Hier ist ja vagabundi auch klein geschrieben, wie in der Fehlermeldung.
Wenn ich jetzt in /etc/hostname den Namen auf raspberrypi umbenenne, welche Kreise zieht dies mit sich?
Bei der Anmeldung in FHEM?
Könnte ja deinem Beispiel folgende einfach mal
sudo hostnamectl neuerName machen und
sudo hostnamectl raspberrypi
Wie hast Du ssh konfiguriert, das Du diese Probleme bekommst?
die /etc/hosts ist eine Datei, die vor dem DNS-System "erfunden" wurde. Gerade für Probleme, wie Du sie hast (Offline) eine ideale Lösung, das lokale Prozesse weiterhin funktionieren.
Gehst Du beo ssh per DNS-Name oder per IP auf den Pi?
Hi wernieman, ich gehe per IP mit ssh auf den Raspberry...
Ich verwende aber auch heidisql, aber auch per IP und auch Filezilla, auch per IP.
Aslo ssh sollte es nichts ausmachen, das Du etwas in die hosts des Pis schreibst. Das problem sollte also woanders liegen ... und ich glaube eher an den Grunsätzlichem Aufbau eines Netzwerkes. Hast Du zum Pi eine andere Hostrange als zum Router Deines Internetzuganges?
Hallo Wernieman,
der PI hängt die längste Zeit des Tages alleine rum.. kein Internetzugang, kein Router, kein Hotspot.
Dies ist der Zeitraum, in dem er die Fehlermeldungen produziert. Und auch sehr häufig, irgendwo im Minutentakt.
Ich fange das Wifi des PI aktuell zeitweise mit dem eingebauten Hotsport des Laptops auf, sprich, er meldet sich am Hotspot des Laptops an.
Darüber bekommt der PI auch Internet,. Der Hotspot im Laptop ist nur freigeschalten, wenn der Laptop mit deinem Wifi an Internet hängt.
Dann meine ich keine Fehlermeldungen mehr zu bekommen, also, wenn der Pi am Laptop hängt. Ziemlich sicher. Ich vermute, dass die DNS Fähigkeit des Laptop Hotspots den Fehler "wegmacht"
Deshalb auch meine Idee, dass ich meinen Huawei Hotspot an an Pi hänge. Der hat zwar aktuell (noch) keinen Internetzugang aufgrund nicht aufgeladener Datenkarte. Dies liesse sich aber ändern. Wenn ich nur wüsste, ob dieser Huawei Hotspot (E5577) eine Routerfunktionalität mitbringt: Meine Idee, ist ich dann über den Huawei mit einem Pad (angemeldet an Huawei) auf FHEM des RPI (angemeldet auf Huawei) komme und auch der Fehler weg ist.
Ok?
Den Huawei hab ich jetzt an dem Pi. An dem Huawei-Router ist auch ein Pad angeschlossen. Darüber komme ich jetzt auf FHEM.
Ich hab noch kein Datenguthaben im Huawei, werde dies aber nächste Woche nachholen.
Jetzt muss nur noch der Fehler weg, dann ist es ok.
Moin,
solange Du Dich per IP auf den Pi verbindest kannst Du den hostnamen manipulieren wie Du willst, da schneidest Du Dich nicht ab.
Aber wie Werner schon sagt, die hosts ist zur lokalen Namens Auflösung, sie bestimmt nicht den Hostnamen. Also die kannst Du einfach mit nano glattziehen.
Mich hat dort nur der Eintrag mit 127.0.1.1 gewundert:
Die hosts wird meines Wissen bei der Namensauflösung als Erstes angefragt, erst danach DNS.
https://debian-handbook.info/browse/de-DE/stable/sect.hostname-name-service.html
Und der Eintrag 127.0.1.1 ist ein Loopback Eintrag falls gar kein Netzwerk aktiv ist, so habe ich das gestern verstanden.
Gruß Otto
Ich kann positives berichten. Die Fehlermeldung ist heute Nacht nicht einmal gekommen. Hotspotrouter war immer am Pi, aber nicht am Internet. Otto, danke für die Tips.
Ich muss mich jetzt mal einlesen in das Thema hosts, loopback, etc. Ich verstehe das alles noch nicht.
Der Fehler sollte auch ohne die Mithilfe des Routers nicht mehr auftreten. Es ist ja nicht nur der Fehler sondern auch das delay eines fast jeden Linux-Befehls .
Den delay solltest Du zurecht biegen können, wenn Du Deine hosts-Datei glatt ziehst. Gibt genug Threads dazu im Netz ..
Hallo, getraue mich fast nicht wieder zurückzukommen. Leider hat sich Pi wieder in seinen ,,Fehlermodus" verabschiedet. Alles lief rund, bis zu diesem Eintrag im Log :
Ohne äußeren Einfluss durch mich sehe ich folgende. Eintrag im Log:
2019.03.24 15:46:35 3: N.Present_Vagabundi return value: FATAL ERROR: Message NOT sent. No gateway device was available.
sudo: Hostname vagabundi kann nicht aufgelöst werden: Verbindungsaufbau abgelehnt
sudo: Hostname vagabundi kann nicht aufgelöst werden
sudo: Hostname vagabundi kann nicht aufgelöst werden
Ab dann nur noch, immer, jede Minute der Eintrag
sudo: Hostname vagabundi kann nicht aufgelöst werden
Aktuell hängt der Pi an einem Hotspot und hängt darüber kontinuierlich am Internet.
Zum Fehlerzeitpunkt hing der Pi, wie schon die Stunden zuvor am Hotspot, jedoch ohne Internet.
N.Present-vagabundi ist ein bluetooth Tag, über den die Anwesenheit geprüft wird und beim Wechsel des Anwesenheitsstatus eine msg über Pushover geschickt wird.
Internals:
DEF BluetoothAnwesend:presence.* {
if ($EVTPART1 eq "present") {
fhem("msg Anwesenheit beim Vagabundi anwesend");
} elsif ($EVTPART1 eq "absent") {
fhem("msg Anwesenheit beim Vagabundi abwesend");
}
}
FUUID 5c838126-f33f-813e-ee2c-e5691eea8f6fcf5a
NAME N.Present_Vagabundi
NOTIFYDEV BluetoothAnwesend
NR 65
NTFY_ORDER 50-N.Present_Vagabundi
REGEXP BluetoothAnwesend:presence.*
STATE 2019-03-25 15:20:49
TRIGGERTIME 1553523649.93477
TYPE notify
READINGS:
2019-03-25 08:42:56 state active
Attributes:
DbLogExclude .*
alias Schickt msg an Mobil, dass wir anwesend sind
room Anwesenheit
CHANGED
DEF function {`sudo /opt/fhem/lescan.sh 7C:2F:80:D1:89:44`}
FUUID 5c837bef-f33f-813e-c993-4f5b252e372ebb2b
INTERVAL_NORMAL 30
INTERVAL_PRESENT 30
MODE function
NAME BluetoothAnwesend
NOTIFYDEV global
NR 64
NTFY_ORDER 50-BluetoothAnwesend
STATE present
TYPE PRESENCE
READINGS:
2019-03-25 08:42:56 model function
2019-03-25 17:27:01 presence present
2019-03-25 17:27:01 state present
helper:
CURRENT_STATE present
call {`sudo /opt/fhem/lescan.sh 7C:2F:80:D1:89:44`}
RUNNING_PID:
abortFn PRESENCE_ProcessAbortedScan
arg BluetoothAnwesend|{`sudo /opt/fhem/lescan.sh 7C:2F:80:D1:89:44`}|0
bc_pid 770
finishFn PRESENCE_ProcessLocalScan
fn PRESENCE_DoLocalFunctionScan
pid 13923
telnet telnetForBlockingFn_1553499778_127.0.0.1_43708
timeout 60
abortArg:
Attributes:
DbLogExclude .*
absenceThreshold 2
alias Scan für Bluetooth G-Tag
event-on-change-reading .*
presenceThreshold 1
room Anwesenheit,GERAETE
Kann dies das Thema bei mir sein?
telnet telnetForBlockingFn_1553499778_127.0.0.1_43708
Ich weiß nicht, wo ich noch suchen soll?
Soviel Popcorn kann man gar nicht machen...
4 Seiten Diskussion über Netzwerkgrundlagen - und immer noch kein Erfolg? Das kann doch nicht ernstgemeint sein.
Hi betateichen. Ich hab deine Antwort leider nicht verstanden. Soll dies heißen, dass ich nicht weiter fragen darf oder soll? Dann stelle ich es ein.
Ich bin der Meinung, dass das Thema irgendwo aus FHEM heraus erzeugt wird. Ansonsten hab ich kein Programm installiert. Hab der RPI neu aufgesetzt nach Vorgaben aus dem Forum. Deshalb frage ich.
Speziell ist, dass zeitweise kein Internet dran ist, aber auch dies ist jetzt weg, und trotzdem der Fehler.
Ich kann es ja nicht so lassen. Was schlägst du vor?
Der Pi war aber aus dem Netz erreichbar?
Zitat von: UweUwe am 25 März 2019, 18:09:38
Soll dies heißen, dass ich nicht weiter fragen darf oder soll?
Nein, das soll es nicht heißen.
Zitat von: UweUwe am 25 März 2019, 18:09:38
Ich kann es ja nicht so lassen. Was schlägst du vor?
Wie hast Du Deine Netzwerkschnittstellen konfiguriert? Über dhcpd oder über networking?
Es scheint so zu sein, dass einer der beiden Client-Daemons Deine Netzwerkkonfiguration verändert, wenn eine funktionierenden Verbindung aufgebaut oder abgebrochen wird.
Deshalb würde ich mir die abhängigen Skripte in der Debian Installation anschauen, die im Zusammenhang mit den Netzwerkverbindungen stehen.
Bevor da nicht Klarheit herrscht, kommst Du vermutlich nicht weiter.
Wie Werniemann ja schon schrieb:
Zitat von: Wernieman am 23 März 2019, 19:18:47
und ich glaube eher an den Grunsätzlichem Aufbau eines Netzwerkes.
liegt die Ursache mit ziemlicher Sicherheit an Deiner Netzwerkkonfiguration selbst.
Und dann gibt es ja auch noch logfiles in Deinem Debian, in denen man vielleicht Hinweise finden könnte. Aber da wurde bis jetzt offenbar noch gar nicht nachgeschaut.
Stimmt .. in den System-Lgofiles zu schauen ist für mich so selbstverständlich, das ich gar nicht mehr daran denke es weiterzugeben ...
Also was steht denn in:
/var/log/syslog
/var/log/kernlog
Hinweis:
Uns interessieren nur die entsprechenden Zeiten ...
Hallo, danke für eure Antworten,
in meinem Heimnetzwerk hatte ich nie Themen mit dem Pi. Sowohl über WLAN , als auch über Ethernet.
Sobald ich aus der angestammten Umgebung raus war, also kein Internet, kein DHCP , dann kamen die Themen.
Anfangs hatte ich nur Wifi Zugriff auf den Pi, jetzt habe ich auch noch zur Sicherheit Lan Zugang über eine feste IP des PI, zur Sicherheit.
Zu keinem Zeitpunkt hatte ich einen externen Zugang ( außerhalb des lokalen Netzes) auf den Pi.
Jetzt hab ich aktuell einen kontinuierlichen Zugang über Wifi ins Internet.
Wie habe ich die Netzwerkschnittstellen konfiguriert. Diese Frage überfordert mein Wissen.
Gerne würde ich deine restlichen Vorschläge nachgehen, wenn ich nur könnte. Sorry.
Ich hatte noch versucht den Pi als DHCP Access Point zu konfigurieren, das ist mir leder misslungen. Vielleicht gibt es hier noch Installationsreste, die zu meinem Phänomen führen.
Zitat von: UweUwe am 25 März 2019, 19:00:31
Ich hatte noch versucht den Pi als DHCP Access Point zu konfigurieren, das ist mir leder misslungen. Vielleicht gibt es hier noch Installationsreste, die zu meinem Phänomen führen.
Das heißt, es könnte ein, dass sogar noch ein DHCP- und ein DNS Server auf Deinem Pi laufen... nur mal so vor mich hin gedacht.
Vielleicht solltest Du nochmal ganz von vorne anfangen - das ist ein ernst gemeinter Vorschlag.
Hallo Wernieman,
danke!.
Zitat/var/log/syslog
Mar 25 08:30:25 vagabundi kernel: [211252.896762] Bluetooth: hci0 advertising data length corrected Diese Nachricht kommt jede Minute !
Mar 25 06:41:59 vagabundi kernel: [204747.201792] Under-voltage detected! (0x00050005)
Mar 25 06:53:38 vagabundi kernel: [205446.094626] Voltage normalised (0x00000000) und auch diese Nachricht sehe ich auch häufig.
nach einem Reboot sehe ich:
ar 25 08:42:51 vagabundi named[467]: network unreachable resolving './NS/IN': 2001:500:2f::f#53
Mar 25 08:42:51 vagabundi named[467]: network unreachable resolving './DNSKEY/IN': 2001:500:2::c#53
Mar 25 08:42:51 vagabundi named[467]: network unreachable resolving 'G.ROOT-SERVERS.NET/AAAA/IN': 2001:500:1::53#53
Mar 25 08:42:51 vagabundi named[467]: network unreachable resolving './NS/IN': 2001:500:2::c#53
Mar 25 08:42:51 vagabundi named[467]: network unreachable resolving './DNSKEY/IN': 192.33.4.12#53
Mar 25 08:42:51 vagabundi named[467]: network unreachable resolving 'G.ROOT-SERVERS.NET/AAAA/IN': 192.58.128.30#53
Mar 25 08:42:51 vagabundi named[467]: network unreachable resolving 'G.ROOT-SERVERS.NET/AAAA/IN': 2001:503:c27::2:30#53
Mar 25 08:42:51 vagabundi named[467]: network unreachable resolving './NS/IN': 198.41.0.4#53
Mar 25 08:42:51 vagabundi named[467]: network unreachable resolving 'G.ROOT-SERVERS.NET/AAAA/IN': 2001:7fd::1#53
Mar 25 08:42:51 vagabundi named[467]: network unreachable resolving 'G.ROOT-SERVERS.NET/AAAA/IN': 192.112.36.4#53
Mar 25 08:42:51 vagabundi named[467]: network unreachable resolving './DNSKEY/IN': 2001:503:ba3e::2:30#53
Mar 25 08:42:51 vagabundi named[467]: network unreachable resolving './NS/IN': 2001:500:1::53#53
Mar 25 08:42:51 vagabundi named[467]: network unreachable resolving 'G.ROOT-SERVERS.NET/AAAA/IN': 199.7.91.13#53
Mar 25 08:42:51 vagabundi named[467]: network unreachable resolving 'G.ROOT-SERVERS.NET/AAAA/IN': 2001:dc3::35#53
Mar 25 08:42:51 vagabundi named[467]: network unreachable resolving 'G.ROOT-SERVERS.NET/AAAA/IN': 192.36.148.17#53
Mar 25 08:42:51 vagabundi named[467]: network unreachable resolving './DNSKEY/IN': 198.97.190.53#53
Mar 25 08:42:51 vagabundi named[467]: network unreachable resolving './NS/IN': 192.203.230.10#53
Mar 25 08:42:51 vagabundi named[467]: network unreachable resolving './DNSKEY/IN': 2001:7fd::1#53
Mar 25 08:42:51 vagabundi named[467]: network unreachable resolving './NS/IN': 192.112.36.4#53
Da gibt es noch >>> 1000 Zeilen in dem Logfile.
Zitat/var/log/kernlog
Da steht nicht drin .. leere Datei.
Hi, leider kann ich nicht von vorne anfangen, da ich keine feste Umgebung habe, und leider auch in den nächsten Wochen keine haben werde. Ansonsten hätte es dies schon lange gemacht, mit dem vorne anfangen. Der Vorschlag ist richtig, die Umsetzung ist der Haken, das Internet tropft leider nur..
Hallo,
mir fällt gerade noch ein Phönomen in FHEM auf: Beim Aufruf von 2 unterschiedlichen Zimmern erhalte ich folgende Fehlermeldung:
svg.js line 45:
NotFoundError: The operation failed because the requested database object could not be found. For example, an object store did not exist but was being opened.
Mar 25 06:41:59 vagabundi kernel: [204747.201792] Under-voltage detected! (0x00050005)
Mar 25 06:53:38 vagabundi kernel: [205446.094626] Voltage normalised (0x00000000)
Also das ist schon mal eine Deutliche Warnung, um nicht FEHLER zu sagen!
Deine Stromversorgung ist "zu klein". Bitte ein passendes Netzteil (KEIN Handyladegerät) nehmen.
Das kernlog leer ist gaube ich Dir nicht. Allerdings lautet es auch kern.log ....
Schaue doch mal, was im Logverzeichnis so alles drinsteht ... und staune ....
ls -lha /var/log
Ich stimme bettateilchen zu, das Du Deinen Pi neu machen solltest (nach obiger Stromverbesserung). Du schreibst, das Du mal dhcp und Wifi-Zugriff (hostap?) auf dem Pi hattest, weißt aber nicht mal, wo/wie man Netzwerk einstellt .... da kann auf dem Pi wirklich VIEL "nicht in Ordnung" sein.
Oder um es mal anders Auszudrücken:
"Die Karre ist Total Verpfriemelt"