Android SmartTV verbindet sich pausenlos neu mit WLAN

Help Deutschsprachige Hilfe
1

Beobachtetes Verhalten:
Es kommt immer nur für wenige Sekunden eine Verbindung mit dem WLAN zustande, dann wird die Verbindung wieder beendet/abgebrochen und es geht von vorne los (Dauerschleife).

Erwartetes Verhalten:
Stabile Verbindung im WLAN (wie mit allen anderen Geräten auch).

Beschreibung
Pi-hole ist bei mir DNS und DHCP-Server. Für den TV habe ich in Pi-hole einen Static DHCP lease eingerichtet mit Adresse 10.2.28.63. Vom Blocking ist das Gerät jedoch ausgeschlossen. Am TV sind die WLAN-Einstellmöglichkeiten absolut minimalistisch. Man kann nur das WLAN-Netz auswählen. Die Grundeinstellung muss DHCP sein, weil ich nichts statisch einstellen kann.
Das WLAN wird bei mir von zwei Unifi APs aufgebaut, wobei ich für Testzwecke schon ein extra Netz mit nur einem AP und nur mit 2.4GHz bereitgestellt habe (wegen der 2.4 / 5 GHz Problematik). Hat aber alles nicht geholfen... Die Signalstärke hat volle Balken.

Man sieht, dass Pi-hole dem Gerät die korrekte IP zugewiesen hat. Während der sehr kurzen erfolgreichen Verbindung werden auch Inhalte auf dem TV geladen (z.B. Marketplace etc.), für Streaming reicht das aber natürlich nicht. Es ploppt auch permament die Meldung auf, dass man nicht mit dem WLAN verbunden ist.

Ich weiß nicht, warum sich das Gerät so anstellt und ich weiß auch nicht, ob es ein Problem mit Pi-hole oder meinem WLAN ist.
Im log tauchen diese dnsmasq Einträge nur beim TV auf (der log ist teilbereinigt wegen Länge). Ich hoffe, das kann ein Hinweis sein:

Mar 23 17:56:47: query[A] vox-digitaltext.rtl-hbbtv.de from 10.2.28.63
Mar 23 17:56:47: forwarded vox-digitaltext.rtl-hbbtv.de to 10.2.28.1

Mar 23 17:56:47: query[AAAA] vox-digitaltext.rtl-hbbtv.de from 10.2.28.63
Mar 23 17:56:47: forwarded vox-digitaltext.rtl-hbbtv.de to 10.2.28.1
Mar 23 17:56:47: reply vox-digitaltext.rtl-hbbtv.de is <CNAME>
Mar 23 17:56:47: reply vox-digitaltext.rtl-hbbtv.de.edgesuite.net is <CNAME>
Mar 23 17:56:47: reply a1790.g1.akamai.net is 185.98.140.25
Mar 23 17:56:47: reply a1790.g1.akamai.net is 185.98.140.27
Mar 23 17:56:47: reply vox-digitaltext.rtl-hbbtv.de is <CNAME>
Mar 23 17:56:47: reply vox-digitaltext.rtl-hbbtv.de.edgesuite.net is <CNAME>
Mar 23 17:56:47: reply a1790.g1.akamai.net is NODATA-IPv6

Mar 23 17:56:48: query[A] clients3.google.com from 10.2.28.63
Mar 23 17:56:48: forwarded clients3.google.com to 10.2.28.1
Mar 23 17:56:48: reply clients3.google.com is <CNAME>
Mar 23 17:56:48: reply clients.l.google.com is 172.217.18.14

Mar 23 17:56:50: query[AAAA] www.googleapis.com from 10.2.28.63
Mar 23 17:56:50: forwarded www.googleapis.com to 10.2.28.1
Mar 23 17:56:50: reply www.googleapis.com is 2a00:1450:4001:80e::200a
Mar 23 17:56:50: reply www.googleapis.com is 2a00:1450:4001:82a::200a
Mar 23 17:56:50: reply www.googleapis.com is 2a00:1450:4001:806::200a
Mar 23 17:56:50: reply www.googleapis.com is 2a00:1450:4001:831::200a

