Probleme mit FBAHAHTTP nach Umstellung auf "hosts"

[Elektrolurch]

Hallo,

bislang hatte ich mit den dect - Steckdosen an der Fritzbox kein Problem.
Der Zugriff war wie folgt definiert:
[cod]
define dect200 FBAHAHTTP fritz.box
[/code]
Nun habe ich in global folgendes gesetzt:

Code Auswählen Erweitern


dnsHostsFile /etc/hosts
[/code}
da ich bei Ausfall des Internets Probleme mit fhem hatte.
In der /etc/hosts steht u.a. folgendes
[cod]
192.168.1.254 fritz.box Router
[/code}}
Andere Module, die "fritz.box" verwenden, haben damit kein Problem.
Im log steht nun für die dectt200:
[code]
2021.03.13 11:13:35 3: dect200: fritz.box: Verbindungsaufbau abgelehnt (111)
2021.03.13 11:18:35 4: FBAHAHTTP_connect dect200: got SID 33e13ac851674d2a
2021.03.13 11:18:35 3: dect200: fritz.box: Verbindungsaufbau abgelehnt (111)
2021.03.13 11:23:36 4: FBAHAHTTP_connect dect200: got SID 582fb62655830a84

Ändert man die Definition auf:

Code Auswählen Erweitern


define dect200 FBAHAHTTP 192.168.1.254

so verschwinden die log-Einträge wieder.
Das Ganze tritt erst auf, seit dem ich das globale Attribut für das hostfile verwende.

Elektrolurch

[rudolfkoenig]

Das Besorgen der AHA Session-ID passiert blockierend, dazu wird die blockierende Resolver-Bibliothek des Betriebsystems verwendet. Diese beachtet bei einem "normalen" /etc/resolv.conf die Datei /etc/hosts. Aus dem angehaengten Log geht hervor, dass das funktioniert.

Die nichtblockierende Version der HttpUtils DNS-Aufloesung wird nur dann verwendet, wenn dnsServer gesetzt ist, sonst wird die blockierende Resolver-Bibliothek verwendet, s.o. Dabei ist auch das "useInet6" global Attribut relevant. Falls man dnsServer und dnsHostsFile gesetzt hat, dann wird zunaechst im (HttpUtils-eigenen) Cache, und dann in dnsHostsFile gesucht. Daraus werden trotz gesetzten useInet6 nur IPv4 Adressen zurueckgeliefert, das ist ein Bug bzw. ein nicht implementiertes Feature.

Ich habe gerade versucht das beschriebene Problem mit FBAHAHTTP nachzustellen, und ich sehe keinen Fehler.
Wenn weiterhin Probleme bestehen, dann waere ein "attr global verbose 5" log interessant.

[kaihs]

Evtl. liegt es an der Vermischung von IPv4 und IPv6 Adressen.
Ich hatte so ein Problem bei der Verwendung des FritzBox Moduls, siehe https://forum.fhem.de/index.php/topic,92231.msg1120830.html#msg1120830.

Geholfen habe ich mir mit der Ermittlung der IPv4 Adresse in Initialize:

Code Auswählen Erweitern


   my $rc = eval
    {
      require Net::Address::IP::Local;
      require IO::Interface::Simple;
      Net::Address::IP::Local->import();
      IO::Interface::Simple->import();
      1;
    };
    if ($rc) {
      $hash->{local_address} = Net::Address::IP::Local->public_ipv4;
    }


Diese Adresse wird dann explizit verwendet wenn die Anmeldung an der Fritzbox erfolgt.

[Elektrolurch]

Hallo Rudi,

hier das log:

Code Auswählen Erweitern


