[jelöst] Korrekte Installation auf RPi mit zwei WLAN-Zugängen

andies · 26 Dezember 2018, 10:18:59

Ich hoffe, ich bin im richtigen Topic. Mich nervt schon seit einiger Zeit ein Problem, das besonders bei Stromausfällen sichtbar wird. Ich beschreibe mal alles, dann sieht man, was los ist - ich weiß aber nicht recht, wo ich ansetzen soll.

Ich habe einen RPi, auf dem FHEM läuft (jessie, fast neu - never change usw.)
Allerdings hat der RPi zwei WLAN-Karten mit unterschiedlichen MAC-Adressen, nämlich einmal 5GHz und 2,4GHz. Letztere hat eine sehr große Antenne, falls der Empfang schlecht ist. Erstere habe ich wegen des Mesh-Fritzbox 7490-Dings drin, dann ist die Verbindung besser. Angeblich wechselt die FB zwischen den besseren Netzen hin und her.
Nach einem Neustart weist die FB nun dem RPi eine IP-Adresse zu. Je nach dem, welches Netzwerk sie nimmt, ist das entweder *.7 (2,4GHz) oder *.14 (5GHz). Ich kann vorher nicht erkennen, welches Netzwerk zuerst da ist. Auf dem RPi ist DHCP eingestellt, die Auswahl der IP-Adressen übernimmt die FB.
Mit avahi-daemon ist der RPi jederzeit über fhem.local erreichbar. Egal welche IP.
Meine Sonoffs müssen nun über MQTT zugreifen. Dabei suchen sie den Host. Während ESPEasy sich mit einem Hostnamen wie fhem.local zufrieden gibt, schaffen das die Sonoffs nicht. Hier muss bei einem Wechsel der IP (etwa alle drei Monate) jedesmal die IP geändert werden.

Kann mir jemand sagen, an welcher Stelle ich was falsch mache?

<edit nach Lösung> Natürlich an der Stelle, an der es beim RPi immer hakt: Der Stromversorgung. Dann kann man sich das Lesen des Threads sparen...

schka17 · 26 Dezember 2018, 10:33:20

Kann dir zwar mit Fritzbox Zeugs nicht helfen, aber grundsätzlich verstehe ich nicht, warum der Pi keine fixe ip Adresse hat.

Ich habe für alle Geräte die irgendeine Art von Service liefern, also NAS, CAM's, Mediaplayer usw. fixe Adressen definiert. Zusätzlich noch DNS dann kann ich sehr einfach Netzwerkdienste ändern ohne dass die Konfiguration in allen Clients geändert werden muss.
Dynamische Adressen bekommen nur Endgeräte also Telefone oder Laptop.

Sent from my iPad using Tapatalk

KölnSolar · 26 Dezember 2018, 10:53:00

ZitatKann dir zwar mit Fritzbox Zeugs nicht helfen, aber grundsätzlich verstehe ich nicht, warum der Pi keine fixe ip Adresse hat.

In der FritzBox(Heimnetzwerk) lässt sich je device einstellen(anhaken), dass das device immer dieselbe IP per DHCP zugewiesen bekommt. Hat den Vorteil, dass man einerseits an den üblicherweise auf DHCP voreingestellten devices nichts ändern muss und trotzdem immer eine feste IP hat.

Ich hab das so für ALLE Geräte eingestellt. Sobald ein neues Gerät in den Haushalt kommt das Häkchen setzen und schon ist auf ewig Schluss mit IP-Adressen-Rate-/-fummelei.

Grüße Markus

andies · 26 Dezember 2018, 10:56:48

Ich weiß, was Ihr meint (siehe Screenshot): Das Problem bei mir ist, dass der eine RPi wegen der beiden WLAN-Karten zweifach angezeigt wird. Ich kann also nur bei der WLAN-Karte, nicht aber dem RPi selbst die IP fixieren. (Oder ich übersehe was).

andies · 26 Dezember 2018, 11:05:50

PS: Tasmota sagt "However the use of local mDNS hostnames (ex: mqtt_home.local) is not supported, if you want to use a broker on your local network you need to use its local IP or rely on a local DNS to resolve the hostnames."

Das ist anscheinend auch mein Problem.

andies · 26 Dezember 2018, 11:25:01

Also, da gibt es anscheinend zwei mögliche Lösungen.

