Router OS is 6.44.3 on hEX and cAP AC
devices on the 2.4 radio are disconnecting from the wifi. Log into the router and check the logs and see…
(MAC of Devices) disconnect 4-way handshake timeout
Devices on 5Gig radio do not show this error.
Last time I reported this, support would send me one email per month… I removed the Tik Wireless and Went to Ruckus and stopped getting angry calls.
MIKROTIK SUPPORT…
I just submitted a support file via email. Please take a look at it and figure out what is wrong.
Took cAP out of caps-mode.
Same result. Well sort of. Log file showed unicast key time out.
Went back to caps mode and added an unencrypted SSID. Devices connected for about 10 seconds. Then I got a disconnected for extensive data loss.
Looked up several old posts tagged with extensive data loss. They all pointed to “interference”.
Changed the 2.4 channel between 1 6 and 11 and all had the same result.
Changed 2.4 channel to auto… cAP chose channel 3. Devices connected. One device still showed 4 way hand shake time out after reading the encryption… But 5 devices do connect to 2.4. During the whole problem… I could not get a client to connect to 2.4 at all.
Mikrotik wireless is coming out Tuesday. Will be trying the Ruckus R510 in the same spot.
Did the Ruckus work? I’ve never seem something like this, are you sure there is no jammer nearby? Jammers don’t show in any of the WiFi protocol scans.
I had exactly the same story on a big event with 12 sxt sq lite 2, it was awe full, i tried basically everything, for 5 hours, then i just moved to another brand then it worked…
I was also using CAPsMAN.
Because some vendors can deal with interference better than others.
I watched a YouTube video linked by Mikrotik. A “respected expert” talked all about frequencies and airtime and “when it’s out of space, it’s out of space.”
I call B–lshit!
I have seen “UniF–k” crumble under the same sort of stress.
But an 8 year old Ruckus systems “cuts right through it.”
Tech in the field (related to owner, so I was out ranked) insisted on putting in the cap AC he had in his truck.
In the days since. Customer has been pounding him with complaints for the last week. Calling everyday. We get into the configuration and try to adjust things… But this is another site where it’s just not going to work.
They have a Ruckus on one building and it has no problems at all. Where client devices transitions to the Tik wireless that “are in less important spots” (yeah… That was the excuse for adding in the Tiks where the Ruckus works) is proving a disaster.
70 bucks vs 270 bucks… I see why he tried it. But that 200 dollars cost us the customers confidence. Will probably have to take out everything, as they will likely not let us change out just the wireless.
Just to piss off the owner of the company… I sat on a site with them and demonstrated.
Put the client device password in.
Connected to the 5Ghz radio. Unit stayed connected.
Cut off the 5Ghz radio and enabled the 2.4 radio. Some devices connected but most didn’t.
Didn’t change ANYTHING but the manufacturer…
R510… All devices connected.
Cut off 2.4. devices that could moved to 5.
Cut off 5 and 2.4 back on… All clients connected and stayed connected.
The site had little to no interference, we set up a new capsman install with wAP AC APs, previously there was an older ubiquiti AP configured with the same SSID and security settings.
This led me to believe that issue had nothing to do with the environment. The clients that had the problem, were wireless printers, with some Hon hai WiFi chipset. The 4-way handshake timeout issues were all resolved by deleting the wireless config from the printers and setting them up again.
I have 2 RBcAPGi-5acD2nD, which are managed through capsman, but from different release batches. There was also a problem with 4-way handshake timeout after the channel setting handle on one of the access points.
Some devices connected normally, some did not switch from one point to the problem one and did not want to immediately connect to the problem point.
After a long search, I came across the Keenetic forum, where this problem was solved by disabling MU-MIMO and other things.
On my points in “current rate set” & “current basic rate set” the values did not match completely.
The problem was solved only after I put the problem point in the country “Germany”, it selected the channel automatically and the “current basic rate set” equaled at both points on OFDM: 6. I did not touch the other point after that.