GN verliert WLAN-Signal (grauer WLAN-Empfangsbalken)

Stimmt, die ROM-Version ist hierbei nicht unwichtig: Ich habe
Stock 4.0.2 mit Tuna 10-Kernel und KK6-Baseband.

Nochmal zur leasetime: versuch sie doch mal recht kurz einzustellen. Dann kann es zwar zu Aussetzern kommen - aber es sollte eine neue Anmeldung erfolgen.
Solange das Gerät aktiv ist, läuft die Zeit ja nicht rückwärts. (Aber irgendwie haben wir jetzt 2 Threads die zusammengehören)
 
N2k1 schrieb:
Ich habe Stock 4.0.2 mit Tuna 10-Kernel und KK6-Baseband.

Dito! :)

N2k1 schrieb:
Nochmal zur leasetime: versuch sie doch mal recht kurz einzustellen. Dann kann es zwar zu Aussetzern kommen - aber es sollte eine neue Anmeldung erfolgen.

Auf diese Idee bin ich gar nicht gekommen, sondern habe sie nur deutlich verlängert. ABER: in diesem Fall kann ich ein Problem mit der Lease-Time nahezu ausschließen, weil ichs ja auch mit statischer IP (die ja nicht abläuft) auf dem SGN versucht habe und das am Problem nichts geändert hat.

N2k1 schrieb:
Solange das Gerät aktiv ist, läuft die Zeit ja nicht rückwärts.

Wie das?! Auch wenns jetzt OT ist, aber die Lease-Time wird doch dem Client vom DHCP-Server bei der IP-Zuteilung "mitgegeben". Ab diesem Zeitpunkt beginnt diese roch rückwärts zu laufen. Egal ob der Client aktiv oder inaktiv ist?!

N2k1 schrieb:
Aber irgendwie haben wir jetzt 2 Threads die zusammengehören

Stimmt! Das ist etwas durcheinander geraten. Hier solls aber eigentlich nur darum gehen, dass das SGN die Verbindung zum WLAN verliert (so wie im Titel bzw. Eingangspost!). ;-) Die Sache mit dem SGN im WDS wird hier behandelt.

Zurück zum Thema:

Gestern Abend wollte ich eine andere Firmware auf den W500V spielen, was aber schief gegangen ist. War wohl das falsche Image! :-( Da der W500V jedoch noch ein für den Notfall erreichbares Webinterface hat, war es kein Problem die Bitswitcher-Firmware wieder zurückzuspielen. ;-)

Interessanterweise gibts seitdem keine Verbindungabbrüche zum SGN mehr! Leider kann ich nicht genau sagen, warum das so ist und hoffe nur, dass es so bleibt. Wenns so bleibt, kann ich drei Mal auf Holz klopfen. Hier meine Vorgehensweise, wodurch das Problem (zumindest bis zum jetzigen Zeitpunkt) gelöst wurde:

- SSID eingeschaltet!

- Im Bitswitcher-Menü die Konfiguration gesichert!

- Im Bitswitcher-Menü unter Administration->JFFS2 and mini_fo "Erase JFFS2 Partition" und "Erase mini_fo" angehakt, anschließend Save und dann Reboot!

- Anschließend die Bitswitcher-Firmware "frisch" über das Notfall-Webinterface eingespielt. Dabei wird der Router ausgeschaltet, der Reset-Knopf gedrückt und gehalten und dann der Router eingeschaltet. Der Reset-Knopf bleibt gedrückt bis die Power-LED dauerhaft rot leuchtet (ca. 10 Sek.). Anschließend ist das Webinterface über einen am Ethernet angeschlossenen Rechner unter 192.168.1.1 erreichbar. DORT habe ich die Bitswitcher-Firmware (0.3.9) geflasht.

- Dann wurde die Konfiguration wieder zurückgespielt und anschließend habe ich den Router noch mal neu gestartet.
 
