After almost a week waking up in hourly basis by the gentle voice of Dude notification ... "XXX router is down" ... and watch at it's terminal a Kernel failure message, and a dozen e-mails exchanged with Janis (tanks sir), seems that the cause was found.

Scenario:

RB433UAH or RB433AH, 2 X R52nM on 2.4GHz, legacy mode only G, AP1 20MHz BW, AP2 10MHz BW, aprox 35 CPEs each AP, peak authenticated = 30 + 30, Nano2 Loco & Nano2 Loco M.

* Authentication type = WPA2-PSK, encription = AES: Kernel failure folowed by router reboot 5 ... 15 times a day.
* Authentication type = WPA-PSK, encription = AES: Kernel failure folowed by router reboot 5 ... 15 times a day.
* Authentication type = WPA2-PSK, encription = TKIP: Not tested, it's not a standard anyway.
* Authentication type = WPA-PSK, encription = TKIP: Stable for hours, 60 CPEs online.

With R52n (same chipset) seems a bit better with WPA2-PSK (AES) but I did not test too much because ~70 clients calling at MSN, phone, skype et al was not fun.

I spent last 12 hours login in each CPE and changing the manually configured WPA2-PSK (AES) settings by WPA only (seems they automatically select AES or TKIP, depends on AP security profile of course).

As far as I can remember, this Kernel failures exists here since V 5.4 or 5.5 with R52n/R52nM. Initially I suspected of the board itself, capacitors, power supplies etc.

Anyway, at least this RB gained a nice aluminum enclosure meanwhile ...

Regards;

Investigating a little bit more ...

According with MT AP debug logs, before each kernel failure (folowed by hardware watchdog reboot) there was this message:

<4>ap_assoc: from 0:15:xx:xx:xx:xx failed to parse
<4>aesccm_decrypt: MIC failure
<4>unaligned data access at c0167520 put_page+0x0/0x250
<4>Unhandled kernel unaligned access[#1]:
<4>Cpu 0

To isolate thinks, I stop using WPA2-PSK AES for a while and set every single UBNT CPE to: WPA-PSK (AES/TKIP). About 70 CPEs. The APs were locked to WPA-PSK TKIP.

Then I had some hours of stability.

Before the last reboot, the debug log revealed an interesting info: all CPEs involved at this event was Nano2 Loco (M) now with 5.3.3. Total of 5 CPEs at the same "time" and at the same interface (one is 10MHz BW, the affected was the 20MHz one).

Note that there is ~30 authenticated CPEs on each interface. 25% was Nano2 Loco M, others are Nano2 Loco (which still at WPA-PSK AES/TKIP).

So I finally set every Nano2 Loco M to WPA-PSK (TKIP only), keeping Nano2 Loco free to discover if APs are TKIP or AES.

Result = 1 day 1 hour and 18 seconds of uptime now. Peak users online = 64 CPEs (33 on 20MHz channel, 31 on 10MHz channel).

This router has an uptime of 11 months. I'll track down to figure when I started using M version mixed with B/G version but as far as I can remember was november 2010, when I started facing those router kernel failures / random reboots.

Regards;

P.S. thanks agn Janis.