Mar 23 17:56:50: query[A] www.googleapis.com from 10.2.28.63
Mar 23 17:56:50: forwarded www.googleapis.com to 10.2.28.1
Mar 23 17:56:50: reply www.googleapis.com is 142.250.186.138
Mar 23 17:56:50: reply www.googleapis.com is 216.58.206.42
Mar 23 17:56:50: reply www.googleapis.com is 172.217.23.106
Mar 23 17:56:50: reply www.googleapis.com is 216.58.212.138
Mar 23 17:56:50: reply www.googleapis.com is 142.250.186.74
Mar 23 17:56:50: reply www.googleapis.com is 142.250.185.106
Mar 23 17:56:50: reply www.googleapis.com is 216.58.206.74
Mar 23 17:56:50: reply www.googleapis.com is 142.250.185.170
Mar 23 17:56:50: reply www.googleapis.com is 142.250.185.202
Mar 23 17:56:50: reply www.googleapis.com is 142.250.185.138
Mar 23 17:56:50: reply www.googleapis.com is 142.250.74.202
Mar 23 17:56:50: reply www.googleapis.com is 172.217.18.10
Mar 23 17:56:50: reply www.googleapis.com is 142.250.186.106
Mar 23 17:56:50: reply www.googleapis.com is 172.217.16.202
Mar 23 17:56:50: reply www.googleapis.com is 142.250.184.234
Mar 23 17:56:50: reply www.googleapis.com is 142.250.185.74

Mar 23 17:57:06 dnsmasq-dhcp[41034]: DHCPDISCOVER(eth0) e8:c7:cf:cb:c1:c1 
Mar 23 17:57:06 dnsmasq-dhcp[41034]: DHCPACK(eth0) 10.2.28.63 e8:c7:cf:cb:c1:c1 TV-Buero

Mar 23 17:57:14 dnsmasq-dhcp[41034]: DHCPDISCOVER(eth0) e8:c7:cf:cb:c1:c1 
Mar 23 17:57:14 dnsmasq-dhcp[41034]: DHCPACK(eth0) 10.2.28.63 e8:c7:cf:cb:c1:c1 TV-Buero

Mar 23 17:57:14: query[A] www.google.com from 10.2.28.63
Mar 23 17:57:14: cached www.google.com is 142.250.186.100

Mar 23 17:57:14: query[A] connectivitycheck.gstatic.com from 10.2.28.63
Mar 23 17:57:14: cached connectivitycheck.gstatic.com is 142.250.186.131

Mar 23 17:57:14: query[AAAA] embeddedassistant.googleapis.com from 10.2.28.63
Mar 23 17:57:14: cached embeddedassistant.googleapis.com is 2a00:1450:4001:80b::200a
Mar 23 17:57:14: cached embeddedassistant.googleapis.com is 2a00:1450:4001:830::200a
Mar 23 17:57:14: cached embeddedassistant.googleapis.com is 2a00:1450:4001:808::200a
Mar 23 17:57:14: cached embeddedassistant.googleapis.com is 2a00:1450:4001:810::200a

Mar 23 17:57:14: query[A] embeddedassistant.googleapis.com from 10.2.28.63
Mar 23 17:57:14: cached embeddedassistant.googleapis.com is 142.250.181.234
Mar 23 17:57:14: cached embeddedassistant.googleapis.com is 142.250.186.42
Mar 23 17:57:14: cached embeddedassistant.googleapis.com is 142.250.184.202
Mar 23 17:57:14: cached embeddedassistant.googleapis.com is 172.217.16.138
Mar 23 17:57:14: cached embeddedassistant.googleapis.com is 142.250.185.138
Mar 23 17:57:14: cached embeddedassistant.googleapis.com is 142.250.74.202
Mar 23 17:57:14: cached embeddedassistant.googleapis.com is 172.217.18.10
Mar 23 17:57:14: cached embeddedassistant.googleapis.com is 142.250.186.106
Mar 23 17:57:14: cached embeddedassistant.googleapis.com is 172.217.16.202
Mar 23 17:57:14: cached embeddedassistant.googleapis.com is 142.250.186.74
Mar 23 17:57:14: cached embeddedassistant.googleapis.com is 142.250.185.106
Mar 23 17:57:14: cached embeddedassistant.googleapis.com is 216.58.206.74
Mar 23 17:57:14: cached embeddedassistant.googleapis.com is 142.250.185.170
Mar 23 17:57:14: cached embeddedassistant.googleapis.com is 142.250.185.202
Mar 23 17:57:14: cached embeddedassistant.googleapis.com is 142.250.185.234
Mar 23 17:57:14: cached embeddedassistant.googleapis.com is 142.250.186.170

Mar 23 17:57:15: query[A] mtalk.google.com from 10.2.28.63
Mar 23 17:57:15: cached mtalk.google.com is <CNAME>
Mar 23 17:57:15: cached mobile-gtalk.l.google.com is 108.177.15.188

Mar 23 17:57:17: query[AAAA] mtalk.google.com from 10.2.28.63
Mar 23 17:57:17: cached mtalk.google.com is <CNAME>
Mar 23 17:57:17: cached mobile-gtalk.l.google.com is 2a00:1450:400c:c06::bc

