05.04.2019

7979

Mikrotik W-Lan - Wifi Probleme (Group Key Exchange Timeout)

Hallo,
ich habe massive Probleme mit der Stabilität eines Mikrotik cAP ac Access Points und das leider schon seit längerem.

Anfangs dachte ich, das sei nur ein temporäres Problem was durch ein neues Firmware Update behoben wird, letztlich bringen die Updates der letzten Monate keine Abhilfe.
Den offiziellen Support von Mikrotik habe ich bereits kontaktiert und war ebenfalls enttäuscht, da sich deren Anweisungen wiederholten und bereits umgesetzt wurden. Zum Schluss wurde ich nur noch aufgefordert die Access Points neuzustarten. Lächerlich.

Die Einträge im Log sehen wie folgt aus:

- disconnected, group key exchange timeout
- disconnected, unicast key exchange timeout
- disconnected, received disassoc: sending station leaving

Zudem habe ich testweise eine Fritzbox als Access Point angeschlossen. Ergebnis: Keine Probleme mit der Stabilität des W-Lans. Daher gehe ich davon aus, das die Einstellungen am Netzwerk-Router in Ordnung sind und es lediglich ein Problem des Access Points ist.

Ich würde mich freuen, wenn sich jemand meine Einstellungen anschauen könnte, um ggf. übersehene Dinge korrigieren zu können.

Was bereits getestet wurde:
- Änderung des Funkkanals
- Veränderung des Group Key Update Intervalls
- Veränderung der Lease Zeit des DHCP

Vollständige Konfiguration des Access Points

/interface bridge
add comment="Bridge - Hotspot / Gastnetz" name=bridge-vlan20  
add comment="Bridge - Lokales Netzwerk" name=bridge-vlan40  
/interface ethernet
set [ find default-name=ether1 ] speed=100Mbps
set [ find default-name=ether2 ] speed=100Mbps
/interface vlan
add comment="Hotspot / Gastnetz" interface=ether1 name=ether1-vlan20 vlan-id=20  
add comment="Lokales Netzwerk" interface=ether1 name=ether1-vlan40 vlan-id=40  
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
add authentication-types=wpa2-psk eap-methods="" group-key-update=1h mode=\  
    dynamic-keys name=EG24/EG50 supplicant-identity=""  
add authentication-types=wpa2-psk group-key-update=1h mode=dynamic-keys name=\
    EG24-Gast supplicant-identity=AP-EG
/interface wireless
set [ find default-name=wlan1 ] antenna-gain=2 band=2ghz-b/g/n comment=\
    "W-Lan - EG24" country=germany disabled=no frequency-mode=regulatory-domain \  
    keepalive-frames=disabled mode=ap-bridge multicast-buffering=disabled name=\
    wlan2.4ghz-vlan40 preamble-mode=long security-profile=EG24/EG50 ssid=EG24 \
    wireless-protocol=802.11 wmm-support=enabled wps-mode=disabled
set [ find default-name=wlan2 ] antenna-gain=3 band=5ghz-a/n/ac comment=\
    "W-Lan - EG50" country=germany disabled=no frequency=5200 frequency-mode=\  
    regulatory-domain keepalive-frames=disabled mode=ap-bridge \
    multicast-buffering=disabled name=wlan5.0ghz-vlan40 security-profile=\
    EG24/EG50 ssid=EG50 wireless-protocol=802.11 wmm-support=required wps-mode=\
    disabled
/interface wireless manual-tx-power-table
set wlan2.4ghz-vlan40 comment="W-Lan - EG24"  
set wlan5.0ghz-vlan40 comment="W-Lan - EG50"  
/interface wireless nstreme
set wlan2.4ghz-vlan40 comment="W-Lan - EG24"  
set wlan5.0ghz-vlan40 comment="W-Lan - EG50"  
/interface wireless
add comment="W-Lan - Hotspot / Gastnetz" disabled=no keepalive-frames=disabled \  
    mac-address=CE:2D:E0:1E:C4:CE master-interface=wlan2.4ghz-vlan40 \
    multicast-buffering=disabled name=wlan2.4ghz-vlan20 security-profile=\
    EG24-Gast ssid=EG24-Gast wds-cost-range=0 wds-default-cost=0 wmm-support=\
    required wps-mode=disabled
