Sonos Sub 4 und Era 300 nicht mehr in App

​@steven11, das nächste Mal: Router gefolgt vom Sonossystem neu starten (Stecker ziehen, 30 Sek. warten, wieder einstöpseln), sollte genügen.

• Wenn Sie die Sonosapp öffnen, sehen Sie da alle drei Komponenten? Gibt es außer dem Opensense noch einen 2. Router oder eine andere Netzwerkkomponente die ebenfalls DHCP-fähig ist?
• Wie haben Sie die Komponenten wieder eingerichtet? Die Arc Ultra als “Neues System” und Sub + Era 300 zu einem “Bestehenden System” hinzugefügt (richtig) oder haben Sie jede Komponente als “Neues System” (falsch) eingerichtet?

​@Hedy L. danke, jetzt funktioniert es wieder! Ich habe den Access Point neu gestartet.

Warum das jetzt funktioniert und davor nicht, ist mir völlig unerklärlich...schließlich waren die Geräte ja erreichbar. Aber egal, ich bin happy :-)

​@steven11, freut mich, danke für die Rückmeldung. Ich wünsche Ihnen viel Freude an Ihrem Surroundsystem. 🙂

​@steven11 

Der Access Point hatte wahrscheinlich noch veraltete IP Adressen der Geräte gespeichert. Nach einem Update oder Reset haben sie aber vom DHCP Server anscheinend neue Adressen bekommen. Mach dem Neustart hat der AP nun die korrekten Adressen. 
Richtig blöd wäre allerdings, wenn du zwei DHCP Server am Laufen hast. Also unbedingt mal checken, dass nur der Router und nicht auch noch der AP DHCP macht. 

