I sent this to support, but I wanted to post this to the public forum as well for others to see / respond to.

I have the following problem between a RB532v5 with R52H and a RB133c with R52 (might be CM9 I can't remember).

Anyone have any ideas?

Scott

hardware configuration?

AP Wireless Settings Client Wireless Settings

What Hardware are you using?

What Hardware are you using?

If you look at what he wrote or the winbox screenshots and ask again, then maybe you would know

/Henrik

Nope, it's not in there.

Nope, it's not in there.

Hmm okay, i see a 133 and a 532A

/Henrik

But no radio information...

But no radio information...

R52H + R52/CM9 !?

oops.

Change hardware retries back to 15.

What are your signal strengths?

Signal strengths look optimal, connection stats look optimal. Also I should have mentioned (and you will see it in winbox image below) that I have two clients connected to this AP. A RB133c and a RB333. The 333 stays connected fine the RB133c is the only one with the problem so if the AP were doing something silly it should affect both clients. Its not.

RSSI Info



Thanks,
Scott

Decrease the power on both ends until your links are running -70ish

Jwcn, I appreciate your time in replying to my post, but I have to say that if MT radio gear has to have -70 or higher signal strength then its broke. Also, no other gear I have (and there is a lot) has this problem even with signal strengths much lower - 40-60

My target RSSI on every link is -60

I'll adjust the power just because you mentioned it and I do respect your experience and input. I don't expect it to fix the problem however, and if I drop the power on the AP then it will affect every other further out client I plan to have negatively. I'll report back my findings.

Scott

Ok, following suggestions above I updated the routerboard firmware on AP and two clients. I also adjusted all three so receive was -66 all the way around. About 10db less power than was running originally.

The problem is exactly the same, no change in the "no beacons received" and error msgs in log files in the past two hours since this change. So its not the firmware and its not the power.

This was happening on v2.9.50 which prompted me to upgrade to v3.1. I am now starting to suspect the RB133c or the radio card in it. I have new equipment showing up tuesday I am swapping it out to see what happens. I'm going to leave the current radio card in place and just swap out the RB133c for a RB144. Then I'll reploy (new word) the RB133c with a new R52H and see which, if either, the problem follows.

Any suggestions between now and then I'm all ears.

Scott

MT support looked into this, says configs look good. Try to change preamble type to long or both and they asked a few more questions.

I changed the preamble on the radios and it did not change anything. Still waiting for suggestions prior to the replacement gear arriving tomorrow.

Scott

Ok... I didn't expect this. Today I swapped out the RB113c and R52 having the problem that has been the topic of this post with a new RB411 and another R52 I had. Only thing thats the same is the case, antenna and power supply. But none of that should matter.

Problem continues with the new hardware at this location. Very odd. I just changed freqs for fun to see if that makes a difference.

The only other thing now in the back of my mind is that this radio is mounted to a metal building wall aiming at a tower behind another metal building about 100-150 yards away. I'm wondering if there are reflections going back and forth between buildings or something. Just doesn't make sense that it happens randomly and had nothing to do with the routerboard or radio card - at least that I can tell.

ideas?

Switched freqs again and the problem went away... Even though I couldn't see the rf energy when scanning etc I have to assume it was there causing me interference. At least its working now and there isn't a mystery any more.

I also have a problem with a site with lots of interference where it seems that 3.0/1 are having more problems than 2.9.xx. Changed cards, antennas, cables, etc but only after labouring through frequencies, now working better.

Have you tried enabling nstream and disable csma? Might help?

It's an AP so can't enable NStream.
What does CSMA do?

It's an AP so can't enable NStream.

Why not? You can enable nstream on a device configured as ap-bridge.

What does CSMA do?

http://en.wikipedia.org/wiki/CSMA/CA

Can I enable NStream even if not all my clients support it?
Most, but not all my clients are RB133C's
And even if they do, I supose I'll then have to switch it on at the clients before I switch over?

Can I enable NStream even if not all my clients support it?
Most, but not all my clients are RB133C's
And even if they do, I supose I'll then have to switch it on at the clients before I switch over?

No,

All clients need to support nstreme. and Yes you will have to enable nstreme on all clients, which, is rather easy using neighbors.

Nstreme helps, but it won't fix underlying physical layer problems such as in/out band interference.

Disabling CSMA/CA also helps, because instead of "asking" permission to transmit data it takes a TDM approach where you have a set time slot to transmit.

I have a CM9 client with 'no beacons' very frequently too. It seems the CM9 is very sensitive to even a momentary drop in communication, if you check the card on the client, I bet you'll find it is a CM9.

It was not a cm9, it was a r52 and changing the channel fixed the problem. You may want to look into that - interference issue.

Scott

Changing the channel doesn't help for me. The problem goes away after a couple of hours, stays away for a few days or a week, then comes back again.

At the AP, a RB333 with R52H running 3.2:

1 name="wlan2" mtu=1500 mac-address=00:0C:42:1B:4B:0C arp=enabled disable-running-check=no
interface-type=Atheros AR5413 radio-name="000C421B4B0C" mode=ap-bridge ssid="********" area=""
frequency-mode=superchannel country=no_country_set antenna-gain=0 frequency=5805 band=5ghz-10mhz
scan-list=default rate-set=default supported-rates-b=1Mbps,2Mbps,5.5Mbps,11Mbps
supported-rates-a/g=6Mbps,9Mbps,12Mbps,18Mbps,24Mbps,36Mbps,48Mbps,54Mbps basic-rates-b=1Mbps
basic-rates-a/g=6Mbps max-station-count=2007 ack-timeout=dynamic tx-power=6 tx-power-mode=card-rates
noise-floor-threshold=default periodic-calibration=default periodic-calibration-interval=60 burst-time=disabled
dfs-mode=none antenna-mode=ant-a wds-mode=disabled wds-default-bridge=none wds-default-cost=100
wds-cost-range=50-150 wds-ignore-ssid=no update-stats-interval=disabled default-authentication=yes
default-forwarding=yes default-ap-tx-limit=0 default-client-tx-limit=0 proprietary-extensions=post-2.9.25
wmm-support=disabled hide-ssid=no security-profile=default disconnect-timeout=3s on-fail-retry-time=100ms
preamble-mode=both compression=no allow-sharedkey=no station-bridge-clone-mac=00:00:00:00:00:00 hw-retries=7
frame-lifetime=0 adaptive-noise-immunity=yes

1 name="wlan2" enable-nstreme=yes enable-polling=yes disable-csma=yes framer-policy=exact-size framer-limit=3200

At the sub, a RB532A with NMP-8602 running 3.0 (now running 3.2):

0 R name="wlan1" mtu=1500 mac-address=00:02:6F:43:1A:61 arp=enabled disable-running-check=no
interface-type=Atheros AR5413 radio-name="00026F431A61" mode=station ssid="******" area=""
frequency-mode=superchannel country=no_country_set antenna-gain=0 frequency=5180 band=5ghz-10mhz
scan-list=5725-5875 rate-set=default supported-rates-b=1Mbps,2Mbps,5.5Mbps,11Mbps
supported-rates-a/g=6Mbps,9Mbps,12Mbps,18Mbps,24Mbps,36Mbps,48Mbps,54Mbps basic-rates-b=1Mbps
basic-rates-a/g=6Mbps max-station-count=2007 ack-timeout=dynamic tx-power=8 tx-power-mode=card-rates
noise-floor-threshold=default periodic-calibration=default periodic-calibration-interval=60
burst-time=disabled dfs-mode=none antenna-mode=ant-a wds-mode=disabled wds-default-bridge=none
wds-default-cost=100 wds-cost-range=50-150 wds-ignore-ssid=no update-stats-interval=disabled
default-authentication=yes default-forwarding=yes default-ap-tx-limit=0 default-client-tx-limit=0
proprietary-extensions=post-2.9.25 wmm-support=disabled hide-ssid=no security-profile=default
disconnect-timeout=3s on-fail-retry-time=100ms preamble-mode=both compression=no allow-sharedkey=no
station-bridge-clone-mac=00:00:00:00:00:00 hw-retries=7 frame-lifetime=0 adaptive-noise-immunity=yes

0 name="wlan1" enable-nstreme=yes enable-polling=yes disable-csma=yes framer-policy=exact-size framer-limit=3200

At the AP RSSI = -61 dBm
At the Sub RSSI = -69 dBm

Both have latest routerboard firmware. Wireless debug doesn't show anything other than associate and deassociated.

07:42:40 wireless,debug wlan2: 00:02:6F:43:1A:61 attempts to associate
07:42:40 wireless,debug wlan2: 00:02:6F:43:1A:61 in local ACL, accept
07:42:40 wireless,info 00:02:6F:43:1A:61@wlan2: connected
07:42:58 wireless,info 00:02:6F:43:1A:61@wlan2: disconnected, extensive data loss
07:43:11 wireless,debug wlan2: 00:02:6F:43:1A:61 attempts to associate
07:43:11 wireless,debug wlan2: 00:02:6F:43:1A:61 in local ACL, accept
07:43:11 wireless,info 00:02:6F:43:1A:61@wlan2: connected
07:43:29 wireless,info 00:02:6F:43:1A:61@wlan2: disconnected, extensive data loss

Ideas?

Has to be interference. Just cause you can't see it doesn't mean it isn't there. Assuming all the hardware it good... Thats been my experience but others here have more experience with these products than I.

I have your problem. My board cliente is 133C and AP 133C
The SO cliente v.3.4, firmware 2.12 and AP v.3.3 firmware 2.12
I update AP to v.3.4
End problem.

Here is a potential Problem.

Client A has 27 Grid.
Client B has 27 Grid.
AP is 12 db omni.
If client A has clear LOS to client B then there may be a potential of overdriving the input amps of of an opposing client when the other client is broadcasting, which could deafen the amp for a brief time following a broadcast.

If the client is temporarily deaf while a beacon is transmited by the AP then there would potentially be a problem.

Is it possible that this is the scenario you face?
If it is then Mikrotik should be able to code around the problem to accomodate this (at least for their clients).