Kein automatischer WIFI Reconnect

Hallo,

kann jm. das folgende Verhalten beim Wifi Modul bestätigen:

• WIFI-Modul verbindet sich korrekt mit meinem WLAN-Router
  
• Status LED leuchtet dauerhaft, Sensor Abfragen sind möglich
  
• WLAN-Router wird abgeschaltet (z.B. über Nacht), WIFI bleibt aktiv
  
• WLAN-Router wird wieder eingeschaltet
  
• WIFI-Modul verbindet sich nicht mehr und bleibt dauerhaft im Modus "associating" mit blinkender Status LED
  

Es muss zuerst ein Reset durchgeführt werden, bevor die Verbindung wieder korrekt hergestellt wird (was z.B. bei Montage in einer Wetterstation denkbar unpraktisch ist).

--Markus

Also ich kann schon mal auf die Schnelle bestätigen, dass mein WLAN-Stack nach längerer Laufzeit (>2 Tage) nicht mehr erreichbar war.

Ich werde diese Woche da noch mal einen gezielten Test durchführen (jetzt auch mit der 1.3.3-Master-Firmware). Aber das mit dem fehlenden Reconnect könnte sein (zumindest unter bestimmten Bedingungen).

Seit 1.3.3 wird ein Direct-WIFI oder Adhoc Modus unterstützt, d.h. der Router ist dazwischen obsolet, probiert doch mal diesen Modus aus und schreibt ob es hilft.

Ich befürchte das ist nicht für alle eine Option ^^

Ich würde aber sagen, dass im AP-Modus nur der Client (also der PC/das Smartphone) fürs Reconnecten verantwortlich ist, automagischer Reconnect seitens Binding ist aber meines Wissens nur in Python im Github implementiert.

Wir haben hier seit heute morgen einen WIFI Stack im Dauertest am laufen, bisher hat er sich noch nicht aufgehängt. Ich schreib mehr dazu sobald wir das reproduzieren konnten, wenn da ein Fehler im reassociating Code ist sollte das eigentlich leicht auffindbar sein.

Wenn die Verbindung zum AP für kurze Zeit verschwindet, und ein reconnect stattfinden muss ist es immer kritisch. Dann kann es passieren dass die Socket-Verbindung geschlossen wird. Im Moment muss dann ein neues Enumerate stattfinden.

Dafür wird es morgen neue Bindings geben, die nach einem Verlust der Socket-Verbindung versuchen sich wieder zu verbinden um so ein weiterlaufen zu erlauben (ohne neues Enumerate!). Das sollte die ganze Sache schon viel robuster machen.

die Idee mit dem Ad-Hoc Modus ist für mich leider keine Option, da hier nur WEP zur Option steht. Ausserdem soll sich mein Router um die Abfrage der Sensoren kümmern.

Ein erster Test zeigte, dass die Verbindung nach einem kurzen Ausfall des Access Points wieder korrekt aufgebaut wurde (Probe Request/ Response) waren im Wireshark auch zu sehen. Könnte das Problem u.a. mit der Dauer der Ausfallzeit des Access Point zusammenhängen?

Was mir auch noch aufgefallen ist:

Verwendet der Access Point einen Höheren Frequenzbereich (2,472 GHz) finded auch nach einem Reset kein Verbindungsaufbau mehr statt. Könnte das evtl. damit zusammenhängen, dass das WLAN-Modul nur die USA-Typischen Kanäle 1-11 (bis 2,462 GHz) unterstützt?

Verwendet der Access Point einen Höheren Frequenzbereich (2,472 GHz) finded auch nach einem Reset kein Verbindungsaufbau mehr statt. Könnte das evtl. damit zusammenhängen, dass das WLAN-Modul nur die USA-Typischen Kanäle 1-11 (bis 2,462 GHz) unterstützt?

Oh, kann das Probleme machen? Das könnte ich umstellbar machen (oder einfach fest auf die vollen Kanäle stellen, muss ich mich nochmal informieren wie das rechtlich ist).

Edit: Neue Master Version ist da, neue Brick Viewer Version folgt im laufe des Tages.

@borg: Auch nach dem Firmwareupdate lässt sich das "Reconnect-Problem" bei mir wie folgt reproduzieren:

• Master mit WIFI-Modul verbindet sich korrekt mit dem Router (Status: "Associated") - alles OK
  
• WLAN wird für einen längeren Zeitraum (mehrere Stunden) abgeschaltet, Bricks bleiben jedoch aktiv (Status LED blinkt "Associating") - soweit auch noch klar
  