/interface wireless manual-tx-power-table
set wlan2.4ghz-vlan20 comment="W-Lan - Hotspot / Gastnetz"  
/interface wireless nstreme
set wlan2.4ghz-vlan20 comment="W-Lan - Hotspot / Gastnetz"  
/ip hotspot profile
set [ find default=yes ] html-directory=flash/hotspot
/interface bridge port
add bridge=bridge-vlan40 interface=ether1-vlan40
add bridge=bridge-vlan40 interface=ether2
add bridge=bridge-vlan40 interface=wlan2.4ghz-vlan40
add bridge=bridge-vlan40 interface=wlan5.0ghz-vlan40
add bridge=bridge-vlan20 interface=ether1-vlan20
add bridge=bridge-vlan20 interface=wlan2.4ghz-vlan20
/ip neighbor discovery-settings
set discover-interface-list=none
/ip address
add address=10.40.0.4/24 interface=ether1-vlan40 network=10.40.0.0
/ip dns
set servers=192.168.0.1
/ip route
add distance=1 gateway=10.40.0.1
/ip service
set telnet disabled=yes
set ftp disabled=yes
set ssh disabled=yes
set api disabled=yes
set api-ssl disabled=yes
/snmp
set trap-generators=temp-exception,temp-exception
/system clock
set time-zone-autodetect=no time-zone-name=Europe/Berlin
/system identity
set name=AP-EG
/system ntp client
set enabled=yes primary-ntp=176.9.40.142 secondary-ntp=136.243.8.140
/system package update
set channel=long-term
/tool bandwidth-server
set enabled=no
/tool graphing interface
add interface=ether1-vlan20
add interface=ether1-vlan40
/tool mac-server
set allowed-interface-list=none
/tool mac-server mac-winbox
set allowed-interface-list=none
/tool mac-server ping
set enabled=no

Vielen Dank im Voraus!

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 437269

Url: https://administrator.de/forum/mikrotik-w-lan-wifi-probleme-group-key-exchange-timeout-437269.html

Ausgedruckt am: 23.12.2024 um 13:12 Uhr

20 Kommentare

Neuester Kommentar

Hi,

wie ist denn der Empfang zum Client? Tritt das Problem auch auf, wenn Client und AP nah zusammen sind? Zum Testen mal ein Netz ohne Verschlüsselung aufgebaut und das Problem dort auch vorhanden?

Gruß,
Thomas

Zitat von @Thomas2:
wie ist denn der Empfang zum Client? Tritt das Problem auch auf, wenn Client und AP nah zusammen sind?

Der Empfang ist gut. Der Access Point ist zentral in einer ~100m² Wohnung platziert.

Zum Testen mal ein Netz ohne Verschlüsselung aufgebaut und das Problem dort auch vorhanden?

Zugegeben, auf diese Idee bin ich bisher noch nicht gekommen. Vielleicht kann ich das morgen Testen, falls ich vor Ort bin.

/interface wireless manual-tx-power-table
/interface wireless nstreme
/set channel=long-term

Das Dinge ist offensichtlich völlig verkonfiguriert, da hat einer manuell an der WIFI TX-Power-Table gedreht (Tödlich wenn man nicht weiß was man da tut, Dauerhafte Schäden des Chips kann mit einer Fehlconfig nicht ausgeschlossen werden!!). Am besten gleich einen vernünftigen Reset ohne Laden der default config machen und dann neu Einrichten. Die meistehn Fehler bei Mikrotik sind nicht das Gerät schuld sondern die User die nicht wissen was sie tun, so meine Erfahrung, die Dinger sind eben kein Klicki-Bunti Spielzeug wie eine Fritte, hier muss der User schon mehr wissen.