Mar 23 17:57:17: query[A] play.googleapis.com from 10.2.28.63
Mar 23 17:57:17: forwarded play.googleapis.com to 10.2.28.1
Mar 23 17:57:17: reply play.googleapis.com is 142.250.185.74
Mar 23 17:57:17: reply play.googleapis.com is 142.250.186.138
Mar 23 17:57:17: reply play.googleapis.com is 216.58.206.42
Mar 23 17:57:17: reply play.googleapis.com is 216.58.212.170
Mar 23 17:57:17: reply play.googleapis.com is 172.217.23.106
Mar 23 17:57:17: reply play.googleapis.com is 216.58.212.138
Mar 23 17:57:17: reply play.googleapis.com is 172.217.18.106
Mar 23 17:57:17: reply play.googleapis.com is 142.250.181.234
Mar 23 17:57:17: reply play.googleapis.com is 142.250.186.42
Mar 23 17:57:17: reply play.googleapis.com is 142.250.184.202
Mar 23 17:57:17: reply play.googleapis.com is 172.217.16.138
Mar 23 17:57:17: reply play.googleapis.com is 142.250.185.138
Mar 23 17:57:17: reply play.googleapis.com is 172.217.18.10
Mar 23 17:57:17: reply play.googleapis.com is 142.250.186.106
Mar 23 17:57:17: reply play.googleapis.com is 172.217.16.202
Mar 23 17:57:17: reply play.googleapis.com is 142.250.184.234

Mar 23 17:57:33 dnsmasq-dhcp[41034]: DHCPDISCOVER(eth0) e8:c7:cf:cb:c1:c1 
Mar 23 17:57:33 dnsmasq-dhcp[41034]: DHCPACK(eth0) 10.2.28.63 e8:c7:cf:cb:c1:c1 TV-Buero

Mar 23 17:57:42 dnsmasq-dhcp[41034]: DHCPDISCOVER(eth0) e8:c7:cf:cb:c1:c1 
Mar 23 17:57:42 dnsmasq-dhcp[41034]: DHCPACK(eth0) 10.2.28.63 e8:c7:cf:cb:c1:c1 TV-Buero

Mar 23 17:57:53 dnsmasq-dhcp[41034]: DHCPDISCOVER(eth0) e8:c7:cf:cb:c1:c1 
Mar 23 17:57:53 dnsmasq-dhcp[41034]: DHCPACK(eth0) 10.2.28.63 e8:c7:cf:cb:c1:c1 TV-Buero

Mar 23 17:58:16 dnsmasq-dhcp[41034]: DHCPDISCOVER(eth0) e8:c7:cf:cb:c1:c1 
Mar 23 17:58:16 dnsmasq-dhcp[41034]: DHCPACK(eth0) 10.2.28.63 e8:c7:cf:cb:c1:c1 TV-Buero

Mar 23 17:58:30 dnsmasq-dhcp[41034]: DHCPDISCOVER(eth0) e8:c7:cf:cb:c1:c1 
Mar 23 17:58:30 dnsmasq-dhcp[41034]: DHCPACK(eth0) 10.2.28.63 e8:c7:cf:cb:c1:c1 TV-Buero

Mar 23 17:58:39 dnsmasq-dhcp[41034]: DHCPDISCOVER(eth0) e8:c7:cf:cb:c1:c1 
Mar 23 17:58:39 dnsmasq-dhcp[41034]: DHCPACK(eth0) 10.2.28.63 e8:c7:cf:cb:c1:c1 TV-Buero

Mar 23 17:58:47 dnsmasq-dhcp[41034]: DHCPDISCOVER(eth0) e8:c7:cf:cb:c1:c1 
Mar 23 17:58:47 dnsmasq-dhcp[41034]: DHCPACK(eth0) 10.2.28.63 e8:c7:cf:cb:c1:c1 TV-Buero

Mar 23 17:58:55 dnsmasq-dhcp[41034]: DHCPDISCOVER(eth0) e8:c7:cf:cb:c1:c1 
Mar 23 17:58:55 dnsmasq-dhcp[41034]: DHCPACK(eth0) 10.2.28.63 e8:c7:cf:cb:c1:c1 TV-Buero

Mar 23 17:59:04 dnsmasq-dhcp[41034]: DHCPDISCOVER(eth0) e8:c7:cf:cb:c1:c1 
Mar 23 17:59:04 dnsmasq-dhcp[41034]: DHCPACK(eth0) 10.2.28.63 e8:c7:cf:cb:c1:c1 TV-Buero

Mar 23 17:59:12 dnsmasq-dhcp[41034]: DHCPREQUEST(eth0) 10.2.28.63 e8:c7:cf:cb:c1:c1 
Mar 23 17:59:12 dnsmasq-dhcp[41034]: DHCPACK(eth0) 10.2.28.63 e8:c7:cf:cb:c1:c1 TV-Buero