Man fügt mDNS in den Tasmota Code ein, siehe https://github.com/madpilot/mDNSResolver/tree/master/examples. Das kostet Speicherplatz und ich übersehe nicht, ob das mit anderen Sachen interferiert.
Da der Unsinn nur auftaucht, wenn Stromausfall war und danach eine andere IP verwendet wird, kann man das wahrscheinlich händisch lösen. Wenn das Gerät offline, dann rufe ich (zB)
Zitathttp://192.168.2.31/cm?cmnd=MqttHost%20192.168.2.14
auf, wobei da rechts dann die IP des MQTT stehen muss. Jetzt muss ich nur herausbekommen, welche IP der RPi hat und dann läuft das eben so.

Das war mit meiner FB immer schon so und hat genervt. Nur wollte ich jetzt mal eine generelle Lösung...

PS Ich habe noch etwas gefunden. Im Programmcode von Tasmota scheint es in der Tat mDNS zu geben, denn my_user_config.h enthält ganz unten

Code Auswählen

// -- mDNS ----------------------------------------
#define USE_DISCOVERY                            // Enable mDNS for the following services (+8k code, +0.3k mem)
  #define WEBSERVER_ADVERTISE                    // Provide access to webserver by name <Hostname>.local/
  #define MQTT_HOST_DISCOVERY                    // Find MQTT host server (overrides MQTT_HOST if found)

Allerdings wird dann, wenn man die Basismodule flasht, diese Sache überschrieben. Denn in sonoff_post.h finde ich

Code Auswählen

/*******************************************************************************************/*********************************************************************************************\
 * [sonoff-basic.bin]
 * Provide an image without sensors
\*********************************************************************************************/

#ifdef USE_BASIC
...
#undef USE_DISCOVERY                          // Disable Discovery services for both MQTT and web server

und dann geht das natürlich nicht mehr. Ich werde die Geräte evtl mal neu flashen und vorher das herausnehmen.

Otto123 · 26 Dezember 2018, 11:43:22

MMoin,,

die beste Lösung: Steck ein Kabel in den Pi und die andere Seite in die Fritzbox!
Ich habe nicht verstanden wozu Du es dem Zufall überlässt, irgendeine Wlanverbindung zu nehmen.
Und ich habe nicht verstanden wieso der Pi nicht immer beide Netzwerkverbindungen hat. Ich habe auch einen Pi mit zwei Netzwerkverbindungen(LAN/Wlan). Verhindert das die Mesh Funktion der FB?
Eine Netzwerkverbindung definieren und fertig! Oder fliegt der Pi auf einer Drohne ständig umher?

Gruß Otto

RaspiLED · 26 Dezember 2018, 11:54:14

Hi,
die Sache ist doch einfach!
Der RPi sollte immer beide Adressen von der Fritte bekommen (deswegen ja auch bei beiden in der FritzBox das Häckchen feste IP). Dabei ist dann such die Reihenfolge egal!
Anscheinend kannst Du aber nicht über beide IPs zugreifen, also hat Dein RPi eine falsche Konfiguration für das MQTT!

Zeig uns die mal, zeig uns auch Deine ifconfig Ausgaben (IPv6 aktiv?), zeig uns mal die Logs bei falschem Sonoff Aufruf (von Sonoff und von RPI), wie stehen die iotables (oder welche Firewall nutzt du?)

Gruß Arnd

Gesendet von iPhone mit Tapatalk

andies · 26 Dezember 2018, 12:11:18

Zitat von: RaspiLED am 26 Dezember 2018, 11:54:14
die Sache ist doch einfach!

Solche Sätze liebe ich, nachdem ich stundenlang mir den Kopf zerbrochen habe

Zitat von: RaspiLED am 26 Dezember 2018, 11:54:14
Der RPi sollte immer beide Adressen von der Fritte bekommen

Ja, das wäre die beste Lösung.

Zitat von: RaspiLED am 26 Dezember 2018, 11:54:14
Anscheinend kannst Du aber nicht über beide IPs zugreifen, also hat Dein RPi eine falsche Konfiguration für das MQTT!
Zeig uns die mal, zeig uns auch Deine ifconfig Ausgaben (IPv6 aktiv?), zeig uns mal die Logs bei falschem Sonoff Aufruf (von Sonoff und von RPI)

Also ich habe

Code Auswählen