Nachdem das Problem nach meiner letzten "Anleitung" heute morgen wieder auftrat, ist alles wieder wie vorher. :-(

Das Desire HD habe ich übers Wochenende noch mal beobachtet und konnte dabei feststellen, dass es sich wie folgt verhält:

- Wenn die "beste WLAN-Leistung" aktiviert ist, gibts keinerlei Probleme. Das Handy ist auch im StandBy jederzeit im WLAN auch auch von anderen Clients jederzeit anpingbar.

- Wenn die "beste WLAN-Leistung" deaktiviert ist, verhält es sich ähnlich wie das Galaxy Nexus (wo es diese Option bei ICS ja nicht mehr gibt). Es ist dann ebenfalls im StandBy nicht mehr anpingbar, wobei das ab und zu doch noch funktioniert.

Ich habs mit dem Galaxy Nexus jetzt noch mal getestet:

- Verbindung mit dem WLAN klappt zunächst einwandfrei
- Zunächst auch im StandBy (egal ob durch TimeOut oder Power-Taster) mit dem WLAN verbunden und anpingbar!
- Handy nach ca. 10 Minuten nicht mehr anpingbar.
Antwort des Pings: "Zeitüberschreitung der Anforderung"
- Im WLAN-Status Menü des Routers steht das Handy noch als Verbunden.
- Ping erst wieder erfolgreich wenn Handy aus StandBy geholt wird. Sobald dann wieder in StandBy versetzt, ebenfalls wieder die Antwort "Zeitüberschreitung der Anforderung".
- nach ca. weiteren 10 Minuten im StandBy Pingantwort "Anwort von 192.168.1.5: Zielhost nicht erreichbar." (wobei 192.168.1.5 die IP des pingabsetzenden Clients ist).
- Im WLAN-Status Menü des Routers steht das Handy nicht(!) mehr als Verbunden.

Beim Desire HD ist das Ganze (mit abgeschalteter "bester WLAN-Leistung") ähnlich, wobei das aber manchmal nach 2.3 erfolglosen Pings wieder "erwacht" und wieder erreichbar ist.

N2k1 schrieb:
Mach mal bitte nochmal ein komplettes logcat (ohne -b radio).

Hab ich dir zukommen lassen!
 
Da meine Mails an Dich nicht rausgehen, schreibe ich es eben für alle ;-)

Nachdem ich gerade eine "satte Störung" hatte, wo selbst 2 von 3 Rechnern keine der 3 Boxen erreichen konnten, war mein Telefon mit dem Router des Nachbarn verbunden (ja, wir kennen gegenseitig den WPA2-Code).
Obwohl das SGN nun wieder mit meiner Box verbunden ist, ist ein Ping nicht möglich.
Aber erst, seit ich Beautiful Widgets installiert habe. Sollte da ein Zusammenhang bestehen?
Davor war es so, daß wenn das SGN eingeschlafen war erst beim 2. Versuch geantwortet wurde - aber im Moment ist mein telefon zwar verbunden (Browser, Mail etc. funktioniert) aber ein Ping ist nicht möglich.
Im Terminal des SGN funktioniert der Ping sowohl auf das eigene device als auch auf die Router oder Rechner im Netz.
 
N2k1 schrieb:
D
a meine Mails an Dich nicht rausgehen, schreibe ich es eben für alle ;-)

Komisch! ;-)

N2k1 schrieb:
D
Obwohl das SGN nun wieder mit meiner Box verbunden ist, ist ein Ping nicht möglich. Aber erst, seit ich Beautiful Widgets installiert habe. Sollte da ein Zusammenhang bestehen?

