Ich habe ein Problem, das gar nicht mit FHEM zusammenhängt (obwohl ich das zuerst dachte) und vielleicht kann mir jemand einen Tipp geben, wo ich suchen kann. Ich weiß sonst nicht, wo ich anfangen soll.
FHEM ist installiert auf einem RPi3 und läuft. Der wiederum hängt in einem WLAN, das von drei Unifi-APs plus einem Ubiquiti-Controller aufgespannt wird (keine weiteren WLAN-APs, nur die Unifi-Dinger). Jedes device im Netz bezieht seine IP von einer FB 7490. Überall wird DHCP verwendet, keine statischen IP-Adressen (sondern so was wie raspberry.fritz.box für MQTT etc.).
Logge ich mich mit meinem Laptop in das System ein, kann ich auf beispielsweise 192.168.2.30 zugreifen (ist ein einfacher ESP mit Webseite, die ich dann sehe). Logge ich mich auf den FHEM-Raspberry mit ssh ein und pinge von dort 192.168.2.30 an, so bekomme ich timeouts. Das ist total unlogisch. Was kann man da tun? Wo kann der Fehler liegen?
Zitat von: andies am 29 Mai 2019, 13:53:20
Logge ich mich mit meinem Laptop in das System ein, kann ich auf beispielsweise 192.168.2.30 zugreifen (ist ein einfacher ESP mit Webseite, die ich dann sehe). Logge ich mich auf den FHEM-Raspberry mit ssh ein und pinge von dort 192.168.2.30 an, so bekomme ich timeouts. Das ist total unlogisch.
Das ist überhaupt nicht unlogisch. Der Zugriff auf die Weboberfläche Deines ESP und der "Zugriff" per ping sind grundsätzlich zwei unterschiedliche Zugriffsverfahren. Davon kann das eine sehr wohl erlaubt, das andere verboten sein. Das ist ein völlig normales Verhalten.
Mein Problem besteht darin, dass dann auch FHEM nicht auf die Seite kommt. Genau das soll es aber und ich dachte, mit dem ping hätte ich den Verursacher. Konkret sendet die Webseite folgendes (raw)
Temperature: 18.6C Humidity 28.7% Tor: 1
und das Gerät sieht so aus:
defmod Garagensensor HTTPMOD http://192.168.2.20/ 300
attr Garagensensor userattr reading01Name reading01Regex reading02Name reading02Regex reading03Name reading03Regex
attr Garagensensor reading01Name Temperatur
attr Garagensensor reading01Regex Temperature: ([\.\d]*)C
attr Garagensensor reading02Name Tor
attr Garagensensor reading02Regex Tor: (\d*)
attr Garagensensor reading03Name Humidity
attr Garagensensor reading03Regex Humidity ([\.\d]*)%
attr Garagensensor timeout 15
Das device garagensensor reagiert aber nicht, ich sehe nicht, was ich auf der Webseite sehe. Woran kann denn das liegen?
nc -vz 192.168.2.20 80
mal vom Pi aus aus führen. Damit schaust ob Du eine Verbindung zu der IP zu dem Port bekommst
Zitat von: CoolTux am 29 Mai 2019, 14:55:01
nc -vz 192.168.2.20 80
mal vom Pi aus aus führen. Damit schaust ob Du eine Verbindung zu der IP zu dem Port bekommst
Danke!
Da kriege ich
nc: connect to 192.168.2.20 port 80 (tcp) failed: No route to hostDas heißt doch, dass ich ein Netzproblem habe, oder? Die beiden sind aber im WLAN und greifen nur auf verschiedene APs zu (ein Switch von Cisco ist noch dazwischen, unmanaged).
Na dann zeig mal Deine Config
ip add
ip route
Nachdem FHEM und ESP im WLAN hängen, einfach mal schauen ob Client Isolation aktiviert ist.
Dann können WLAN Geräte nicht untereinander kommunizieren.
Passt natürlich nur wenn der Laptop nicht im WLAN hängt sondern am LAN.
Echt danke für Eure Hilfe, ich bin bei dem Zeug völlig verloren. Also: Der laptop hängt am WLAN. Ich erhalte
pi@raspfhem:~ $ ip add
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
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: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
link/ether b8:27:eb:1b:8c:7b brd ff:ff:ff:ff:ff:ff
inet6 fe80::fffb:79dd:22c5:af80/64 scope link tentative
valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether b8:27:eb:4e:d9:2e brd ff:ff:ff:ff:ff:ff
inet 192.168.2.7/24 brd 192.168.2.255 scope global wlan0
valid_lft forever preferred_lft forever
inet6 2003:cf:5716:9600:ba27:ebff:fe4e:d92e/64 scope global mngtmpaddr dynamic
valid_lft 7185sec preferred_lft 1227sec
inet6 fe80::ba27:ebff:fe4e:d92e/64 scope link
valid_lft forever preferred_lft forever
4: wlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether a0:ab:1b:cc:98:fd brd ff:ff:ff:ff:ff:ff
inet 192.168.2.14/24 brd 192.168.2.255 scope global wlan1
valid_lft forever preferred_lft forever
inet6 2003:cf:5716:9600:a2ab:1bff:fecc:98fd/64 scope global mngtmpaddr dynamic
valid_lft 7185sec preferred_lft 1227sec
inet6 fe80::a2ab:1bff:fecc:98fd/64 scope link
valid_lft forever preferred_lft forever
und
ip route
default via 192.168.2.1 dev wlan0 metric 303
default via 192.168.2.1 dev wlan1 metric 304
192.168.2.0/24 dev wlan0 proto kernel scope link src 192.168.2.7 metric 303
192.168.2.0/24 dev wlan1 proto kernel scope link src 192.168.2.14 metric 304
Für mich sind das Böhmische Dörfer...
Du hast 2 default gateways. Das ist falsch. Hast du wirklich 2 WLAN Netzwerkkarten beim Raspi?
Zitat von: CoolTux am 29 Mai 2019, 21:13:23
Du hast 2 default gateways. Das ist falsch. Hast du wirklich 2 WLAN Netzwerkkarten beim Raspi?
Ah, ein Glück - wenigstens ein Fehler gefunden. (Übrigens vermute ich, dass mein Problem bei meinem VCLIENT.pm-Modul, wo Du mir geholfen hast: https://forum.fhem.de/index.php/topic,78101.msg943400.html#msg943400 (https://forum.fhem.de/index.php/topic,78101.msg943400.html#msg943400), auch irgendeine Rolle spielte!!)
Ich habe in der Tat zwei Netzwerkkarten, einmal 2,4GHz und einmal 5GHz und demzufolge auch zwei IPs, das ist schon irgendwie ok. Aber zwei gateways ist natürlich Blödsinn.
Wo siehst Du das bzw wo lösche ich das? Bei mir sehen die Sachen ja so aus:
>nano /etc/network/interfaces
source-directory /etc/network/interfaces.d <== ist leer
auto lo
iface lo inet loopback
iface eth0 inet manual
allow-hotplug wlan0
iface wlan0 inet dhcp <== will ich umstellen auf statische IP
wireless-power off
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
allow-hotplug wlan1
iface wlan1 inet dhcp
wireless-power off
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
und
>nano /etc/networks
default 0.0.0.0
loopback 127.0.0.0
link-local 169.254.0.0
Dann stelle Mal wlan0 um und vergib dafür kein default gsteway
habe das jetzt so gemacht (nur wlan0):
auto lo
iface lo inet loopback
iface eth0 inet manual
allow-hotplug wlan0
iface wlan0 inet static
address 192.168.2.7
netmask 255.255.255.0
dns-nameservers 192.168.2.1
wireless-power off
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
allow-hotplug wlan1
iface wlan1 inet static
address 192.168.2.14
netmask 255.255.255.0
gateway 192.168.2.1
dns-nameservers 192.168.2.1
wireless-power off
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
und dann
ip add
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
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: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
link/ether b8:27:eb:1b:8c:7b brd ff:ff:ff:ff:ff:ff
inet6 fe80::fffb:79dd:22c5:af80/64 scope link tentative
valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether b8:27:eb:4e:d9:2e brd ff:ff:ff:ff:ff:ff
inet 192.168.2.7/24 brd 192.168.2.255 scope global wlan0
valid_lft forever preferred_lft forever
inet6 2003:cf:5716:9600:ba27:ebff:fe4e:d92e/64 scope global mngtmpaddr dynamic
valid_lft 7155sec preferred_lft 1007sec
inet6 fe80::ba27:ebff:fe4e:d92e/64 scope link
valid_lft forever preferred_lft forever
inet6 fe80::7a41:4e51:ddb0:7808/64 scope link
valid_lft forever preferred_lft forever
4: wlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether a0:ab:1b:cc:98:fd brd ff:ff:ff:ff:ff:ff
inet 192.168.2.14/24 brd 192.168.2.255 scope global wlan1
valid_lft forever preferred_lft forever
inet6 2003:cf:5716:9600:a2ab:1bff:fecc:98fd/64 scope global mngtmpaddr dynamic
valid_lft 7155sec preferred_lft 1007sec
inet6 fe80::a2ab:1bff:fecc:98fd/64 scope link
valid_lft forever preferred_lft forever
inet6 fe80::8542:4ab5:81cc:834e/64 scope link
valid_lft forever preferred_lft forever
sowie
ip route
default via 192.168.2.1 dev wlan1
default via 192.168.2.1 dev wlan0 metric 303
default via 192.168.2.1 dev wlan1 metric 304
192.168.2.0/24 dev wlan0 proto kernel scope link src 192.168.2.7
192.168.2.0/24 dev wlan1 proto kernel scope link src 192.168.2.14
192.168.2.0/24 dev wlan0 proto kernel scope link src 192.168.2.7 metric 303
192.168.2.0/24 dev wlan1 proto kernel scope link src 192.168.2.14 metric 304
Soll ich wlan1 auch umstellen? Problem gelöst?
Du hast doch wlan1 auch umgestellt. Hast du schon neu gestartet?
Neustart war schon, aber wlan1 hatte ich nicht explizit umgestellt (war mir unsicher, Du hattest nur wlan0 geschrieben). Mache ich aber jetzt.
Ist das Problem denn dann weg?
Zitat von: andies am 29 Mai 2019, 21:33:36
auto lo
iface lo inet loopback
iface eth0 inet manual
allow-hotplug wlan0
iface wlan0 inet static
address 192.168.2.7
netmask 255.255.255.0
dns-nameservers 192.168.2.1
wireless-power off
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
allow-hotplug wlan1
iface wlan1 inet static
address 192.168.2.14
netmask 255.255.255.0
gateway 192.168.2.1
dns-nameservers 192.168.2.1
wireless-power off
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
Ich hoffe.
Aber für mich sieht es so aus als das Du beide Netzwerkkarten auf static umgebaut hast.
Der Fehler war wahrscheinlich in der Einstellung des Unifi Controllers. Dort stand etwas bei DHCP und daneben in klein ,,usg erforderlich", aber ich habe keinen unifi service gateway usg. Ich vermute, dadurch wurde irgend etwas mit den gateways falsch eingestellt.
Gesendet von iPad mit Tapatalk Pro
Ich hatte vor ein paar Tagen wieder 100% CPU und habe deshalb noch einmal genauer hingeschaut. Zuerst habe ich den Unifi Controller sowie die AP zurückgesetzt; ob das etwas gebracht hat, weiß ich nicht - aber so konnte ich Konfigurationsprobleme dort ausschließen. Und dann ist mir aufgefallen, dass man beim OS Jessie nicht mehr mit interfaces arbeiten, sondern die Konfiguration in dhcpcd.conf vornehmen soll. Das habe ich dann auch geändert, seitdem keine Ausfälle mehr.
Gesendet von iPad mit Tapatalk Pro
und noch ein Detail müsste ich ändern, weil ich manchmal einzelne Geräte nicht anpingen konnte: Die automatische Optimierung bei unifi muss deaktiviert werden. Das Netzwerk war vorher sporadisch nich erreichbar. Keine Ahnung, was da optimiert wurde.
OK, alles klar. Ist ein Unifi-bug; kein Wunder, das ich damit nicht klar kam:
https://community.ubnt.com/t5/UniFi-Wireless/ping-impossible-with-automatic-network-optimziation/m-p/2816676#M403675 (https://community.ubnt.com/t5/UniFi-Wireless/ping-impossible-with-automatic-network-optimziation/m-p/2816676#M403675)