Blocking DNS in HttpUtils_NonblockingGet

Begonnen von Markus M., 12 Mai 2016, 17:07:28

Vorheriges Thema - Nächstes Thema

dev0

DNS Answer zu einem CNAME (www.ddtlab.de):

2016.05.16 06:16:58.476 1: DNS ANSWER 277:70728580000100020003000603777777066464746c61620264650000010001c00c0005000100000000000603787878c010c02b0001000100000e1000040523f4e2c0100002000100000e10000f026e73076464746c61627302657500c0100002000100000e10000d026e73076464746c616273c017c0100002000100000e100010026e73076464746c616273036e657400c0680001000100000e1000040523f4e2c068001c000100000e1000102a010488006610000523f4e200000001c0810001000100000e1000046c3b0841c081001c000100000e10001026049a002010a0130001000000000001c04d0001000100000e1000045fd30191c04d001c000100000e10001020011af84400a0480001000000000001


www.ddtlab.de ist ein Alias für den canonical name xxx.ddtlab.de.

www.ddtlab.de. IN CNAME xxx.ddtlab.de.
xxx.ddtlab.de. IN A     5.35.244.226

rudolfkoenig

@dev0: dein DNS Server ist wie die Politiker: beantwortet eine Frage, die man nicht gestellt hat.
Habe eine Version eingecheckt, die mit solchen Antworten besser umgehen kann.
Es gibt noch eine Merkwuerdigkeit mit inet_aton/gethostbyname hier.

dev0

Ist mehr oder weniger eine standard bind 9.8 Installation, keine Fritzbox ;)
Die Adresse wird jetzt korrekt aufgelöst.

Markus M.

Ich habe leider nach wie vor das selbe Verhalten bei einem Netzausfall.
Also Blockieren wenn das Netz komplett weg ist und der DNS TTL überschritten ist.
FHEM dev + HomeBridge + Lenovo Flex15 + HM-CFG-USB + RFXtrx433 + Fritz!Box 7590/7580/546E

HM Aktor/Sensor/Winmatic/Keymatic/Thermostat, HUE, Netatmo Weather/Security/Heating, Xiaomi AirPurifier/Vacuum, Withings Aura/BPM/Cardio/Go/Pulse/Thermo, VSX828, Harmony, Siro ERB15LE
https://paypal.me/mm0

rudolfkoenig

Liegt das an meiner neu eingebauten DNS Aufloesung?
Wenn ja, dann bitte ein "attr global verbose 5" Log hier reinkleben.

Markus M.

Welche Logeinträge interessieren dich genau? Die zwei DNS?
global verbose 5 geht leider nicht, da reicht die Platte keine 10 Minuten für das Log.
Ich kann mal versuchen das zu simulieren, der Rechner muss dabei aber länger als die TTL offline sein.
FHEM dev + HomeBridge + Lenovo Flex15 + HM-CFG-USB + RFXtrx433 + Fritz!Box 7590/7580/546E

HM Aktor/Sensor/Winmatic/Keymatic/Thermostat, HUE, Netatmo Weather/Security/Heating, Xiaomi AirPurifier/Vacuum, Withings Aura/BPM/Cardio/Go/Pulse/Thermo, VSX828, Harmony, Siro ERB15LE
https://paypal.me/mm0

rudolfkoenig

Erstens will ich wissen, welche DNS Auflösung verwendet wird. Und dann Details in diesem Fall. Manche Module reichen ein loglevel weiter, in diesem Fall reicht es da verbose hochzudrehen.

StefanStrobel

Hallo,

kann es sein, dass HttpUtils_Err den callback mit dem falschen Hash aufruft (%dh) und dass dieser dann in der Sub, die von HttpUtils_Connect an HttpUtils_gethostbyname übergeben wird auch falsch an den Callback des aufrufenden Moduls geht?
Ich habe da eine Beschwerde eines HTTPMOD Anwenders, die ich mir nur so erklären kann ...

Gruss
    Stefan

rudolfkoenig

