New Member
Posts: 5
Registered: ‎09-16-2016

Re: 4-way keying handshake timeout

Hi I am having the same problem with my newly purchased powerbeam m5 400..

It connects to a powerstation and a powerbridge. When I set security to none it works perfectly

when I use either wpa2 or wpa ... failures.

 

wireless: ath0 Sending deauth to dc:9f:db:2e:13:c6. Reason: 4-way keying handshake timeout (15).

 

I am using the lastest firmware with no luck.. 

any solution to this?

 

thanks

Zakir

Established Member
Posts: 859
Registered: ‎09-03-2009
Kudos: 44
Solutions: 7

Re: 4-way keying handshake timeout

i encounter the same problem last night and i decided to upgrade my firmware to XC.v7.2.4.31259.160714.1715. im using rocket ac lite in 40 km.

Skype: nanflexal
WISP - Bicol Region, Philippines
www.adamosbroadband.com
New Member
Posts: 1
Registered: ‎01-25-2017

[SOLVED] Re: 4-way keying handshake timeout

[ Edited ]

I am using v5.6.9-cs.29546 (XM) on an NSM2 in Wifi mode (not wimax), and I can confirm it suffers from this rekeying timeout bug. Each client would disconnect 1:00:15 after connecting, and every hour afterwards, though occasionally they would stay connected for two hours, indicating that the rekey does succeed sometimes. On this AP traffic totals less than 3Mbps, with a dozen clients relying on it for service.

 

I found that the solution suggested at the following URL works for me:

 

https://community.ubnt.com/t5/Installation-Troubleshooting/Rocket-M5ti-clients-being-dropped/m-p/120...

 

The summary is:

 

echo "aaa.1.wpa.group_rekey=0" >> /tmp/system.cfg
save
/usr/etc/rc.d/rc.softrestart save

 

My understanding is that this disables group rekeying entirely, and thus defeats a security measure built into the 802.11 standard, but it improves the experience of the users, as they no longer disconnect every hour.

 

Edit: I should mention that the AP consistently reports 4-way keying timeouts for one of the clients, even after this fix. However, this particular client also has consistently low signal (-73dB) and low CCQ (50-93%). It disconnects often, and its keying timeouts occur immediately after authentication (WPA-EAP, same as all the clients). I suspect it is really having trouble communicating over radio, and the timeouts may be legitimate.

 

Regards,

Todd

Veteran Member
Posts: 5,068
Registered: ‎03-02-2015
Kudos: 1003
Solutions: 230

Re: 4-way keying handshake timeout

yes your guess is right.... poor connection leads to disconnects with all your troubles on that one radio.
===================================================
We all work for KUDOs here.
Thx
New Member
Posts: 2
Registered: ‎12-15-2016

Re: 4-way keying handshake timeout

yes i had to put security off WPA2-AES does not correctely Putting security in none resolve the problem. XC.v7.2.1 firmware is in problems

Ubiquiti Employee
Posts: 11,657
Registered: ‎04-14-2017
Kudos: 2182
Solutions: 335

Re: 4-way keying handshake timeout

Have you tried more recent firmware?
New Member
Posts: 16
Registered: ‎02-20-2015
Solutions: 3

Re: 4-way keying handshake timeout

have the same ptoblem :

4-way keying handshake timeout (15)

in a NanoStation Loco M5, I 'd take out the WPA2 secutiry, and now is working,....with no security Man Happy

 

The firmware is: v6.1.0 (XW). Distance 0.2miles

Established Member
Posts: 1,609
Registered: ‎10-11-2009
Kudos: 337
Solutions: 6

Re: 4-way keying handshake timeout

I'm having the same problem with an AC sector with only one AC client connected to it.  VERY STRANGE behavior.

 

https://community.ubnt.com/t5/airMAX-AC/8-4-0-8-4-1-Stop-passing-traffic/m-p/2098951#M25807

 

I'm having a rash of traffic stopping issues as well since we started deploying this firmware.  The weirdest one I'm looking at now is the sector AP doesn't even show that the CPE is connected to it but I'm seeing the station IP and the router beyond its IP show up with no arp value in the ARP table. The router log will also show 6 times a min "PPPoE connection established from (the MAC on their router)" beyond the CPE indicating to me the CPE is connected. On the sector its showing this in the log:

 

Oct 15 19:44:57 wireless: ath0     Authenticated Station f0:9f:c2:50:69:cc (Successful)

Oct 15 19:44:57 wireless: ath0     Sending auth to f0:9f:c2:50:69:cc. Status: Successful (0).

Oct 15 19:44:57 hostapd: ath0: STA f0:9f:c2:50:69:cc IEEE 802.11: associated

Oct 15 19:44:57 wireless: ath0     Received assoc_req from f0:9f:c2:50:69:cc.

Oct 15 19:44:57 wireless: ath0     Sending assoc_resp to f0:9f:c2:50:69:cc. Status: Successful (0).

Oct 15 19:44:57 wireless: ath0     Registered node:F0:9F:C2:50:69:CC