Sagen wirs mal so: ich habe auch Beautiful Widgets installiert (die kostenlose Version von getjar) und benutze es als Live-Wallpaper. Ich wüsste jetzt nicht, was das mit dem WLAN zu tun haben sollte, aber wenn du das beobachtet hast, sollte mans zumindest mal in Betracht ziehen. Deshalb habe ich jetzt, bevor ich Beautiful Widgets komplett deinstalliere, erstmal dessen Live-Wallpaper deaktiviert. EDIT: Alleine die Deaktivierung des Beautiful Widgets Live-Wallpapers (mit anschließendem Neustart des Handys) hat rein gar nichts gebracht. Also müsste ich Beautiful Widgets komplett deinstallieren um zu überprüfen, ob es einen Zusammenhang damit gibt.

N2k1 schrieb:
Davor war es so, daß wenn das SGN eingeschlafen war erst beim 2. Versuch geantwortet wurde...

Das kann ich noch halbwegs nachvollziehen. Wenn das SGN in einen Deep-Sleep geht und dann den ersten Ping evtl. zum "Aufwachen" braucht.

N2k1 schrieb:
D
- aber im Moment ist mein telefon zwar verbunden (Browser, Mail etc. funktioniert) aber ein Ping ist nicht möglich.

DAS finde ich sehr seltsam! Wenn du browsen kannst, sollte das Handy doch auch auf Pings antworten?!
 
Zuletzt bearbeitet:
Telefon neu gestartet - da ich ohnehin mal mit dem 4.0.4-OTA-Update spielen wollte - und der Fehler ist nicht reproduzierbar.
Nach einer Stunde "Tiefschlaf" sieht es bei mir dann so aus:

