/ interface wireless
set wlan1 name="wlan1" mtu=1500 mac-address=00:15:6D:63:14:6E arp=enabled disable-running-check=no radio-name="00156D63146E" \
mode=ap-bridge ssid="ap4" area="" frequency-mode=manual-txpower country=no_country_set antenna-gain=0 frequency=2417 \
band=2.4ghz-b 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-mode=default 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 hide-ssid=no \
security-profile=default disconnect-timeout=3s on-fail-retry-time=100ms preamble-mode=both compression=no allow-sharedkey=no \
Next time this happens just try to disable - enable the card over and over till everyone connects , if that works, then you are in the same boat as the rest of us.I have to change the AP back to previous config, change the client, then change the AP, then reboot the AP. This is a pain in the @#$@#$.
My link is ptp, rb133c and SR9 on both sides. About as simple as you can get.Is there anyone having this problem with a NL-2511MP in the AP and all prizm CPE's?
I think if you have all Atheros (AP and CPE) or all Prizm you don't have this problem.
Maybe somethings things work fine untill you hit that magic number of clients and then things go nuts.
R52, XR2/5 are 5414 single chip (DC with ZIF), lots of trade off, cheap to make and cost more with marketing hype.My network is made up of 70% CB3, 5% Deliberant, and 5% Tranzeo. I never had any problem till I started adding RB133 with R52 cards in them. I dont have the problem on nodes where there are no mikrotik CPEs, I dont have this problem if I user Prism chipsets in the APs, but when I do that I get all sort of complaints, the prism cards are just not good enough in crowed environment.
the noise floor on my nodes averages around -105, which is pretty good. If a -105 is considered noisy, then we have a major problem, or is it a wrong reading ?I talked with someone at ubiquiti today and he thinks the problem has something to do with noise.
We have a Deliberant AP up also, although it was put up to replace a tranzeo. I would agree this is a MT issue.I've been having this problem for a year now.
I finally solved it by hanging Deliberant AP's on my busy towers and forcing the Tranzeos and Zcomaxs on them and letting all the other clients connect via MT.
It IS a MT problem and needs to be fixed.
Problem is that now you dont have the signal reporting and traffic reporting that you have with pure MT - kinda loose the MT effect.
on a problem node I see the Ack value at 90.. on a working node I see the ack value at 53from the previous post it was stated
ack timeout is calculated on each association when ack-timeout=dynamic.
A little bit of packet loss can leave it at an unreasonable high ack-timeout, giving really poor performance.
ack-timeout=dynamic is meant to be used when you initially setup the link and should be fixed at the suggested ack-timeout
the client keeps sending frames even if he has been disconnected, while it should already start looking for the ap (which it doesn't). this is a known problem, and as I said, we will work on a workaround because there is no way to fix all the clients that have this problem.
another small question.. . If it is indeed the CPE causing the problem, then how come putting a Senao prism card in the AP solves the problem?the client keeps sending frames even if he has been disconnected, while it should already start looking for the ap (which it doesn't). this is a known problem, and as I said, we will work on a workaround because there is no way to fix all the clients that have this problem.
... And as a result almost all of your traffic over the air is completely unnecessary retransmissions.Sten,
The ACK timing shows to be 30us on my end when I log into one of my towers with a 2511 card on the AP. I guess that is what the Prism card AP forces the client cards to when associating. That seems kind of short considering I have one customer on this tower who is 13.85 miles from the tower. The test client I am using is a MT 133c board with a R52 installed sitting several hundred feet from the tower.
Resembles Windows(r) startup with many items, many processes hang and system freezes for a while, unless some changes in registry are implemented4 Filling Up the Access Point Association and Authentication Buffers
Many access points do not implement any protection against these buffers being overflowed and will crash after an excessive amount of connections are established or authentication requests sent. This applies to software access points as well; for example, an OpenBSD 3.1-based AP.
I guess they are afraid to come out and say..'Yes our card or our software has a bug and it gets choked by to many prism cards attempting to connect to it'
Thx Adam. I just turned the other cheek. But unfortunately I only have two!I read your post before it was erased. I thought it was good. Ha ha ha.