FRITZ!Box 7490 Firmware 113.06.60 vom 06.07.2016

PeterPawn · 18 Nov 2016

Dann wäre wohl als nächstes zu klären, ob das "Deauthentication"-Paket Ursache oder Wirkung des Problems ist. Wenn das nur das Ergebnis einer fehlenden Rückmeldung des STA sein sollte und der AP sendet es nur "der Ordnung halber", obwohl er schon gar nicht mehr an den Empfang glaubt, dann sähe das ja auch nicht anders aus.

Vielleicht kriegt man ja aus dem Mitschnitt auf anderen Ebenen (aber immer noch auf der "Hardware-Seite" eines WLAN-Interfaces) auch noch heraus, was dem "Deauthentication" vorausgeht. Da sehe ich in einem Falle ein "Disassociate" (auch mehrfach, also zweimal zumindest) und im anderen Fall keines. Beim "Disassociate" darf man vermutlich den AP als "Rausschmeißer" ansehen - bei reinem "Deauthentication" würde ich ein "pro forma"-Invalidieren des TK für denkbar halten.

rst-cologne · 18 Nov 2016

Irgendeine Rückmeldung ist z.b. von den anderen Geräten in diesem Mitschnitt nicht zu erkennen. Wenn, dann hat die passende Frage dazu auf einer anderen Ebene statt gefunden.

Ein Disassociate geht bei mir auch manchmal einem Deauthentification vorraus, ist aber eher die Ausnahme. Vielleicht kann man auch auf der Android Seite ansetzten. Gibt es dort Apps zum mitschneiden des kompletten (!) WLAN Verkehrs?

meierchen006 · 18 Nov 2016

Hallo,

nun habe ich auch mal solch einen Mitschnitt gemacht:

PHP:

No	Time           Source	     Destination	Protocol	Length	Info
2	0000.000321	AvmAudio	LenovoMo	EAPOL	165	Key (Group Message 1 of 2)
7	0000.493701	LenovoMo	AvmAudio	EAPOL	133	Key (Group Message 2 of 2)
10	0600.010339	AvmAudio	LenovoMo	EAPOL	165	Key (Group Message 1 of 2)
16	0601.011282	AvmAudio	LenovoMo	EAPOL	165	Key (Group Message 1 of 2)
17	0602.011691	AvmAudio	LenovoMo	EAPOL	165	Key (Group Message 1 of 2)
18	0602.401408	LenovoMo	AvmAudio	EAPOL	133	Key (Group Message 2 of 2)
19	0602.401690	LenovoMo	AvmAudio	EAPOL	133	Key (Group Message 2 of 2)
23	1200.012462	AvmAudio	LenovoMo	EAPOL	165	Key (Group Message 1 of 2)
28	1200.312137	LenovoMo	AvmAudio	EAPOL	133	Key (Group Message 2 of 2)
30	1486.890192	AvmAudio	LenovoMo	802.11	26	Disassociate, SN=303, FN=0, Flags=........
31	1486.895891	AvmAudio	LenovoMo	802.11	26	Deauthentication, SN=256, FN=0, Flags=........
32	1487.756636	LenovoMo	AvmAudio	802.11	30	Authentication, SN=3636, FN=0, Flags=........
33	1487.758260	AvmAudio	LenovoMo	802.11	30	Authentication, SN=256, FN=0, Flags=........
34	1487.765627	LenovoMo	AvmAudio	802.11	115	Association Request, SN=3637, FN=0, Flags=........, SSID=
35	1487.768975	AvmAudio	LenovoMo	802.11	134	Association Response, SN=258, FN=0, Flags=........
36	1487.772179	AvmAudio	LenovoMo	EAPOL	133	Key (Message 1 of 4)
37	1487.784472	LenovoMo	AvmAudio	EAPOL	155	Key (Message 2 of 4)
38	1487.785933	AvmAudio	LenovoMo	EAPOL	189	Key (Message 3 of 4)
39	1487.796538	LenovoMo	AvmAudio	EAPOL	133	Key (Message 4 of 4)
40	1487.985892	AvmAudio	LenovoMo	802.11	33	Action, SN=259, FN=0, Flags=........
41	1487.987363	LenovoMo	AvmAudio	802.11	33	Action, SN=3638, FN=0, Flags=........
42	1489.331427	LenovoMo	AvmAudio	802.11	33	Action, SN=3639, FN=0, Flags=........
43	1489.331572	AvmAudio	LenovoMo	802.11	33	Action, SN=260, FN=0, Flags=........
44	1730.922588	AvmAudio	LenovoMo	802.11	26	Disassociate, SN=267, FN=0, Flags=........
45	1730.922791	AvmAudio	LenovoMo	802.11	26	Deauthentication, SN=256, FN=0, Flags=........
46	1731.631010	LenovoMo	AvmAudio	802.11	30	Authentication, SN=3729, FN=0, Flags=........
47	1731.632667	AvmAudio	LenovoMo	802.11	30	Authentication, SN=256, FN=0, Flags=........
48	1731.640077	LenovoMo	AvmAudio	802.11	115	Association Request, SN=3730, FN=0, Flags=........, SSID=
49	1731.641468	AvmAudio	LenovoMo	802.11	134	Association Response, SN=258, FN=0, Flags=........
50	1731.644275	AvmAudio	LenovoMo	EAPOL	133	Key (Message 1 of 4)
51	1731.657984	LenovoMo	AvmAudio	EAPOL	155	Key (Message 2 of 4)
52	1731.659691	AvmAudio	LenovoMo	EAPOL	189	Key (Message 3 of 4)
53	1731.670264	LenovoMo	AvmAudio	EAPOL	133	Key (Message 4 of 4)
54	1731.806901	AvmAudio	LenovoMo	802.11	33	Action, SN=259, FN=0, Flags=........
55	1731.808355	LenovoMo	AvmAudio	802.11	33	Action, SN=3731, FN=0, Flags=........
56	1732.985693	LenovoMo	AvmAudio	802.11	33	Action, SN=3732, FN=0, Flags=........
57	1732.985872	AvmAudio	LenovoMo	802.11	33	Action, SN=260, FN=0, Flags=........
58	1800.019974	AvmAudio	LenovoMo	EAPOL	165	Key (Group Message 1 of 2)
64	1800.603283	LenovoMo	AvmAudio	EAPOL	133	Key (Group Message 2 of 2)
66	2148.424372	AvmAudio	LenovoMo	802.11	26	Disassociate, SN=267, FN=0, Flags=........
67	2150.937435	AvmAudio	LenovoMo	802.11	26	Deauthentication, SN=256, FN=0, Flags=........
68	2151.623992	LenovoMo	AvmAudio	802.11	30	Authentication, SN=3887, FN=0, Flags=........
69	2151.625381	AvmAudio	LenovoMo	802.11	30	Authentication, SN=256, FN=0, Flags=........
70	2151.632582	LenovoMo	AvmAudio	802.11	115	Association Request, SN=3888, FN=0, Flags=........, SSID=
71	2151.634087	AvmAudio	LenovoMo	802.11	134	Association Response, SN=258, FN=0, Flags=........
72	2151.637572	AvmAudio	LenovoMo	EAPOL	133	Key (Message 1 of 4)
73	2151.649944	LenovoMo	AvmAudio	EAPOL	155	Key (Message 2 of 4)
74	2151.651379	AvmAudio	LenovoMo	EAPOL	189	Key (Message 3 of 4)
75	2151.661983	LenovoMo	AvmAudio	EAPOL	133	Key (Message 4 of 4)
76	2151.800493	AvmAudio	LenovoMo	802.11	33	Action, SN=259, FN=0, Flags=........
77	2151.802183	LenovoMo	AvmAudio	802.11	33	Action, SN=3889, FN=0, Flags=........
78	2153.137163	LenovoMo	AvmAudio	802.11	33	Action, SN=3890, FN=0, Flags=........
79	2153.137372	AvmAudio	LenovoMo	802.11	33	Action, SN=260, FN=0, Flags=........
80	2157.648252	AvmAudio	LenovoMo	802.11	33	Action, SN=261, FN=0, Flags=........
81	2157.649660	LenovoMo	AvmAudio	802.11	33	Action, SN=3891, FN=0, Flags=........
82	2400.028307	AvmAudio	LenovoMo	EAPOL	165	Key (Group Message 1 of 2)
88	2400.266210	LenovoMo	AvmAudio	EAPOL	133	Key (Group Message 2 of 2)
90	2686.816712	AvmAudio	LenovoMo	802.11	26	Disassociate, SN=285, FN=0, Flags=........
91	2686.822212	AvmAudio	LenovoMo	802.11	26	Deauthentication, SN=256, FN=0, Flags=........
92	2687.704580	LenovoMo	AvmAudio	802.11	30	Authentication, SN=39, FN=0, Flags=........
93	2687.706266	AvmAudio	LenovoMo	802.11	30	Authentication, SN=256, FN=0, Flags=........
94	2687.713759	LenovoMo	AvmAudio	802.11	115	Association Request, SN=40, FN=0, Flags=........, SSID=
95	2687.715933	AvmAudio	LenovoMo	802.11	134	Association Response, SN=258, FN=0, Flags=........

