Support Fritzbox Gerätestatus nicht richtig (LLDP)

[pcbastler]

Hallo zusammen,
ich habe seit FritzOS 8.0 ein komplexes Problem und dazu auch schon ein Ticket bei AVM.
Mein Routing sieht so aus: DSL -> Fritzbox 7590 -> Netgear GS724Tv4 -> TP-Link WDR4900 mit OpenWRT -> Laptop.
Hängt das Laptop per LAN am TP-Link wird es in der FB als aktives Gerät im Heimnetz angezeigt, soweit alles ok.
Bringe ich das Laptop per WLAN an den TP-Link, ist es in der FB plötzlich inaktiv (obwohl alles vom Laptop funktioniert, sogar der Aufruf der FB-Konfiguration).
Seitens AVM kam jetzt der Hinweis auf LLDP, das hab ich auf dem GS724T und dem OpenWRT-Router installiert, das ändert aber nichts an der Situation. Bis FritzOS 7.29 hat das alles einwandfrei funktioniert.

Richtig nervig ist das, weil die Erkennung des Mobiltelefons auf dem selben Weg jetzt falsch ist und somit die Anwesenheitserkennung im HomeAssistent fehlschlägt.
Hat hier jemand eine Idee oder das gleiche Problem?

 

[prisrak]

Hi!

Das klingt nach einer wirklich kniffligen Netzwerk-Unstimmigkeit! Lass uns das mal systematisch angehen. Ich denke, der Schlüssel liegt im Unterschied zwischen der LAN- und WLAN-Verbindung am TP-Link mit OpenWRT — und wie die Fritzbox seit FritzOS 8.0 diese Geräte erkennt. Lass mich ein paar Gedanken dazu sortieren!

Mögliche Lösung ist hier:

Spoiler: Ki Info

Was passiert hier vermutlich?

• Bis FritzOS 7.29 hat alles funktioniert — also muss sich mit FritzOS 8.0 entweder die Netzwerkerkennung oder das ARP/LLDP-Handling verändert haben.
• Dass das Laptop im WLAN am TP-Link in der Fritzbox als „inaktiv“ auftaucht, obwohl alles funktioniert, deutet darauf hin, dass die Fritzbox keine gültige ARP-Antwort oder einen Layer-2-Mechanismus für diese WLAN-Clients mehr bekommt.
• Beim LAN-Anschluss am TP-Link scheint das anders zu sein — vermutlich wird hier direkt eine MAC-Adress-Weiterleitung gemacht, während beim WLAN irgendetwas anders gehandhabt wird.

Mögliche Ursachen:

1. IGMP-Snooping oder Bridge-Handling:
   
   • In OpenWRT wird WLAN oft in einer Bridge mit dem LAN-Interface betrieben. Eventuell läuft hier ein Filtering oder Proxy-ARP, das FritzOS 8.0 nicht mag.
   • Schau mal unter OpenWRT → Network → Interfaces → LAN/WLAN Bridge, ob IGMP-Snooping aktiviert ist. Falls ja, testweise deaktivieren.
2. FritzOS 8.0 und LLDP:
   
   • Du hast LLDP bereits installiert — gut! Aber AVM setzt manchmal eher auf ARP oder sogar ein eigenes Protokoll (wie das FRITZ!Box Mesh-Protokoll). LLDP könnte hier also nur bedingt helfen.
   • In OpenWRT mal prüfen: opkg list-installed | grep lldpd — und falls nötig, sicherstellen, dass der LLDP-Daemon auch aktiv läuft:
     /etc/init.d/lldpd enable<br>/etc/init.d/lldpd start<br>
3. Fritzbox 8.0 und Multicast-MDNS:
   
   • Eventuell erkennt FritzOS 8.0 WLAN-Clients am TP-Link nicht mehr korrekt, weil Multicast-MDNS nicht sauber durch die TP-Link-Bridge geht.
   • Test: avahi-browse -a auf dem OpenWRT-Router ausführen und sehen, ob das Laptop sowohl über LAN als auch WLAN sichtbar ist.