Mar 23 17:59:23 dnsmasq-dhcp[41034]: DHCPDISCOVER(eth0) e8:c7:cf:cb:c1:c1 
Mar 23 17:59:23 dnsmasq-dhcp[41034]: DHCPACK(eth0) 10.2.28.63 e8:c7:cf:cb:c1:c1 TV-Buero

Mar 23 17:59:38 dnsmasq-dhcp[41034]: DHCPREQUEST(eth0) 10.2.28.63 e8:c7:cf:cb:c1:c1 
Mar 23 17:59:38 dnsmasq-dhcp[41034]: DHCPACK(eth0) 10.2.28.63 e8:c7:cf:cb:c1:c1 TV-Buero

Mar 23 17:59:51 dnsmasq-dhcp[41034]: DHCPDISCOVER(eth0) e8:c7:cf:cb:c1:c1 
Mar 23 17:59:51 dnsmasq-dhcp[41034]: DHCPACK(eth0) 10.2.28.63 e8:c7:cf:cb:c1:c1 TV-Buero

Ich wäre sehr dankbar, wenn sich jemand mein Problem ansehen könnte. Vielen Dank im Voraus!!!

Debug Token:
https://tricorder.pi-hole.net/JnYYRSAm/

2

Eine vollständige, erfolgreiche DHCP-Sequenz würde aus DHCPDISCOVER (Client), DHCPOFFER (Server), DHCPREQUEST (Client) und DHCPACK (Server) bestehen.
Es ist auch möglich, diese Sequenz auf DHCPDISCOVER (Client) und DHCPACK (Server) zu verkürzen (rapid commit), sofern ein Client dies in seinem DHCPDISCOVER signalisiert und der DHCP-Server dies unterstützt.
Dein Debug Log zeigt, dass Du rapid commit für Deinen Pi-hole aktiviert hast.

Deine Logauszüge zeigen, dass Dein Pi-hole das entsprechende DHCPACK gesendet hat, es wird allerdings vom Client offensichtlich nicht akzeptiert, da dieser 10-20 Sekunden später erneut ein DHCPDISCOVER sendet.

Entweder kommt das DHCPACK beim Client nicht an, oder der Client ignoriert es.

Letzteres könnte z.B. passieren, sofern der Client nach Erhalt von DHCPACK feststellen sollte, dass die zugeordnete IP-Adresse bereits im Netzwerk existiert.
Allerdings sollte er in diesem Falle die zugeordnete Adresse über DHCPDECLINE ablehnen.

Gibt es vielleicht ein weiteres Gerät, auf dem 10.2.28.63 manuell statisch konfiguriert wurde?
Passen die von 10.2.28.63 gesendeten DNS-Anfragen inhaltlich zu Deinem TV?
Die von Dir geteilten Auszüge zeigen das aktuell nicht, aber gibt es eventuell DNS-Anfragen von dieser IP, die von Pi-hole geblockt werden?

Akzeptiert Dein TV-Client die Adresse vielleicht, wenn Du in Pi-holes DHCP Server Enable DHCPv4 rapid commit (fast address assignment) deaktivierst?

3

Hallo und vielen Dank für deine Beteiligung.
Das würde ich ausschließen. Wenn ich den static lease entferne wird eine Adresse aus dem oberen Bereich vergeben und da ist das Problem identisch.

Ich würde schon sagen, dass es inhaltlich passt. Sehr viel Google, hbbtv und ein paar senderspezifische Anfragen. Interessant finde ich den connectivitycheck.gstatic, aber wenn ich das richtig sehe, bekommt der auch eine Antwort.
Ich sehe (auch dauerhaft) keine geblockten DNS Anfragen für diese IP. Für die IP ist das Blocking deaktiviert.

Macht keinen Unterschied. Der log sieht identisch aus. Muss ich irgendwie noch etwas flushen oder reicht es, die neue Einstellung zu speichern?

4

Es gibt Geräte, die nach Hause telefonieren wollen. Wenn das nicht klappt, wird die Verbindung als nicht funktionierend abgelehnt.

Schalte mal das Blocking im pihole ab und Versuch es mal.

Es gibt hier User, die Millionen Server blockieren und sich dann wundern, dass reguläre Services nicht mehr funktionieren.

5

Für das Gerät ist das Blocking nicht aktiv, ich habe es aber auch mit vollständig deaktiviertem Blocking versucht. Es hat leider nicht geholfen.

6

Idee:

Die Unifi APs haben vollen Zugang zum pihole?

Also keine krummen VLAN Einstellungen oder Firewall Regeln die DHCP UDP Port 67/68 vielleicht in einer Richtung ausbremsen?

7