PeterPawn · 18 Nov 2016

OK, ein weiteres Beispiel mit "Disassociate" ... nun muß es ja aber einen Grund für die FRITZ!Box geben, ein solches Paket zu senden. Einfache Deauth-Attacken sollten dank 802.11w der Vergangenheit angehören und außerdem würden die Pakete dann (vermutlich) nicht von der Box selbst protokolliert, sondern höchstens vom Client. Entweder die Box ist an dieser Stelle tatsächlich buggy (warum dann nur für einige Clients - das müßte dann ein richtig zufälliger Fehler sein) oder es passiert noch etwas anderes.

Vielleicht ja ein Problem bei der Aushandlung eines neuen "~~temporary~~ temporal keys"? Das könnte dann (wenn das Limit für die damit zu übertragenden Daten erreicht ist) auch tatsächlich mitten "in der Arbeit" ein Problem werden. Ich hätte jetzt erwartet, daß dem Problem unmittelbar irgendein Kommunikationsversuch vorausgeht und dabei z.B. einer der anderen Schlüssel in so einer WLAN-Architektur (PMK, PTK oder auch der TK am Ende) durch irgendeinen falschen Speicherzugriff (zumindest teilweise) überschrieben werden und sich AP und STA deshalb nicht mehr verstehen. So wie das jetzt aussieht, muß man ja eher davon ausgehen, daß der AP irgendwann seine Schäfchen durchgeht, dabei auf ein schwarzes (abgängiges) trifft und dann beim Aufräumen vielleicht den falschen Client rauswirft - meinetwegen durch ein "off by one"-Problem oder ähnliches.

Sind die Ergebnisse der Mitschnitte eigentlich bereinigt, so daß sie nur jeweils die Kommunikation zwischen dem AP und dem betroffenen Client zeigen oder ist dazwischen tatsächlich in allen Fällen kein anderer Traffic zu irgendeinem WLAN-Client? Das erscheint mir schon recht "unüblich", daß es so gar keine andere Kommunikation geben soll - in keinem der Mitschnitte. Ein Anzeige-Filter würde das aber erklären ... daß es bei den drei "Einsendern" der Mitschnitte keine weiteren WLAN-Geräte geben soll, erscheint mir irgendwie unwahrscheinlich und dann könnte so ein "off by one"-Problem beim Aufräumen (auch wenn die Annahme reine Spekulation und nur eine Theorie ist) schon von der Art der Verwaltung der aktiven Clients und der Reihenfolge dort abhängen.

