MikroTik

I have 3 APs running 2.9.46 that consantly lose connection with tranzeo cpq line
my mikrotik cpe and CB3 users seem to stay up fine with a drop every now and then. Does anyone else have this problem? When my connections drop all i do is move the ap 1 channel up or down and everyone comes right back up and it lasts for a day or some times less. i just move the channel up or down 1 and back to same routine until next drop also all of my connections are -76 or better and have great bandwith. the ap setup is pretty basic with just wep and mac auth

any suggestions

have you tried doing ONLY b mode or only g mode?

what is the chipset in tranzeo cpq?

have you tried doing ONLY b mode or only g mode?

what is the chipset in tranzeo cpq?

FYI - Tranzeo CPQ's are Atheros based mPCI radios (early units were CM9's - and advertised as 200mW output, which was basically a marketing lie, not sure what the new ones are), and use a custom (Tranzeo) Ubicom IP3023 based SBC internally.

99% of the time, when a CPQ dies, it's the radio that's actually gone bad. I'm not exactly sure what causes it, but we've seen >10% field failure rate on early CPQ's. All of which have been gutted, and had RB133c's and new radios installed

I have a nice little aluminum mounting bracket tooled that we've been using to cleanly mount RB133's in the place of Tranzeo's board. Works great, if you're interested, drop me a note (I'm in the USA BTW).


Brad

Yep, any Tranzeo TR-5a CPE we take down from customer sites get ripped open and RB411 and R52 put inside.

I'm also seeing these issues, see the following related posts:

http://forum.mikrotik.com/viewtopic.php?f=7&t=23367
http://forum.mikrotik.com/viewtopic.php?f=7&t=21299

Had this problem. Using even the newest CPQ firmware doesn't resolve the issue - fixed it by moving to only TKIP on the AP, and set the AP rekey to 3600 seconds (Tranzeo default). Also hardcoded the AP and the Tranzeo's to B mode.

Of the 30 or so Tranzeos that still haven't been replaced across the network there is only one that occasionally disconnects and won't reconnect.

Change hardware retries to 4

Semaphore, where do you set the "AP rekey" to in Winbox? Do you have to set it from the CLI? We use WPA1/AES and have these sporadic disconnect issues.

In addition, jwcn.... I believe the hardware retries are set to 4 by default in newer releases of ROS. This issue (at least in my situation) has not improved by having hardware retries set to 4 (or anything else for that matter). Any other ideas?

I believe this is some sort of encryption handshake/synchronization issue that is occurring.

Again, could you please set your logging for wireless errors to 'debug' mode and please let me know what errors you're getting?

Incorrect, hardware retries are set to 15 by default. This is an old issue. The issue lies with Tranzeo or more specifically the Zcom radios they use although they deny it. Mikrotik attempted to make a bandaid fix with the hardware retries but it is really a fix Tranzeo needs to implement.

Setting hardware retries has stabilized at least one of my AP's I'm going to try it on a couple more that were problematic.. The one I was having the most problems with now has tranzeo units connected for 2+days.. which prior to changing HW-Retries I had difficulty keeping them connected for more than 12hrs at a time.

Incorrect, hardware retries are set to 15 by default. This is an old issue. The issue lies with Tranzeo or more specifically the Zcom radios they use although they deny it. Mikrotik attempted to make a bandaid fix with the hardware retries but it is really a fix Tranzeo needs to implement.

Actually, I do not believe that statement is correct.

To start with, any fresh installation or configuration reset I've done of ROS from v3.0 forward (and perhaps even in the latest 2.9.x releases) default to a hardware retry value of 4.

If you upgrade from an older version of 2.9.x that did not have the setting for hardware retries available to one of the latest versions of 2.9.x or 3.x that does have it available, you will find it set to 15. I suspect this is due to the configuration data defaulting to a "legacy setting" when the variable did not previously exist.

I still have about 30 Tranzeo CPQ's in my network, and I can confirm that when the deassociation issue happens (even with HW retries set to 4), *all* CPQ units deauth simultaneously and reconnect, and all MT units stay rock solid. The HW retries at 4 definitely reduced the frequency and impact of the issue, but did not cure it.

I also know that this behaviour is not specific to the Zcom cards, as I know for an absolute certainty that on every sector that has CPQ's on it, there is one or more that have CM9's in them. I know this for certain because previously I personally opened the failed CPQ units and replaced the dead CM9 radio with a new CM9. I don't bother keeping the Tranzeo board anymore, I just retool it with a RB133/411. It appears the "cure" may be just to avoid Tranzeo altogether - let's say I've been less than impressed.

I'm running 802.11b, with WPA-PSK AES on all sectors that still have CPQ's on them, so I may have to try changing one to TKIP to see if that has anything to do with it as reported by Semaphore.

I do agree that this appears to be a Tranzeo specific issue, and needs to be fixed by them. However, I think the chance of that happening are low - at best.


Brad

I could be wrong on the default hardware retries.

Tranzeo denies the problem exists.