Ideen zur Lösung:
OpenWRT: Bridge-Mode verfeinern

• Unter Network → Interfaces → LAN/WLAN sicherstellen, dass WLAN im reinen Bridge-Mode läuft und nicht als separater Routing-Hub arbeitet.
• Eventuell brctl show verwenden, um die Bridge-Interfaces zu prüfen.

Fritzbox: Netzwerkprotokolle checken

• Im FritzOS 8.0 gibt es in „Heimnetz → Netzwerk → Netzwerkeinstellungen“ häufig neue Optionen zu IPv6-Router-Advertisements oder „Mesh-Steering“ — testweise deaktivieren.

ARP-Timeout anpassen:

• Es gibt Berichte, dass FritzOS 8.0 ARP-Cache-Timeouts verändert hat. Ein kurzes Ping-Skript auf dem OpenWRT-Router könnte den ARP-Cache frisch halten:
  while true; do ping -c 1 192.168.178.1; sleep 60; done<br>

Letzter Ausweg:

• Falls all das nicht hilft, könntest du versuchen, die TP-Link-WLAN-Clients per statischem DHCP-Eintrag in der Fritzbox fest zu verankern — das könnte helfen, die „inaktiv“-Erkennung zu umgehen.
• Alternativ: Home Assistant könnte eventuell auf den OpenWRT-Router umgestellt werden, um die Anwesenheitserkennung zuverlässiger zu machen (z. B. über einen direkten ARP-Scan dort).

Ich bin gespannt, ob wir das Problem damit einkreisen können — lass mich gern wissen, ob sich dadurch etwas ändert oder ob wir weitergraben müssen!

 

[pcbastler]

Test: avahi-browse -a auf dem OpenWRT-Router ausführen und sehen, ob das Laptop sowohl über LAN als auch WLAN sichtbar ist.

Das war der entscheidende Hinweis. Hier werden nur LAN-Geräte gefunden (plus zwei Shellys die per WLAN an der FB hängen).

Aber wo muss ich jetzt schrauben? avahi ist auf den OpenWRT-Routern standardmäßig nicht installiert.

 

[prisrak]

Ah, super, dass der Test etwas Licht ins Dunkel gebracht hat! Dass nur die LAN-Geräte und nicht die WLAN-Geräte am TP-Link-Router gefunden werden, deutet stark darauf hin, dass Multicast-MDNS (also Bonjour/Avahi) über die WLAN-Bridge nicht sauber durchkommt. Lass uns das Stück für Stück fixen!

Spoiler: Ki Info

---

1. Avahi auf dem OpenWRT-Router installieren


Da OpenWRT Avahi nicht standardmäßig mitbringt, kannst du das ganz einfach nachinstallieren:


opkg update<br>opkg install avahi-daemon avahi-utils<br>

Falls opkg die Pakete nicht findet, musst du eventuell das luci-proto-ipv6 oder zusätzliche Repos aktivieren.

---

2. Avahi konfigurieren


Nach der Installation gibt’s eine Konfigurationsdatei, meistens unter:


/etc/avahi/avahi-daemon.conf<br>

Darin solltest du sicherstellen, dass:

• Interfaces korrekt gewählt sind.
• Multicast-Reflektierung erlaubt ist.

Öffne die Datei und editiere:


vi /etc/avahi/avahi-daemon.conf<br>

Ändere oder ergänze:


[server]<br>allow-interfaces=br-lan,wlan0<br><br>[reflector]<br>enable-reflector=yes<br>

br-lan ist in OpenWRT normalerweise das LAN-Bridge-Interface.
wlan0 oder wlan1 sollte das Interface für das WLAN sein — mit ip a kannst du die genaue Bezeichnung prüfen.

---

3. Avahi als Multicast-Reflector aktivieren


Damit Avahi die mDNS-Pakete zwischen LAN und WLAN weiterleiten kann:


/etc/init.d/avahi-daemon enable<br>/etc/init.d/avahi-daemon start<br>

Das sorgt dafür, dass Avahi die Bonjour/Multicast-Pakete zwischen deinen OpenWRT-Interfaces reflektiert.

---

4. Firewall-Regel checken


Manchmal blockiert die OpenWRT-Firewall Multicast- oder mDNS-Verkehr:


Geh ins OpenWRT-Webinterface:
Network -> Firewall -> Traffic Rules


Füge eine neue Regel hinzu:

• Name: Allow-mDNS
• Protocol: UDP
• Ports: 5353
• Source Zone: lan
• Destination Zone: lan
• Action: Accept

Oder per CLI:


uci add firewall rule<br>uci set firewall.@rule[-1].name='Allow-mDNS'<br>uci set firewall.@rule[-1].src='lan'<br>uci set firewall.@rule[-1].dest='lan'<br>uci set firewall.@rule[-1].proto='udp'<br>uci set firewall.@rule[-1].dest_port='5353'<br>uci set firewall.@rule[-1].target='ACCEPT'<br>uci commit firewall<br>/etc/init.d/firewall restart<br>

---

5. Testen


Jetzt nochmal:


avahi-browse -a<br>

Wenn jetzt auch die WLAN-Geräte auftauchen, sind wir auf dem richtigen Weg!
Danach solltest du auch in der Fritzbox wieder korrekte Statusanzeigen für die TP-Link-WLAN-Geräte sehen.

---

Hintergrund:

• FritzOS 8.0 scheint mehr auf Multicast-MDNS zu setzen (besonders fürs Heimnetz-Device-Tracking).
• Dass LAN klappt, aber WLAN nicht, ist ein typisches Zeichen, dass die mDNS-Pakete nicht reflektiert werden.
• OpenWRT trennt LAN und WLAN-Interfaces oft logisch, sodass ohne Multicast-Reflector der Traffic hängen bleibt.

---

 

[pcbastler]

Ich werde aus den Resultaten nicht schlau:

Spoiler

 br-lan IPv4 DkApi-3                                       _dkapi._tcp          local
+ br-lan IPv4 DkApi-2                                       _dkapi._tcp          local
+ br-lan IPv4 solaredgeinv-7503DFB8                         _solaredge-inv._tcp  local
+ br-lan IPv4 solaredgeinv-7503DFB8                         _solaredge-modbus._tcp local
+ br-lan IPv4 solaredgeinv-7503DFB8                         _solaredge-sense-monitor._udp local
+ br-lan IPv4 Frank_IPad                                    _companion-link._tcp local
- br-lan IPv4 Frank_IPad                                    _companion-link._tcp local
+ br-lan IPv4 DkApi                                         _dkapi._tcp          local
+ br-lan IPv4 Frank_IPad                                    _companion-link._tcp local

Die _dkapi_tcp Geräte sind Daikin-Klimaanlagen, die mit WLAN am OpenWRT hängen, die werden Korrekt in der FB angezeigt. Das Ipad taucht hier auf, aber nicht in der FB, Mein Laptop und das Iphone (ebenfalls per WLAN am gleichen AP) tauchen noch nicht mal bei avahi-browse auf????

 

[prisrak]

Okay, das ist interessant! Dass die Daikin-Klimaanlagen per WLAN korrekt in der Fritz!Box angezeigt werden, aber das iPad, iPhone und Laptop nicht mal in avahi-browse auftauchen, deutet darauf hin, dass diese Geräte entweder:

1. mDNS/Multicast nicht senden oder empfangen
2. In einer anderen OpenWRT-Bridge oder VLAN-Konfiguration hängen
3. Eventuell von OpenWRT oder ihrer eigenen Firewall blockiert werden

---

​

Spoiler: Ki Info

Prüfe die Netzwerkinterfaces auf dem OpenWRT-Router:
Zeigt an, welche Netzwerkschnittstellen da sind und wie sie miteinander verbunden sind:


ip a<br>

