Office test:
ePMP1000 intergrated
2 x ePMP-AP-GPSSync
8 on 10 times have error:
Invalid Wireless Security Key
What is wrong?
Both AP powered on. SM connected to AP2
I shutdown the AP2. SM scan and say "Rejected - Invalid Wireless Security Key" on AP1
Another error on AP1 say "Rejected - Generic Authentication Failure"
After 5 minutes SM connect on AP1
Why this behaviour?
Log on AP1 is:
Jan 1 00:40:23 Ronco 1 hostapd: ath0: STA 00:04:56:c4:74:a1 IEEE 802.11: deauthenticated due to local deauth request
Jan 1 00:40:23 Ronco 1 hostapd: ath0: STA 00:04:56:c4:74:a1 IEEE 802.11: disassociated
Jan 1 00:40:44 Ronco 1 hostapd: ath0: STA 00:04:56:c4:74:a1 IEEE 802.11: associated
Jan 1 00:40:52 Ronco 1 kernel: SM[00:04:56:c4:74:a1] aid=1 disassociated. Reason: INVALID SECURITY KEY
Jan 1 00:40:52 Ronco 1 hostapd: ath0: STA 00:04:56:c4:74:a1 IEEE 802.11: deauthenticated due to local deauth request
Jan 1 00:40:52 Ronco 1 hostapd: ath0: STA 00:04:56:c4:74:a1 IEEE 802.11: disassociated
Jan 1 00:41:13 Ronco 1 hostapd: ath0: STA 00:04:56:c4:74:a1 IEEE 802.11: associated
Jan 1 00:41:21 Ronco 1 kernel: SM[00:04:56:c4:74:a1] aid=1 disassociated. Reason: INVALID SECURITY KEY
Jan 1 00:41:21 Ronco 1 hostapd: ath0: STA 00:04:56:c4:74:a1 IEEE 802.11: deauthenticated due to local deauth request
Jan 1 00:41:21 Ronco 1 hostapd: ath0: STA 00:04:56:c4:74:a1 IEEE 802.11: disassociated
Jan 1 00:41:48 Ronco 1 hostapd: ath0: STA 00:04:56:c4:74:a1 IEEE 802.11: associated
Jan 1 00:41:48 Ronco 1 hostapd: ath0: STA 00:04:56:c4:74:a1 RADIUS: starting accounting session 0000048F-00000001
Jan 1 00:41:48 Ronco 1 hostapd: ath0: STA 00:04:56:c4:74:a1 WPA: pairwise key handshake completed (RSN)
Jan 1 00:41:54 Ronco 1 kernel: Adding WDS entry for 00:0c:42:c8:28:be, through ni=00:04:56:c4:74:a1
Jan 1 00:43:13 Ronco 1 kernel: Adding WDS entry for 90:02:a9:12:39:57, through ni=00:04:56:c4:74:a1
Log on SM:
Jan 1 01:29:03 Cambium-Device kernel: CCA receive level from HW, strong 10, weak 2
Jan 1 01:29:03 Cambium-Device kernel: Flags 0, Scheduler Mode 0
Jan 1 01:29:03 Cambium-Device kernel: connection is UP
Jan 1 01:29:03 Cambium-Device kernel: br-lan: port 2(ath0) entering forwarding state
Jan 1 01:29:03 Cambium-Device kernel: Adding WDS entry for 78:92:9c:5b:f9:6a, through ni=00:04:56:ce:a1:a0
Jan 1 01:29:04 Cambium-Device kernel: Adding WDS entry for bc:cd:45:02:02:4a, through ni=00:04:56:ce:a1:a0
Jan 1 01:29:06 Cambium-Device kernel: Adding WDS entry for 00:15:58:a0:df:4f, through ni=00:04:56:ce:a1:a0
Jan 1 01:29:11 Cambium-Device kernel: SM disassociated from AP[00:04:56:ce:a1:a0] F=5500 11naht20. Reason: 49 (INVALID SECURITY KEY)
Jan 1 01:29:11 Cambium-Device kernel: br-lan: port 2(ath0) entering disabled state
Jan 1 01:29:28 Cambium-Device kernel: TPC set initial Tx-Power to 12dbm
Jan 1 01:29:52 Cambium-Device kernel: CCA receive level from HW, strong 10, weak 2
Jan 1 01:29:52 Cambium-Device kernel: Flags 0, Scheduler Mode 0
Jan 1 01:29:52 Cambium-Device kernel: connection is UP
Jan 1 01:29:52 Cambium-Device kernel: br-lan: port 2(ath0) entering forwarding state
Jan 1 01:30:00 Cambium-Device kernel: SM disassociated from AP[00:04:56:ce:a1:a0] F=5500 11naht20. Reason: 49 (INVALID SECURITY KEY)
Jan 1 01:30:00 Cambium-Device kernel: br-lan: port 2(ath0) entering disabled state
Jan 1 01:30:17 Cambium-Device kernel: TPC set initial Tx-Power to 11dbm
Jan 1 01:30:31 Cambium-Device kernel: CCA receive level from HW, strong 10, weak 2
Jan 1 01:30:31 Cambium-Device kernel: Flags 0, Scheduler Mode 0
Jan 1 01:30:31 Cambium-Device kernel: connection is UP
Jan 1 01:30:31 Cambium-Device kernel: br-lan: port 2(ath0) entering forwarding state
Jan 1 01:30:33 Cambium-Device kernel: Adding WDS entry for 30:65:ec:77:49:f2, through ni=00:04:56:ce:a1:a0
Jan 1 01:30:39 Cambium-Device kernel: SM disassociated from AP[00:04:56:ce:a1:a0] F=5500 11naht20. Reason: 49 (INVALID SECURITY KEY)
Jan 1 01:30:39 Cambium-Device kernel: br-lan: port 2(ath0) entering disabled state
Jan 1 01:30:56 Cambium-Device kernel: TPC set initial Tx-Power to 12dbm
Jan 1 01:30:57 Cambium-Device kernel: CCA receive level from HW, strong 10, weak 2
Jan 1 01:30:57 Cambium-Device kernel: Flags 0, Scheduler Mode 0
Jan 1 01:30:57 Cambium-Device kernel: connection is UP
Jan 1 01:30:58 Cambium-Device kernel: br-lan: port 2(ath0) entering forwarding state
Jan 1 01:31:06 Cambium-Device kernel: SM disassociated from AP[00:04:56:ce:a1:a0] F=5500 11naht20. Reason: 49 (INVALID SECURITY KEY)
Jan 1 01:31:06 Cambium-Device kernel: br-lan: port 2(ath0) entering disabled state
Jan 1 01:31:22 Cambium-Device kernel: TPC set initial Tx-Power to 11dbm
Jan 1 01:31:29 Cambium-Device kernel: CCA receive level from HW, strong 10, weak 2
Jan 1 01:31:29 Cambium-Device kernel: Flags 0, Scheduler Mode 0
Jan 1 01:31:29 Cambium-Device kernel: connection is UP
Jan 1 01:31:29 Cambium-Device kernel: br-lan: port 2(ath0) entering forwarding state
Jan 1 01:31:37 Cambium-Device kernel: SM disassociated from AP[00:04:56:ce:a1:a0] F=5500 11naht20. Reason: 49 (INVALID SECURITY KEY)
Jan 1 01:31:37 Cambium-Device kernel: br-lan: port 2(ath0) entering disabled state
Jan 1 01:31:54 Cambium-Device kernel: TPC set initial Tx-Power to 11dbm
Jan 1 01:32:10 Cambium-Device kernel: CCA receive level from HW, strong 10, weak 2
Jan 1 01:32:10 Cambium-Device kernel: Flags 0, Scheduler Mode 0
Jan 1 01:32:10 Cambium-Device kernel: connection is UP
Jan 1 01:32:10 Cambium-Device kernel: br-lan: port 2(ath0) entering forwarding state
Jan 1 01:32:13 Cambium-Device kernel: Adding WDS entry for c0:3f:d5:f0:4f:1b, through ni=00:04:56:ce:a1:a0
Jan 1 01:32:18 Cambium-Device kernel: SM disassociated from AP[00:04:56:ce:a1:a0] F=5500 11naht20. Reason: 49 (INVALID SECURITY KEY)
Jan 1 01:32:18 Cambium-Device kernel: br-lan: port 2(ath0) entering disabled state
Jan 1 01:32:35 Cambium-Device kernel: TPC set initial Tx-Power to 11dbm
Jan 1 01:32:38 Cambium-Device kernel: CCA receive level from HW, strong 10, weak 2
Jan 1 01:32:38 Cambium-Device kernel: Flags 0, Scheduler Mode 0
Jan 1 01:32:38 Cambium-Device kernel: connection is UP
Jan 1 01:32:38 Cambium-Device kernel: br-lan: port 2(ath0) entering forwarding state
Jan 1 01:32:47 Cambium-Device kernel: SM disassociated from AP[00:04:56:ce:a1:a0] F=5500 11naht20. Reason: 49 (INVALID SECURITY KEY)
Jan 1 01:32:47 Cambium-Device kernel: br-lan: port 2(ath0) entering disabled state
Jan 1 01:33:04 Cambium-Device kernel: TPC set initial Tx-Power to 11dbm
Jan 1 01:33:07 Cambium-Device kernel: CCA receive level from HW, strong 10, weak 2
Jan 1 01:33:07 Cambium-Device kernel: Flags 0, Scheduler Mode 0
Jan 1 01:33:07 Cambium-Device kernel: connection is UP
Jan 1 01:33:07 Cambium-Device kernel: br-lan: port 2(ath0) entering forwarding state
Jan 1 01:33:16 Cambium-Device kernel: SM disassociated from AP[00:04:56:ce:a1:a0] F=5500 11naht20. Reason: 49 (INVALID SECURITY KEY)
Jan 1 01:33:16 Cambium-Device kernel: br-lan: port 2(ath0) entering disabled state
Jan 1 01:33:27 Cambium-Device kernel: TPC set initial Tx-Power to 11dbm
Jan 1 01:33:43 Cambium-Device kernel: CCA receive level from HW, strong 10, weak 2
Jan 1 01:33:43 Cambium-Device kernel: Flags 0, Scheduler Mode 0
Jan 1 01:33:43 Cambium-Device kernel: connection is UP
Jan 1 01:33:43 Cambium-Device kernel: br-lan: port 2(ath0) entering forwarding state
Jan 1 01:33:43 Cambium-Device kernel: SM associated with AP[00:04:56:ce:a1:a0]
Jan 1 01:33:47 Cambium-Device ifup: Allowing Router Advertisements on lan (br-lan)
Jan 1 01:33:47 Cambium-Device firewall: removing lan (br-lan) from zone lan
Jan 1 01:33:49 Cambium-Device firewall: adding lan (br-lan) to zone lan
Jan 1 01:33:49 Cambium-Device kernel: Adding WDS entry for 00:0c:42:c8:28:be, through ni=00:04:56:ce:a1:a0
Jan 1 01:34:42 Cambium-Device kernel: Adding WDS entry for ec:a8:6b:da:d8:be, through ni=00:04:56:ce:a1:a0
Jan 1 01:35:08 Cambium-Device kernel: Adding WDS entry for 90:02:a9:12:39:57, through ni=00:04:56:ce:a1:a0
Jan 1 01:37:16 Cambium-Device kernel: Adding WDS entry for a4:ee:57:e5:e7:dc, through ni=00:04:56:ce:a1:a0
Jan 1 01:37:32 Cambium-Device kernel: Adding WDS entry for c8:85:50:ad:74:d1, through ni=00:04:56:ce:a1:a0
Hi Mirko,Â
This is a unique issue. One thing that I see is that your DL RSSI is very high. I see it anywhere between -38 and -29 dB. At this level, the reciever may be getting saturated and causing issue. Can you try dropping the Tx power on the AP so the RSSI falls below -40 (ideally in the -50s). This way, we can be sure something else is the issue.Â
Thanks,
Sriram
I drop the tx-power on both AP. Now SM see these:
So, after shut down the AP2 the SM scan and at first time see "Invalid Wireless Security Key"
But after a while it associate to AP1
Ok, seems to be faster than yesterday
But then the error of the wireless key has nothing to do with the key, but it's a saturation?
You might change log label
Why also have another one error in scan with a -52?
And what is the recommended maximum RSSI signal before encounter problems? (-40 ??)
We too have seen this, almost exclusively with ePMP PtP links using WPA2 TDD. (not seen [yet] with ePtP mode) Â My usual fix has been to enable unencrypted connections at the slave/SM end in advance, and when we lose the link and it has endless security key errors trying to restore, I disable WPA2 on the master and it connects immediately, and usually when I re-enable WPA2 at that point it again connects immediately.
Brought to the attention of Cambium engineers about 10 months ago, still see it happen occasionally.
j
It sure would be nice to have a ''test'' mode, or to have an ''activate without saving'' mode, and then to be able to reboot to last settings if it can't ping some IP for some period of time. It's tricky to make changes to a link remotely, and yet risk one wrong move that may make the remote side unreachable.
Our other (non-Cambium gear)has a ''ping watchdog'' and that allows us to make and try temporary setting remotely, and if the remote side can't relink, it'll reboot after our 'timeout' back to the previous settings.
Because, the problem persists even when the signal around -50, I opened a ticket assistance.
Seems to me, a software bug
Same problem here. Â We've had to disable WPA2 on all of our ptp links.
Disable WPA2 is like leaving the door open.
This is a bug and should be solved urgently.
I have set up a network in PTMP and it is unthinkable to leave it open
Excuse me, but you have reported the behaviour to Cambium Support?
Just to clarify my work-around, we don't leave the links running unsecured. Â I keep the slave end locked to the master's SSID, and permit both Open and WPA2.
When a problem arises (rarely, to be honest) I disable WPA2 on the master, the client reconnects, I re-enabled WPA2 on the master, the client reconnects. Â I've still not been able to perceive a pattern in when/how it happens, it's been very infrequent but still occurs.
j
Has anyone seen this issue lately?Â
I know it's a pretty old thread, but sounds like exactly what I've been experiencing lately.
I've seen it here and there, but I'm seeing it more lately on my new EPMP PTMP installations only on a new sector with no other connections. It always seems to be the first SM to connect that has the issue. As soon as I figure out how to get that first one connected, everyone else seems to connect fine. It goes back and forth between the "rejected - invalid wireless security key" or no gps available from the AP. (but we aren't running gps sync)
Thanks,
Ryo
So Guys was this ever correted? I'm still seeing this with or without a Cmm. On new firmware or 3.3 or 3.4 ecetera. Obiously I don't want to run these units open.
this can happen from interference, saturated receivers and most any other kind of signaling issue.  the handshake is done on the management level, and will not retry a packet. if something corrupts during the auth portion, its dropped.  running your radios to hot WILL cause issues. co-band noise can be a factor.  sync can clean it out, but running in PTP mode, you're probably not synced with your local cluster and can have some issues with it. physical separation or good band spacing can fix it.  anything below 40db, over time, can physically harm the APs. if you don't need the power as high, back it down to 50db to stop those issues.Â
I noticed your modulations were very low, do they move up to MCS15 once the load is applied? if not I'd be looking to figure out what noise you are fighting with, that's also likely causing your handshake problems too.
EPMP2000s can be used as slaves in PTP links when co-band noise is bothering them too FYI.  Â
1 Like