Ja, es kann sein, obwohl ich euer Problem nicht nachstellen kann.
Mit einem falsch gesetzten dnsServer Attribut habe ich ein "PERL WARNING: Deep recursion on anonymous subroutine at FHEM/HttpUtils.pm line 237" generiert. Das habe ich gerade behoben und eingecheckt. Kannst du bitte euer Problem mit der neuen Version pruefen?

StefanStrobel

#24
Hallo,

ich kann das Problem leider auch nicht nachvollziehen, aber das Symptom ist dass HTTPMOD ewig auf die letzte Antwort wartet und weitere Requests in die Queue stellt. Das kann nur dann passieren wenn entweder der Callback gar nicht von HttpUtils augerufen wird oder wenn er mit einem falschen Hash aufgerufen wird. Deshalb habe ich nach einem potentiellen Bug gesucht.
Mit Deiner Änderung kann das nach meinem Verständnis nun nicht mehr passieren.

Gruss / Thanx
    Stefan

StefanStrobel

Hallo nochmal,

inzwischen hat Ernst die Logs von einem neuen Blockade-Fall gepostet: https://forum.fhem.de/index.php/topic,45176.240.html
Daraus wird ersichtlich, dass der _Read Callback von HTTPMOD in seinem Fall gar nicht aufgerufen wird. Es muss also irgendwo noch ein Bug liegen. Ich bin etwas ratlos und es fällt mir auch schwer den Datenfluss bei HttpUtils mit den vielen Callbacks und Übergaben nachzuvollziehen.
Es wäre naheliegend ihm eine Spezialversion von HttpUtils mit vielen Log-Aufrufen zu geben, habe aber Skrupel inoffizielle Versionen von fremdem Code zu verteilen...

Ich könnte auch einen zu HttpUtils redundanten Timeout-Timer in HTTPMOD einbauen, aber das löst dann das eigentliche Problem nicht.

Ideen?

Gruss
    Stefan

rudolfkoenig

Ich habe jetzt einen weiteren Bug behoben, der allerdings "seit immer" vorhanden war: falls das nonblocking Connect sofort mit Fehler zurueckkommt, dann hat Nonblocking_Get return "Fehlermeldung" ausgefuehrt, statt den Callback aufzurufen. Das habe ich jetzt gefixt.
Reproduzieren kann man das, indem man Http_NonblockingGet in ca 4-Sekunden Rhythmus mit einem ausgeschalteten Rechner aufruft. In der "alten" Version werden manchmal die Callbacks nicht aufgerufen.

Ich gehe davon aus, dass das die Ursache des verlinkten Problems ist.

StefanStrobel

Wunderbar!
Jetzt müsste nur noch jemand das ganze auch für DevIO und Fhem2Fhem nutzbar machen ;-)

Gruss und vielen Dank
    Stefan

rudolfkoenig


StefanStrobel

Es wäre schön wenn DevIO und Fhem2Fhem ebenfalls einen nonblocking connect hätten. Im Prinzip steckt ein großer Teil der Arbeit dafür in HttpUtils schon drin. Früher oder später wird vermutlich jemand die dafür nötige Zeit finden und versuchen die Ideen für DevIO und Fhem2Fhem zu adaptieren. Ich habe mir das auch schon mal vorgenommen, aber ich finde leider momentan auch nicht die Zeit dafür. Ich bin schon froh wenn ich mit HTTPMOD am Ball bleiben kann und Modbus mal wieder erweitern kann. Euch wird es nicht anders gehen.

Jedenfalls wenn es jemand anpackt, dann wäre es doch naheliegend, die anderswo verwendbaren Funktionen wie HttpUtils_GetHostByName eher zu einem FhemGetHostByName zu machen. Vielleicht könnte man auch ein TCPUtils Modul aus einigen Funktionen von HttpUtils machen, so dass ein nonblocking Connect einfacher von anderen Modulen nutzbar wäre.

So einfach wie das jetzt klingt ist es sicher nicht aber eine so schöne Verbesserung beim GetHostByName verdient doch zumindest mittel- oder langfristig einen breiteren Einsatz ;-)

Gruß
     Stefan