Try setting key update to "1d 00:00:00"I dont understand, how it's possible to manufacture so called router os and still have this HUGE, 14 years nover solved problem?
How to fix it??? I have Shelly device, it connects to wifi and after few seconds receives "disconnected, unicast key exchange timeout, signal strength -52".
WHy this bug is not resolved and this IS bug 100%. Why i NEVER ever had any problems with ANY of my used non MikroTIk routers exept this one, Chateau LTE12.
Im not even talking about super duper unstable 5g wifi it have.
Group Key update is set to 35mins. NO matter this setting, no matter frequency..nothing matters... this is why this is bug and MikroTik fails to fix it 14 years already!
Using latest fw 7.2RC3, but this happens on ANY fw.
I have like 20 such devices... What a piece of sh. is MikroTik soft!
image_2022-01-30_171617.png
You giving 0 value to this topic so move on to some other topic. I provided all info needed - all the rest routers in the world works and MikroTik doesnt. That's it!So you have an issue and instead of posting with an actual question and your config, you wait 14 years and post a rant (without proofreading)?
Last time i had to deal with that issue was with some wireless automation devices that someone else had installed to a customer, it wasn't the password the problem in that case, but to my surprise it was the SSID name.2 hints seen in the forum:
No special characters in PSK: viewtopic.php?t=116480#p799611
Setting Advanced 'distance' to "indoors" instead of "dynamic" may stabilise the timing for key exchange. One can even set a value : viewtopic.php?p=900289#p900289
A bit rich. You haven’t provided and detail. Where are the steps to reproduce? Where is your config? What have you tried? Where is your MT ticket?You giving 0 value to this topic so move on to some other topic. I provided all info needed - all the rest routers in the world works and MikroTik doesnt. That's it!
This and the simple fact that MT WiFi still lacks MU-MIMO, Bandsteering, 802.11k/v/r mandated for almost all customer installation those days.Switching vendors for wifi was a bitter pill to swallow... But the amount of complaints and trouble tickets made it absolutely essential.
I agree with that. MikroTik are not in competition anymore in the indoor WiFi market. Their own fault.As a csutomer, it looks like MT has given up on WiFi after they lost touch with WiFi technology progress some 5 years ago.
Thank's to crappy Latvian english
MikroTik when logging error "unicast key exchange timeout" - they really mean INCORRECT PASSWORD!
RouterOs is crappy os.
easy one and advanced.
fanboys who are sooo USLESS in this forum, seen so many topic when those idiots just thinks that every user is god damn RouterOs wizard and knows every possible command...
The Truth Is Out There
Well, he is right. When you try to connect with an incorrect password, you get "unicast key exchange timeout" on the AP.MikroTik when logging error "unicast key exchange timeout" - they really mean INCORRECT PASSWORD!
I'm sure it means exactly what it says.
Well, he is right. When you try to connect with an incorrect password, you get "unicast key exchange timeout" on the AP.
I see indoor/outdoor/any under 'installation'.On wireless; "indoor" means 150 feet (46 meters) while outdoor means 300 feet. then you set "any" in "Installation".
interface wireless info country-info etsi
ranges: 2402-2482/b,g,gn20,gn40(20dBm)
5170-5250/a,an20,an40,ac20,ac40,ac80,ac160,ac80+80(23dBm)/passive,indoor
5170-5330/a,an20,an40,ac20,ac40,ac80,ac160,ac80+80(20dBm)/dfs,passive,indoor
5250-5330/a,an20,an40,ac20,ac40,ac80,ac160,ac80+80(20dBm)/dfs,passive,indoor
5490-5710/a,an20,an40,ac20,ac40,ac80,ac160,ac80+80(27dBm)/dfs,passive
5190-5310/a-turbo(20dBm)/dfs
5180-5300/a-turbo(20dBm)/dfs
5520-5680/a-turbo(27dBm)/dfs,passive
5510-5670/a-turbo(27dBm)/dfs,passive
902-927/b,g,g-turbo,gn20,gn40(30dBm)
Tuning is personal.set on-fail-retry-time=0.1s , set hw-retries=15, set frame-lifetime=1.6
I have read the documentation and the FAQ. I could not understand why would you want to keep packet on the router forever? Do you need packet after several seconds? We do not need them in our networks. Packet drops are not the worst. But, Disconnects are..I see indoor/outdoor/any under 'installation'.On wireless; "indoor" means 150 feet (46 meters) while outdoor means 300 feet. then you set "any" in "Installation".
Then there is indoors/dynamic for the 'Advanced Distance'
AFAIK and experienced, the installation "any/indoor/outdoor" is used as filter for the allowed frequencies for the choosen regulatory domain or country
Like in:E.g.for ETSI/Europe: Some frequencies (from 5180 till 5320) are allowed indoor only (forbidden to be used outdoor).Code: Select allinterface wireless info country-info etsi ranges: 2402-2482/b,g,gn20,gn40(20dBm) 5170-5250/a,an20,an40,ac20,ac40,ac80,ac160,ac80+80(23dBm)/passive,indoor 5170-5330/a,an20,an40,ac20,ac40,ac80,ac160,ac80+80(20dBm)/dfs,passive,indoor 5250-5330/a,an20,an40,ac20,ac40,ac80,ac160,ac80+80(20dBm)/dfs,passive,indoor 5490-5710/a,an20,an40,ac20,ac40,ac80,ac160,ac80+80(27dBm)/dfs,passive 5190-5310/a-turbo(20dBm)/dfs 5180-5300/a-turbo(20dBm)/dfs 5520-5680/a-turbo(27dBm)/dfs,passive 5510-5670/a-turbo(27dBm)/dfs,passive 902-927/b,g,g-turbo,gn20,gn40(30dBm)
E.g. for ETSI/Europe : 5500 till 5700 are higher power and not installation limited, so can be used anywhere (outdoor as well as indoor), but they must check for DFS (radar and weather radar detects)
Tuning is personal.set on-fail-retry-time=0.1s , set hw-retries=15, set frame-lifetime=1.6,
hw-retries=15 will allow 14 faulty transmissions before the software is informed about the failure. This will hold on the high interface rate somewhat longer, but will step down the interface rate only later (less dynamic behaviour)
set frame-lifetime=1.6 , is normally infinite. wifi does not drop a packet, until it disconnects
For me, first adjusted setting aims at a faster but more unstable wifi connection. The 2nd allows wifi to loose packets.
https://wiki.mikrotik.com/wiki/Manual:Wireless_FAQ
TCP congestion avoidance [Reno, new Reno, Cubic, Compound, ...) and queue rates, and Access List TX/RX rates, are not, and are not related to wifi interface rates (and encodings) (# of chains, HT MCS for 802.11ac, 6 to 54 Mbps per chain for n, VHT MCS for ax)If you used simple or interface queues, you will see lots of packet drops and retransmits, which are usual for TCP to tell server/CPE to lower the rate.
Yes, wifi rates are dynamic, while queues are static. But you dont want packet with 1.7s delay. Neither your routers cache.TCP congestion avoidance [Reno, new Reno, Cubic, Compound, ...) and queue rates, and Access List TX/RX rates, are not, and are not related to wifi interface rates (and encodings) (# of chains, HT MCS for 802.11ac, 6 to 54 Mbps per chain for n, VHT MCS for ax)If you used simple or interface queues, you will see lots of packet drops and retransmits, which are usual for TCP to tell server/CPE to lower the rate.
Wifi interface rates are seen in "Registrations" as [bandwidth MHz/interface rate Mbps/number of S(streams)] , those are not the TX/RX rates of the connection, or the IP rates, but are dynamicly related to the signal strength (SN ratio) and signal quality.
Wifi needs these dynamic rate settings to work in varying conditions. It almost always works, if allowed to adapt.
Normal wifi delivers packets in the correct sequence, unless you don't want/need this and fidle with the settings.
Not my experience. I do have many times a RADIUS controlled (EAP secured) wifi interface, where the added virtual wifi interfaces are WPA2/PSK secured. (A lot of devices have no means to handle username based EAP security. So they are given WPA2/PSK secured access)when you have virtual wireless interface and wireless security does not match main wireless interface's security,; this bug occurs.
hope this wireless driver bug can be fixed. thanks!
best regards & wishes.