Das würde auch wieder erklären können, warum es wahlfrei verschiedene Geräte verschiedener Hersteller trifft, die bei anderen Besitzern das Problem nicht einmal im Ansatz zeigen und ggf. sogar, warum es unterschiedliche Zeitspannen gibt.

Wenn das z.B. nach MAC-Adressen verwaltet wird und das eigentliche Ziel dieses "Rauswurfs" ist mal vorhanden und mal nicht (das kann auch wieder ein "corner case" sein, der nur auftritt, wenn ein solcher Eintrag am Ende oder am Anfang so einer Liste steht oder nur noch ein einzelner nach so einem Aufräumen übrig bleibt, usw. - da gibt es tausende mögliche Randbedingungen, die das zu einem "seltenen" Ereignis machen können), dann trifft es manchmal den falschen "Nachbarn" in der Liste.

Wie gesagt - alles Spekulation und nur der Versuch einer (halbwegs logischen) Erklärung aus der Erfahrung, was es sonst noch so an Fehlerquellen beim Programmieren gibt. Um so etwas einzugrenzen oder auch nur eine Idee für einen gezielten Test zu entwickeln, braucht es dann immer "das ganze Bild", damit die Idee wie der "Phoenix" auferstehen kann. Daher meine "Neugier", ob es da wirklich so gar keinen anderen Client bei allen dreien gibt ... sogar das wäre ja eine (vermutlich recht seltene) Besonderheit, wenn es wirklich so wäre.

meierchen006 · 18 Nov 2016

Hallo PeterPawn,

klar die No. die zwischendurch fehlen sind andere Teilnehmer in meinem Wlan.

Bin gerne bereit dir meinen .eth Mitschnitt zu senden um evtl. weitere Probleme feststellen zu können.
Bitte dann eine Nachricht an mich wohin die Mail gehen soll.

Anbei mal noch vier Bilder von Frame 30 | 31 | 32 | 33

Also hier wo ich jetzt bin ist nur eine 7490 in Betrieb, als keine weitere Fritzbox oder Wlan AP bzw. Repeater in meinem Haushalt.

martinbee · 18 Nov 2016

Ja, war um einen Client bereinigt (Intel Wireless N-2230). Da gibt es aber nur action Pakete. Hier nochmal eine vollständige Sequenz disassociate bis zum Wiedereinsetzen des normalen action-Verkehrs.

Code:

[TABLE="width: 1041"]
[TR]
[TD]No.[/TD]
[TD]Time[/TD]
[TD]Source[/TD]
[TD]Destination[/TD]
[TD]Protocol[/TD]
[TD]Length[/TD]
[TD]Info[/TD]
[/TR]
[TR]
[TD]60[/TD]
[TD]208.918909[/TD]
[TD]IntelCor_da:d9:7d[/TD]
[TD]AvmAudio_5a:3b:87[/TD]
[TD]802.11[/TD]
[TD]30[/TD]
[TD]Action, SN=505, FN=0, Flags=........[/TD]
[/TR]
[TR]
[TD]61[/TD]
[TD]209.103563[/TD]
[TD]AvmAudio_5a:3b:87[/TD]
[TD]IntelCor_da:d9:7d[/TD]
[TD]802.11[/TD]
[TD]33[/TD]
[TD]Action, SN=825, FN=0, Flags=........[/TD]
[/TR]
[TR]
[TD]62[/TD]
[TD]209.105293[/TD]
[TD]IntelCor_da:d9:7d[/TD]
[TD]AvmAudio_5a:3b:87[/TD]
[TD]802.11[/TD]
[TD]33[/TD]
[TD]Action, SN=506, FN=0, Flags=........[/TD]
[/TR]
[TR]
[TD]63[/TD]
[TD]209.828991[/TD]
[TD]AvmAudio_5a:3b:87[/TD]
[TD]IntelCor_da:d9:7d[/TD]
[TD]802.11[/TD]
[TD]33[/TD]
[TD]Action, SN=826, FN=0, Flags=........[/TD]
[/TR]
[TR]
[TD]64[/TD]
[TD]209.830736[/TD]
[TD]IntelCor_da:d9:7d[/TD]
[TD]AvmAudio_5a:3b:87[/TD]
[TD]802.11[/TD]
[TD]33[/TD]
[TD]Action, SN=507, FN=0, Flags=........[/TD]
[/TR]
[TR]
[TD]65[/TD]
[TD]215.503503[/TD]
[TD]AvmAudio_5a:3b:87[/TD]
[TD]TctMobil_91:df:38[/TD]
[TD]802.11[/TD]
[TD]26[/TD]
[TD]Disassociate, SN=271, FN=0, Flags=........[/TD]
[/TR]
[TR]
[TD]66[/TD]
[TD]215.517518[/TD]
[TD]AvmAudio_5a:3b:87[/TD]
[TD]TctMobil_91:df:38[/TD]
[TD]802.11[/TD]
[TD]26[/TD]
[TD]Deauthentication, SN=256, FN=0, Flags=........[/TD]
[/TR]
[TR]
[TD]67[/TD]
[TD]216.370792[/TD]
[TD]TctMobil_91:df:38[/TD]
[TD]AvmAudio_5a:3b:87[/TD]
[TD]802.11[/TD]
[TD]30[/TD]
[TD]Authentication, SN=3710, FN=0, Flags=........[/TD]
[/TR]
[TR]
[TD]68[/TD]
[TD]216.372222[/TD]
[TD]AvmAudio_5a:3b:87[/TD]
[TD]TctMobil_91:df:38[/TD]
[TD]802.11[/TD]
[TD]30[/TD]
[TD]Authentication, SN=256, FN=0, Flags=........[/TD]
[/TR]
[TR]
[TD]69[/TD]
[TD]216.380056[/TD]
[TD]TctMobil_91:df:38[/TD]
[TD]AvmAudio_5a:3b:87[/TD]
[TD]802.11[/TD]
[TD]115[/TD]
[TD]Association Request, SN=3711, FN=0, Flags=........, SSID=meinessid[/TD]
[/TR]
[TR]
[TD]70[/TD]
[TD]216.381630[/TD]
[TD]AvmAudio_5a:3b:87[/TD]
[TD]TctMobil_91:df:38[/TD]
[TD]802.11[/TD]
[TD]134[/TD]
[TD]Association Response, SN=258, FN=0, Flags=........[/TD]
[/TR]
[TR]
[TD]71[/TD]
[TD]216.385162[/TD]
[TD]AvmAudio_5a:3b:87[/TD]
[TD]TctMobil_91:df:38[/TD]
[TD]EAPOL[/TD]
[TD]133[/TD]
[TD]Key (Message 1 of 4)[/TD]
[/TR]
[TR]
[TD]72[/TD]
[TD]216.397380[/TD]
[TD]TctMobil_91:df:38[/TD]
[TD]AvmAudio_5a:3b:87[/TD]
[TD]EAPOL[/TD]
[TD]155[/TD]
[TD]Key (Message 2 of 4)[/TD]
[/TR]
[TR]
[TD]73[/TD]
[TD]216.398828[/TD]
[TD]AvmAudio_5a:3b:87[/TD]
[TD]TctMobil_91:df:38[/TD]
[TD]EAPOL[/TD]
[TD]189[/TD]
[TD]Key (Message 3 of 4)[/TD]
[/TR]
[TR]
[TD]74[/TD]
[TD]216.409722[/TD]
[TD]TctMobil_91:df:38[/TD]
[TD]AvmAudio_5a:3b:87[/TD]
[TD]EAPOL[/TD]
[TD]133[/TD]
[TD]Key (Message 4 of 4)[/TD]
[/TR]
[TR]
[TD]75[/TD]
[TD]216.518477[/TD]
[TD]AvmAudio_5a:3b:87[/TD]
[TD]TctMobil_91:df:38[/TD]
[TD]802.11[/TD]
[TD]33[/TD]
[TD]Action, SN=259, FN=0, Flags=........[/TD]
[/TR]
[TR]
[TD]76[/TD]
[TD]216.520443[/TD]
[TD]TctMobil_91:df:38[/TD]
[TD]AvmAudio_5a:3b:87[/TD]
[TD]802.11[/TD]
[TD]33[/TD]
[TD]Action, SN=3712, FN=0, Flags=........[/TD]
[/TR]
[TR]
[TD]77[/TD]
[TD]218.467522[/TD]
[TD]IntelCor_da:d9:7d[/TD]
[TD]AvmAudio_5a:3b:87[/TD]
[TD]802.11[/TD]
[TD]30[/TD]
[TD]Action, SN=508, FN=0, Flags=........[/TD]
[/TR]
[TR]
[TD]78[/TD]
[TD]218.467658[/TD]
[TD]IntelCor_da:d9:7d[/TD]
[TD]AvmAudio_5a:3b:87[/TD]
[TD]802.11[/TD]
[TD]30[/TD]
[TD]Action, SN=509, FN=0, Flags=........[/TD]
[/TR]
[/TABLE]

Ich werfe auch nochmal eine Spekulation in die Diskussion. Disassociation Pakete werden wohl auch zur Einleitung des AP-Wechsels beim Roaming verwendet. Evtl will die Fritzbox den Client zum Roaming veranlassen (es ist noch ein AVM Repeater im Haus). Aber warum nur bestimmte Androiden?

chartmix · 18 Nov 2016

Mir ist noch eingefallen, dass in meinem WLAN auch ein Client ist, der laut Log nicht antwortet und ein paar Sekunden später wieder verbunden wird. Hierbei handelt es sich um ein Huawei Y300 mit Custom-ROM.
Dadurch kommen zum Beispiel WhatsApp-Nachrichten verspätet an. Eine Änderung der Einstellungen im Smartphone brachte nichts.
Das Phänomen tritt bei seit 6.50 auf. Hier bei einer 7412, vorher 7362SL.

PeterPawn · 19 Nov 2016

Den "reason code" im Disassociate-Paket ("Class 3 frame received from nonassociated STA") finde ich zumindest mal interessant ... aber (ehrlich gesagt) nun auch wieder nicht so interessant, daß ich mich (für AVM oder jemand anderen) alleine auf eine Fehlersuche machen würde. Mich interessiert(e) es halt nur, wo die Gemeinsamkeit liegen könnte, wenn es mehrere Geräte und mehrere Hersteller betrifft.

Die nächste Frage wäre es jetzt, was das für ein "class 3 frame" gewesen sein sollte. Eigentlich hätte ich auch vermutet, daß die FRITZ!Box PMF (Protected Management Frames) nach 802.11w benutzt - damit dürfte da kein Fremder mehr dazwischenfunken und eine Deauth-Attacke o.ä. starten können oder eine neue Assoziation einleiten - solange die nach Ansicht des AP noch assoziierte STA auf ein SA-Query antwortet.

Die "Zustände", in denen sich die Verbindung zwischen AP und STA befinden kann, sind hier anschaulich beschrieben: http://community.arubanetworks.com/t5/Technology-Blog/Understanding-802-11-State-Machine/ba-p/270933

