14 years lasting BUG - disconnected, unicast key exchange timeout

On wireless; “indoor” means 150 feet (46 meters) while outdoor means 300 feet. then you set “any” in “Installation”.

I see indoor/outdoor/any under ‘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:

 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)

E.g.for ETSI/Europe: Some frequencies (from 5180 till 5320) are allowed indoor only (forbidden to be used outdoor).
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)


set on-fail-retry-time=0.1s , set hw-retries=15, set frame-lifetime=1.6

Tuning is personal. :slight_smile:,


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

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..

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.

Funny enough, if you unset update stats interval, you get ~1 second. but if you are going to set it, 10s is minimum, which is a bug IMHO..

My WISP friends tell me that use another brand for home setups, for sure..

Maybe thats because you cant set distance between 1-1000 meters? lots of disconnects due to ACK timeout?

I can understand that MT ROS is optimized for PtP long-distance links, but they could simply allow 0.N in distance, for example 0.1km for 100 meters.

Which is also bug and also feature request. Mikrotik Team should keep improving wireless package, and do not discontinue until all wave1 products are EOL for 7 years. Thats my opinion and I respect others, too.

And if station roaming means, unlocking from set frequency, and loss of the link, they could disable it altogether on station mode..

I am open to discuss your ideas. What do you think? We disabled it on stations, to be able to solve loss-of-strong-signal.

For example, in mobile (GSM) phones, it can receive signal (guess/observation) from about 32 base stations, without loosing link/lock.? Why wireless chips are not developed for proper roaming? Keep locked frequency working, while you scan other freqs?

Be aware of the min and max limits on the number and type of characters in SSID and PSK passwords.
These min/max limits and types are more restrictive with Mikrotik than with other brands.


Stick to the brands limitations. Happens everywhere:
Use a password with a “+” at the end of the password with Fortigate, and fail. (FortiOS 2012 version)

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.

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)
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.

removed by author

removed by author

What do you mean with “this bug”?

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)
Be aware of the usual “Access list” settings, to limit the allowed signal range, … it also sets the security (and VLAN). If not set up carefully, security key can change with the signal strength.

That’s how I make all my WPA2/PSK passwords to be MAC address unique. While most interactive connections are Username based.

removed by author

I solved setting the wpa rekey timeout to 24h.

Try to basic wlan to be wpa , and the SECOND to be open.

I had a similar issue, but it was more freakish due to being able to connect to the WiFi via other devices (able to connect on Samsung Android but not ThinkPad Windows)

I used the letter "ä" in my password, after changing it to something else (and in general not use non-standard characters), I was able to finally connect.

Personally I believe it's because Latvians do not appreciate Estonian alphabet's "ä"-letter.

This is a client problem.

Generally it's not wise to use special characters in passwords since it can cause unexpected results, as you have experienced.