- disconnected, group key exchange timeout

normales Verhalten wenn die Group Key Phase zu kurz gesetzt ist.
Achtung ! Neueste Firmware aufpspielen, auf älteren gab es da einen Bug mit dem Group Key Interval per (auch per Capsman)

- disconnected, unicast key exchange timeout

Gehört dazu

- disconnected, received disassoc: sending station leaving

Das ist eine normale Meldung wenn sich ein WIFI-Device vom WLAN abmeldet und hat nichts mit deinem Problem zu tun!

Ein WinBox Screenshot des WLAN Port Setups wäre etwas übersichtlicher gewesen.
Interface wireless nstreme ist in jedem Falle falsch. Hier muss auf "regulatory domain" gestellt werden und als Country dann Germany. Antenna Gain dann "2".
Schlüssel usw. alles auf Default.

Zitat von @139374:
Das Dinge ist offensichtlich völlig verkonfiguriert, da hat einer manuell an der WIFI TX-Power-Table gedreht (Tödlich wenn man nicht weiß was man da tut, Dauerhafte Schäden des Chips kann mit einer Fehlconfig nicht ausgeschlossen werden!!). Am besten gleich einen vernünftigen Reset ohne Laden der default config machen und dann neu Einrichten.

Ich habe soeben den Reset ohne laden der default config gemacht und das ganze neu eingerichtet und dabei wirklich nur das nötigstes angepasst (z.b. ssid, winbox zugriff nur über ip-adresse, etc.). beim anschließenenden export steht an der gleichen stelle wieder "/interface wireless manual-tx-power-table". wenn wireless -> interface -> tx power über winbox aufgerufen wird steht dort "Tx power mode: default". Ich habe was power angeht nichts umgestellt und alles so gelassen wie es standardmäßig ist.

normales Verhalten wenn die Group Key Phase zu kurz gesetzt ist.
Achtung ! Neueste Firmware aufpspielen, auf älteren gab es da einen Bug mit dem Group Key Interval per (auch per Capsman)

In 6.43.13 ist der angesprochene Fehler laut Changelog bereits behoben. 6.43.14 läuft nun, dort wurde aber nur ein IPV6 Fehler behoben. Da das nicht benutzt wird, sollte es irrelevant für mich sein. Dennoch habe ich auf 6.43.14 geupgraded (firmware + pakete)

Zitat von @aqui:

Ein WinBox Screenshot des WLAN Port Setups wäre etwas übersichtlicher gewesen.

Here we go:

Ich sehe auf den ersten Blick keine Unterschiede, bitte korrigieren falls ich etwas übersehen habe.
Das Group Key Update Intervall ist jetzt nach einem Reset wieder auf dem Default Wert von 5 Minuten (Vorher: 60 Minuten)

und hier nochmal der druckfrische aktuelle Export sämtlicher Einstellungen:

# apr/06/2019 18:50:02 by RouterOS 6.43.14
# model = RouterBOARD cAP Gi-5acD2nD
/interface bridge
add comment="Bridge - Hotspot / Gastnetz" name=bridge-vlan20  
add comment="Bridge - Lokales Netzwerk" name=bridge-vlan40  
/interface vlan
add comment="Hotspot / Gastnetz" interface=ether1 name=ether1-vlan20 vlan-id=\  
    20
add comment="Lokales Netzwerk / Internet" interface=ether1 name=ether1-vlan40 \  
    vlan-id=40
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
add authentication-types=wpa2-psk eap-methods="" mode=dynamic-keys name=\  
    EG24/EG50 supplicant-identity=""  
add authentication-types=wpa2-psk eap-methods="" mode=dynamic-keys name=\  
    "Hotspot / Gastnetz" supplicant-identity=""  
