Wireless bridge keeps deauthing

RouterOS Wireless Networking
1

I was forced to replace a vintage Engenius radio bridge with a Tranzeo SL2 tonight. Since then, the log has been filled with disconnection messages, mostly for “4-way handshake timeout.” Log file is attached as a file. Hardware retries were set to 4; raised them to 6 and then 8 and got no relief. AP configuration is:

 0  R name="AP" mtu=1500 mac-address=00:15:6D:64:4D:55 arp=enabled interface-type=Atheros AR5413 mode=ap-bridge 
      ssid="Call.623-640-7883" frequency=2462 band=2ghz-b channel-width=20mhz scan-list=default 
      wireless-protocol=unspecified antenna-mode=ant-a wds-mode=disabled wds-default-bridge=none wds-ignore-ssid=no 
      bridge-mode=enabled default-authentication=yes default-forwarding=yes default-ap-tx-limit=0 
      default-client-tx-limit=0 hide-ssid=no security-profile=RioVistaAP compression=no 

/interface wireless security-profiles print

 1 name="AP" mode=dynamic-keys authentication-types=wpa-psk,wpa2-psk unicast-ciphers=tkip group-ciphers=tkip 
   wpa-pre-shared-key="Whatever" wpa2-pre-shared-key="Whatever" supplicant-identity="AP" 
   tls-mode=no-certificates tls-certificate=none static-algo-0=none static-key-0="" static-algo-1=none static-key-1="" 
   static-algo-2=none static-key-2="" static-algo-3=none static-key-3="" static-transmit-key=key-0 
   static-sta-private-algo=none static-sta-private-key="" radius-mac-authentication=no radius-mac-accounting=no 
   radius-eap-accounting=no interim-update=0s radius-mac-format=XX:XX:XX:XX:XX:XX radius-mac-mode=as-username 
   radius-mac-caching=disabled group-key-update=5m management-protection=disabled management-protection-key=""

[/size]I saw this problem beaten to death [u]here[/u] with no real resolution. I am running 5.5 on my router, which is an RB433. The old Engenius had a solid radio connection with no dropouts of this type, but had to be replaced due to water damage. I am running out of radio brands to use as this bridge. Any suggestions?
log.0.txt (10.1 KB)

Client Disconnect Issues
2

Is this correct? I see no security profile with that name.

0 R name=“AP” mtu=1500 mac-address=00:15:6D:64:4D:55 arp=enabled interface-type=Atheros AR5413 mode=ap-bridge
ssid=“Call.623-640-7883” frequency=2462 band=2ghz-b channel-width=20mhz scan-list=default
wireless-protocol=unspecified antenna-mode=ant-a wds-mode=disabled wds-default-bridge=none wds-ignore-ssid=no
bridge-mode=enabled default-authentication=yes default-forwarding=yes default-ap-tx-limit=0
default-client-tx-limit=0 hide-ssid=no > security-profile=RioVistaAP > compression=no

/interface wireless security-profiles print

1 > name=“AP” > mode=dynamic-keys authentication-types=wpa-psk,wpa2-psk unicast-ciphers=tkip group-ciphers=tkip
wpa-pre-shared-key=“Whatever” wpa2-pre-shared-key=“Whatever” supplicant-identity=“AP”
tls-mode=no-certificates tls-certificate=none static-algo-0=none static-key-0=“” static-algo-1=none static-key-1=“”
static-algo-2=none static-key-2=“” static-algo-3=none static-key-3=“” static-transmit-key=key-0
static-sta-private-algo=none static-sta-private-key=“” radius-mac-authentication=no radius-mac-accounting=no
radius-eap-accounting=no interim-update=0s radius-mac-format=XX:XX:XX:XX:XX:XX radius-mac-mode=as-username
radius-mac-caching=disabled group-key-update=5m management-protection=disabled management-protection-key=“”

3

Assume they match. I massaged the posting by hand to remove immaterial identifying information, and missed one.

4

Assume they match.

Then assume it works! :smiley:

5

This isn’t really helping. This is a valid problem.

6

The Tranzeo engineer suggested I change the group key update time on the AP from the default 00:05:00 to 01:00:00, which is what the Tranzeo expects. It didn’t solve the seizures, it just cut them down to one per hour. He also suggested I set the unit to simple WPA/TKIP, which I did, but that doesn’t seem to have made a difference.

I’ve gone through two Tranzeos (both HW rev 2 and 3) and swapped out the AP radio card last night with a brand new one. I’ve never seen this behavior from other Tranzeos being used as CPEs on our other towers.

7

Guess I jinxed myself. The same problem just started happening on my oldest access point, an RB532, which was running 5.6, upgraded today to 5.7 but it didn’t help.

echo: wireless,info 00:13:4F:10:4C:D6@Town: connected
echo: wireless,info 00:13:4F:00:DE:F5@Town: connected
echo: wireless,info 00:13:4F:00:C3:15@Town: connected
echo: wireless,info 00:13:4F:10:4C:D6@Town: disconnected, received deauth: 4-way handshake timeout (15)
echo: wireless,info 00:13:4F:00:DE:F5@Town: disconnected, received deauth: 4-way handshake timeout (15)
echo: wireless,info 00:13:4F:00:C3:15@Town: disconnected, received deauth: 4-way handshake timeout (15)

[/size]
…over and over and over. And this time they are subscriber CPEs, not infrastructure bridges. I am going to have some peevish subscribers tomorrow morning. :frowning:

8

Looks like our problem was that our AP radio card (UBNT XR2) was going sour. It appears that one symptom of this is Tranzeos at the edge of their effective range start de-authing. Replaced the card with a fresh card and problems magically disappeared.

I’m going to post a copy of this diagnosis [u]here[/u] too, as I see many others have seen this problem.