Oct 15 19:45:01 hostapd: ath0: STA f0:9f:c2:50:69:cc IEEE 802.11: disassociated

Oct 15 19:45:01 wireless: ath0     Sending disassoc to f0:9f:c2:50:69:cc. Reason: 4-way keying handshake timeout (15).

Oct 15 19:45:01 wireless: ath0     Expired node:F0:9F:C2:50:69:CC

Oct 15 19:45:26 wireless: ath0     Received auth from f0:9f:c2:50:69:cc. Status: Successful (0).

Oct 15 19:45:26 wireless: ath0     Authenticated Station f0:9f:c2:50:69:cc (Successful)

Oct 15 19:45:26 wireless: ath0     Sending auth to f0:9f:c2:50:69:cc. Status: Successful (0).

Oct 15 19:45:26 wireless: ath0     Received assoc_req from f0:9f:c2:50:69:cc.

Oct 15 19:45:26 wireless: ath0     Sending assoc_resp to f0:9f:c2:50:69:cc. Status: Successful (0).

Oct 15 19:45:26 wireless: ath0     Registered node:F0:9F:C2:50:69:CC

Oct 15 19:45:26 hostapd: ath0: STA f0:9f:c2:50:69:cc IEEE 802.11: associated

Oct 15 19:45:30 wireless: ath0     Sending disassoc to f0:9f:c2:50:69:cc. Reason: 4-way keying handshake timeout (15).

Oct 15 19:45:30 hostapd: ath0: STA f0:9f:c2:50:69:cc IEEE 802.11: disassociated

Oct 15 19:45:30 wireless: ath0     Expired node:F0:9F:C2:50:69:CC

I've never seen this behavior before in the last 8 years we've been running UBNT gear.   

Ubiquiti Employee
Posts: 11,657
Registered: ‎04-14-2017
Kudos: 2182
Solutions: 335

Re: 4-way keying handshake timeout

@russman We are looking into this.
New Member
Posts: 18
Registered: ‎02-27-2014

Re: 4-way keying handshake timeout

Any update on this?

Highlighted
New Member
Posts: 18
Registered: ‎02-27-2014

Re: 4-way keying handshake timeout

Trying the 9 character key that others say works. I was using a longer one. Had one handshake error and then hooked up right away. Before it would take about a minute or two to finally connect.

 

Will post back the results as time progresses.

 

Oddly enough I have a similar key in other links without issue.

New Member
Posts: 18
Registered: ‎02-27-2014

Re: 4-way keying handshake timeout

Setting the pass phrase down to the minimum 8 characters seem to cause less disconnects and then it seemed that it only occured at night where there was low/no usage.

 

Other observations is site survey sends it off into this keying  failure (15). Logging at the other end yeilded no fruitful information.

 

Only had one disconnect during the day (with multiple over night) but that was enough and I reverted back to no encryption,

 

Without encryption the link stays up flawlessly.

 

Implimented no rekey on the AP

 

echo "aaa.1.wpa.group_rekey=0" >> /tmp/system.cfg
save
/usr/etc/rc.d/rc.softrestart save

Established Member
Posts: 859
Registered: ‎09-03-2009
Kudos: 44
Solutions: 7

Re: 4-way keying handshake timeout


@markus411 wrote:

 

 

Without encryption the link stays up flawlessly.

 


Yeah. I do this before. it should my problem

Skype: nanflexal
WISP - Bicol Region, Philippines
www.adamosbroadband.com
New Member
Posts: 18
Registered: ‎02-27-2014

Re: 4-way keying handshake timeout

Up 3+ days no disconnections but no renewing the security keys. Worst case senario I could change keys in off hours. Still not ideal though.

 

There are a couple of threads that refer to the issue and suggest different potential solutions.

 

One suggests that devices with macs starting 00:27:22 have had issues requiring special firmware (maybe the special firmware was changing the rekeying to 0 anyhow). There seemed to be no conclusive results indicated in the posts. I do have a couple of newer M2s that have different macs which I may try as a last resort (I want to try exhausting configuration changes first).

 

Second is to switch the operating modes (ap and client) of the devices. Since this is a PtP link I could do that and I will try that next.

 

Mark

 

 

New Member
Posts: 18
Registered: ‎02-27-2014

Re: 4-way keying handshake timeout

Changing operating modes did nothing. Tried it twice, no successful negotiation at all. So I switched it back.

 

Managed to change aaa.1.wpa.group_rekey=0 to 86400 which will limit the group key change to 24 hours. Also noticed from the logs that if the key change took some time to re-establish it was the time from the reestablishment that the next key change took place. I may have to force an adjustment in the distant future if it gets close to a non desirable hour.

 

Have done a lot of reading about 4 way authentication and keying looking at what changes I can make to try to get this to at least establish quicker.

 

One thing I noticed is that although I often see link speeds of 150 they will go as low as 120 maybe lower the odd time. Since MCS4 is the upper end of 16qam I set it there as the max and bingo it hooked up in two or three attempts. I know the link is not perfect but when on MCS7 I can get upwards of 54Mb and I am unlikely to see that on MCS 4 so I set it at MCS5 and it hooks up in a reasonable number of attempts (~4).  Going to watch/play with this for the next couple of days.

 