Wenn also die STA zuvor sicher auf "Stufe 4" war, dann kann sie kaum irgendein Frame senden, welchen den Rückfall auf Stufe 2, geschweige denn auf Stufe 1, zur Folge haben sollte ... außer sie meldet sich selbst ab. Dann wäre der angegebene "reason code" aber ein anderer (3 oder 8) - das erklärt es also auch nicht wirklich. Eigentlich ist dieser Code auch eher für den Fall gedacht, daß eine STA auf Stufe 2 irgendetwas anderes als ein "class 1 or 2"-Frame sendet (ein Associate-Request ist ein "class 2"-Frame und einer der Wege, Level 2 zu verlassen -> in Richtung Level 3) - daß der in diesem Falle dort auftaucht, ist ziemlich fragwürdig ... solange es keinen guten Grund gibt, warum die STA plötzlich und unerwartet auf Level 2 sein sollte nach Ansicht des AP.

Warum da also die FRITZ!Box auf einmal auf die Idee kommen sollte, daß die STA tatsächlich "nonassociated" ist (aber noch immer "authenticated", sonst sollte es ein anderer Code (2, 6, irgendwas) sein), läßt sich - durch reines Nachdenken - kaum erklären. Da tippe ich dann weiterhin darauf, daß tatsächlich die FRITZ!Box irgendwie intern durcheinander kommt - denn merkwürdigerweise wird ja auch kein Paket protokolliert, das sie dermaßen falsch interpretieren könnte oder es ist der Filterung jeweils zum Opfer gefallen.

Da erscheint mir dann irgendein seltener interner Zustand, wo einfach der "falsche Ausgang" bei der Prüfung einer Status-Variablen genommen wird, doch wahrscheinlich. An eine simple Verwechselung der Codes (7 statt 4 für "inactivity") glaube ich auch nicht so richtig ... wobei dann ein Client m.W. noch eine "reassociation" versuchen könnte.

Es ist schon mysteriös - aber solange das Paket von der FRITZ!Box kommt (vielleicht kann ja irgendjemand noch mit einem unabhängigen Sniffer noch einmal prüfen, ob die Box vielleicht irgendetwas im Packetdump unterschlagen hat), sollte AVM m.E. auch dort die Erklärung finden können. Notfalls baut man eben zusätzlichen Code zum Tracen ein ... im "normalen Leben" dürfte eine tatsächliche "Protokollverletzung", die ein "Disassociate" mit Reason 7 nach sich zieht, (zumindest meiner Meinung nach) eher selten vorkommen.

Vielleicht ist das aber auch bereits erfolgt ... AVM hat einiges am "wland" geändert, der ist inzwischen deutlich geschwätziger als früher (und m.E. nicht erst seit der Labor-Version, wobei ich das nicht beschwören würde) und mit ein wenig Glück steht sogar irgendetwas genaueres zu einem solchen "Rauswurf" in den Support-Daten.

-Die These mit dem Roaming glaube ich bei der 06.60 eigentlich auch noch nicht so richtig ... das Roaming leitet im Normalfall ja nicht der AP, sondern die STA ein. Der AP kann ja gar nicht wissen, ob und welche anderen AP die STA an ihrem aktuellen Standort empfangen kann.

Bei der 06.69-irgendwas mit "band steering" könnte ich mir das wieder vorstellen, wenn der AP einen Client auf das andere Band schicken will - aber das kann die 06.60 ja noch nicht.

rst-cologne · 19 Nov 2016

In meinem Mitschnitt sind auch Stellen wo die Verbindung beendet wurde ohne das ein Disassociate Paket voraus ging. Der Mitschnitt ist auch nicht Bereinigt sondern ich habe bewusst einen Zeitpunkt gewählt wo nicht von den anderen gesendet wurde.
Folgendes habe ich bisher noch probiert, alles ohne Erfolg.
Alle WLAN Geräte deaktiviert so das nur noch das Nexus 5X alleine ist.
WLAN AC deaktiviert.
5GHz deaktiviert.
Möglichst weit weg von der Fritzbox damit ja noch mit voller Leistung gesendet wird.
Danach kamen die radikaleren Methoden, Fritzbox auf Werkseinstellung und nur beim WLAN alte SSID und PW vergeben.
Und zum Schluss nun sogar das Nexus 5X auf Werkseinstellungen zurück gesetzt.
Testszenario sah nun so aus, Fritzbox und Nexus 5X auf praktisch Werkseinstellungen, über WLAN verbunden, und einem Desktop PC an LAN1 der FB.
Soviel dazu das hier Geräte evtl. zerfrickelt sein könnten.
Da die betroffenen WLAN Clients eher zufällig sind und die Fritzbox immer die gleiche, sehe ich die Hauptschuld auf jeden Fall bei der Fritzbox.
Dafür spricht auch das diese Problemchen verschwindet wenn man die alte 6.30 Firmware verwendet (so ist zumindest an einigen Stellen zu lesen).
Da ich die Labor Threads nicht so genau lese, frage ich hiermit mal ob jemand weiß ob diese Problematik in einer Labor Version vielleicht schon behoben wurde?

- - - Aktualisiert - - -

Und noch was wichtiges habe ich vergessen zu schreiben. So ganz raus ist Android bei mir zumindest noch nicht. Denn sobald ich den Ruhezustand ausschalte (Einstellungen->Display->Ruhezustand = 30min) , werden keine Ab und Anmeldungen mehr vorgenommen. Und ja, "WLAN im Ruhemodus aktiviert lassen" steht auf "Immer".

- - - Aktualisiert - - -

Ergänzung: sobald der "Datensparmodus" aktiviert ist geschieht das Ab und Anmelden auch im im nicht-Ruhezustand.

- - - Aktualisiert - - -