Wenn die gezeigten Anfragen von Deinem TV stammen, ist außerdem auffällig, dass in Deinem obigen Logauszug nur DHCPDISCOVERs/DHCPACKs zu sehen sind, auch für den Fall, dass Dein TV offensichtlich zwischenzeitlich erfolgreich ein DHCP-Lease verwendet.

Normalerweise würde ein DHCP-Client erst nach Ablauf des Lease versuchen, das bestehende Lease zu erneuern, und zwar zunächst über ein DHCPREQUEST an den DHCP-Server, von dem das bestehende Lease bezogen wurde, und nicht über ein unspezifsiches DHCPDISCOVER.

Dies könnte darauf hindeuten, dass Dein TV tatsächlich die Netzwerkverbindung verliert.

Falls Dein TV über Wifi verbunden ist:
Lässt es sich auch über Ethernetkabel anschliessen?

Dann können wir zumindest ausschließen, dass Pi-holes Blockierverhalten Dein TV daran hindert, eine bestehende Netzwerkverbindung zu erkennen und deswegen dazu bringt, eine neue DHCP-Aushandlung anzustoßen.

Speichern ist in diesem Falle ausreichend.
Generell muss man dafür sorgen, dass ein Gerät auch ein neues DHCP-Lease anfordert, aber das passiert in Deinem Fall ohnehin dauernd.

Im Ergebnis, oder von der tatsächlichen Sequenz?
Ich hätte zumindest erwartet, dass jetzt eine vollständige DORA-Sequenz zu sehen ist.

Ist Dein TV direkt mit Deinem Router verbunden, oder sitzt da noch weiteres Netzwerkgerät dazwischen (Access Point, Switch, Router)?

8

Wären dann nicht auch andere Netzwerkteilnehmer betroffen? Es sind knapp 20 weitere Teilnehmer (verteilt auf beide APs) über WLAN im Netzwerk angemeldet. Nur der TV macht Probleme.

9

Naja, der AP ist wirklich sehr nah dran und das Netzwerk zeigt volle Empfangsstärke am TV.

Hast du gesehen, dass im unteren Teil des log-Ausschnitt auch dhcprequest auftauchen?

Ja, mit Netzwerkkabel gibt es keine Probleme. Stabile und schnelle Verbindung. Leider ist Kabel keine dauerhafte Lösung, da wo der TV steht. Ich habe aber einen WLAN2LAN Adapter bestellt. Wenn wir hier keine Lösung finden, werde ich es damit versuchen.

Im Ergebnis gleich mit den gleichen Sequenzen was die dnsmasq-dhcp Einträge betrifft. Die queries habe ich im Detail nicht verglichen. Sehr viel Google halt...

Das WLAN wird von zwei UniFi APs aufgebaut. Ich hatte aber sogar extra probehalber auch WLAN an der Fritzbox aktiviert. Interessanterweise ebenfalls das gleiche Fehlerbild. Allerdings war auch zu diesem Zeitpunkt Pi-hole der DHCP Server. Der WLAN Controller des TV will nicht mit dem Pi-hole DHCP Controller, oder möglicherweise ist er sogar Schrott. Aber ich halte das eher für unwahrscheinlich. Vielleicht kann ich von der Arbeit mal einen WLAN Router zum testen mitnehmen...

10

Ich habe jetzt mit einem separaten WLAN Router erfolgreich eine dauerhafte Verbindung herstellen können. Es wird zwar logischerweise "kein Internet" angezeigt, aber die Verbindung mit dem Netzwerk selbst ist stabil.

Das lässt für mich darauf schließen, dass das WLAN-Modul des Fernsehers NICHT defekt ist. Demnach müsste es tatsächlich ein Problem mit dem DHCP-Server von Pi-Hole sein.

11

Das passiert allerdings nur selten, und nicht nach den Zeiten, zu denen in Deinem Auszug nachweislich Anfragen von der vergebenen IP registriert wurden.
Bei dem so indirekt nachgewiesenen erfolgreichen DHPC-Bezug bedeutet ein erneutes DHCPDISCOVER ohne vorheriges DHCPREQUEST, dass der Client annimmt, er hätte keine bestehende Verbindung mehr.

Das ist eine entscheidende Beobachtung:
Wenn die DHCP-Aushandlung über Ethernet funktioniert, liegt es sehr wahrscheinlich nicht an Pi-holes DHCP-Server.

Ich kann daher nur über Ursachen spekulieren:
Mögĺicherweise unterstützt der TV-WiFi-Adapter nicht alle Funkkanäle, die vom AP/Router verwendet werden, so dass er einem Kanalwechsel nicht immer folgen kann. GGf. sind Adapater und/oder Router diesbezüglich konfigurierbar.
Das würde aber nur dann passen, wenn es nur zeitweise zu diesen Verbindungsschwierigkeiten kommt.