2021.03.13 19:32:32 4: FBAHAHTTP_connect dect200: got SID 7e712a851c0b6448
2021.03.13 19:32:32 5: HttpUtils url=http://fritz.box/webservices/homeautoswitch.lua?sid=7e712a851c0b6448&switchcmd=getdevicelistinfos
2021.03.13 19:32:32 4: IP: fritz.box -> 127.0.1.1
2021.03.13 19:32:32 4: HttpUtils: fritz.box: Verbindungsaufbau abgelehnt (111)
2021.03.13 19:32:32 3: dect200: fritz.box: Verbindungsaufbau abgelehnt (111)

Jetz habe ich mich gefragt, warum da der loop-back steht?
In der hosts ist folgendes eingetragen:

Code Auswählen Erweitern


127.0.1.1 Speicherknecht.fritz.box Speicherknecht

Eigentlich sollte das Format für die hosts ja so sein

Code Auswählen Erweitern


<ip_Adresse> <hostname.domain> hostname

Tja, dumm, wenn der Domainname gleich dem hostnamen (Router) ist.
Offensichtlich nimmt der fhem-resolver per grep den ersten Eintrag in der hosts, den er mit dem hostnamen finden kann.
Wenn ich die Zeile herausnehme, dann gehts.
Ich möchte eigentlich von der Auflösung per hosts und fritzbox weg (derzeit habe ich noch viele Geräte mit statischen IPs im Netz) und statt dessen dnsmasq einsetzen.
Kann ich dann auf die globalen Attribute
dnsHostsFile /etc/hosts
dnsServer 192.168.1.254
verzichten? Ohne dnsServer Attribut bei fehm bleibt diesdes ohne Internetverbindung hängen...

Kleine Anmerkung: Ich hatte beim experimentieren mit dnsmasq das attribut global dnsServer auf den Testserver mit dnsmasq gesetzt und es dann vergessen zurückzusetzen.
Als dann der Testserver aus war, passierte folgendes:
Nach ca. 4 - 6 Stunden wurde das log-File von fhem mit Meldungen vollgemüllt:

Code Auswählen Erweitern


to many open files ... /dev/null

und fhem war über die Web-Oberfläche nicht mehr zu erreichen.
Da fehlt in fhem für die Verwendung von "attr global dnsServer" vielleicht noch eine Sicherheitsabfrage, wenn der angegebene Server nicht erreichbar ist.

Gruß

Elektrolurch

[rudolfkoenig]

Das sind zu viele Fragen, ich werde vmtl. welche uebersehen.
- dnsHostsFile: habs gefixt
- Verzicht auf dnsServer Attribut: dann wird die OS-eigene DNS-Abfrage verwendet, mit 4 Sekunden FHEM-Blockierung, falls der DNS-Server nichts findet oder nicht erreichbar ist.
- too many open files: keine Ahnung: die Fehlermeldung mit /dev/null kommt mir komisch vor, wenn ich was machen soll, brauche ich was zum Nachstellen.

[Elektrolurch]

Hallo Rudi,

[Zitat]
- Verzicht auf dnsServer Attribut: dann wird die OS-eigene DNS-Abfrage verwendet, mit 4 Sekunden FHEM-Blockierung, falls der DNS-Server nichts findet oder nicht erreichbar ist.
[/Zitat]
Das war das Verhalten, was ich vor drei Jahren hatte, als das Attribut "dnsServer" nicht gesetzt war. fhem war im Betrieb sporadisch immer wieder über mehrere Sekunden blockiert (wenn das Internet ausgefallen war) und der fhem Neustart dauerte zwischen 30 und 60 Minuten! Ich denke, das daran die .svg - Dateien der >Iconen schuld sind, die enthalten nämlich zum Teil eine ganze Reihe von Links.... und beim Start von fhem wird ja wohl ein WEB rereadicons ausgeführt. Allen Modulen, die das Internet benötigen, hatte ich ein "disable 1" verpasst.