Falls dein WLAN nicht Teil von br-lan ist, sondern in einer separaten Schnittstelle (wlan0 oder wlan1), dann kann Avahi den Traffic nicht weiterleiten.


Gibt es ein VLAN, das WLAN und LAN trennt?
Führe aus:


brctl show<br>

Wenn WLAN nicht in der br-lan-Bridge ist, dann müsste es mit in die Bridge aufgenommen werden:


uci set network.lan.ifname='eth0 wlan0'<br>uci commit network<br>/etc/init.d/network restart<br>

Falls dein OpenWRT-Router VLANs nutzt, müssen wir prüfen, ob das WLAN-Netz sich mit dem LAN-Netz „unterhält“.

---

​

Teste auf dem Laptop oder iPhone direkt mit:


dns-sd -B _services._dns-sd._udp<br>

Falls nichts auftaucht, senden diese Geräte keine mDNS-Infos – das kann an Firewalls oder WLAN-Isolierung liegen.


Falls du ein Linux- oder macOS-Gerät hast, kannst du auch mit:


avahi-browse -a<br>

prüfen, ob dein Laptop sich selbst sieht.

---

​

Einige Access Points und Switches blockieren Multicast-Verkehr, um Bandbreite zu sparen.


IGMP-Snooping auf OpenWRT deaktivieren:Falls aktiviert, kann es Multicast stören:


uci set network.lan.igmp_snooping=0<br>uci commit network<br>/etc/init.d/network restart<br>

Prüfe dann nochmal avahi-browse -a.


Fritzbox: Multicast-Sperren ausschalten
Falls die Fritzbox IGMP-Snooping oder eine „Multicast-Filterung“ durchführt, kann das auch Probleme machen:
Heimnetz → Netzwerk → Netzwerkeinstellungen → „Multicast-Sperren“ deaktivieren.

---

​

Falls die OpenWRT-Firewall Multicast-Pakete blockiert, kann mDNS nicht zwischen WLAN und LAN passieren.


Testweise die Firewall für Multicast freigeben:


uci add firewall rule<br>uci set firewall.@rule[-1].name='Allow-mDNS'<br>uci set firewall.@rule[-1].src='lan'<br>uci set firewall.@rule[-1].dest='lan'<br>uci set firewall.@rule[-1].proto='udp'<br>uci set firewall.@rule[-1].dest_port='5353'<br>uci set firewall.@rule[-1].target='ACCEPT'<br>uci commit firewall<br>/etc/init.d/firewall restart<br>

---

​

Einige Access Points verhindern, dass WLAN-Geräte untereinander oder mit LAN kommunizieren.


Prüfe in OpenWRT Wireless → SSID-Einstellungen, ob eine Option wie "AP Isolation" oder "Client Isolation" aktiviert ist – wenn ja, deaktivieren.


Falls dein iPhone oder Laptop in einem Gastnetzwerk ist (z. B. wlan1-1 oder wlan1-guest), ist es evtl. aus dem Heimnetz isoliert.

---

1. WLAN-Interface in br-lan bringen (brctl show → Falls nötig, uci set network.lan.ifname='eth0 wlan0')
2. IGMP-Snooping deaktivieren (uci set network.lan.igmp_snooping=0)
3. Multicast-Firewallregel setzen (uci add firewall rule ...)
4. WLAN-Isolierung (AP Isolation) in OpenWRT deaktivieren
5. iPhone & Laptop testen, ob sie überhaupt mDNS senden (dns-sd -B _services._dns-sd._udp auf Mac/iOS)

Ich bin gespannt, ob eine dieser Maßnahmen das Problem löst! ein Tip für Ki -> chatgpt.com

 

[pcbastler]

Ich hab grad noch einen Archer C7 gefunden. Ich setz den mal mit einem aktuellen OpenWRT neu auf damit icht eine saubere Testumgebung habe. Der mdns-browser unter Windows sieht das Laptop auch nicht, da muss ich mal nach eine Debian-tauglichen Variante suchen.