• Nach erneutem aktivieren des WLANs am Router wird die Verbindung nicht wieder aufgebaut (Status LED blinkt noch immer) - Verbindung wird auch nach lägerer Verfügbarkeit des WLANs nicht wieder aufgebaut
  

Interessant, hab ich so noch nicht getestet. Probiere ich gleich mal aus!

Hat ausser mir jm. auch noch das "Reconnect Problem"?

@borg: Konntest Du das Problem bei Deinen Tests nachvollziehen?

Würde meine geplante Wetterstation nur ungern in ein Gehäuse einbauen, bevor es eine Lösung gibt, ansonsten wird es schwierig an den Reset-Button zu kommen :-)

Entschuldigung, ich wollte mich gerade melden, da ich vorher noch keine Zeit hatte, aber den Thread schon laenger verfolge. 

Ja, ist bei mir genauso. Nach gewisser Zeit, sagen wir mal 1 Stunde, ohne Accesspoint, kann sich die WLAN Extension micht mehr an den AP anmelden. Die gruene LED blinkt permanent weiter. Ein Reset hilft, aber das ist keine Loesung wenn die Hardware "remote" genutzt wird.

Wenn das Problem nicht schnell zu finden ist oder gar in der FW des WLAN Moduls liegt, koennte ich mir folgendes vorstellen, da er in der FW des Masterbrick untergebracht werden koennte:

Wenn NUR die WLAN Extension angeschlossen ist (kein USB) und sich nach 10 Minuten kein Connect ergeben hat, dass fuehre einen Stack-Reset durch.

Ein Reset wuerde zwar dann auch bei fehlerhafter Config (z.B. falsche SSID) gemacht, aber das waere wohl zu verschmerzen.

nicht huebsch, wuerde aber erstmal helfen.

Der Loetkolben

Hallo ich möchte mal kurz eine Anmerkung machen ich betreibe meinen WiFi Brick im AdHoc Modus und verwende Windows 7. Unter Drahtlosverbindungen erscheint das Thinkerforge "Netzwerk" unter einen anderen Symbol und auch nur als "öffentliches Netz" was sich beides nicht ändenr lässt. Zusätzlich lässt sich das Passwort nicht speichern und nicht automatisch anmelden wählen.

Wie lässt sich dieses Problem beheben?

Ziel wäre es das Passwort zu speichern Automatisch anmelden zu aktivieren (Windows seitig) und daraus ein Privates Netz machen...

Bin gerade bei dem reconnect Problem dabei, mir ist im Moment noch unklar warum er irgendwann aufhört sich wieder zu verbinden. Ich kann es aber reproduzieren.

Ist halt eine langwierige Geschichte, ich muss nach jeder Änderung erst ne halbe Stunde warten .

Ist halt eine langwierige Geschichte, ich muss nach jeder Änderung erst ne halbe Stunde warten

http://kaffeejunkies.org/

Der Loetkolben

Ist halt eine langwierige Geschichte, ich muss nach jeder Änderung erst ne halbe Stunde warten

Einfach 30 Versuche paralell laufen lassen, so bekommst alle Minute ein Ergenbis.

Worum genau das reassociating nicht funktioniert konnte ich leider nicht ausfindig machen, das GS1011 antwortet einfach nach einer Zeit gar nicht mehr wenn sehr viele Verbindungsversuche stattgefunden haben.

Ich hab jetzt in 1.3.5 einfach eingebaut, dass ein komplettes Reset des WLAN Moduls ausgeführt wird wenn es mir für 3 Minuten nicht auf eine Anfrage geantwortet hat. D.h. ihr müsst nach einer langen Auszeit des AP bis zu 3 Minuten warten bis die Verbindung wieder aufgebaut wird.

Hallo borg,

erstmal vielen Dank fuer den schnellen Workaround! 

Damit kann man den Stack auch "remote" laufen lassen.

Kann ich igendwie erkennen, dass das Modul gerade geresettet wird?

Bei mir leuchtet das Masterbrick huebsch blau. Die WLAN Extension hat die blaue LED an und die gruene LED faengt kurze Zeit nach abschalten des AP an zu blinken. So bleibt es.

Edit: Zusatzfrage: Hat jemand rausgefunden wie lange es dauert bis sich das WLAN Modul aufhaengt?

Der Loetkolben

Besten Dank für den schnellen Workaround! Werde mich gleich dran machen und die  1.3.5 testen.