/interface wireless
set [ find default-name=wlan1 ] antenna-gain=2 band=2ghz-onlyn comment=\
    "W-Lan - EG24" country=germany disabled=no frequency=2437 frequency-mode=\  
    regulatory-domain mode=ap-bridge name=wlan2.4ghz-vlan40 security-profile=\
    EG24/EG50 ssid=EG24 wps-mode=disabled
set [ find default-name=wlan2 ] antenna-gain=3 comment="W-Lan - EG50" country=\  
    germany disabled=no frequency-mode=regulatory-domain mode=ap-bridge name=\
    wlan5.0ghz-vlan40 security-profile=EG24/EG50 ssid=EG50 wps-mode=disabled
/interface wireless manual-tx-power-table
set wlan2.4ghz-vlan40 comment="W-Lan - EG24"  
set wlan5.0ghz-vlan40 comment="W-Lan - EG50"  
/interface wireless nstreme
set wlan2.4ghz-vlan40 comment="W-Lan - EG24"  
set wlan5.0ghz-vlan40 comment="W-Lan - EG50"  
/interface wireless
add comment="W-Lan - EG24-Gast" disabled=no keepalive-frames=disabled \  
    mac-address=CE:2D:E0:1E:C4:CE master-interface=wlan2.4ghz-vlan40 \
    multicast-buffering=disabled name=wlan2.4ghz-vlan20 security-profile=\
    "Hotspot / Gastnetz" ssid=EG24-Gast wds-cost-range=0 wds-default-cost=0 \  
    wps-mode=disabled
/interface wireless manual-tx-power-table
set wlan2.4ghz-vlan20 comment="W-Lan - EG24-Gast"  
/interface wireless nstreme
set wlan2.4ghz-vlan20 comment="W-Lan - EG24-Gast"  
/ip hotspot profile
set [ find default=yes ] html-directory=flash/hotspot
/interface bridge port
add bridge=bridge-vlan20 interface=wlan2.4ghz-vlan20
add bridge=bridge-vlan40 interface=ether1-vlan40
add bridge=bridge-vlan40 interface=wlan2.4ghz-vlan40
add bridge=bridge-vlan40 interface=wlan5.0ghz-vlan40
add bridge=bridge-vlan40 interface=ether2
add bridge=bridge-vlan20 interface=ether1-vlan20
/ip neighbor discovery-settings
set discover-interface-list=none
/ip address
add address=10.40.0.4/24 interface=ether1-vlan40 network=10.40.0.0
/ip dns
set servers=192.168.0.1
/ip route
add distance=1 gateway=10.40.0.1
/ip service
set telnet disabled=yes
set ftp disabled=yes
set ssh disabled=yes
set api disabled=yes
set api-ssl disabled=yes
/system clock
set time-zone-name=Europe/Berlin
/system identity
set name=AP-EG
/system ntp client
set enabled=yes primary-ntp=176.9.40.142 secondary-ntp=136.243.8.140
/system package update
set channel=long-term
/tool bandwidth-server
set enabled=no
/tool graphing interface
add interface=ether1-vlan20
add interface=ether1-vlan40
/tool mac-server
set allowed-interface-list=none
/tool mac-server mac-winbox
set allowed-interface-list=none
/tool mac-server ping
set enabled=no

Interface wireless nstreme ist in jedem Falle falsch. Hier muss auf "regulatory domain" gestellt werden und als Country dann Germany. Antenna Gain dann "2".

Ich kann nicht so ganz nachvollziehen, warum das dort auftaucht, obwohl wie auf dem Screenshot zu sehen ist regulatory domain eingestellt ist.
Kannst du mir ggf. erklären warum das dort auftaucht bzw. wie ich es wegbekomme? Ich habe das Gefühl das wird standardmäßig von RouterOS bzw. Winbox gesetzt, beim Anlegen von einem Virtual Ap's.