pi@FHEM:~ $ ifconfig
eth0      Link encap:Ethernet  Hardware Adresse b8:27:eb:1b:8c:7b  
          inet6-Adresse: fe80::fffb:79dd:22c5:af80/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST MULTICAST  MTU:1500  Metrik:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lo        Link encap:Lokale Schleife  
          inet Adresse:127.0.0.1  Maske:255.0.0.0
          inet6-Adresse: ::1/128 Gültigkeitsbereich:Maschine
          UP LOOPBACK RUNNING  MTU:65536  Metrik:1
          RX packets:360951 errors:0 dropped:0 overruns:0 frame:0
          TX packets:360951 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000 
          RX bytes:249016604 (237.4 MiB)  TX bytes:249016604 (237.4 MiB)

wlan0     Link encap:Ethernet  Hardware Adresse b8:27:eb:4e:d9:2e  
          inet6-Adresse: fe80::7a41:4e51:ddb0:7808/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST MULTICAST  MTU:1500  Metrik:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

wlan1     Link encap:Ethernet  Hardware Adresse a0:ab:1b:cc:98:fd  
          inet Adresse:192.168.2.14  Bcast:192.168.2.255  Maske:255.255.255.0
          inet6-Adresse: fe80::a2ab:1bff:fecc:98fd/64 Gültigkeitsbereich:Verbindung
          inet6-Adresse: fe80::8542:4ab5:81cc:834e/64 Gültigkeitsbereich:Verbindung
          inet6-Adresse: 2003:cf:5700:6600:a2ab:1bff:fecc:98fd/64 Gültigkeitsbereich:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:368406 errors:0 dropped:41029 overruns:0 frame:0
          TX packets:205807 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000 
          RX bytes:83704768 (79.8 MiB)  TX bytes:100215499 (95.5 MiB)

sowie

Code Auswählen

pi@FHEM:~ $ iwconfig
wlan0     IEEE 802.11  ESSID:off/any  
          Mode:Managed  Access Point: Not-Associated   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:off
          
lo        no wireless extensions.

eth0      no wireless extensions.

wlan1     IEEE 802.11bg  ESSID:"WLAN-120954"  Nickname:"<WIFI@REALTEK>"
          Mode:Managed  Frequency:2.462 GHz  Access Point: 00:26:4D:60:D9:58   
          Bit Rate:54 Mb/s   Sensitivity:0/0  
          Retry:off   RTS thr:off   Fragment thr:off
          Power Management:off
          Link Quality=88/100  Signal level=57/100  Noise level=0/100
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

Zitat von: RaspiLED am 26 Dezember 2018, 11:54:14
wie stehen die iotables (oder welche Firewall nutzt du?)

Code Auswählen

pi@FHEM:~ $ sudo iptables --table nat --list
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination

Keine Firewall außer der FB, keine Ports offen etc.

Außerdem sehe ich im Logfile ellenlange Meldungen à la

Code Auswählen

Dec 26 12:01:45 FHEM kernel: [76854.408884] Voltage normalised (0x00000000)
Dec 26 12:01:47 FHEM kernel: [76856.488917] Under-voltage detected! (0x00050005)
Dec 26 12:02:07 FHEM kernel: [76877.289011] Voltage normalised (0x00000000)
Dec 26 12:02:10 FHEM kernel: [76879.369015] Under-voltage detected! (0x00050005)
Dec 26 12:02:22 FHEM kernel: [76891.849072] Voltage normalised (0x00000000)
Dec 26 12:02:24 FHEM kernel: [76893.929090] Under-voltage detected! (0x00050005)
Dec 26 12:02:30 FHEM kernel: [76900.169141] Voltage normalised (0x00000000)
Dec 26 12:02:32 FHEM kernel: [76902.249141] Under-voltage detected! (0x00050005)
Dec 26 12:03:31 FHEM kernel: [76960.489464] Voltage normalised (0x00000000)

und ich habe eine 2A-Versorgung da dran. Könnte es sein, dass ich da 3A nehmen muss? Ansonsten ging anscheinend der Zugriff und dann mal wieder nicht:

Code Auswählen