Das Problem ist leider wieder da, die App meldet mir, dass die Geräte nicht verbunden sind :-(

Ich habe dann probiert, sie anzupingen → ging diesmal nicht.

Dann in meinem Router (es ist OPNSense) geschaut, ob sie von DHCP eine IP-Adresse bekommen haben: im Log-File sehe ich, dass sie eine anfordern (DHCPDISCOVER) und der Router ihnen eine liefert (DHHCPOFFER). ABER: die Eras und der Sub bestätigen das nicht mit einem DHCPACK-Paket!

Daraus schließe ich, dass es sich nicht um ein Verbindungs-/WLAN-problem handeln kann, sondern die Sonos-Geräte aus irgendeinem Grund die IP-Adresse nicht annehmen.

Hat jemand eine Idee, was da los ist? Die Sonos-Geräte sind nicht in einem eigenen VLAN, sondern im Standard-LAN der OPNSense. DHCP funktioniert da auch definitiv, mein PC oder andere Geräte bekommen alle eine IP-Adresse und meine Sonos Arc Ultra ja auch. Die IP-Adressen .21, .22 und .23, die ich für die Eras und den Sub gewählt habe, werden auch nicht bereits von anderen Geräten belegt.

Das würde ich so noch nicht verbindlich unterschrieben.

Was Du da im Log beobachtest ist doch nur die Eingangsrichtung. - vom WLAN-Client zum Router / DHCP-Server.

Ob das Angebot (DHCPOFFER) auch auf dem WLAN-Client sauber ankommt (und dort fehlerfrei verarbeitet werden kann) siehst Du aber nicht in diesem Log !

Was sagen denn die RSSI-Werte und die anderen Daten, welche Du auf den Eras unter "IP-ADRESSE:1400/status" abfragen kannst ?

Ja ok, da hast du natürlich Recht damit. Eingehend kommt auf jeden Fall was, man sieht im Log dass ein paar Sekunden vorher schon mal ein Request reinkam.

Die Verbindungsqualität kann nicht schlecht sein - der Access Point ist 4 m von den Eras entfernt und hat direkte Luftlinie.

Was aber verdächtig ist: ich konnte die Verbindungsqualität mangels IP-Adresse nicht prüfen und habe deshalb den Access Point wieder neu gestartet → die Eras sind wieder alle da! Damit muss es irgendwie zusammenhängen. Ich checke das mal genauer, ich habe ein Omada-System.

Zur Verbindungsqualität: in der App habe ich dann nachgeschaut und sowohl die Arc Ultra als auch die Eras und der Sub haben eine SNR von 51 dB → sehr gut. Die Frequenz ist 5180 MHz.

5180 MHz entspricht dem WLAN-Kanal 36 im 5-GHz-Band.

Arbeitet Dein AP mit 40 oder 80 MHz Bandbreite ?

Wie sieht die Bandauslastung am Standort des APs, und direkt am Standort des Clients (ermitteln mit einem WLAN-Scanner auf einem Mobile-Device) aus? 
SNR ind RSSI ist das Eine, Interferenzen und / oder verfügbare AirTime ist das Andere.

Auf welchem Wert steht denn eigentlich die TTL für den DHCP-Release ?

Irgendeinen Grund muss es ja geben, dass der Client die IP verliert bzw. sein Release nicht erneuern kann.

Btw., wenn der Client keine IP bekommt, oder die Antwort vom DHCP-Server nicht verarbeiten kann, dann verfällt er nach einem kurzen Timeout in eine Zeroconf und weist sich eine Link-Local-IP-Adresse zu. Problem ist halt diese dann heraus zu bekommen um Analysen auf dem Client starten zu können.

Der AP hat die Bandbreite auf 80 MHz eingestellt.

Messen mit WLAN-Scanner kann ich heute abend.

Die Lease-Time steht auf Default (= 2 Stunden).

Im DHCP-Log habe ich auf die MAC-Adresse gefiltert und sehe, dass er immer und immer wieder probiert hatte eine IP über DHCP zu bekommen: immer 3 Versuche, dann ca. eine Minute Pause.

Da kommt es jetzt drauf an wie das Band bei Dir an den verschiedenen Stellen im Haus / in der Wohnung ausgelastet ist.

Mit 80 MHz belegst Du auf jeden Fall 4 Kanäle (36, 40, 44 u. 48).

Mit Kanal 52 fängt DSF an. 

je nach Auslastung kann ggf. 40 MHz weitaus besser sein !?

Das wäre mir viel, viel zu klein.

Solche Werte kann man in einem hoch frequentierten Gast-Netz nehmen wo ständig die Clients wechseln.

Bei mir steht die Lease-Time für das heimische WLAN auf 7 Tage. - es würde locker auch 1 Monat reichen, da die meisten Clients eh eine feste Reservierung haben und keine Veränderung statt findet.

Und wenn es mal notwendig sein sollte kann ich einzelne Clients immer noch manuell refrechen.

Aber dennoch … ob nun 2 Stunden oder 2 Wochen … Die Erneuerung des Lease sollte hier auf jeden Fall funktionieren und nicht zu Problemen führen. - außer Du hättest so viele Clients und die kurze Zeit würde zu einer Überlastung des Servers führen, was ich aber zunächst mal nicht vermuten würde.  

also nach einer Minute sollte der eigentlich schon in der ZeroConf sein.

Ich weiß jetzt nicht wie SONOS den Time-Out dafür eingestellt hat …

Irgendwie muss der Client Probleme mit der Verarbeitung der Antworten vom DHCP-Server haben.

Kannst Du mal Deine SSID und das PW auf ggf. kritische oder grenzwertige Zeichen überprüfen.
Auch wenn laut Spezifikation eigentlich der volle UTF16 (mindestens UTF8) unterstützt werden soll würde ich aus Erfahrung grundsätzlich aber immer nur Zeichen aus dem Standard-ASCII verwenden.
Evtl. resultieren die Probleme ja aus dieser Ecke und werden dann erst beim DHCP sichtbar. - einfach mal so als Hypothese …
Oft ist es einfach nur eine Folge von Fehlern, wo die eigentliche Ursache dann aber an ganz anderer Stelle liegt.

→ Ich habe die Lease-Time jetzt auch mal auf 1 Woche eingestellt.

→ SSID lautet “code-factory”. PW hat nur Buchstaben und Zahlen. Das ist denke ich nicht das Problem, sonst würde es ja nie funktionieren. Im Moment geht es aber.

→ Was komisch ist: im Moment funktioniert es ja. In der App kein Fehler und wenn ich einen Atmos-Song anhören will, höre ich das auch. Allerdings sehe ich die 3 Geräte weder in Omada, noch kann ich sie anpingen - WTF? Auf die Status-Seite komme ich auch nicht mehr. Ich checks nicht…

→ Hier sind noch die Messergebnisse:

Beim AP im Wohnzimmer:

Beim Era:

Hier ist komisch bzw. ich glaube ich weiß was das sein könnte…einmal wird Kanal 36 gut angezeigt. Wenn ich paar Sekunden warte bis zum erneuten Scan, wird er ganz schlecht angezeigt.

Ich kann es mir nur dadurch erklären, dass ich mehrere Access Points habe und das der im Garten ist.

Im Signalverlauf sieht der Kanal aber gut aus:

Sagt euch das irgendwas? Ich habe leider nicht so die Erfahrung mit WLAN-Optimierung.

In Omada habe ich die Optimierung jetzt mal gemacht, mal schauen ob es was bringt. Die Sonos-Geräte sind da aber leider weiterhin nicht sichtbar.