Ich habe das ganze Spielchen mal auf die 2,4GHz verlagert. Damit ergibt sich die Möglichkeit die Schnittstelle "HW (2.4 GHz, wifi0) - Schnittstelle 0" mitzuschneiden.
Eine genaue Erklärung zu dieser Schnittstelle habe ich zwar nicht gefunden, in die Bezeichnung interpretiere ich aber das man dort näher an der Hardware dran ist ;-)
Wenn also wieder mal folgendes passiert (mac Adressen wurden verfremdet)...

19.11.16 15:03:41 WLAN-Gerät angemeldet (2,4 GHz), 144 Mbit/s, Nexus5X, IP 192.168.178.20, MAC SS:TT:AA:SS:TT:AA.
19.11.16 15:03:38 WLAN-Gerät wird abgemeldet (2,4 GHz): WLAN-Gerät antwortet nicht, Nexus5X, IP 192.168.178.20, MAC SS:TT:AA:SS:TT:AA. (#0104).

...dann kann man dazu im Mitschnitt folgendes sehen:

No. Time Source Destination Protocol Length Info
1202 15:03:39.226736 LgElectr_SS:TT:AA (SS:TT:AA:SS:TT:AA) (BSSID) AvmAudio_AA:AP

P (38:10:d5:AA:AP

P) (BSSID) 802.11 16 Power-Save poll, Flags=...P....
1203 15:03:39.226916 AvmAudio_30:20:06 LgElectr_SS:TT:AA 802.11 86 QoS Data, SN=100, FN=0, Flags=.p....F.
1204 15:03:39.233170 LgElectr_SS:TT:AA AvmAudio_AA:AP

P 802.11 28 QoS Null function (No data), SN=153, FN=0, Flags=.......T
1205 15:03:39.233913 LgElectr_SS:TT:AA AvmAudio_30:20:06 802.11 80 QoS Data, SN=75, FN=0, Flags=.p.....T
1206 15:03:39.234369 AvmAudio_AA:AP

P LgElectr_SS:TT:AA 802.11 26 Deauthentication, SN=256, FN=0, Flags=........
1207 15:03:39.240353 LgElectr_SS:TT:AA AvmAudio_AA:AP

P 802.11 28 QoS Null function (No data), SN=154, FN=0, Flags=...P...T

Warum nun in der Ereignisanzeige der Fritzbox Sekunde 38 steht , im Mitschnitt aber 39, entzieht sich meiner Kenntnis. In Sekunde 38 sind nur Beacon Frames unterwegs, das müsst ihr mir glauben.
Diese "Power-Save poll" vom Nexus5X (STA) finden reichlich statt (No. 1202). Sie werden vom STA immer dann an die Fritzbox (AP) gesendet wenn der STA aus dem Powersave heraus bei dem AP nachfragt ob es in der Zwischenzeit wo der STA im Powersave Mode war Daten für ihn angekommen sind. Die Antwort des AP (1203) folgt unmittelbar (1203 - 1202 = 0,18ms) oder bleibt völlig aus und der STA fragt weiter.
Ich habe mir nun viele Fälle bei mir angeschaut, und ich bin der Meinung das es nun wohl wichtig ist wie schnell der STA jetzt nochmal dem AP antwortet. Oben in dem schlechten Fall dauert dies (1204-1203) über 6ms. In den anderen schlechten fällen sind es immer 6,1ms bis 6,3ms. Dies ist der Fritzbox wohl zu lahm, und das Nexus fliegt raus (1206) ehe es sich wieder in den Powersafe Mode verabschieden kann (1207)

Als Gegenbeispiel mal ein guter Fall von dem es natürlich reichlich gibt.

577 15:02:52.224791 LgElectr_SS:TT:AA (SS:TT:AA:SS:TT:AA) (BSSID) AvmAudio_AA:AP

P (38:10:d5:AA:AP

P) (BSSID) 802.11 16 Power-Save poll, Flags=...P....
578 15:02:52.224969 AvmAudio_30:20:06 LgElectr_SS:TT:AA 802.11 86 QoS Data, SN=70, FN=0, Flags=.p....F.
579 15:02:52.225831 LgElectr_SS:TT:AA AvmAudio_AA:AP

P 802.11 28 QoS Null function (No data), SN=69, FN=0, Flags=.......T
580 15:02:52.226651 LgElectr_SS:TT:AA AvmAudio_30:20:06 802.11 80 QoS Data, SN=74, FN=0, Flags=.p.....T
581 15:02:52.238171 LgElectr_SS:TT:AA AvmAudio_AA:AP

P 802.11 28 QoS Null function (No data), SN=70, FN=0, Flags=...P...T

Hier dauert die Antwort des AP auf die Power-Save poll Frage wieder nur 0,18ms. Und die weitere Antwort des STA ist hier in 0,8ms erledigt (zur Erinnerung, im schlechten Fall waren es über 6ms)
Das ganze scheint mir also eine Art timeout Problem zu sein. Das Smartphone antwortet zu spät oder die Fritzbox schmeisst zu früh raus. Sucht es euch aus.

PeterPawn · 21 Nov 2016

@rst-cologne:
Nette Analyse ... die Frage wäre nun die nach dem "gemeinsamen Nenner". Wenn das bei anderen Geräten auch das Timeout an diesen Stellen sein sollte (wie soll das dann erst in stark frequentierter Umgebung aussehen, wenn beide (AP und STA) erst einmal "nach Slots anstehen" müssen), dann wäre wohl die Box etwas zu ungeduldig. Entscheidend ist ja zunächst mal, daß tatsächlich die Box die STAs rauswirft und es nicht etwa so ist, daß die gar nicht mehr antworten - es halt etwas später.

rst-cologne · 21 Nov 2016

Ich habe leider (oder zum Glück?!) nur ein Gerät was sich an dieser Fritzbox mit dieser Firmware so verhält. Ich kann also keine anderen Fälle überprüfen.
Die Zeit in der die Antwort erfolgen sollte scheint auch variabel zu sein. Auf einem Kanal wo viel los ist, ist diese Zeit kürzer als auf einem Kanal wo wenig los ist. Und einen 2,4GHz Kanal oder Bereich wo nichts los ist, gibt es bei mir leider nicht.
Die im Beispiel genannten 6ms sind also nur eine Momentaufnhame und treffen nur für die zum Zeitpunkt herrschende Umgebung zu. Wenn mein Nexus5X rausgeworfen wurde dann wurde aber immer eine zeitliche Schwelle überschritten denn die restlichen Antwortzeiten waren kürzer.
Auf den 5GHz wird mein Nexus5X auch rausgeworfen und das auf Kanälen wo ich weit und Breit alleine Funke. Leider kann man die 5GHz Schnittstelle nicht so direkt abgreifen wie die 2,4GHz.
In jedem von mir gesehenen Fall erfolgt das Deauthentication aber stets im Anschluss von einem Power-Save poll. Das passt auch gut dazu das wenn man das Smartphone "am Leben" hält, es also Daten übertragen lässt, es zu keinen Abbrüchen kommt. Bei mir zumindest...
Und ja, die Box schmeisst raus. Aber vieleicht steht ja auch irgendwo, oder wurde zwischen den Geräten ausgehandelt wann der STA (oder auch der AP) zu antworten hat, und er hält sich aber nicht daran.
Über eine Antwort von AVM wie z.b. "wir sind nicht schuld, wir halten uns an den Standard, das Nexus5X aber nicht" würde ich mich dann also nicht wundern.
Auf jeden Fall lässt sich das Problem per Firmware lösen, denn bei der 6.30 ist dieses Phänomen unbekannt.

EDIT: Bei Intel scheint das Problem auch bekannt zu sein.
http://www.intel.com/content/www/us/en/support/network-and-i-o/wireless-networking/000005645.html

Da fällt mir ein, meinen Laptop im Batterie Betrieb habe ich garnicht ausprobiert ...

chartmix · 21 Nov 2016

@rst-cologne
Hast du denn vor bei AVM ein Ticket aufzumachen?
Mehr als Gerät antwortet nicht, wird abgemeldet und wieder angemeldet kann ich denen nicht sagen. Evtl. kann man auf ein Ticket verweisen.

rst-cologne · 21 Nov 2016

Ja, während meiner Analyse habe ich auch mal an den Support geschrieben. Ich hab nicht die geringste Ahnung was da raus kommen kann, damit haben hier andere Leute sicher schon viel mehr Erfahrung (Peter?). Ich weiß ja noch nicht mal ob es in einer der Labor Versionen schon behoben wurde. Einige Fragen hat man mir schon gestellt. Wenn was bei raus kommt, sag ich Bescheid. Bisher hatte ich mich nur wegen Gerätedefekte an den Support gewandt. Und sogar diesen Fall würde ich dieses mal auch noch nicht zu 100% ausschließen wollen. Ist halt schon merkwürdig wenn das Smartphone, 1m neben der 7490, alleine im 5Ghz band, im 2 Minuten Takt ab und angemeldet wird.

Ich möchte auch noch auf die Support Seite von AVM hinweisen
https://avm.de/service/fritzbox/fri...show/27_Haeufiger-Abbruch-der-WLAN-Verbindung

alles was da steht ist natürlich absolut richtig und wichtig, und kann vielleicht das Problem bei dem ein oder anderen lösen. Davon trifft bei mir aber eben nichts zu.

chartmix · 21 Nov 2016

Ich glaube nicht an einen Gerätedefekt, da das Problem bei mir mit verschiedenen Boxen mit 6.50 in Zusammenhang mit nem Androiden aufgetaucht ist.
Da ist was an der Firmware anders als vorher.
Ob nun AVM oder das Betriebssystem des Clients abseits des Standards agiert, kann man nur mutmaßen.
Ich bin gespannt was das Ticket ergibt.

rst-cologne · 21 Nov 2016

Ich habe hier eine 3390 mit Firmware 6.51. Dort gibt es das Problem nicht. Ich bin aber auch noch ein bisschen weiter gekommen.
Aber zuerst noch was lustiges zu der einen Sekunde Abweichung. Die Fritzbox scheint es mit der Zeitnahme nicht so genau zu nehmen.

21.11.16 19:38:58 WLAN-Gerät angemeldet (2,4 GHz), 144 Mbit/s, Nexus5X, ......
21.11.16 19:38:06 WLAN-Gerät angemeldet (2,4 GHz), 72 Mbit/s, android-......

21.11.16 19:38:57 WLAN-Gerät angemeldet (2,4 GHz), 144 Mbit/s, Nexus5X, .....
21.11.16 19:38:05 WLAN-Gerät angemeldet (2,4 GHz), 72 Mbit/s, android-.....

Das gleiche Ereignis, blos um eine Sekunde verschoben. Man muss nur oft genug auf Aktualisieren klicken, dann sieht es mal so und mal so aus. Oder ist es nur schlecht gerundet... wer weiß. Ist auch egal.

So, ich hatte jetzt tatsächlich einige male den Zustand das mein Nexus5X nicht rausgeworfen wurde. Jetzt wird es interessant, denn siehe da, dort gibt es keine Power-Safe polls im Mitschnitt.
Das WLAN vom Nexus geht trotzdem in einen Power-Safe Mode , nur wird sich darüber in einer anderen Methode verständigt.
Wer es genauer wissen will kann hier nachlesen , http://wifi-insider.com/wlan/psd.htm .

Es gibt eine "Veraltete" Methode die mit dem polling arbeitet und wo es zu den hier genannten Problemen kommt, und es gibt eben bessere Methoden die ohne polling auskommen.
Bei allen bei mir angemeldeten WLAN Geräten haben ich dieses Power-Safe polling bisher nicht gesehen. Nur das Nexus5X scheint sich mal so oder mal so anzumelden.
Die große Frage ist nun, warum ist das so?

PeterPawn · 21 Nov 2016

rst-cologne schrieb:
Die Fritzbox scheint es mit der Zeitnahme nicht so genau zu nehmen.

Das liegt an der Art der Speicherung.

Diese beginnt ja schon zu einem Zeitpunkt, wo die FRITZ!Box noch keine korrekte Uhrzeit hat.

Daher wird eine relative Angabe zum Start gespeichert und beim Setzen der Uhrzeit die Differenz zur "Nullzeit" irgendwo gespeichert.

Ob direkt (als Timestamp) oder als zusätzliches Delta weiß ich nicht mehr - aber das sollte die Erklärung für das "Schwanken" der Sekunden sein, je nachdem, ob am Ende auf- oder abgerundet wird.

Auf wieviele Stellen diese Angabe möglich wäre vor dem Runden, weiß ich auch nicht.

Den (ungefähren) Aufbau der internen Datei für das Eventlog habe ich irgendwo mal aufgeschrieben (iirc in einer Diskussion mit @kingtutt), da ging es auch um die Feststellung, daß die Sekunde in einer angezeigten Nachricht nicht fix ist - bei einem "corner case" könnte das bis zum Tag gehen (Woche, Monat, Jahr ist dann wieder zu exotisch, aber natürlich in der Theorie ebenfalls denkbar).

Damit taugt diese Angabe auch nicht als Vergleichsbasis für bereits (extern) gesicherte Nachrichten, wenn man dabei nicht diese mögliche Abweichung berücksichtigt und auch noch die "Nachbarn" (+/- 1 Sekunde) in den Test einbezieht.

rst-cologne · 24 Nov 2016

chartmix schrieb:
Ich bin gespannt was das Ticket ergibt.

Wie ich ja schon selber erwartet habe , hatten meine Bemühungen zur Klärung dieses Problems auch keinen Erfolg.

- dieser Fehler ist mit anderen Android Geräten nicht bekannt
- der Verweis auf einen problemlosen Betrieb mit Version 6.30 wurde mehrmals komplett ignoriert

...waren die hier ja schon bekannten Verhaltensmuster. Ich warte jetzt erst mal die Weihnachtsversion ab und werde dann weiter sehen.

meierchen006 · 7 Jan 2017

MyFritz!App 2--Sicherheitslücke?

Hallo,

Ich habe festgestellt das man mit der aktuellen BETA 2.3.1(13182) der MyFritz!App2 sich mit einem falschen Benutzernamen, der nicht als Benutzer in der 7490 angelegt ist, und richtigen Passwort trotzdem an der Fritzbox mit dieser Firmware 113.06.60 anmelden kann.

Kann das von Euch einer nachstellen?

Bei mir funktioniert es mit drei verschiedenen Android Geräten.

falscher Benutzernamen bei mir ist "test" zum probieren.

PeterPawn · 8 Jan 2017

Das könnte daran liegen, daß die MyFRITZ!App2 die neue "App-Schnittstelle" benutzt, wo bei der Einrichtung einmalig ein gültiges Konto für TR-064 gebraucht wird für den Aufruf von "RegisterApp".

Um das besser einschätzen zu können, müßte man schon noch etwas mehr über die Rahmenbedingungen (z.B. den eingestellten Anmeldemodus und/oder die Stelle mit der Aufforderung zur Eingabe von Username/Password) wissen, damit man einschätzen kann, was sich in dieser App an dieser Stelle hinter "Benutzername" verbergen soll.

Beim "RegisterApp" kann ja ein "anderer Benutzername" festgelegt werden (hieraus entstehen dann die Fehler mit den Nummern 828-831) und ich bin mir nicht so richtig sicher, über welchen "Benutzernamen" wir hier eigentlich reden.

meierchen006 · 8 Jan 2017

MyFritz!App 2--Sicherheitslücke?

Hallo PeterPawn,

anbei mal ein paar Screenshots:

0-Anmelden an der Fritzbox 7490 mit: Benutzername und Passwort

1-Hinterlegte Benutzer in der Fritzbox: nur einer (ich selbst)

2-Anmelden im Heimnetz: Benutzername und Passwort

3-Apps in der Fritzbox für Android Geräte: drei registrierte

Beim Android Gerät gehe ich wie folgt vor:

4-Im Hamburger Menü oben links >>Hamburger Menü<< >>Einstellungen<< >>Neu anmelden<<
>>>Meldung im Android Gerät <<<
> Für die Neuanmeldung werden Einstellungen zur bisherigen Fritz!Box gelöscht. Möchten Sie fortfahren? >OK< <

5-Danach wird die Fritz!Box neu gesucht

6-Jetzt kann der neue falsche Benutzername und das richtige Passwort eingegeben werden.

7-Auch mit falschem Benutzernamen wird trotzdem eine Verbindung zur Fritz!Box aufgebaut und die Daten geladen.

Mit richtigen Benutzernamen und falschem Passwort ist es nicht möglich sich anzumelden!

FRITZ!Box 7490 Firmware 113.06.60 vom 06.07.2016

IPPF-Urgestein

Mitglied

Aktives Mitglied

IPPF-Urgestein

Aktives Mitglied

Neuer User

Neuer User

IPPF-Urgestein

Mitglied

IPPF-Urgestein

Mitglied

Neuer User

Mitglied

Neuer User

Mitglied

IPPF-Urgestein

Mitglied

Aktives Mitglied

IPPF-Urgestein

Aktives Mitglied

Statistik des Forums