Dec 25 13:15:58 FHEM wpa_supplicant[560]: wlan1: WPA: Group rekeying completed with 38:10:d5:1c:d5:b9 [GTK=CCMP]
Dec 25 13:25:59 FHEM wpa_supplicant[601]: wlan0: WPA: Group rekeying completed with 38:10:d5:1c:d5:b8 [GTK=CCMP]
Dec 25 13:25:59 FHEM wpa_supplicant[560]: wlan1: WPA: Group rekeying completed with 38:10:d5:1c:d5:b9 [GTK=CCMP]
Dec 25 13:35:59 FHEM wpa_supplicant[601]: wlan0: WPA: Group rekeying completed with 38:10:d5:1c:d5:b8 [GTK=CCMP]
Dec 25 13:35:59 FHEM wpa_supplicant[560]: wlan1: WPA: Group rekeying completed with 38:10:d5:1c:d5:b9 [GTK=CCMP]
Dec 25 13:45:59 FHEM wpa_supplicant[601]: wlan0: WPA: Group rekeying completed with 38:10:d5:1c:d5:b8 [GTK=CCMP]
Dec 25 13:45:59 FHEM wpa_supplicant[560]: wlan1: WPA: Group rekeying completed with 38:10:d5:1c:d5:b9 [GTK=CCMP]
Dec 25 13:55:59 FHEM wpa_supplicant[601]: wlan0: WPA: Group rekeying completed with 38:10:d5:1c:d5:b8 [GTK=CCMP]
Dec 25 13:55:59 FHEM wpa_supplicant[560]: wlan1: WPA: Group rekeying completed with 38:10:d5:1c:d5:b9 [GTK=CCMP]
Dec 25 14:05:59 FHEM wpa_supplicant[601]: wlan0: WPA: Group rekeying completed with 38:10:d5:1c:d5:b8 [GTK=CCMP]
Dec 25 14:06:00 FHEM wpa_supplicant[560]: wlan1: WPA: Group rekeying completed with 38:10:d5:1c:d5:b9 [GTK=CCMP]
...
Dec 25 14:08:33 FHEM wpa_supplicant[598]: wlan0: Trying to associate with 00:26:4d:60:d9:58 (SSID='WLAN-120954' freq=2462 MHz)
Dec 25 14:08:33 FHEM wpa_supplicant[598]: wlan0: CTRL-EVENT-ASSOC-REJECT bssid=00:00:00:00:00:00 status_code=16
Dec 25 14:08:34 FHEM wpa_supplicant[598]: wlan0: Trying to associate with 00:26:4d:60:d9:58 (SSID='WLAN-120954' freq=2462 MHz)
Dec 25 14:08:34 FHEM wpa_supplicant[598]: wlan0: CTRL-EVENT-ASSOC-REJECT bssid=00:00:00:00:00:00 status_code=16
Dec 25 14:08:35 FHEM wpa_supplicant[598]: wlan0: Trying to associate with 00:26:4d:60:d9:58 (SSID='WLAN-120954' freq=2462 MHz)
Dec 25 14:08:35 FHEM wpa_supplicant[598]: wlan0: CTRL-EVENT-ASSOC-REJECT bssid=00:00:00:00:00:00 status_code=16
Dec 25 14:08:37 FHEM wpa_supplicant[598]: wlan0: Trying to associate with 00:26:4d:60:d9:58 (SSID='WLAN-120954' freq=2462 MHz)
Dec 25 14:08:37 FHEM wpa_supplicant[598]: wlan0: CTRL-EVENT-ASSOC-REJECT bssid=00:00:00:00:00:00 status_code=16
Dec 25 14:08:37 FHEM wpa_supplicant[598]: wlan0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="WLAN-120954" auth_failures=1 duration=10 reason=CONN_FAILED
Dec 25 14:08:40 FHEM wpa_supplicant[583]: wlan1: Trying to associate with 00:26:4d:60:d9:58 (SSID='WLAN-120954' freq=2462 MHz)
Dec 25 14:08:40 FHEM wpa_supplicant[583]: wlan1: CTRL-EVENT-ASSOC-REJECT status_code=1
Dec 25 14:08:40 FHEM wpa_supplicant[583]: wlan1: CTRL-EVENT-ASSOC-REJECT status_code=1
Dec 25 14:08:48 FHEM wpa_supplicant[598]: wlan0: Failed to initiate sched scan
Dec 25 14:08:48 FHEM wpa_supplicant[583]: wlan1: Trying to associate with 00:26:4d:60:d9:58 (SSID='WLAN-120954' freq=2462 MHz)
Dec 25 14:08:48 FHEM wpa_supplicant[583]: wlan1: Associated with 00:26:4d:60:d9:58
Dec 25 14:08:48 FHEM wpa_supplicant[583]: wlan1: WPA: Key negotiation completed with 00:26:4d:60:d9:58 [PTK=CCMP GTK=TKIP]
Dec 25 14:08:48 FHEM wpa_supplicant[583]: wlan1: CTRL-EVENT-CONNECTED - Connection to 00:26:4d:60:d9:58 completed [id=0 id_str=]
Dec 25 14:08:48 FHEM dhcpcd[470]: wlan1: carrier acquired
Dec 25 14:08:48 FHEM dhcpcd[470]: DUID 00:01:00:01:1f:77:63:ca:b8:27:eb:1b:8c:7b
Dec 25 14:08:48 FHEM dhcpcd[470]: wlan1: IAID 1b:cc:98:fd
Dec 25 14:08:48 FHEM dhcpcd[470]: wlan1: rebinding lease of 192.168.2.14
Dec 25 14:08:51 FHEM wpa_supplicant[598]: wlan0: CTRL-EVENT-REGDOM-CHANGE init=COUNTRY_IE type=COUNTRY alpha2=DE
Dec 25 14:08:51 FHEM wpa_supplicant[583]: wlan1: CTRL-EVENT-REGDOM-CHANGE init=COUNTRY_IE type=COUNTRY alpha2=DE
Dec 25 14:08:52 FHEM avahi-daemon[468]: Registering new address record for fe80::a2ab:1bff:fecc:98fd on wlan1.*.
Dec 25 14:08:53 FHEM dhcpcd[470]: wlan1: probing for an IPv4LL address
Dec 25 14:08:53 FHEM dhcpcd[470]: wlan1: DHCP lease expired
Dec 25 14:08:54 FHEM dhcpcd[470]: wlan1: soliciting a DHCP lease
Dec 25 14:08:58 FHEM dhcpcd[470]: timed out
Dec 25 14:08:58 FHEM dhcpcd[470]: forked to background, child pid 853