Hallo ich möchte mal kurz eine Anmerkung machen ich betreibe meinen WiFi Brick im AdHoc Modus und verwende Windows 7. Unter Drahtlosverbindungen erscheint das Thinkerforge "Netzwerk" unter einen anderen Symbol und auch nur als "öffentliches Netz" was sich beides nicht ändenr lässt. Zusätzlich lässt sich das Passwort nicht speichern und nicht automatisch anmelden wählen.

Wie lässt sich dieses Problem beheben?

 

Ziel wäre es das Passwort zu speichern Automatisch anmelden zu aktivieren (Windows seitig) und daraus ein Privates Netz machen...

Kannst du das nochmal mit Master Brick Firmware Version 1.4.3 probieren? Ich befürchte der AP Modus wurde nie richtig konfiguriert, weil da eine Verwechselung in den defines war .

https://github.com/Tinkerforge/master-brick/commit/2941a7062052e62a0817ad87098c213c0172dba5

Hallo,

also ich kann das Problem reproduzieren und kämpfe schon seit langem damit.

Meiner Erfahrung nach hat es nichts mit dem Verbindungsmodus (AdHock, Router) zu tun sondern nur mit der Qualität der Verbindung.

D.h. wenn ich Router und Brick nur 1m entfernt sind, klappt es 'dauerhaft' gut. Wenn z.B. eine Wand und/oder 6-8m dazwischen sind, tritt das problem relativ schnell auf. Um wieder eine Verbindung zu bekommen hilft nur ein Reset.

Der weiter oben angesprochene automatische reconnect nach 3minuten klappt ebenfalls nicht.

Firmware ist aktuell.

Zum Testen lese ich von einem IMU alle 10ms Werte.

Was kann ich tun?

Danke

Ralf

Ich kann das leider nicht reproduzieren.

Meine Vorgehensweise: Ich stelle eine Verbindung her, öffne Brick Viewer und schaue mir eingehende Daten an (bin ein Raum neben dem AP). Dann schraube ich die Antenne ab und warte bis die grüne LED der WIFI Extension das blinken anfängt (das bedeutet sie versucht sich zu verbinden).

Jetzt bekomme ich natürlich im Brick Viewer Timeouts und keine neuen Daten mehr.

Dann schraube ich die Antenne wieder an, danach dauert es noch einen Moment bis der Socket merkt das er nicht mehr aktiv ist, es wird eine neue Verbindung aufgebaut und ich kann wieder eingehende Daten im Brick Viewer sehen.

Ich betreibe das im Moment mit dem neuen Protokoll, ich meine aber das damals auch mit dem alten Protokoll genauso getestet zu haben.

Hallo,

bei mir verhält sich das etwas anders:

Wenn ich die Antenne abschraube blinkt die grüne LED (nach einiger Zeit) nicht.

Die Verbindung ist allerdings "kaputt" und ich bekomme keine Daten.

Nachdem ich die Antenne wieder dran schraube (und > 3min warte) kann ich nur wieder durch Reset eine Verbindung wieder herstellen.

Danke

Dazu hab ich einen kleinen Versuch.

@borg

Lass auf deinen Brick einfach nur eine Temperaturabfrage laufen die ständig (jede sekunde, jede 100ms) die Werte ausliest.

Dann nimmst du einen anderen Rechner und für ein enum auf diesen aus.

Bei mir friert der Stack dann immer ein, die WiFi LED leuchtet ständig grün aber der Stack ist "tot". Ich weiß nicht ob das ein ähnliches Problem ist.

Gruß

P.S.: Mein Programm liest die Temperatur von Stapel aus und schreibt sie auf ein LCD20x4 am gleichen Stapel.

Hallo,

kann das verhalten beim Timeout wie von 'borg' beschrieben nun doch nachvollziehen.

Ein paar mal klappt das Wiederaufnehmen der Verbindung, die grüne LED leuchtet aber immer dauerhaft.

Wenn allerdings ein Timeout "öfter hintereinander" auftritt hängt sich die WIFI Extention dann doch auf und es hilft nur ein Reset.

Gruß - Ralf

konnte das Problem ebenfalls schon nachvollziehen. Bei mir trat das Problem beim Debuggen eines Programms auf, d.h. sofern die "IPConnection" zwar aufgebaut aber nicht wieder korrekt freigegeben wurde. Nach ein paar aufgebauten und nicht freigegebenen IPConnections war eine Verbindung erst wieder nach einem Reset möglich.

@borg: Könnten mehrere nicht freigegebene IPConnection-Objekte zu dem Problem führen? Ein IPConnection Objekt könnte ebenfalls nicht freigegeben werden, wenn aufgrund einer schlechten Verbindung keine Kommunikation mit dem Stack mehr möglich ist.