Hi there! I am experiencing sudden AP clients drop. First I thought it is interference, but it happens end of the month on different APs. I have also done this attack but to UBNT successfully.
Is there any plans on implementing defence against such attack?
How it works:
The hacker makes an AP with Same SSID and Same BSSID with no encryption at all, or with random WPA2 passphrase, then the stations start to reconnect to the fake AP with no luck, and the they jump from AP to AP trying to pass the data.
If there is no encryption on the fake AP, stations can stuck there forever.
The attack is easy reproduced with a Mtik AP in superchannel mode.
To resolve this i think there should be some extra checksum mechanism or some sort of plain text extra field(Easier for CPU) in the control packet which Stations should check all the time.
Any thoughts on how to overcome this now?
I gues also it is pointless to search for the device as if it is close to AP , the RSSI will be almost same.
If you use a FIPS compliant WPA2 password on the SM, they should not connect to a fake AP which has open/no encryption. ePMP SMs give you the option of enabling multiple security options - Open, WPA2 and RADIUS. Disable the "Open" option on the SMs. Even better, use RADIUS and you have an added layer of security where network entry is controlled by your RADIUS server.
The air interface in ePMP uses 128 bit AES encryption. Therefore its highly unlikely that a hacker can sniff and obtain information.
Hi there! I am experiencing sudden AP clients drop. First I thought it is interference, but it happens end of the month on different APs. I have also done this attack but to UBNT successfully.
Is there any plans on implementing defence against such attack?
How it works:
The hacker makes an AP with Same SSID and Same BSSID with no encryption at all, or with random WPA2 passphrase, then the stations start to reconnect to the fake AP with no luck, and the they jump from AP to AP trying to pass the data.
If there is no encryption on the fake AP, stations can stuck there forever.
The attack is easy reproduced with a Mtik AP in superchannel mode.
To resolve this i think there should be some extra checksum mechanism or some sort of plain text extra field(Easier for CPU) in the control packet which Stations should check all the time.
Any thoughts on how to overcome this now?
I gues also it is pointless to search for the device as if it is close to AP , the RSSI will be almost same.
Out of curiosity, was this done in standard wifi mode ?
Yes, it is preferred on all of the clients, wpa2 is the only enabled security. The AP just keeps losing stations with error "Communication lost" and will not let them reconnect until reboot
"The AP just keeps losing stations with error "Communication lost" and will not let them reconnect until reboot"
Most likely not an attack.. well maybe the ePMP firmware attacking itself... but a recurring / known bug. I think the current 4x has this problem (mostly with non AC clients ?). Not sure if the 4.4beta fixes it or not.
Hi, for my 2c I agree - I think you're seeing that bug where the clients can disconnect and a reboot is needed to get them to reassociate. I think most people are reporting that 4.4-RC30 mostly fixes that - or improves it greatly for most people. Also, some people have reported that it's important to have it in both the primary and backup firmware bank on radios which have two banks.
We've found that (for AC or Compatibility Mode) that the latest RC is far and away the best. I'm usually hesitant to put anything 'beta' anywhere in production, but the Release Candidates like RC30 have been better than 4.x.anything.else in my opinion. :)
From my standpoint, I think most of Cambium's issues in the last several month's have been with the daunting (and admirable) task of backwards and forwards compatibilities - but also in my opinion, I think each bug is getting solved & squashed fairly steadily.
Hi, for my 2c I agree - I think you're seeing that bug where the clients can disconnect and a reboot is needed to get them to reassociate. I think most people are reporting that 4.4-RC30 mostly fixes that - or improves it greatly for most people. Also, some people have reported that it's important to have it in both the primary and backup firmware bank on radios which have two banks.
We've found that (for AC or Compatibility Mode) that the latest RC is far and away the best. I'm usually hesitant to put anything 'beta' anywhere in production, but the Release Candidates like RC30 have been better than 4.x.anything.else in my opinion. :)
From my standpoint, I think most of Cambium's issues in the last several month's have been with the daunting (and admirable) task of backwards and forwards compatibilities - but also in my opinion, I think each bug is getting solved & squashed fairly steadily.
Thanks for the response Todd. Its actually mandatory that Force 300-16s are upgraded twice if continuous reboot or disconnects are seen. We are very close to an official 4.4 release (few days) and there are additional stability fixes between RC30 and official 4.4.
I am now also thinking it is not an attack, but what is that then? I happens randomly on many one of my 3 BS. Yes, we have a lot of interference, but it happens on high MCS an Uplink/Downlink quality.