@Otto: Ein Kabel kann ich da nicht anschließen, ohne mehrere Meter Wand aufzuhacken.

Otto123 · 26 Dezember 2018, 12:17:45

Zitat@Otto: Ein Kabel kann ich da nicht anschließen, ohne mehrere Meter Wand aufzuhacken.

Das ist die Sache mit dem Berg und dem Propheten

Ich würde halt die Zentrale nicht wackelig mit dem Netzwerk verbinden. Lieber würde ich dann die Funktionen auf abgesetzte Geräte aufteilen.

Aber der Ansatz von Arnd klingt gut und vernünftig

Gruß Otto

andies · 26 Dezember 2018, 12:21:11

PS Also im Sonoff steht 192.168.2.7 und die findet er nicht, weil der dusslige RPi gerade entschieden hat 192.168.2.14 zu sein. Ich sehe dann nur, dass der Sonoff den Host nicht findet. Im RPi steht nichts, weil der ja formal nicht angesprochen wird.

Otto123 · 26 Dezember 2018, 12:26:43

Ich sehe gerade, Wlan 0 ist nicht verbunden und Wlan 1 ist verbunden. Lässt das die FB wegen Mesh nicht zu?

Dann deaktiviere doch Wlan 1.

Gruß Otto

RaspiLED · 26 Dezember 2018, 12:36:26

Hi,
deswegen habe ich den ,,einfach" Spruch ja gepostet

Also meine aktuelle Vermutung ist, das IPv6 zuschlägt und Dein RPi auf einem WLAN die IPv6 erhält und auf WLAN1 eine IPv4.

Wie wäre es in der Fritte IPv6 zu deaktivieren? Oder als

Code Auswählen

add this to /boot/cmdline.txt
ipv6.disable=1

Und reboot

Gruß Arnd

Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...

andies · 26 Dezember 2018, 12:45:55

Bevor ich das tue, noch eine Frage: Könnte das mit der Spannungsversorgung nicht die Ursache sein? Immerhin gingen vor einigen Tagen beide WLANs noch.

RaspiLED · 26 Dezember 2018, 12:58:20

Doch, weil im Energiemanagement dann USB Ports deaktiviert werden ,,könnten" - Aber meine RPis zicken an meiner Fritte auch ständig w/ IPv6! Daher habe ich das ,,einfach" deaktiviert und seitdem keine Probleme mehr

Gruß Arnd

Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...