Handys verlieren im Standby Wlan seit Controller Update

Ich hatte das Problem damals mit Samsung Handys, welche einen Exynos Prozessor hatten.

Das Softwareupdate des Controllers ändert sicherlich nicht deine AP Konfiguration.

Ich halte das für Zufall…

Hast du die FW der AP geändert oder die Konfiguration?

Hast du die Kanäle händisch konfiguriert oder steht alles auf Automatik?

Eventuell sind das Interferenzen, verursacht durch einen Nachbarn?

Ich habe das mal bei meinem iPhone beobachtet und musste feststellen: -68dB sind kein gutes Signal bei 5 GHZ…jetzt habe ich zwei zusätzliche APs und alle Geräte halten die Verbindung, auch im Standby…

Ist hier bei uns auch so, allerdings kann ich nicht sagen ob das vor dem Update auch so war. Apple iPhones haben das Problem, Android Handys nicht.

Zitat von SaturniaTravertini

Ist hier bei uns auch so, allerdings kann ich nicht sagen ob das vor dem Update auch so war. Apple iPhones haben das Problem, Android Handys nicht.

Mir wäre neu, das Apple-Smartphones im Standby nicht das WLAN runterfahren um Strom zu sparen, auch mein MacBook macht das

Ich kann dazu nix sagen, hab nix von Apple. Ich bin da von den zugetragenen Infos der Mitarbeiter abhängig - und die sagen dass das erst seit einiger Zeit der Fall ist.

Das ist bei iPhones völlig normal. Allerdings sollten die sich so schnell wieder verbinden das man das eigentlich kaum merkt.

Könnte mir vorstellen, dass es auch in die Kategorie Problem beim Verbindungsaufbau fällt. Gab doch hier einige Threats zu diversen Apple Geräten die sehr lange brauchten um ins WLAN zu kommen.

Ich habe mir das Phänomen mal zeigen lassen. Sobald man das iPhone mit der An/Aus Taste in den Standby schickt, kommen keine Push Nachrichten mehr an.
Das liegt daran, dass tatsächlich sofort mit dem "Ausschalten" das WLAN die Verbindung verliert. Dadurch dass wir eh in einem Funkloch arbeiten, kommt also nix über 4G/5G, also mobiles Internet an. Ergo müssen diese Mitarbeiter entweder alle 10Min manuell nachschauen oder das Display dauerhaft eingeschaltet lassen.

Das ist definitiv nicht normal. Wie sieht denn die WLAN Konfig aus?

Broadcasting für alle APs, Rest auf Auto.

Dann würde ich mal das Auto raus nehmen und die Details konfigurieren. Bei mir läuft es mit diversen Iphones Problemlos so:

Zitat von Tomcat

Mir wäre neu, das Apple-Smartphones im Standby nicht das WLAN runterfahren um Strom zu sparen, auch mein MacBook macht das

Das IOS Device aktiviert einen Stromsparmodus, korrekt, aber die WiFi Verbindung mit dem AP bleibt erhalten. Meine IOS Devices sind permanent mit dem dem WLAN verbunden und verlieren die Verbindung im Standby nicht. Im Fall der iPads wochenlang, es sei denn die Geräte werden neu gestartet.

Es wäre in dem Fall nicht möglich Push Notifications zu erhalten, Stichwort DTIM.

Zitat von Downsideup

Das IOS Device aktiviert einen Stromsparmodus, korrekt, aber die WiFi Verbindung mit dem AP bleibt erhalten. Meine IOS Devices sind permanent mit dem dem WLAN verbunden und verlieren die Verbindung im Standby nicht. Im Fall der iPads wochenlang, es sei denn die Geräte werden neu gestartet.

Es wäre in dem Fall nicht möglich Push Notifications zu erhalten, Stichwort DTIM.

Stimmt, hast Recht, WLAN bleibt bestehen, aber das iPhone reagiert z.b. nicht mehr auf Ping:

64 bytes from 10.0.20.20: icmp_seq=43 ttl=64 time=94.673 ms
64 bytes from 10.0.20.20: icmp_seq=44 ttl=64 time=115.146 ms
64 bytes from 10.0.20.20: icmp_seq=45 ttl=64 time=33.936 ms
64 bytes from 10.0.20.20: icmp_seq=46 ttl=64 time=52.630 ms
64 bytes from 10.0.20.20: icmp_seq=47 ttl=64 time=75.768 ms
64 bytes from 10.0.20.20: icmp_seq=48 ttl=64 time=94.767 ms
64 bytes from 10.0.20.20: icmp_seq=49 ttl=64 time=2.762 ms
64 bytes from 10.0.20.20: icmp_seq=50 ttl=64 time=36.254 ms
64 bytes from 10.0.20.20: icmp_seq=51 ttl=64 time=55.374 ms
Request timeout for icmp_seq 52           <<<<<---- da ist es in Standby gegangen
Request timeout for icmp_seq 53
Request timeout for icmp_seq 54
Request timeout for icmp_seq 55
Request timeout for icmp_seq 56
Request timeout for icmp_seq 57
Request timeout for icmp_seq 58