How do you manually set the ack-timeout value with an rb532 and an xr2 card.
Thanks
I have looked in the manual and normally leave this setting on dynamic but I had UBNT take a look at one of my setups yesterday and he set it to 56. I was available when they did this and I have been unable to find where you set this.
Thanks
hai
how to set manuall ack-timeout try this
/in wir set [wlan_iface_name] ack-timeout=56
i suggest you to check datasheet that card first before set it, and that sample code with 56 value
regards
Hasbullah.com
thanks for the reply. it works. however i realized that it just takes a while for it to lower the ack-timeout to a normal reading. When you first start the radio it will show somewhere around 400 and then level out around 60. But thanks again for the good info.
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 ack-timeout is different in each “band” and different for each channel width (5mhz, 10mhz, 20mhz, 40mhz). it is also different depending on the distance of the link.
Thanks for the extra info on that although I already knew what it was for I was unable to change it in mikrotik.
The more I learn today the less I have to do tomorrow. At least its a nice thought. haha
Hi sten.
I know that ack timeout was only dependent on distance between the two sites, but you wrote:
the ack-timeout is different in each “band” and different for each channel width (5mhz, 10mhz, 20mhz, 40mhz)
Can you explaint it better?
Thanks
try this;
we have wireless router A connected to wireless router B via a 10 km 802.11a (20mhz) link. set the ack timeout on both sides.
then change the link to “turbo” (40mhz) mode. (it still should work)
then change ack timeout to dynamic, read the ack-timeouts and set the new ack-timeout values to the suggested ones.
they will be lower by this point (roughly half)
then change wireless mode back to regular 802.11a (20mhz) link.
does it still work?
I can’t try this soon, but i will remember next time i will put my hand on a 5GHz backhaul.
Thanks
P.S.
Do you know what causes this behaviour (theory)?
basically;
If ACK packets where on the link layer, it would not have mattered, but ACKs are on L2.
Yes, i know that ack are on L2, but my request was a phisical (or theoretical) explanation of this “phenomenon”, if you know it.
Thanks
I just noticed a correlation between the ACK and the atheros/prism association problem.
When the problem is occurring, on the AP.. look at your ACK value under status..
from 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
on a problem node I see the Ack value at 90.. on a working node I see the ack value at 53
after a few minutes of the card being enabled it finds the ACK it seems to stick on a number
when the problem of NO cpes can connect the Ack value is way high.. mine currently is setting at 349
after disabling and -re-enalbing the card a 1000 times.. the act value goes to a normal rate of around 50..
so is the problem related to the dynamic ack ? or is the ack a byproduct of the problem.
well yes. dynamic-ack only works against Atheros, AFAIK
I sort of worked on a PRISM based PLC client antenna a couple of years ago and back then dynamic ack (on routeros) never worked for the PRISM chips. It had random results. We had to calculate the max distance by hand to be able to connect PRISM cards.
Which is the main reason i say; do not leave ack-timeout at dynamic.
Try 56 and work your way upwards. We used 80 (~6 km) as the default on 802.11b.
It’s almost always better with a positive margin than a negative one.
to clarify.
ack-timeout=dynamic did not work on the AP which was routeros.
the PLC/PRISM antenna had no concept of dynamic ack timeout.
And since the AP calculated the ACK timeout by gradually decrease ACK timeout during association, it usually failed miserably.
Might be wrong, it’s been 3 years!
Just as a side note. Leaving ack-timeout at a static 80 usually did the trick for clients closer than 3-4 km’s. It still works today.
Sten,
I have been following this problem for quite a while and have been waiting for a solution before really launching several new AP’s. Let me make sure I understand you. You are saying that if we set the Ack-Timeout to a fixed amount, say 53 or something like that, maybe up to 80 then this whole problem of clients dropping off and not reassociating is cleared up. You mention 3 years, have you been doing this sucessfully for 3 years now? If this is the answer and I hope it is, the you have saved the day. I have already changed a couple of AP’s and have not had a single deauth in the log. This has been since last night when I read your post.
Thank you for sharing this.
Steve Loomis
Vroomwireless Inc
Yes, the PRISM antenna i’m currently looking at has been connected for 13 days (AP reboot), it was installed atleast 2 years and 8 months ago (as that was when the last PRISM based client antenna was installed). It has been in active operation since then.
EDIT: AP is version 2.9.26 and ack-timeout is 80
when I look at my senao prism card in one of my APs running 2.9.29, and I see no ack-timeout anywhere, the field does not show up on the advance tab, and the status is blank.
here is my atheros, it shows the ack
name=“wlan4” mtu=1500 mac-address=00:0B:6B:34:33:E2 arp=enabled
disable-running-check=no interface-type=Atheros AR5213 radio-name=“000B6B3433E2”
mode=station ssid=“MVRE” area=“” frequency-mode=manual-txpower
country=no_country_set antenna-gain=0 frequency=5745 band=5ghz 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=no
default-ap-tx-limit=0 default-client-tx-limit=0 proprietary-extensions=pre-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
here is my prism
notice no ack
name=“wlan2” mtu=1500 mac-address=00:02:6F:35:30:3E arp=enabled
disable-running-check=no interface-type=Prism prism-cardtype=200mW
radio-name=“00026F35303E” mode=ap-bridge ssid=“SurfnetAP6” area=“”
frequency-mode=manual-txpower country=no_country_set antenna-gain=0 frequency=2457
band=2.4ghz-b scan-list=default rate-set=default
supported-rates-b=1Mbps,2Mbps,5.5Mbps,11Mbps basic-rates-b=1Mbps
max-station-count=2007 IT SHOULD BE HEREtx-power-mode=default periodic-calibration=default
periodic-calibration-interval=60 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=no default-ap-tx-limit=0
default-client-tx-limit=0 proprietary-extensions=pre-2.9.25 hide-ssid=no
security-profile=default disconnect-timeout=3s on-fail-retry-time=100ms
compression=no allow-sharedkey=no
I just went to a problem node with an atheros AP. I looked and the ack was 346.
I then with to the reg table double clicked on each client and looked at their ack.
Most of the clients had an ack value in the 30-50 range. I found the one that had an ack of 346 and clicked ‘copy to access list’.. which basically resets his connection and it resets their ACK as well. It went to 50.. but the AP interface went to 254, I then looked for the client that was at 254 and reset him. I did this over and over again till I found all the high ack clients.
Now my AP interface ACK read 53.
question: did I improve performance? I feel like I must have.. but only time will tell.
and should I llok at all the APs for this issue? Perhaps MK should have a periodic ack check on clients, if this is indeed an issue.
ack-timeout=dynamic is only meant to be used during installation of a link.
i’m sure you could script something, but;
what would you regard your maximum to be?
why didn’t you set it to that value in the first place?
how will you enforce the client side ack-timeout?
without ack-timeout setting on clients and AP, you will experience very poor performance for links that are longer than ~4 km’s, depending on the firmware. if a link is longer than the (prism hardcoded?) ack-timeout then every packet that this station (or AP) will transmit, will essentially be retransmitted X number of times, even though the first was accepted.
but perhaps none of your links are longer than that?
I don’t think that you can set ack-timeout on a tranzeo tr-cpe-200. If so I don’t know how. Every setting is done with web gui and there isn’t any distance or ack setting in there. Now what?