Still using the 8 character key and not liking it (particularly if I only exchange keys once a day) decided now might be a good time to try a full 63 character key. The link authenticated in a reasonable number of attempts.

 

Tomorrow I will speed test the link out and monitor the logs.

 

Mark

New Member
Posts: 18
Registered: ‎02-27-2014

Re: 4-way keying handshake timeout

Bingo was short lived.

 

Never got to checking speed at the distant end.

 

It did the key renewal at the 24 hour time without issue the first time. Second time it took about 6-7 minutes to establish the connection.  This is with MCS turned down and 63 character key. Except that it only changes the group key once a day I could live with this. The third 24 hour key change took 1 minute. However this morning (not at the time its suppose to) out of the blue it disconnects for 8 minutes. Hmm, I understand if the power is disconnected or there is significant interference then a disconnect could occur. Logs at either end don't show power failure. Not ruling out interference but this is relatively remote site. Not certain why the key change is initiated but did look for aaa setup to extend traffic volume initiated key change. Didn't find anything but that matters little as this ultimately does not remedy the actual problem.

 

If wpa is turned off I have 0 connection issues. So far any changes made seem to have little impact.

 

This morning set Airmax off and put MCS back to 7 and it hooked up immediately. Going to do some testing tomorrow morning with group rekeying if I don't have further issues today.

 

Mark

Ubiquiti Employee
Posts: 11,657
Registered: ‎04-14-2017
Kudos: 2182
Solutions: 335

Re: 4-way keying handshake timeout

Your link performance will typically suffer with airMAX off.
New Member
Posts: 18
Registered: ‎02-27-2014

Re: 4-way keying handshake timeout

Yes, I know. I like what it does but having the link disconnect and/or not having encryption on and updating like it should is not really what I want either.

 

We will see what it does for the weekend. If leaving Airmax off solves my issues with WPA then I might have to be satisfied with the poorer performance till I can figure out what is going on.

 

Mark

New Member
Posts: 18
Registered: ‎02-27-2014

Re: 4-way keying handshake timeout

I wanted to do a bandwidth test at the end of the link before I reported back my findings.

 

The current settings on my M2 PtP are:

Airmax = off

Channel width = 40

WPA2 = 63 character key

WPA group rekey = 10 minutes (just to give it lots of chances to fail)

the rest is standard stuff

 

I've played around with channels, acks, mcs, extension channels, data rate modules, frequency lists, wpa key lengths, and wpa group rekeying time.  None made the link completely stable (the users would notice outages at some point).

 

Bandwidth test yielded similar throughput (54Mb user data, not perfect but good enough) as when I had Airmax on with no encryption (which was the only way I could get the link to remain hooked up without reporting errors).

 

With Airmax off and encryption turned on there are no logged issues with the group rekeying (doing the rekey every ten minutes) any longer.

 

Not that Airmax is really needed (because of this link is in a remote location and is certainly not subject to interference like my other links which have different equipment) but what would cause this in Airmax?

 

I might try bumping up  the hop interval from default (3seconds). That is a job for off hours.

 

I still have the option to replace the hardware as someone had mentioned that in another post as being a possible issue but did not report back if they did or the results.

 

Mark

 

Established Member
Posts: 1,609
Registered: ‎10-11-2009
Kudos: 337
Solutions: 6

Re: 4-way keying handshake timeout

[ Edited ]

@UBNT-SNK wrote:
@russman We are looking into this.

Any updates on this?  We have some 900Mhz gear that is in a super clean area all clients have 92% CCQ or higher and half the clients are disconnected at a time. The AP was on 6.13 and for testing we switched to 6.14-RC to see if the clients not connecting would reconnect but it didn't help.

 

Log is pages of:

Jun  2 00:10:24 hostapd: ath0: STA dc:9f:db:04:10:31 IEEE 802.11: associated
Jun  2 00:10:26 wireless: ath0     Sending deauth to 68:72:51:40:b4:a4. Reason: 4-way keying handshake timeout (15).
Jun  2 00:10:26 wireless: ath0     STA-TRAFFIC-STAT mac=68:72:51:40:b4:a4 rx_packets=0 rx_bytes=0 tx_packets=4 tx_bytes=428
Jun  2 00:10:26 wireless: ath0     Expired node:68:72:51:40:B4:A4
Jun  2 00:10:26 hostapd: ath0: STA 68:72:51:40:b4:a4 IEEE 802.11: disassociated
Jun  2 00:10:27 wireless: ath0     Registered node:68:72:51:40:B4:A4
Jun  2 00:10:27 hostapd: ath0: STA 68:72:51:40:b4:a4 IEEE 802.11: associated
Jun  2 00:10:28 wireless: ath0     Sending deauth to dc:9f:db:04:10:31. Reason: 4-way keying handshake timeout (15).
Jun  2 00:10:28 wireless: ath0     STA-TRAFFIC-STAT mac=dc:9f:db:04:10:31 rx_packets=0 rx_bytes=0 tx_packets=4 tx_bytes=428