Ähnliches würde gelten, wenn der TV-WiFi-Adapter nur über das 2,4GHz-Band funkt, Dein Router hingegen auf 2,4GHz und 5GHz unter derselben SSID.
Falls das der Fall sein sollte, könntest Du versuchen, im Router verschiedene SSIDs für jedes Band einzurichten, und Dein TV nur mit der passenden SSID zu verbinden.

12

Das hatte ich auch gedacht. Wir sprechen hier jedoch von unterschiedlichen Network-Controllern für WLAN UND LAN.

Erstens das, und zweitens ist eine Fritzbox ja sehr geläufig. Selbst mit ihr hat es Probleme gegeben, wenn Pi-hole der DHCP Server ist.

Mein billo Test Router liefert eine stabile Verbindung. Zudem habe ich eben erfolgreich mit dem Handy einen Hotspot erstellt und auch dort habe ich eine gute Verbindung. Diesmal sogar "mit Internet".

Habe ich alles schon probiert.

Theoretisch könnte ich wohl meine Fritzbox als DHCP Server einrichten. Es gab aber Gründe, warum ich das nicht gemacht habe. Wenn ich nur noch wüsste, welche es waren. Es ist schon so lange her...

13

...die beide von derselben DHCP-Client-Software des TV-Geräts angemeldet werden.

Zusammen mit den unvermittelt auftretenden DHCPDISCOVER nach erfolgreichem DHCP-Lease-Bezug macht das einen Zusammenhang mit der DHCP-Aushandlung unwahrscheinlich.

Die vielfach von Deinem TV ausgelösten DHCPDISCOVERs würde ich daher eher als Symptom einer zugrundeliegenden WLAN-Verbindungsproblematik deuten.

Eine Möglichkeit, wie DHCP eventuell doch noch involviert sein könnte, wäre eine extrem kurze Gültigkeitsdauer (Leasetime). Dein Debug Log ist bereits abgelaufen, deshalb kann ich Deine aktuelle Einstellung nicht mehr überprüfen.
Ich gehe jedoch davon aus, dass diese deutlich länger als wenige Sekunden eingestellt ist.
Sofern Dein TV-Gerät dann trotzdem aufgrund einer empfangenen niedrigen Dauer sofort nach einem neuen DHCP-Lease suchen sollte, müsste diese auf dem Weg zum TV-Gerät verändert worden sein.
Das wäre aber nur dann ein Erklärungsansatz, wenn Dein TV als einziges Gerät an einem AP hängt, da sonst auch andere Geräte betroffen sein müssten.

14

Ich prüfe nochmal die AP Einstellungen.

Daran soll es nicht scheitern: https://tricorder.pi-hole.net/EuhYX1lu/

15

Zunächst einmal vielen Dank für deine Hilfe in dieser Sache! :+1:

Mittlerweile ist diese WLAN-Bridge eingetroffen, die ich für den TV bestellt habe. Das Teil hat mit meinem WLAN zum Glück keine Probleme und somit ist das "akute" Problem des Fernsehers erstmal umgangen, wenn auch nicht wirklich gelöst.

Meine Frau hat unterdessen mitbekommen, dass ich die ganze Zeit über dieses WLAN-Problem fluche und teilt mir daraufhin mit, dass ihr Küchengerät ebenfalls Probleme mit dem WLAN hat. :exploding_head: Und tatsächlich verbindet sich auch dieses tolle Gerät regelmäßig neu mit dem WLAN!!! Der Pi-hole log sieht jedoch etwas anders/vollständiger aus:

Mar 27 19:39:24 dnsmasq-dhcp[26768]: DHCPDISCOVER(eth0) 9c:28:41:26:49:de 
Mar 27 19:39:24 dnsmasq-dhcp[26768]: DHCPOFFER(eth0) 10.2.28.89 9c:28:41:26:49:de 
Mar 27 19:39:24 dnsmasq-dhcp[26768]: DHCPREQUEST(eth0) 10.2.28.89 9c:28:41:26:49:de 
Mar 27 19:39:24 dnsmasq-dhcp[26768]: DHCPACK(eth0) 10.2.28.89 9c:28:41:26:49:de Monsi-ku
Mar 27 19:39:27 dnsmasq-dhcp[26768]: DHCPREQUEST(eth0) 10.2.28.89 9c:28:41:26:49:de 
Mar 27 19:39:27 dnsmasq-dhcp[26768]: DHCPACK(eth0) 10.2.28.89 9c:28:41:26:49:de Monsi-ku
Mar 27 19:39:27 dnsmasq-dhcp[26768]: DHCPREQUEST(eth0) 10.2.28.89 9c:28:41:26:49:de 
Mar 27 19:39:27 dnsmasq-dhcp[26768]: DHCPACK(eth0) 10.2.28.89 9c:28:41:26:49:de Monsi-ku
Mar 27 19:39:29 dnsmasq-dhcp[26768]: DHCPDISCOVER(eth0) 9c:28:41:26:49:de 
Mar 27 19:39:29 dnsmasq-dhcp[26768]: DHCPOFFER(eth0) 10.2.28.89 9c:28:41:26:49:de 
Mar 27 19:39:29 dnsmasq-dhcp[26768]: DHCPREQUEST(eth0) 10.2.28.89 9c:28:41:26:49:de 
Mar 27 19:39:29 dnsmasq-dhcp[26768]: DHCPACK(eth0) 10.2.28.89 9c:28:41:26:49:de Monsi-ku
Mar 27 19:39:29: query[A] captive.apple.com from 10.2.28.89
Mar 27 19:39:29: cached captive.apple.com is <CNAME>
Mar 27 19:39:29: cached captive-cidr.origin-apple.com.akadns.net is <CNAME>
Mar 27 19:39:29: cached captive-cdn.origin-apple.com.akadns.net is <CNAME>
Mar 27 19:39:29: cached captive.g.aaplimg.com is 17.253.57.201
Mar 27 19:39:29: cached captive.g.aaplimg.com is 17.253.57.195
Mar 27 19:39:29: query[A] mc-api.tecpal.com from 10.2.28.89
Mar 27 19:39:29: cached mc-api.tecpal.com is 130.211.30.106

Verbinde ich das Küchengerät mit mit dem WLAN-Hotspot (vom Handy) funktioniert alles. Genau wie beim TV.

Ich habe also mittlerweile zwei Geräte, die sich in Dauerschleife immer wieder neu mit dem WLAN verbinden. Ich habe wohl ein systematisches Problem im Netzwerk/WLAN und finde einfach nicht die Ursache... Gemeinsam haben beide Geräte, dass sie recht neu sind. Sonst sehe ich keine besonderen Gemeinsamkeiten.

Um den DHCP-Server des Pi-hole auszuschließen, habe ich zwischenzeitlich den DHCP-Server der fritzbox verwendet. Der TV hatte dann trotzdem noch die Verbindungsprobleme gehabt! Der DHCP-Server des Pi-hole scheint also nicht das Problem zu sein. Vom Problem des Küchengerätes wusste ich zu diesem Zeitpunkt noch nicht, deshalb kann ich hier keine Aussage treffen.

Das Küchengerät MUSS schon mal erfolgreich im WLAN gewesen sein, sonst hätte meine Frau nicht die Ersteinrichtung machen können. Ich bin echt ratlos. Kann man das Problem irgendwie gezielter diagnostizieren? Ich habe schon öfter von Wireshark gehört/gelesen. Könnte das ein Ansatz sein?

  • Ich gebe zu, WLAN-Einstellungen klingen momentan am wahrscheinlichsten. Ich habe dort aber schon fast alles probiert. (werde wohl trotzdem mal in der UniFi Community vorsprechen)
  • Kann es ein DNS-Problem sein?
  • Kann es ein IPv6-Problem sein?
16

Probiere doch mal 2 DHCP server.
1-100 im Router
101-200 im Pi.

Dann lass die Geräte, die eh keine Werbung anzeigen (Küchenmaschine) über den Router laufen.
Zum Testen reicht es allemal.

Ich habe auch den Pi in Verdacht, da ich annehme, dass nur sehr wenige Benutzer das DHCP Feature auf dem Pi nutzen.

17

Das hatte ich (zumindest für den Fernseher) bereits gemacht.

Rein vom Gefühl her vermute ich eine falsche Einstellung auf dem RPi IPv6 betreffend. Ich kann es aber nicht benennen.

Eben hatte ich das Küchengerät für längere Zeit im WLAN angemeldet, nachdem ich im Pi-hole DHCP Server "Enable IPv6 support" aktiviert hatte. Ich habe mich schon mega gefreut und wollte es direkt am TV bestätigen. Dort ging es aber leider nicht. Als ich dann zum Küchengerät zurückkehrte, war auch dort die Verbindung wieder weg. Seitdem bekomme ich sie auch nicht mehr hergestellt....

18

Naja, dieser Verdacht ist schon wegen folgender Beobachtung nicht haltbar:

Zudem verwendet Pi-hole die DHCP-Server-Komponente von dnsmasq, das recht häufig als DHCP- und DNS-Server in resourcekritischen Systemen wie Routern eingesetzt wird.

Wir verlassen hier rapide den Bereich, wo Pi-hole involviert ist.
Ich werde daher vermutlich nicht mehr viel weiter helfen können.

Das würde den Verdacht auf das Netzwerkequipment lenken, das zwischen der FritzBox und dem TV sitzt.

