Update 1. August 2019:
Das Problem konnte dadurch gelöst werden, dass im UniFi-Controller unter Network --> WAN die Option IPV6 Connection Type angewählt wurde: UsingDHCPv6
Warum es zum Verbindungsproblem kam, und warum das die Lösung ist, ist mir aber völlig schleierhaft.Hallo,
mit dem Maintainer des Blitzer-Moduls habe ich bereits kommuniziert.
Immerhin konnte er das Problem eingrenzen:
Zitat... das Modul macht 2 unterschiedliche Abfragen.
1x bei atudo.net -> Blitzerdaten (Koordinaten und grundlegende Informationen) (Diese kommen bei mir an)
und pro Blitzer dann noch bei OSM -> Genauere Ortsangaben basierend auf die Koordinaten des Blitzers (Diese kommen NICHT bei mir an).
Er hat mir geraten, das Problem hier kundzutun.
Der Link zum bisherigen Thread, sowie die folgende Kommunikation:
//[code]https://forum.fhem.de/index.php/topic,99070.msg960326.html#msg960326[/code]
Wenn in der Linux-Konsole die URL abfragt wird, scheint es in Ordnung zu sein, d.h. alle Infos kommen an.
pi@HPT610:/media/USBBackup/FhemBackup$ wget -O - "https://nominatim.openstreetmap.org/reverse?format=json&lat=50.934
--2019-07-24 18:55:26-- https://nominatim.openstreetmap.org/reverse?format=json&lat=50.934988&lon=6.963184
Resolving nominatim.openstreetmap.org (nominatim.openstreetmap.org)... 130.117.76.9, 2001:978:2:2c::172:9
Connecting to nominatim.openstreetmap.org (nominatim.openstreetmap.org)|130.117.76.9|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [application/json]
Saving to: 'STDOUT'
- [<=> "place_id":116736594,"licence":"Data © OpenStreetMap contributors, ODbL 1.0. https://osm.org/copyright","osm_type":"wtadt, Köln, Regierungsbezirk Köln, Nordrhein-Westfalen, 50667, Deutschland","address":{"road":"Heumarkt","suburb":"Al- [ <=>
2019-07-24 18:55:26 (23.9 MB/s) - written to stdout [617]
pi@HPT610:/media/USBBackup/FhemBackup$ wget -O - "https://nominatim.openstreetmap.org/reverse?format=json&lat=50.934988&lon=6.963184"
--2019-07-24 19:18:44-- https://nominatim.openstreetmap.org/reverse?format=json&lat=50.934988&lon=6.963184
Resolving nominatim.openstreetmap.org (nominatim.openstreetmap.org)... 130.117.76.9, 2001:978:2:2c::172:9
Connecting to nominatim.openstreetmap.org (nominatim.openstreetmap.org)|130.117.76.9|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [application/json]
Saving to: 'STDOUT'
- [<=> ] 0 --.-KB/s {"place_id":116736594,"licence":"Data © OpenStreetMap contributors, ODbL 1.0. https://osm.org/copyright","osm_type":"way","osm_id":171952941,"lat":"50.9349990559632","lon":"6.96317995651474","display_name":"Heumarkt, Altstadt-Nord, Innenstadt, Köln, Regierungsbezirk Köln, Nordrhein-Westfalen, 50667, Deutschland","address":{"road":"Heumarkt","suburb":"Altstadt-Nord","city_district":"Innenstadt","city":"Köln","state_district":"Regierungsbezirk Köln","state":"Nordrhein-Westfalen","postcode":"50667","country":"Deutschland","country_code":"de"},"boundingbox":["50.9349452","50.9350167"- [ <=> ] 617 --.-KB/s in 0s
2019-07-24 19:18:45 (17.3 MB/s) - written to stdout [617]Mein Device:
defmod myBlitzer Blitzer 15
attr myBlitzer Ausgabe number,{OR,city,town,},{OR,suburb,city_district,village,},road,building,[max.],vmax,[km/h],[-],distanceShort,[km],newline
attr myBlitzer HTML_Before <html> <p align='left'>Aktuelle Blitzer:<br>
attr myBlitzer HTML_Without <html> <p align='left'>Keine Blitzer in der Nähe</p></html>
attr myBlitzer MapHeight 600px
attr myBlitzer MapShow 1
attr myBlitzer MapWidth 600px
attr myBlitzer ShowFixed 0
attr myBlitzer area_bottomLeft_latitude 50.9393399099099
attr myBlitzer area_bottomLeft_longitude 6.91259454955601
attr myBlitzer area_topRight_latitude 51.1195200900901
attr myBlitzer area_topRight_longitude 7.19908545044399
attr myBlitzer comment Die Readings werden (im Detail) nicht benötigt, deshalb wurde das Attribut "createAllReadings" auf 0 gesetzt. \
ShowFixed: hiermit werden die festen Blitzer angezeigt. \
Leider können im ausgewählten Vereich nicht alle angezeigt werden, deshalb werden nur die mobilen Blitzer ausgewählt.
attr myBlitzer createAllReadings 0
attr myBlitzer createNoHTML 0
attr myBlitzer createUpdateReading 1
attr myBlitzer disable 1
attr myBlitzer home_latitude 50.972032
attr myBlitzer home_longitude 6.917153
attr myBlitzer icon car
attr myBlitzer radius 12
attr myBlitzer room Traffic
setstate myBlitzer Defined
setstate myBlitzer 2019-07-24 07:27:13 Anzeige 1
setstate myBlitzer 2019-07-24 18:55:17 Error error while requesting https://nominatim.openstreetmap.org/reverse?format=json&lat=51.046664&lon=6.992052 - connect to https://nominatim.openstreetmap.org:443: Network is unreachable
setstate myBlitzer 2019-07-24 18:55:17 html <html> <p align='left'>Aktuelle Blitzer:<br>00 max. 50 km/h - 9.9 km <br></p></html>
setstate myBlitzer 2019-07-24 18:55:17 lastUpdate Wed Jul 24 18:55:17 2019
setstate myBlitzer 2019-07-24 18:55:17 status okIn den Readings erscheint eine error-Meldung.
In global steht sslVersion auf SSLv23:!SSLv3:!SSLv2 - kann das ein Ansatzpunkt sein?
Ich nutze pi-hole auf dem gleichen Rechner, auf dem auch Fhem läuft kann das ein Problem sein?
Da es ja schon längere Zeit funktioniert hat, frage ich mich woran es liegen könnte.
Wegen eines anderen Problem mit dem Modul Buienradar kann ich aber die genaue Reihenfolge meiner Änderungen nicht mehr sagen.
Backups habe ich im Prinzip, leider nicht den aktuellen Stand (ich hatte Änderungen wegen Nutzung des neuen flex-styles durchgeführt, von diesem habe ich aber kein Backup gleichzeitig und funktionierendem Blitzermodul).
Wäre schön, wenn sich jemand der Sache annehmen könnte.
Nur zur Information in eigener Sache: ich nutze zwar das Blitzermodul, falle aber ansonsten auch an Stellen ohne Blitzer nicht durch zu schnelles Fahren auf.
Viele Grüße Gisbert
Hallo!
Ich bin der Maintainer vom Blitzermodul. Da wir mittlerweile im dem Thread
https://forum.fhem.de/index.php/topic,99070.150.html
festgestellt haben, dass es nicht nur das Blitzermodul betrifft, wird hier die Diskussion fortgesetzt in der Hoffnung, dass wir noch jemanden mit weiteren Lösungsvorschlägen finden.
Hier ein auszug aus den letzten Beiträgen:
Zitat von: Gisbert am 27 Juli 2019, 10:39:40
Hallo Joachim,
hallo Bismosa,
ja, ich weiß, dass das hier OT ist, bin aber dennoch froh darüber, dass ihr euch dieser Sache annehmt.
Da ich meine Familie nicht mit pi-hole terrorisieren wollte, habe ich nur auf meinem Desktop-Rechner und meinem Handy das DNS-Server die IP des pi-hole/Fhem-Servers eingetragen.
In pi-hole habe ich bereits alle möglich Domains auf die Whitelist gesetzt, die aus Fhem nicht erreichbar sind.
Die IP des Fhem-Servers ist fix auf 192.168.1.46 eingestellt.Ja, ping funktioniert in allen erdenklichen Varianten für die "nicht erreichbaren" URLs.
pi@HPT610:~$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
pi@HPT610:~$ ip route
default via 192.168.1.1 dev enp3s0
192.168.1.0/24 dev enp3s0 proto kernel scope link src 192.168.1.46
pi@HPT610:~$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether c8:cb:b8:2f:5a:02 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.46/24 brd 192.168.1.255 scope global enp3s0
valid_lft forever preferred_lft forever
inet6 fe80::cacb:b8ff:fe2f:5a02/64 scope link
valid_lft forever preferred_lft forever
pi@HPT610:~$ nslookup nominatim.openstreetmap.org
Server: 127.0.0.1
Address: 127.0.0.1#53
Non-authoritative answer:
Name: nominatim.openstreetmap.org
Address: 130.117.76.9
pi@HPT610:~$ dig nominatim.openstreetmap.org
; <<>> DiG 9.10.3-P4-Debian <<>> nominatim.openstreetmap.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57798
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;nominatim.openstreetmap.org. IN A
;; ANSWER SECTION:
nominatim.openstreetmap.org. 192 IN A 130.117.76.9
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Jul 27 10:18:07 CEST 2019
;; MSG SIZE rcvd: 72
pi@HPT610:~$ sudo nmap -p 443 nominatim.openstreetmap.org
Starting Nmap 7.40 ( https://nmap.org ) at 2019-07-27 10:31 CEST
Nmap scan report for nominatim.openstreetmap.org (130.117.76.9)
Host is up (0.021s latency).
Other addresses for nominatim.openstreetmap.org (not scanned): 2001:978:2:2c::172:9
PORT STATE SERVICE
443/tcp open https
Nmap done: 1 IP address (1 host up) scanned in 0.71 seconds
Es ist sowas von mysteriös, aber anscheinend sind diese (und andere URLs) auf Linux-Ebene erreichbar.
Viele Grüße Gisbert
Edit:
Vielleicht das noch:
pi@HPT610:~$ curl -k https://nominatim.openstreetmap.org/reverse?format=json&lat=50.911849&lon=6.989686
[1] 23750
[2] 23751
pi@HPT610:~$ {"error":{"code":400,"message":"Need coordinates or OSM object to lookup."}}
[1]- Done curl -k https://nominatim.openstreetmap.org/reverse?format=json
[2]+ Done lat=50.911849
Zitat von: MadMax-FHEM am 27 Juli 2019, 10:54:39
Ja sehr misteriös...
Mit den von dir gegebenen Infos scheiden wohl pihole als auch iptables aus (bin aber da kein Spezialist, sieht aber "normal" aus)...
Eine Idee hab ich noch (aber weder der Fehler deiner letzten Ausgabe noch andere Fehler deuten darauf hin): es gibt hier einen Thread bzgl. ssl und Buster (Nachfolger von raspbian Stretch)...
Hat begonnen in dem Thread zu "Abfragen" von "irgendwas.bund.de" (weiß den genauen Namen leider nicht, lese dort nur ab und an mal rein)...
Welches OS hast du?
Ansonsten wirklich mal im USG schauen, nicht dass der irgendwas blockt...
...oder wie vorgeschlagen: mal direkt ans Internet/FB
Gruß, Joachim
Gruß
Bismosa
Hallo Joachim,
ich hab folgendes OS:
pi@HPT610:~$ uname -a
Linux HPT610 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1+deb9u4 (2019-07-19) x86_64 GNU/Linux
Viele Grüße Gisbert
Hallo Gisbert,
was kommt bei:
cat /etc/os-release
EDIT: das ist der Thread wo auch einige Zugriffsprobleme zu externen Diensten haben, da liegt es aber wohl an ssl: https://forum.fhem.de/index.php/topic,48609.msg402741.html#msg402741 (ist erst so im hinteren Drittel)...
EDIT2: das ist der "ausgelagerte Thread" dazu: https://forum.fhem.de/index.php/topic,102385.msg959441.html#msg959441
Gruß, Joachim
ZitatIn global steht sslVersion auf SSLv23:!SSLv3:!SSLv2 - kann das ein Ansatzpunkt sein?
Vielleicht. Warum hast Du das überhaupt ? :-\
Ist nicht so wirklich ein Thema, wo ich tief drin stecke, aber in meinem neuen Nina-Modul haben MANCHE user auch ein Problem durch den "normalen" HttpUtils_BlockingGet-Aufruf ohne den Parameter sslargs. Das hinzufügen von
sslargs => { SSL_version => 'TLSv12' }, scheint zu helfen.
Details zu der Diskussion hier (https://forum.fhem.de/index.php/topic,102385.0.html)
Grüße Markus
Hallo!
Sorry...da verstehe ich leider nichts von :o
Aber man könnte es mit der Demo in den MyUtils mal testen:
sub TestHTTP(){
my $hash = {};
my $param = {
url => "https://nominatim.openstreetmap.org/reverse?format=json&lat=".52.111."&lon=".8.1212,
timeout => 15,
sslargs => { SSL_version => 'TLSv12' },
method => "GET", # Lesen von Inhalten
hash => $hash, # Muss gesetzt werden, damit die Callback funktion wieder $hash hat
header => "agent: FHEM/1.0\r\nUser-Agent: FHEM/1.0\r\nAccept: application/json",
callback => \&TestHTTPCallback # Diese Funktion soll das Ergebnis dieser HTTP Anfrage bearbeiten
};
#agent: FHEM/1.0\r\nUser-Agent: FHEM/1.0\r\nAccept: application/json
HttpUtils_NonblockingGet($param); # Starten der HTTP Abfrage. Es gibt keinen Return-Code.
}
sub TestHTTPCallback($){
my ($param, $err, $data) = @_;
my $mydata = $param->{hash};
my $hash = $mydata->{hash};
Log 1, "http:".$err."\n".$data;
return;
}
Dann könnte ich das im Blitzermodul auch einbauen (oder sind Schwierigkeiten bei anderen Usern zu erwarten?
Gruß
Bismosa
Zitat von: KölnSolar am 27 Juli 2019, 11:35:25
Vielleicht. Warum hast Du das überhaupt ? :-\
Ist nicht so wirklich ein Thema, wo ich tief drin stecke, aber in meinem neuen Nina-Modul haben MANCHE user auch ein Problem durch den "normalen" HttpUtils_BlockingGet-Aufruf ohne den Parameter sslargs. Das hinzufügen von sslargs => { SSL_version => 'TLSv12' }, scheint zu helfen.
Details zu der Diskussion hier (https://forum.fhem.de/index.php/topic,102385.0.html)
Grüße Markus
Hallo Markus,
das Ergebnis ist das gleiche für diese 3 Fälle:
- kein sslVersion Attribut
- sslVersion SSLv23:!SSLv3:!SSLv2
- sslVersion TLSv12:!SSLv3
@Joachim, ich antworte gleich, wenn ich wieder am PC bin.
Viele Grüße Gisbert
Ich lese nur eine einzige Fehlermeldung und die ist immer gleich.
Network unreachable.
Ist das noch aktuell? Wenn ja ist das nicht gerade eine typische SSL Fehlermeldung wie hier vermutet.
Zitat von: MadMax-FHEM am 27 Juli 2019, 11:22:22
was kommt bei:
cat /etc/os-release
Gruß, Joachim
Ergebnis:
pi@HPT610:~$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
NAME="Debian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
pi@HPT610:~$Zitat von: CoolTux am 27 Juli 2019, 13:55:45
Ich lese nur eine einzige Fehlermeldung und die ist immer gleich.
Network unreachable.
Ist das noch aktuell? Wenn ja ist das nicht gerade eine typische SSL Fehlermeldung wie hier vermutet.
Ja ist leider immer noch aktuell, Vorschläge zum Testen sind willkommen.
Das Vertrackte daran ist, dass die URL's auf der Linuxebene erreichbar sind (bin Laie - deshalb kann ich's nicht besser beschreiben), nicht aber wenn sie aus Fhem heraus in den entsprechenden Modulen aufgerufen werden.
Viele Grüße Gisbert
Hallo!
Könntest Du bitte das
Zitat von: bismosa am 27 Juli 2019, 11:43:49
Aber man könnte es mit der Demo in den MyUtils mal testen:
...
Dann könnte ich das im Blitzermodul auch einbauen (oder sind Schwierigkeiten bei anderen Usern zu erwarten?
nochmal testen? Vielleicht können wir es dann wirklich auf SSL eingrenzen.
Gruß
Bismosa
Zitat von: bismosa am 27 Juli 2019, 11:43:49
Hallo!
Sorry...da verstehe ich leider nichts von :o
Aber man könnte es mit der Demo in den MyUtils mal testen:
sub TestHTTP(){
my $hash = {};
my $param = {
url => "https://nominatim.openstreetmap.org/reverse?format=json&lat=".52.111."&lon=".8.1212,
timeout => 15,
sslargs => { SSL_version => 'TLSv12' },
method => "GET", # Lesen von Inhalten
hash => $hash, # Muss gesetzt werden, damit die Callback funktion wieder $hash hat
header => "agent: FHEM/1.0\r\nUser-Agent: FHEM/1.0\r\nAccept: application/json",
callback => \&TestHTTPCallback # Diese Funktion soll das Ergebnis dieser HTTP Anfrage bearbeiten
};
#agent: FHEM/1.0\r\nUser-Agent: FHEM/1.0\r\nAccept: application/json
HttpUtils_NonblockingGet($param); # Starten der HTTP Abfrage. Es gibt keinen Return-Code.
}
sub TestHTTPCallback($){
my ($param, $err, $data) = @_;
my $mydata = $param->{hash};
my $hash = $mydata->{hash};
Log 1, "http:".$err."\n".$data;
return;
}
Dann könnte ich das im Blitzermodul auch einbauen (oder sind Schwierigkeiten bei anderen Usern zu erwarten?
Gruß
Bismosa
Ich habe es damit getestet. Habe sowohl sslargs als auch method auskommentiert. Dennoch keine Fehler.
Zitat von: bismosa am 27 Juli 2019, 11:43:49
Hallo!
Sorry...da verstehe ich leider nichts von :o
Aber man könnte es mit der Demo in den MyUtils mal testen:
sub TestHTTP(){
my $hash = {};
my $param = {
url => "https://nominatim.openstreetmap.org/reverse?format=json&lat=".52.111."&lon=".8.1212,
timeout => 15,
sslargs => { SSL_version => 'TLSv12' },
method => "GET", # Lesen von Inhalten
hash => $hash, # Muss gesetzt werden, damit die Callback funktion wieder $hash hat
header => "agent: FHEM/1.0\r\nUser-Agent: FHEM/1.0\r\nAccept: application/json",
callback => \&TestHTTPCallback # Diese Funktion soll das Ergebnis dieser HTTP Anfrage bearbeiten
};
#agent: FHEM/1.0\r\nUser-Agent: FHEM/1.0\r\nAccept: application/json
HttpUtils_NonblockingGet($param); # Starten der HTTP Abfrage. Es gibt keinen Return-Code.
}
sub TestHTTPCallback($){
my ($param, $err, $data) = @_;
my $mydata = $param->{hash};
my $hash = $mydata->{hash};
Log 1, "http:".$err."\n".$data;
return;
}
Dann könnte ich das im Blitzermodul auch einbauen (oder sind Schwierigkeiten bei anderen Usern zu erwarten?
Gruß
Bismosa
Ergebnis:
2019.07.27 16:30:32 1: PERL WARNING: Subroutine TestHTTP redefined at .//FHEM/99_myUtils.pm line 226.
2019.07.27 16:30:32 1: PERL WARNING: Subroutine TestHTTPCallback redefined at .//FHEM/99_myUtils.pm line 242.
2019.07.27 16:30:52 1: http:connect to https://nominatim.openstreetmap.org:443: Network is unreachableD.h. :'(
Gibt es noch Ideen, was ich machen könnte?
Außer Weglaufen, das Land verlassen, ... :-\
Hast Du ein dnsServer Eintrag im global Device?
Hallo!
1.) Hast Du denn schon probiert Dein FHEM ohne den USG3 Router zu betreiben?
2.) Hast Du dort vielleicht Log-Einträge?
3.) Beim Stöbern im Thread ist mir gerade dein Edit nochmal ins Auge gesprungen:
ZitatEdit:
Vielleicht das noch:
Code: [Auswählen]
pi@HPT610:~$ curl -k https://nominatim.openstreetmap.org/reverse?format=json&lat=50.911849&lon=6.989686
[1] 23750
[2] 23751
pi@HPT610:~$ {"error":{"code":400,"message":"Need coordinates or OSM object to lookup."}}
[1]- Done curl -k https://nominatim.openstreetmap.org/reverse?format=json
[2]+ Done lat=50.911849
Den Fehler habe ich bei curl übrigens auch...
4.) Versuch doch nochmal bitte diesen Code in der myUtils:
sub TestWGET(){
system("wget -O - \"https://nominatim.openstreetmap.org/reverse?format=json&lat=50.934988&lon=6.963184\"");
}und aufrufen mittels
{TestWGET()}in der Kommandozeile.Dies hatte ja auf Kommandozeilenebene schonmal funktioniert. Funktioniert das auch aus FHEM heraus? Die Ausgabe davon steht in der Log.
5.)Wie wäre es, wenn Du FHEM mal stoppst, die config umbenennen, statefile umbenennen, myUtils umbenennen (noch etwas???) und mit einem leeren FHEM nochmal probierst (in einer neuen myUtils dann einfach obiggen Code probieren). Vorher unbedingt ein Backup vom FHEM Verzeichnis machen!
Ich bin auch leider bis auf weiteres raus. Bin die nächsten Tage unterwegs...werde aber versuchen vom Handy aus bei der Fehlersuche zu helfen :)
Gruß
Bismosa
Hallo CoolTux,
Zitat von: CoolTux am 27 Juli 2019, 17:03:33
Hast Du ein dnsServer Eintrag im global Device?
Ja, ich hab's mit 8.8.8.8 und mit der IP des Fhemservers / pi-hole (192.168.1.46) probiert, mit beiden erhalte ich das gleiche (schlechte) Resultat.
Hallo Bismosa,
zu deinen Fragen:
1.) Hast Du denn schon probiert Dein FHEM ohne den USG3 Router zu betreiben?
--> Nein, würde ich nur äußerst ungern machen, da die Fritzbox alles durchleitet und ich Angst hab, dass dann mein Fhemserver ungeschützt im Netz hängt.
2.) Hast Du dort vielleicht Log-Einträge?
--> Es gibt log-Einträge auf dem USG3, aber nichts was auf eine Fhelfunktion auch nur im Entfertesten hindeuten würde.
3.) ok
4.) Versuch doch nochmal bitte diesen Code in der myUtils, hier die Antwort:
--2019-07-27 21:56:49-- https://nominatim.openstreetmap.org/reverse?format=json&lat=50.934988&lon=6.963184
Resolving nominatim.openstreetmap.org (nominatim.openstreetmap.org)... 130.117.76.9, 2001:978:2:2c::172:9
Connecting to nominatim.openstreetmap.org (nominatim.openstreetmap.org)|130.117.76.9|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [application/json]
Saving to: 'STDOUT'
{"place_id":116736594,"licence":"Data © OpenStreetMap contributors, ODbL 1.0. https://osm.org/copyright","osm_type":"way","osm_id":171952941,"lat":"50.9349990559632","lon":"6.96317995651474","display_name":"Heumarkt, Altstadt-Nord, Innenstadt, Köln, Regierungsbezirk Köln, Nordrhein-Westfalen, 50667, Deutschland","address":{"road":"Heumarkt","suburb":"Altstadt-Nord","city_district":"Innenstadt","city":"Köln","state_district":"Regierungsbezirk Köln","state":"Nordrhein-Westfalen","postcode":"50667","country":"Deutschland","country_code":"de"},"boundingbox":["50.9349452","50.9350167","6.9630327","6.9632282"]}
0K 8.95M=0s
2019-07-27 21:56:50 (8.95 MB/s) - written to stdout [617]
5.) Fhem neu aufsetzen --> das geht bei mir nicht in den nächsten Tagen, da ich auch unterwegs sein werde.
Viele Grüße Gisbert
Hallo,
Zitat4.) Versuch doch nochmal bitte diesen Code in der myUtils, hier die Antwort:
also würde ich denken, das der Fehler bei den HttpUtils_NonblockingGet zu suchen ist. Da ein wget scheinbar funktioniert. Aber wo ansetzen?
Mal wieder so ins blaue: Könnte das auch mit der PERL-Version zuammenhängen?
Zitat1.) Hast Du denn schon probiert Dein FHEM ohne den USG3 Router zu betreiben?
--> Nein, würde ich nur äußerst ungern machen, da die Fritzbox alles durchleitet und ich Angst hab, dass dann mein Fhemserver ungeschützt im Netz hängt.
öhm...dann würde mein System ja schon lange von allen Hackern der Erde übernommen worden sein? Solange keine offenen Ports in der Fritzbox vorhanden sind, kann da auch theoretisch keiner ran. Ich würde behaupten, das es so bei den meisten Usern läuft. Alles andere wird erst dringend benötigt, wenn man offene Ports hat. (Bitte keine große Sicherheitsdiskussion hier...selbst mit offenen Ports sollte das für einen Test gehen...? Bitte korrigiert mich, wenn ich ganz falsch liegen sollte.
Bitte vor dem FHEM (temporär) neu aufsetzen nochmal an anderer Stelle informieren...nicht das ich da einen Denkfehler habe und dir nachher noch mehr zerschieße...
Gruß
Bismosa
Wenn du in der FB nicht Ports freigegeben hast oder einen ganzen "Rechner" (vermutlich bei dir aber max. den USG), dann ist dein fhem, selbst direkt an der FB nicht von außen gefährdet.
Die FB blockt erst mal alles von außen kommende...
EDIT: ;)
Gruß, Joachim
Was steht denn in der /etc/resolv.conf für eine IP drin? Wenn die anders lautet nimm Mal die.
Und da du ja anscheinend alles über Pi hole leitest, was sagt das Log vom Pi hole zum Verbindungsversuch?
Hallo CoolTux,
/etc/resolv.conf:
# Dynamic resolv.conf(5) file for glibc resolver(3) generat$
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE$
nameserver 127.0.0.1
search localdomain
Mit dieser IP wird's nicht besser, ist vermutlich erwartbar.
Im pi-hole query log erscheint etwas: siehe screenshot (bin unterwegs, es geht nicht besser)
Viele Grüße Gisbert
Und hast Du das dnsServer Attribut einmal gelöscht?
Attribut dnsServer gelöscht, Änderung abgespeichert, aber keine Änderung/Verbesserung.
Dann weiß ich leider auch nicht.
Ich denke aber nicht das es etwas mit SSL oder so zu tun hat. Ich denke da eher an Deine allgemeine Umgebung.
Daher ja auch die Idee mal mit fhem direkt an die FB, um möglichst wenig "Umgebung" zu haben... ;)
Weil wenn das dann geht, liegt es nicht an fhem, pihole etc. also nicht am "fhem-Rechner" selbst...
Wenn dem dann so sein sollte muss man halt Stück für Stück analysieren was dazwischen ist/war...
Und wenn das mit fhem direkt an der FB auch nicht funktioniert, dann muss man wohl weiter auf dem "fhem.Rechner" suchen...
Gruß, Joachim
Ok, vielen Dank erstmal an alle.
Vorort testen kann ich dann erst mit der Fritzbox nachdem ich wieder zuhause bin, so gegem Ende der kommenden Woche.
Viele Grüße Gisbert
Wenn auf dem selben Client wget funktioniert und die Methode von httpUtils nicht funktioniert, wie kommt ihr darauf, dass es dann an der Netzwerkumgebung liegen muss?
Meiner Meinung nach kann es nur an daran liegen, dass wget und httpUtils unterschiedliche (Netzwerk-)Konfigurationen nutzen.
Hallo!
Guter Gedanke! Wir stochern auch nur im Nebel...und versuchen die Ursache irgendwie zu finden...
Gruß
Bismosa
Da man mich gerade per PM gefragt hat hier reinzuschauen (wieso ist das eine Anfaengerfrage?):
- bitte eine Anleitung bauen, wie man das Problem mit FHEM reproduziert.
- das Problem nach Anleitung mit "attr global verbose 5" reproduzieren, und das FHEM-Log samt Anleitung hier anhaengen
Hallo Rudi,
da neben dem Blitzemodul, auch Pushover betroffen ist, habe ich letzteres bei global verbose 5 zur Versendung einer Nachricht benutzt.
Da ich im Moment unterwegs bin, und das Blitzermodul bei global verbose 5 sehr viel auswirft, was beim Kopieren am Handy nicht gelingen will, poste ich den kurzen log-Eintrag von Pushover:
2019.07.29 21:04:56 5: Cmd: >set Pushover.Nachricht msg 'TEST' 'Testnachricht'<
2019.07.29 21:04:56 5: HttpUtils url=https://api.pushover.net:443/1/messages.json
2019.07.29 21:04:56 4: IP: api.pushover.net -> [2604:9a00:2010:a01e:3::2]
2019.07.29 21:04:56 4: HttpUtils: connect to https://api.pushover.net:443: Network is unreachable
Der Aufruf dieser Seite gelingt ebenfalls nicht:
2019.07.29 20:45:36 5: HttpUtils url=https://api.co2signal.com/v1/latest?countryCode=DE
2019.07.29 20:45:36 4: IP: api.co2signal.com -> [2606:4700:30::681b:8566]
2019.07.29 20:45:36 4: HttpUtils: connect to https://api.co2signal.com:443: Network is unreachable
2019.07.29 20:45:36 2: error while requesting https://api.co2signal.com/v1/latest?countryCode=DE - connect to https://api.co2signal.com:443: Network is unreachable
Wenn ich wieder zuhause bin (gegen Ende der Woche) poste ich den log-Auszug zum Blitzer-Aufruf.
Vielen Dank und viele Grüße
Gisbert
Ich finde hier werden die Pferde unnötig scheu gemacht. Das ist definitiv ein Netzwerk/Netzwerkkonfigurations problem und hat mit FHEM rein gar nichts zu tun.
Hast du (durchgängig) IP v6 aktiviert!?
Weil:
Zitat
IP: api.co2signal.com -> [2606:4700:30::681b:8566]
Da wird eine/die IP v6 "aufgelöst"...
Wie ist dein pihole DNS konfiguriert?
Gruß, Joachim
Hallo!
@rudolfkoenig
Eigentlich ist dies keine direkte Anfängerfrage. Wir haben das Problem auch schon ausführlich im thread zum Blitzermodul besprochen.
Da mir hier auch die Ideen ausgegangen sind und auch andere Module davon betroffen sind, war mein Vorschlag das hier nochmal zu Posten, damit sich das auch noch jemand anderes anschauen kann.
Sorry, wenn das falsch war!
Vermuten tue ich hier auch ein Konfigurationsproblem. Also ein Einzelfall.
Um das bei ihm nachzustellen ohne ein Modul zu verwenden reicht folgendes in der myUtils:
sub TestHTTP(){
my $hash = {};
my $param = {
url => "https://nominatim.openstreetmap.org/reverse?format=json&lat=".52.111."&lon=".8.1212,
timeout => 15,
sslargs => { SSL_version => 'TLSv12' },
method => "GET", # Lesen von Inhalten
hash => $hash, # Muss gesetzt werden, damit die Callback funktion wieder $hash hat
header => "agent: FHEM/1.0\r\nUser-Agent: FHEM/1.0\r\nAccept: application/json",
callback => \&TestHTTPCallback # Diese Funktion soll das Ergebnis dieser HTTP Anfrage bearbeiten
};
#agent: FHEM/1.0\r\nUser-Agent: FHEM/1.0\r\nAccept: application/json
HttpUtils_NonblockingGet($param); # Starten der HTTP Abfrage. Es gibt keinen Return-Code.
}
sub TestHTTPCallback($){
my ($param, $err, $data) = @_;
my $mydata = $param->{hash};
my $hash = $mydata->{hash};
Log 1, "http:".$err."\n".$data;
return;
}
Aufruf dann mittels:
{TestHTTP()}in der Befehlszeile. In der Log steht dann das Ergebnis der Abfrage.
Bei Gisbert sah es dann so aus:
Zitat
2019.07.27 16:30:52 1: http:connect to https://nominatim.openstreetmap.org:443: Network is unreachable
@Gisbert
Bitte nur dies zum testen mit verbose 5 verwenden. Dann ist die Ausgabe nicht so heftig wie im Modul.
Gruß
Bismosa
Habs mit und ohne dnsServer probiert, sogar IPv6 geht bei mir ohne Probleme:
fhem> attr global dnsServer 1.1.1.1
fhem> attr global useInet6
fhem> attr global verbose 5
fhem> {TestHTTP()}
Zitat
2019.07.29 23:14:45 4: DNS result for nominatim.openstreetmap.org: [2001:978:2:2c::172:9], ttl:523
2019.07.29 23:14:45 4: IP: nominatim.openstreetmap.org -> [2001:978:2:2c::172:9]
...
2019.07.29 23:14:45 5: HttpUtils https://nominatim.openstreetmap.org/reverse?format=json&lat=52.111&lon=8.1212: Got data, length: 570
...
2019.07.29 23:14:45 1: http:
{"place_id":1401478,"licence":"Data © OpenStreetMap contributors, ODbL 1.0. https://osm.org/copyright","osm_type":"node","osm_id":320212341,"lat":"52.1132377","lon":"8.1198954","display_name":"Schutzhütte, Bielefelder Straße, Bad Laer, Landkreis Osnabrück, Niedersachsen, 49196, Deutschland","address":{"address29":"Schutzhütte","road":"Bielefelder Straße","village":"Bad Laer","county":"Landkreis Osnabrück","state":"Niedersachsen","postcode":"49196","country":"Deutschland","country_code":"de"},"boundingbox":["52.1131377","52.1133377","8.1197954","8.1199954"]}
Jetzt warte ich auf das verbose 5 Log eines Problemfalls.
Mit dnsServer 192.168.1.46 (Fhemserver und pi-hole):
2019.07.29 23:24:44 5: Cmd: >{TestHTTP()}<
2019.07.29 23:24:44 5: HttpUtils url=https://nominatim.openstreetmap.org/reverse?format=json&lat=52.111&lon=8.1212
2019.07.29 23:24:44 5: DNS QUERY 707201000001000000000000096e6f6d696e6174696d0d6f70656e7374726565746d6170036f726700001c0001
2019.07.29 23:24:44 5: DNS ANSWER 73:707281800001000100000000096e6f6d696e6174696d0d6f70656e7374726565746d6170036f726700001c0001c00c001c00010000011e0010200109780002002c0000000001720009
2019.07.29 23:24:44 4: DNS result for nominatim.openstreetmap.org: [2001:978:2:2c::172:9], ttl:286
2019.07.29 23:24:44 4: IP: nominatim.openstreetmap.org -> [2001:978:2:2c::172:9]
2019.07.29 23:24:44 4: HttpUtils: connect to https://nominatim.openstreetmap.org:443: Network is unreachable
2019.07.29 23:24:44 1: http:connect to https://nominatim.openstreetmap.org:443: Network is unreachable
ohne attr dnsServer:
2019.07.29 23:19:30 5: Cmd: >{TestHTTP()}<
2019.07.29 23:19:30 5: HttpUtils url=https://nominatim.openstreetmap.org/reverse?format=json&lat=52.111&lon=8.1212
2019.07.29 23:19:30 4: IP: nominatim.openstreetmap.org -> [2001:978:2:2c::172:9]
2019.07.29 23:19:30 4: HttpUtils: connect to https://nominatim.openstreetmap.org:443: Network is unreachable
2019.07.29 23:19:30 1: http:connect to https://nominatim.openstreetmap.org:443: Network is unreachable
Viele Grüße Gisbert
Bei dir werden die Namen in IP v6 Adressen aufgelöst.
Ich habe IP v6 nicht aktiviert (nirgends / bzw. wo möglich deaktiviert), bei mir kommt da (wenn ich versuche IP v6 zu erreichen) dann auch "network unreacheable"...
Hast du IP v6 konfiguriert?
Wie ist dein DNS konfiguriert?
Weil ja die "Auflösung" der "Namen" eine v6 IP-Adresse liefert...
Gruß, Joachim
Zitat von: MadMax-FHEM am 29 Juli 2019, 23:39:03
Bei dir werden die Namen in IP v6 Adressen aufgelöst.
Ich habe IP v6 nicht aktiviert (nirgends / bzw. wo möglich deaktiviert), bei mir kommt da (wenn ich versuche IP v6 zu erreichen) dann auch "network unreacheable"...
Hast du IP v6 konfiguriert?
Wie ist dein DNS konfiguriert?
Weil ja die "Auflösung" der "Namen" eine v6 IP-Adresse liefert...
Gruß, Joachim
Hallo Joachim,
ohne Unterstützung vorort kann ich deine Fragen alleine nicht beantworten.
Im UniFi-Controller ist nur IPv4 konfiguriert, nicht IPv6.
Unter Network gibt es die Auswahloption
IPV4 Connection Type Using DHCP und
IPV6 Connection Type Disabled - diese Option habe ich zu DHCPv6 geändert - und siehe da, die IPv6-Adressen werden jetzt aufgelöst !!
Ich hab keine Ahnung, wie es zu der Änderung beim Aufruf der entsprechenden 3 Seiten (Blitzer, Pushover und CO2Signal) gekommen ist, jedenfalls war ich nicht am UniFi-Controller dran.
Vielen Dank an alle Beteiligten, die mich tatkräftig unterstüzt haben, ihr seit Klasse !!
Jetzt gibt es bei der Eingabe {TestHTTP()} mit global verbose 5:
Zitat2019.07.30 00:44:57 5: Cmd: >{TestHTTP()}<
2019.07.30 00:44:57 5: HttpUtils url=https://nominatim.openstreetmap.org/reverse?format=json&lat=52.111&lon=8.1212
2019.07.30 00:44:57 5: DNS QUERY 707201000001000000000000096e6f6d696e6174696d0d6f70656e7374726565746d6170036f72670000010001
2019.07.30 00:44:57 5: DNS ANSWER 61:707281800001000100000000096e6f6d696e6174696d0d6f70656e7374726565746d6170036f72670000010001c00c0001000100000005000482754c09
2019.07.30 00:44:57 4: DNS result for nominatim.openstreetmap.org: 130.117.76.9, ttl:5
2019.07.30 00:44:57 4: IP: nominatim.openstreetmap.org -> 130.117.76.9
2019.07.30 00:44:57 5: HttpUtils request header:
GET /reverse?format=json&lat=52.111&lon=8.1212 HTTP/1.0
Host: nominatim.openstreetmap.org
Accept-Encoding: gzip,deflate
agent: FHEM/1.0
User-Agent: FHEM/1.0
Accept: application/json
2019.07.30 00:44:57 4: https://nominatim.openstreetmap.org/reverse?format=json&lat=52.111&lon=8.1212: HTTP response code 200
2019.07.30 00:44:57 5: HttpUtils https://nominatim.openstreetmap.org/reverse?format=json&lat=52.111&lon=8.1212: Got data, length: 570
2019.07.30 00:44:57 5: HttpUtils response header:
HTTP/1.1 200 OK
Date: Mon, 29 Jul 2019 22:44:57 GMT
Server: Apache/2.4.29 (Ubuntu)
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: OPTIONS,GET
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Expect-CT: max-age=0, report-uri="https://openstreetmap.report-uri.com/r/d/ct/reportOnly"
Upgrade: h2
Connection: Upgrade, close
Content-Type: application/json; charset=UTF-8
2019.07.30 00:44:57 1: http:
{"place_id":1401478,"licence":"Data © OpenStreetMap contributors, ODbL 1.0. https://osm.org/copyright","osm_type":"node","osm_id":320212341,"lat":"52.1132377","lon":"8.1198954","display_name":"Schutzhütte, Bielefelder Straße, Bad Laer, Landkreis Osnabrück, Niedersachsen, 49196, Deutschland","address":{"address29":"Schutzhütte","road":"Bielefelder Straße","village":"Bad Laer","county":"Landkreis Osnabrück","state":"Niedersachsen","postcode":"49196","country":"Deutschland","country_code":"de"},"boundingbox":["52.1131377","52.1133377","8.1197954","8.1199954"]}
Viele Grüße Gisbert
Zitat2019.07.29 23:24:44 4: DNS result for nominatim.openstreetmap.org: [2001:978:2:2c::172:9], ttl:286
Nur wenn man "attr global useInet6" gesetzt hat, versucht FHEM (mit oder ohne "attr global dnsServer") die IPv6 Adresse zu besorgen.
Man sollte dieses Attribut nur dann setzen, wenn IPv6 durchgehend funktioniert.
Sollte aber heutzutage zunehmend der Fall sein.
Hallo Rudi,
Zitat"attr global useInet6"
Dieses Attribut war und ist
nicht gesetzt, bis auf einen Versuch gestern abend.
Insofern liegt dann möglicherweise irgendwo noch eine Unregelmäßigkeit vor.
Viele Grüße Gisbert
Es bleibt dennoch seltsam, da ein unerwartetes Ergebnis vorliegt.
Wenn ich "attr global useInet6 1" setze, dann bekomme ich keine Verbindung zu Pushover und der Internetseite aus dem Blitzmodul.
Entferne ich es, dann funktionieren die Verbindingen wieder.
Viele Grüße Gisbert
Eventuell testest Du falsch.
Zitat
Im UniFi-Controller ist nur IPv4 konfiguriert, nicht IPv6.
Unter Network gibt es die Auswahloption
IPV4 Connection Type Using DHCP und
IPV6 Connection Type Disabled - diese Option habe ich zu DHCPv6 geändert - und siehe da, die IPv6-Adressen werden jetzt aufgelöst !!
Nach dem Du das umgestellt hast ging es ja anscheinend. Nun musst Du das wieder zurück stellen um wieder dahin zu kommen wo Du vor der Lösung warst. Du also wieder Dein Problem hast.
Danach kannst dann das Attribut für IPv6 einstellen und testen.
Zitat von: CoolTux am 30 Juli 2019, 09:02:31
Eventuell testest Du falsch.
Nach dem Du das umgestellt hast ging es ja anscheinend. Nun musst Du das wieder zurück stellen um wieder dahin zu kommen wo Du vor der Lösung warst. Du also wieder Dein Problem hast.
Danach kannst dann das Attribut für IPv6 einstellen und testen.
Hallo CoolTux,
die Kombination
kein IPV6 Connection Type im UniFi-Controller und "attr global useInet6 1
oder 0" führt zum gleichen Ergebnis, nämlich, dass die Verbindung nicht zustande kommt.
Wenn die Option IPV6 Connection Type im UniFi-Controller gesetzt ist, dann funktioniert die Verbindung nur, wenn "attr global useInet6 0" (d.h. das Attribut gelöscht) gesetzt ist.
Ich glaube nicht, dass es am Testen liegt, kann es aber auch nicht zu 100% ausschließen.
Viele Grüße Gisbert
Hallo!
Sehe ich es denn richtig, dass das Problem nun vollständig behoben ist? Es lag letztendlich an der Konfiguration des UniFi Controller?
Kann es sein, das du bisher auch eine ipv4 Adresse über deinen Kabel Anschluss hattest?
Wenn es erledigt ist, dann bitte diesen thread als erledigt markieren und bitte im thread beim Blitzer Modul auch eine kurze Auflösung des Problems Posten. Dann haben vielleicht auch mitlesende die Auflösung dort.
Hast du das Problem mit den FHEM Neustarts denn noch?
Gruß
Bismosa
Hallo Bismosa,
ZitatSehe ich es denn richtig, dass das Problem nun vollständig behoben ist? Es lag letztendlich an der Konfiguration des UniFi Controller?
Kann es sein, das du bisher auch eine ipv4 Adresse über deinen Kabel Anschluss hattest?
Jetzt läuft es - aber es ist unklar, wieso es zum Problem kam, genaus wie die Lösung. Ich hab einen Dual-Stack-Anschluss von Unitymedia, also IPv4 und IPv6, und das seit 8 Monaten.
ZitatWenn es erledigt ist, dann bitte diesen thread als erledigt markieren und bitte im thread beim Blitzer Modul auch eine kurze Auflösung des Problems Posten. Dann haben vielleicht auch mitlesende die Auflösung dort.
Wird gemacht.
ZitatHast du das Problem mit den FHEM Neustarts denn noch?
Dieses Problem wurde reproduzierbar durch das Modul Buienradar verursacht. Andere User hatten das gleiche beobachtet. Der Modulautor/maintainer hat sich der Sache angenommen. Ich mache heute einen Test, nachdem ich das Modul ein paar Tage schlafen gelegt habe.
Viele Grüße Gisbert