Die Anpassungen welche Apple speziell für seine Geräte vorschlägt habe ich auch vorerst ignoriert (Siehe: https://support.apple.com/en-au/HT202068). Daher ist WMM derzeit auf disabled gesetzt.

Was mir auch noch aufgefallen ist:
Standardmäßig sind auf den Wifi-Interfaces Multicast, Buggering und Keepalive Frames aktiviert. Lege ich einen Virtual AP an, sind sie standardmäßig deaktiviert. Sind diese Vorschläge von Mikrotik korrekt und bewusst so gewählt? Falls nicht, wie sollten ich sie setzen?

Ich hinterfrage gerade alle meine Einstellungen die mich in den letzten 2-3 Jahren im Mikrotik-Universum begleitet haben. Vorher nie irgendwelche Probleme gehabt, aber jetzt fühl ich mich dezent hilflos :P.

WMM solltest du aktivieren, denn das aktiviert die Multicast zur Unicast Konversion. Ein erheblicher Performance Vorteil wenn du Multicast überträgst im WLAN.
Es ist möglich das das auf Virtual APs nicht supportet ist. Dazu müsste man mal den Konfig Guide lesen. Nicht alles was auf physischen WLAN Ports supportet ist rennt auch auf den Virtuellen.
Alles was geht wie WMM, Multicast zu Unicast Konvertierung usw. sollte man aber immer auch auf den Virtuellen aktivieren wenn möglich.

Auch eine sinnvolle Frequenzplanung solltest du bei dir unbedingt machen wenn du mehrere APs hast oder WLANs in der Nachbarschaft. Zu denen musst du mindestens einen Abstand von 4 Funkkanälen halten !!
Guckst du auch hier:
Seit WLAN Umstellung von Cisco WAP 200 auf Zyxel NWA3560-N schlechtere Verbindung

Okay, also ich habe WMM, Multicast Buffering und Keepalive Frames überall aktiviert. Die Exchange Timeout Probleme sind nach wie vor da. Circa. 40 stück sind in den Logs während der letzten 7 Tage aufgelaufen.

Die Kanäle der Access Points überschneiden sich nicht. Das WPA-Passwort hat keine Sonderzeichen.

Es hat sich weder etwas zum positiven, noch zum negativen verändert bisher.

Weitere Ideen?

Dann liegt das Problem auch niemals im WLAN bzw. der Infrastruktur an sich sondern in der Anwendung selber.
Du kannst ja parallel nochmal einen Durchsatztest mit NetIO oder IPerf3 über das WLAN laufen lassen um mal zu sehen ob dort wirklich Aussetzer vorkommen. Vermutlich wohl nicht...
https://web.ars.de/netio/
http://www.nwlab.net/art/netio/netio.html

Zitat von @aqui:

Dann liegt das Problem auch niemals im WLAN bzw. der Infrastruktur an sich sondern in der Anwendung selber.

Damit meinst du RouterOs, korrekt?
- Falls ja, dieser Meinung bin ich schon seit einem Jahr, zumindest was W-Lan Geschichten angeht.

Nein, denn Router OS steuert ja die Infrastruktur !
Das Gegenteil, deine Endanwendung !
Dein WLAN Szenario rennt hier seit Jahren absolut unauffällig und störungsfrei bei diversen Business Kunden.
RouterOS ist es de facto eher nicht.
Hast du mal in Betracht gezogen das es auch DFS sein kann sofern du 5Ghz benutzt, Outdoor Kanäle und Radar oder andere Primärnutzer dieses Bandes im Umfeld hast...?

Dein WLAN Szenario rennt hier seit Jahren absolut unauffällig und störungsfrei bei diversen Business Kunden

Kann ich nur bestätigen, die Teile rennen auch ohne Neustart Jahrelang zuverlässig, wenn man mal von geplanten Updates absieht.
Ich würde das ganze mal in den Keller im Testaufbau laufen lassen abgeschirmt von jeglichen anderen Störquellen/-Faktoren.
Entweder das Problem löst sich dann, du hast ein defektes Gerät erwischt, auch ein Mikrotik ist davor nicht gefeit, oder es gibt irgendeine Inkompatibilität zu den Client-Chipsets, was ich aber für eher unwahrscheinlich halte.

Zitat von @aqui:

Nein, denn Router OS steuert ja die Infrastruktur !
Das Gegenteil, deine Endanwendung !
Dein WLAN Szenario rennt hier seit Jahren absolut unauffällig und störungsfrei bei diversen Business Kunden.
RouterOS ist es de facto eher nicht.

Es sind 3 Stockwerke mit 3 Familien im Haus. Jedes Stockwerk hat 1 Access Point, jediglich im Erdgeschoss sind 2 Access Points installiert.
Jeder Access Point strahlt lediglich das jeweilige Familien-Netz (Vlan) und eine Gastnetzwerk aus. Eigentlich nichts exotisches.

Wenn ich einen billigen TP-Link Access Point mit OpenWRT anstelle der Mikrotik AP's dranhänge, läuft das ganze ohne Störungen.
Hänge ich einen Mikrotik hap lite, anstelle des hap ac² oder cap ac dran, sind nach wie vor group exchange timeouts vorhanden.

Das ist das merkwürdige, was mich zur Verzweifelung bringt und der Grund warum ich irgendeinen Fehler oder ein Problem bei den Access Points, nicht aber beim Router (MT 750gr3) vermute.

Hast du mal in Betracht gezogen das es auch DFS sein kann sofern du 5Ghz benutzt, Outdoor Kanäle und Radar oder andere Primärnutzer dieses Bandes im Umfeld hast...?

Viele der Timeouts treten im 2.4 Ghz Bereich auf. Ich kann nicht sagen ob 5 Ghz komplett davon verschont wird, jedoch dürfte die DFS-Problematik keine Auswirkungen auf meine 2.4 Ghz Wlan haben.

Groupkey exchange timeouts im Log, sind völlig normal solange das Intervall nicht zu kurz gewählt wird. Sie haben ja primär mit der Verschlüsselung von Multicast- und Broadcast Paketen zu tun und nichts mit der Wifi-Verbindung an sich. Läuft der Timeout-Zeitraum ab verhandeln die Clients unterbrechungsfrei neu mit dem AP. Ist das bei dir nicht der Fall ist entweder das Signal vom Client zu schwach oder deine Mikrotiks haben eine Macke.
Da die Antennen der Mikrotiks mit 2dB nicht so der Burner sind vermute ich eher das hier das Signal zu den Clients das Problem ist.

Zitat von @139374:

Groupkey exchange timeouts im Log, sind völlig normal solange das Intervall nicht zu kurz gewählt wird. Sie haben ja primär mit der Verschlüsselung von Multicast- und Broadcast Paketen zu tun und nichts mit der Wifi-Verbindung an sich. Läuft der Timeout-Zeitraum ab verhandeln die Clients unterbrechungsfrei neu mit dem AP. Ist das bei dir nicht der Fall ist entweder das Signal vom Client zu schwach oder deine Mikrotiks haben eine Macke.
Da die Antennen der Mikrotiks mit 2dB nicht so der Burner sind vermute ich eher das hier das Signal zu den Clients das Problem ist.

Wenn ich mit einer Connect-List am Access Point die Verbindungen zu Clients mit einer Signalstärke von -80db oder schlechter verbiete, müsste dann die Zahl der Timeouts in den Logs sich reduzieren lassen.

Ist dieser Gedankengang richtig? Falls ja, würde ich das gerne mal als Experiment aufsetzen und schauen, ob das zur Verbesserung beiträgt.

Zitat von @Uwoerl:

Wenn ich mit einer Connect-List am Access Point die Verbindungen zu Clients mit einer Signalstärke von -80db oder schlechter verbiete, müsste dann die Zahl der Timeouts in den Logs sich reduzieren lassen.

Ist dieser Gedankengang richtig? Falls ja, würde ich das gerne mal als Experiment aufsetzen und schauen, ob das zur Verbesserung beiträgt.

Nur wenn die Clients dauerhaft eine gute Verbindung haben, sobald sie sich nahe an der Grenze von -80db bewegen z.B.-77 und sich nur jemand kurz in die Sichtlinie zwischen AP und Client bewegt, werden die Abbrüche eher mehr als weniger werden, das sollte dir bei dieser Vorgehensweise bewusst sein.
Und Apple Geräte mögen das überhaupt nicht wenn der AP ihnen dauernd die Verbindung kappt, denn irgendwann verbinden sie sich gar nicht mehr automatisch wenn das zu häufig hintereinander passiert, dann muss der User manuell eingreifen und kurz WLAN OFF/ON oder explizit die SSID neu anklicken.

Dewr AP kappt niemals von sich aus die Verbindung. Jedenfalls nie sofern man kein aktives Roaming über die APs aktiviert hat. Stand alone APs so wie deiner oder solche die generell kein Roaming supporten wie die Masse der Controller losen Heim APs kappen also von sich aus niemals die Verbindung. Das lässt der WiFi Standard gar nicht zu !
In solchen WLAN herrscht immer ein Client basiertes Roaming !!
Sprich der Client selber entscheided wann er die Verbindung kappt und eine neue BSSID sucht. Hier machst du also einen entscheidenden Denkfehler.
-80 dBm ist aber auch schon die Untergrenze von Daten WLANs aber der es kritisch wird. Da endet man schon auf Connect Raten von 1 Mbit. Geht die Feldstärke noch weiter runter, also gegen -85 dBm und mehr sind Abrisse vorprogrammiert.
Was dann in solchen Bereichen noch geht oder nicht mehr geht ist dann in erheblichem Maße abhängig von der Trennschärfe und Empfindlichkeit eines WLAN Radios. In der Regel sind dann 1 Cip Geräte wie Smartphones usw. immer schlecht. Man muss sich nur mal HF technisch vorstellen was auf so engem Raum alles zusammengequetscht wird. Da ist Platz der entscheidende Faktor aber kein HF seitig sauberes Layout der Platine.
Folglich ist bei Smarthones, USB Sticks und allen Geräten wo es eng zugeht die Trennschärfe und Empfindlichkeit mau. Da geben dann Nachbarkanal Störungen und schlechte Feldstärke den geräten den Rest.
Da kommt man nur raus wenn man dafür sorgt das man eine saubere Kanalplanung hat mit mindestens 5 Kanälen Abstand, keine Störung von Nachbar WLANs, also auch hier 5 Kanäle Abstand. Und eine homogene Feldstärke die idealerweise niemals unter 70 dBm sinken sollte.
Diese simplen HF Binsenweisheiten sind vollkommen unabhängig von der verwendeten HW. Obwohl bei Billig HW auch immer die Radios gerade im HF Eingangsbereich schlecht designed sind.

Zitat von @aqui:

Dewr AP kappt niemals von sich aus die Verbindung.
Heim APs kappen also von sich aus niemals die Verbindung. Das lässt der WiFi Standard gar nicht zu !

Ich würde dir dringend mal dazu raten die Kommentare der Leute hier vor dem Antworten gründlicher zu lesen! Denn der TO wollte in den letzten beiden Posts mit Access-Listen des WiFi Interfaces den Bereich einschränken in dem sich ein Device noch mit dem AP verbinden kann. Und genau das tun die AccessListen am Mikrotik, sobald ein Client unter eine gewisse Feldstärke fällt kappt der AP die Verbindung mit dem Client mit einem Deauth Paket! Das ist Fakt, deine Antwort stimmt also generell so nicht, denn das Trennen von Clients kann der AP hiermit sehr wohl forcieren, und ebenfalls Verhindern das sich ein Client erneut verbinden kann sofern er weiterhin ein schlechteres Signal wie angegeben hat.
Und genau dieses Thema war hier in den letzten beiden Posts von mir und dem TO die Rede.

Das ist unbestritten richtig und nichts Gegenteiliges wurde gesagt. Nur das der AP selber nie den Deauth Frame sendet sondern in Client Roaming basierten WLANs immer der Client. Kann man übrigens auch mit dem Wireshark wunderbar sehen wenn man so einen Abbruch mal provoziert und das mitsniffert. Da eben wie gesagt Client basiertes Roaming bei Billig APs gemacht wird. In der Beziehung stimmt dann deine Antwort so auch nicht.
Der AP forciert es nur wenn er selber aktives Roaming macht und Clients damit entsprechend steuert andere BSSIDs zu suchen. Deauth Frames können generell beide Seiten senden was nebenbei ein großer Schwachpunkt vom WiFi Protokoll ist, da es dann einfach missbraucht werden kann.
Mit einem 3 Euro ESP 8266 Miniboard kann man ein ganzes WLAN problemlos lahm legen. Siehe:
https://github.com/spacehuhn/esp8266_deauther
Wenn also genau, dann auch richtig.
Aber auch an Ostern nicht abschweifen sonst hagelt es wieder Ermahnung richtig zu lesen...

Also zurück zum eigentlichen Thema !

Zitat von @aqui:

Das ist unbestritten richtig und nichts Gegenteiliges wurde gesagt.

Doch, genau das hast du, in einem Kontext der eben nicht zum Thema passte.

Nur das der AP selber nie den Deauth Frame sendet sondern in Client Roaming basierten WLANs immer der Client.

Es ging hier nicht ums Roaming!!

Da eben wie gesagt Client basiertes Roaming bei Billig APs gemacht wird. In der Beziehung stimmt dann deine Antwort so auch nicht.

Nochmal, es ging hier nicht ums Roaming.

Aber auch an Ostern nicht abschweifen sonst hagelt es wieder Ermahnung richtig zu lesen...

Genau, du schweifst hier nämlich vollkommen ab, Post des TO bitte sehr:
Mikrotik W-Lan - Wifi Probleme (Group Key Exchange Timeout)

Also zurück zum eigentlichen Thema !

Genau das solltest du unbedingt beherzigen, du sprichst hier nämlich eigentlich von Dingen die überhaupt nicht zur Debatte standen.
Also erst selbst mal an die Nase fassen statt hier den Leuten Dinge zu erzählen die überhaupt nicht zum Thema passen.

Da scheint jemand so überzeugt von sich selbst das er glaubt noch nicht mal mehr die Posts der TOs lesen zu müssen, einfach nur zum schiessen kann man da nur noch sagen...sorry Thema verfehlt, setzen sechs.

Frohes Eier schaukeln noch 😂.

Hallo,
sorry für meine späte Rückmeldung. Inzwischen scheinen die Probleme verschwunden zu sein, bzw. tauchen die group exchange timeout Meldungen nur noch auf, wenn ein Gerät sich nicht zwischen zwei Access Points mit der selben SSID entscheiden kann oder eben die Verbindung aufgrund eines schwachen Signals verliert.

Ich denke die Firmware Updates und das Finetuning der Einstellungen haben auch zur Lösung beigetragen.

Wer Probleme mit Apple Geräten hat, sollte vermutlichen auch diesen Hinweis im Mikrotik Wiki berücksichtigen:
https://wiki.mikrotik.com/wiki/Manual:Wireless_FAQ#Why_I_can.27t_connect ...

Vielen Dank noch einmal an alle für ihre Hilfe!

gelöst Frage Netzwerke LAN, WAN, Wireless

Mehr von Uwoerl

Mikrotik: Wireless Point to Point TrunkUwoerl - 6 Kommentare

Endgeräte wechseln zwischen zwei Access Points hin und herUwoerl - 15 Kommentare

Mikrotik Access Point - Probleme mit Multi-SSID und VlanUwoerl - 7 Kommentare

Freifunk über vorhandene Access Points ausstrahlenUwoerl - 23 Kommentare

Heiß diskutiert