[Zitat]
- too many open files: keine Ahnung: die Fehlermeldung mit /dev/null kommt mir komisch vor, wenn ich was machen soll, brauche ich was zum Nachstellen.
[/Zitat]
Na ja, wäre ja ganz einfach: attr global dnsServer <non-existent-IP-lokal_LAN>
Ich habe da einige Module, die externe (Internet) benötigen. Die brachten keine Fehlermeldungen, da vermutlich non-blocking programmiert.
Es dauert dann so einige Stunden, bis die Meldungen dann im log auftauchen... Das fhem-log File hat dann mal schnell über 100 Mb.
(debian buster Kernel 10.14 auf AMD)
Ich habe mir die Implementierung von http-utils nicht angesehen, wird da irgendwie Buch über die non-blocking Anfragen geführt?
Man könnte ja in einem hash die Adresse, an die ein request geht, vermerken und einen Zähler hochzählen, wenn erneut ein request abgesendet wird. Kommt die Antwort, wird der Zähler für diese Adresse wieder dekrementiert.
Übersteigt die Zahl der offenen requests eine bestimmte Anzahl, so weiß man das das Ziel nicht erreichbar ist. - und wenn es ein DNS-Request ist, weiß man dass da was "oberfaul" ist...

Elektrolurch

[rudolfkoenig]

Ich denke, das daran die .svg - Dateien der >Iconen schuld sind, die enthalten nämlich zum Teil eine ganze Reihe von Links.... und beim Start von fhem wird ja wohl ein WEB rereadicons ausgeführt.

Erstens ist mir nicht bewusst, dass in den Icons Links waeren (hast Du dafuer ein Beispiel?), und zweitens wird bei rereadicons sicher kein Internet kontaktiert, nur auf der lokalen Festplatte ein "ls" durchgefuehrt.

Na ja, wäre ja ganz einfach: attr global dnsServer <non-existent-IP-lokal_LAN>

So einfach ist das nicht, bei mir kam es zu keinem solchen Fehler.
Allerdings auch zu keinem anderen Fehler, was natuerlich ein Fehler ist
=> Habe das timeout Handling in HttpUtils/dnsServer jetzt gefixt.

[Elektrolurch]

Hallo Rudi,

mit den SVGs -> da ist mir nichts anderes eingefallen, um zu verstehen, warum fhem bei fehlendem Internet fast 1 Stunde braucht, um hochzufahren. Im normalen Betrieb sind es dann immer wieder erhebliche Aussetzer von bis zu 1 Minute gewesen.

Code Auswählen Erweitern


<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- Created with Inkscape (http://www.inkscape.org/) -->

<svg
   xmlns:dc="http://purl.org/dc/elements/1.1/"
   xmlns:cc="http://creativecommons.org/ns#"
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:svg="http://www.w3.org/2000/svg"
   xmlns="http://www.w3.org/2000/svg"
   version="1.0"

Ich weiß nicht, ob diese Links beim Laden des svgs interpretiert werden.
Ich hatte alle Module, die Internet nutzen, deaktiviert und trotzdem blieb fhem hängen.

Elektrolurch

[rudolfkoenig]

Ach diese Links.
Die sind fuer Programme gedacht, die die SVG-Syntax pruefen wollen.
FHEM tut das sicher nicht, und ich hoffe, dass die Browser das auch nicht tun.
Es kostet viel CPU und Netzwerk, ohne einen praktischen Nutzen.

[Elektrolurch]

Ok. Ist ja jetzt auch schon 2 - 3 Jahre her, wo ich wirklich über Wochen hinweg wegen der Internet - Probleme auch mit fhem hatte.
Werde bei Gelegenheit mal das DSL-Kabel herausziehn und fhem dann mit verbose 5 neu starten. Vielleicht gibt es ja dieses Problem auch nicht mehr, da sich ja die http-utils seit dem ja auch weiter entwicklet haben.
Mir  ist es jedenfalls auch schon ziemlich wichtig, das fhem auch ohne Probleme ohne Internet läuft.
Werde dann wieder berichten.
Danke.
Elektrolurch