DHCP-Broadcasts (wie z.B. bei DHCPDISCOVER) sind grundsätzlich limitiert auf dasselbe Netzwerksegment/denselben Link/dieselbe Collision oder Broadcast Domain - im einfachsten Fall also alle Geräte, die direkt mit dem Router verbunden sind.

Kommen weitere Netzwerkgeräte wie z.B. Router, APs, oder bestimmte Switches hinzu, teilen diese Dein Netzwerk ggf. in verschiedene Segmente, sofern sie als Layer-3-Switch arbeiten. Gleiches gilt für VLANs.

Broadcasts erreichen dann nur noch die an ein jeweiliges Segment angeschlossenen Geräte.
Ein DHCPDISCOVER eines potentiellen Clients aus Segment A kann also einen DHCP-Server in Segment B nicht erreichen.

Dafür braucht es die Möglichkeit zur Inter-VLAN-Kommunikaton im Router (nur im Fall von VLANs), oder ein DHCP-Relay in Segment A, dass die entsprechenden Broadcasts aus beiden Segmenten weiterleitet und dabei die Datenpakete passend manipuliert.
Nur wenn Router und/oder DHCP Relay ihren jeweiligen Job richtig machten, können DHCP-Client und DHCP-Server so segmentübergreifend zueinander finden.

Da Dein TV sich anstandslos über einen DHCP-Server in demselben Segment anmelden kann (z.B. über den Telefon-Hotspot), kann das darauf hindeuten, dass Dein zusätzliches Netzwerkequipment hier involviert ist.

Nein, DHCP wickelt die Kommunikation ausschließlich über IP-Adressen und Hardware-IDs ab.

Nein, DHCP ist ein reines IPv4-Protokoll.
Das Gegenstück in IPv6 wäre DHCPv6; ein eigenständiges Protokoll auf komplett anderen Ports, welches ohnehin selten zur Anwendung kommt, da IPv6 stark auf Autokonfiguration über NDP/SLAAC ausgelegt ist.

Grundsätzlich schon, in Deinem Fall bin ich eher skeptisch.

Aus Deinen DHCP-Logs wissen wir bereits, dass Piholes DHCP-Server die erwarteten DHCP-Nachrichten versendet.
Natürlich könntest Du Dir das mit Wireshark auch nochmal im Rohformat ansehen.
Interessant wäre aber, was beim Client ankommt, d.h. Du müsstest Wireshark direkt auf dem TV oder dem Küchengerät laufen lassen.

Selbst wenn das geht:
Zumindest Dein TV verhält sich so, als hätte es die Netzwerkverbindung verloren, d.h es verwirft Pi-holes DHCPACK wortlos.

Möglicherweise siehst Du also auf dem TV Pi-holes DHCPACK ankommen und das TV kurz danach ein neues DHCPDISCOVER senden.
Warum das TV das tut, wirst Du so allerdings auch nicht erfahren.

Interessant wäre hier allenfalls, ob das von Pi-hole versendete Paket überhaupt und inhaltsgleich (nicht notwendigerweise byte-identisch) beim TV ankommt oder umgekehrt.
Wäre das nicht der Fall, würde das wiederum auf Router oder Relay hindeuten.

Das ist eine vollständige DORA-Sequenz.
Auch hier sendet Pi-hole das finale DHCPACK, das wieder nicht empfangen oder ignoriert wird, diesmal von der Küche.

Es gibt Fälle, in denen Geräte in den vom Server angebotenen DHCP-Informationen nach bestimmten, herstellerspezifischen Optionen suchen und ein DHCP-Lease verwerfen, wenn diese nicht vorhanden sind.
Das sind dann aber zum einen Netzwerkgeräte wie Mesh-Systeme, die nur mit DHCP-Servern auf Routern desselben Herstellers zusammenarbeiten wollen, und zum anderen würde die Sequenz dann in der Regel schon nach DHCPOFFER abbrechen, weil der Client nicht weiter reagiert.

Für ein Küchengerät oder ein TV wäre eine Herstellerbindung an einen bestimmten Router allerdings absolut ungewöhnlich und für die Hersteller kontraproduktiv.

19

Ist schon sehr seltsam, wenn schon der DHCP der Fritzbox nicht funktioniert.

Da ist grundsätzlich etwas im Argen.

Läuft ein zweiter DHCP im Netzwerk?
Reduziere mal das Netzwerk auf das Wesentliche. Nur die Fritzbox und die Clients.
Dann der Pi mit pihole.
Wenn das funktioniert, kommt ein AP nach dem anderen dazu.

Ich würde es so machen.

20

Kann es sein, dass Du die FritzBox nicht mit default WiFi-Settings betriebst? Autokanal mal deaktiviert?