Ping wird ausgeführt für 10.100.1.29 mit 32 Bytes Daten:
Antwort von 10.100.1.33: Zielhost nicht erreichbar.
Zeitüberschreitung der Anforderung.
Antwort von 10.100.1.29: Bytes=32 Zeit=7ms TTL=64
Antwort von 10.100.1.29: Bytes=32 Zeit=988ms TTL=64
Ping-Statistik für 10.100.1.29:
Pakete: Gesendet = 4, Empfangen = 3, Verloren = 1
(25% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 7ms, Maximum = 988ms, Mittelwert = 497ms

Dabei hat das Telefon die 10.100.1.29 und der rechner die 10.100.1.33
 
Wenn ich mit das Ping-Protokoll anschaue, kamen doch nur zwei Pings an und nicht drei?!

Mit dem Zusatz -t kannst du übrigens durchgängig pingen (und mit STRG+C abbrechen). Manchmal vereinfacht das die Sache etwas. Aber wenn das Handy im Tiefschlaf war, kann ich mir gut vorstellen, dass es erstmal 1-2 "Pings" braucht um aufzuwachen.

Genau das macht aber mein SGN nicht! :-( Weder wenn da zunächst nur "Zeitüberschreitung der Anforderung" steht, noch wenn nach einer weiteren Zeit "Antwort von <Rechner-IP>: Zielhost nicht erreichbar." kommt. :-/
 
Das hatte mich auch gewundert (die Anzahl) - aber es ist immer einer zu viel unten in der Ansicht.
Mit -n kann man ja auch sagen, wie oft angepingt wird.

>ping 10.100.1.29 -n 8
Ping wird ausgeführt für 10.100.1.29 mit 32 Bytes Daten:
Antwort von 10.100.1.33: Zielhost nicht erreichbar.
Antwort von 10.100.1.29: Bytes=32 Zeit=2051ms TTL=64
Antwort von 10.100.1.29: Bytes=32 Zeit=918ms TTL=64
Antwort von 10.100.1.29: Bytes=32 Zeit=833ms TTL=64
Antwort von 10.100.1.29: Bytes=32 Zeit=753ms TTL=64
Antwort von 10.100.1.29: Bytes=32 Zeit=671ms TTL=64
Antwort von 10.100.1.29: Bytes=32 Zeit=532ms TTL=64
Antwort von 10.100.1.29: Bytes=32 Zeit=451ms TTL=64
Ping-Statistik für 10.100.1.29:
Pakete: Gesendet = 8, Empfangen = 8, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 451ms, Maximum = 2051ms, Mittelwert = 887ms

Der einzige Unterschied unserer Geräte scheint ja im Kernel zu liegen - vielleicht solltest Du ein backup machen und den Tuna-Kernel mal installieren?!
 
N2k1 schrieb:
... es ist immer einer zu viel unten in der Ansicht.

Eine Vermutung meinerseits: "Antwort von 10.100.1.33: Zielhost nicht erreichbar." wird mitgezählt, weil es ja eine "Antwort" ist. Auch wenn diese nicht vom angepingten SGN, sondern vom eigenen Rechner kommt. "Zeitüberschreitung der Anforderung." heisst dagegen "keine Antwort" (innerhalb der vorgegebenen Zeit) und wird deshalb nicht mitgezählt.

Deine jetzt aufgezeigte "Ping-Reihe" zeigt wieder, dass der erste Ping scheinbar immer zum "Aufwecken" verwendet wird. Zumindest würde ich das zum jetzigen Zeitpunkt so deuten.

N2k1 schrieb:
Der einzige Unterschied unserer Geräte scheint ja im Kernel zu liegen - vielleicht solltest Du ein backup machen und den Tuna-Kernel mal installieren?!

Ja, der Kernel ist unterschiedlich, aber sicher auch die installierten Apps. Gestern habe ich noch mal drüber geschaut, welche Apps ich installiert habe, die das WLAN (auf den ersten Blick) beeinflussen könnten. Da ist mir aufgefallen, dass ich noch WiFi Advanced Configurator installiert hatte und irgendwann auch mal benutzt habe. Diesen habe ich gestern deinstalliert (in der Beschreibung steht auch, dass die APP noch nicht für ICS geeignet ist)! Trotzdem wäre es ja denkbar, dass diese APP irgendwelche WLAN- oder Sleep-Einstellungen verbogen hat. :-/ Energiemanager oder sowas in der Art habe ich allerdings nicht installiert!

Da ich erst wieder am Wochenende zum Testen komme, habe ich Zeit bis dahin mal einen Wipe des Handys zu machen und zu hoffen, dass das was bringt.

Mein Handy wurde via OTA von 4.0.1 auf 4.0.2 aktualisiert. Ist dann nach dem Zurücksetzen auf die Werkseinstellungen 4.0.2 automatisch drauf oder muss ich dann das OTA wieder durchführen? Evtl. wäre es auch sinnvoll 4.0.2 als komplett-Image zu flashen?!
 
Ich klinke mich auch mal ein: Habe mich heute mit dem Uni WLAN verbunden und seitdem war sowohl die WLAN Anzeige als auch sie Netzanzeige grau...Aber voller Empfang...Als ich mich vom WLAN wieder getrennt hab war alles wieder normal grau...jemand eine Idee?

Gesendet mit der Android-Hilfe.de-App
 
Erstens schreibst du überhaupt nichts zu deinem Uni-WLAN und zweitens ist die Bedeutung der grauen Anzeige längst geklärt. ;-)

@N2k1: Mein Galaxy Nexus macht im WLAN mit dem Linksys-Router im StandBy genau das Gleiche wie deins. Beim ersten Ping gibts "Antwort von <Rechner-IP>: Zielhost nicht erreichbar, die darauf folgenden Pings klappen. :) Also alles prima!

Komisch nur, warum das im WLAN mit dem anderen Router nicht so ist!
 
Ich hatte ähnliche Probleme mit einem Samsung Galaxy, hab dann in den Einstellungen meiner Fritzbox die Unterstützung für ältere Geräte mit dem b-Standard ausgeschaltet.
Seitdem ist die WLAN-Verbindung stabil.
(Einstellung WLan-Standard steht jetzt auf 802.11n+g, Defauleinstellung ist n+g+b)
 
Daran liegts bei mir nicht! Ist ein reines G-Netzwerk...
 
Ich verwende das Nexus auch mit einem Linksys Router WRT54GL in Original-SW. Anfangs hatte ich zu wenige DHCP Adressen freigegeben. Nach Korrektur funktioniert alles bestens, auch SSID verstecken, Mac-Adressen usw. Die Anzeige ist immer blau, sobald ich in der Nähe des Routers bin. Dasselbe im Uni-Netz.

Grafiker
 
Hallo zusammen,

ich glaube, das "immer an" im Standby Modus ist nicht richtig. Ich hatte auch ständig Probleme, dass trotz aktiviertem WLAN keine Verbindung da war und hatte auch auf "immer an" eingestellt gehabt. Nun habe ich gestern umgestellt auf "Nie (erhöht den Datenverbrauch)" und siehe da, seitdem keinerlei Probleme mehr. Ich habe gestern abend und auch heute mehrmals über den Tag verteilt in verschienen Räumen WLAN aktiviert und alles läuft einwandfrei.
 
Na wenn du "Nie" machst, dann schaltet sich WLan automatisch ab wenn der Bildschirm aus ist. Wenn du dann wieder einschaltest (den Screen) dann aktiviert er W-Lan wieder. Somit sollte es hier ohnehin keine Probleme geben.
Wenn dagegen die WLan Verbindung ständig aktiviert ist, dann passiert das beschriebene Problem.
 
briddel36 schrieb:
Hallo zusammen,

ich glaube, das "immer an" im Standby Modus ist nicht richtig. Ich hatte auch ständig Probleme, dass trotz aktiviertem WLAN keine Verbindung da war und hatte auch auf "immer an" eingestellt gehabt. Nun habe ich gestern umgestellt auf "Nie (erhöht den Datenverbrauch)" und siehe da, seitdem keinerlei Probleme mehr. Ich habe gestern abend und auch heute mehrmals über den Tag verteilt in verschienen Räumen WLAN aktiviert und alles läuft einwandfrei.

Mal abgesehen davon, daß es hier um etwas anderes ging, hast Diu doch auch hier geschrieben?!
https://www.android-hilfe.de/forum/...richt-im-stand-by-ab.208776.html#post-3265195
 
Ich häng mich mal hier ran...

Habe seit heute das Nexus und schon auf ICS 4.0.4 aktualisiert. Bei mir bleibt das WLAN-Symbol aktiv, wenn ich das Nexus in den Standby schicke. Aber ich möchte gern zum Daten übertragen AirDroid nutzen. Das Problem bei der Sache: sobald das Display ausgeht, kann ich mit AirDroid nicht mehr auf das Nexus zugreifen. Aktiviere ich das Display wieder, dann geht es sofort. Auch Downloads und Radiostreams (z.B. mit TuneinRadio) brechen ab, sobald das Display ausgeht. Die Option steht auf "Nie", also sollte das WLAN im Standby NIE deaktiviert werden.

Den gleichen Fehler hatte ich schon mal beim Xoom mit einer Nightly von TeamEOS (ebenfalls ICS). Aber da wurde das Problem mit der letzten stabilen Version gefixt.

Gibt es für das Nexus auch eine Lösung oder muss ich rooten und ein Custom ROM flashen? :winki:
 
Zuletzt bearbeitet von einem Moderator:
"NIE" bedeutet, dass er vom wlan wechselt und dein datenverbrauch erhöht wird.

du musst auf "immer" stellen
 
Sorry, mein Fehler. Die Option steht bereits auf "immer". Trotzdem unterbrechen Downloads und Streams, wenn das Display ausgeht. Aber mit "nie" hatte ich es auch schon getestet...

Gesendet von meinem Galaxy Nexus mit der Android-Hilfe.de App
 

Ähnliche Themen

Schotti
  • Schotti
Antworten
7
Aufrufe
3.224
schnueppi
schnueppi
T
Antworten
6
Aufrufe
2.409
Klarooo
Klarooo
jigga1986
  • jigga1986
Antworten
0
Aufrufe
1.791
jigga1986
jigga1986
Zurück
Oben Unten