Yesterday I pulled my hair trying to get a 3 km link to work.
RFE UD-24 and L11UG at both ends, 7.15.3.
Rates were stuck at 6/7.3 Mbps, -45 to -50. Saw other devices on opposite side in /ip neighbor but no traffic or mac telnet.
Replaced RB and Twistport adapter on both sides but to no avail.
Then I saw the configuration.distance setting and gave it a shot, set it to 4km and bang! full rates.
Yes this setting is in the changelog for 7.15, but only explanation is “to enable operation over multi-kilometer distances”
I have other PtP links with L11UG running all fine on 7.14.3.
What will happen if I upgrade them to 7.15.3, will I have to turn up at the far end and hook up to the RB to set the distance parameter?
Or run some script upon startup?
And what about PtMP setups?
I have an AP with 4 clients at from 0,6 to 3km, 7.14.1, running all fine. What will I set for distance here? The distance to the farthest client?
In PtMP setups you can have different values on different nodes:
The value should reflect the distance to the AP or station that is furthest from the device.
So on hub node (PtMP AP) you need to have e.g. 3km, on station nodes whatever needed (on the farthest node 3km, on nearer nodes something lower).
To set value on nodes farther than 2km you can create a scheduled job which runs command to set the value every few minutes … before node gets upgraded setting will fail (and will likely spam the log but will show that schefuled job is actually running periodically). After upgrade it’ll set the value and after the link establishes you can log in and disable/remove the scheduled job.
But do you know why MT changed this from being “all automatic” to be “all manual”?
Like I mentioned my pre-7.15 installs runs all fine without this setting, both PtP and PtMP, and somehow the Wifi6 chips or drivers must have detected the distance and adjusted accordingly to make it work.
IMHO, default Auto and being allowed to override with static values when needed would be the best. Then you could just config devices on your desk and deploy like before, and do the fine adjustment afterwards.
Have you found any doc for this setting (the quote you posted)?
I assume this is about some “guard interval” or something.
Will an excess value, let’s say a standard of 10km “waste airtime” and degrade the connection?
For sectors with clients at 1-1.5km distance I have left the configuration.distance untouched.
This morning I got complaints about speed and found that quite a few of the clients were stuck at 7.3 Mbps in one direction - some on uplink and some on downlink.
APs (L11UG) has ran for some weeks now.
This symptom is the same I saw on the PtP before I specified distance.
I thought that for distances up to ca 2km the setting could be omitted.
Or should I always round up to next higher km and specify it?
A reboot solved the problem this time (7.16.1)
Could this be due to a bug?
I have NOT used wifi-qcom for long PtMP links… But I can only imagine still you’d want to “round up”. While an oversimplification, “distance” more a timeout value with “km” being a proxy for time… so a short distance is a lower timeout.
And yeah outside other information, I think setting it explicitly if more 1km be a good idea.
What is the maximum distance that this parameter supports?
I am having problems establishing a link on a Netbox 5 ax using the wifi-qcom driver over a distance of 53km, despite the fact the signal is good and having set a distance (I tried several values between 53 and 120).
I have another link with 8.5km distance to the same AP and it works OK. But the 53km link worked when the AP was an old Netbox 5, which has now been replaced with Netbox 5 ax.
I’d open a support ticket as well. Maybe additional tickets will stimulate them to spend some time on outdoor wireless again. I submitted a feature request ticket in June 2025 asking for improvements needed for outdoor wireless, such as the addition of an alignment mode, display of individual chain RSSI, noise floor, SNR, CCQ in the driver and configuration options for AMPDU, guard interval, channel shifting and modulation index, but 6 months later, nothing has changed and none of it is implemented. I give up on MikroTik wireless.
I have opened a ticket a week ago but I understand they would be understaffed right now so I am trying on the forum to maybe encounter someone with experience.
The issue is that it worked OK when the AP was Netbox 5 (old wireless architecture) and it no longer works now that AP is Netbox 5 ax (wifi-qcom). The client is a LHG XL HP5, it used to be running v6.49 and in an attempt to fix it it was already updated to 7.20.6 which the AP is also running. No difference. The AP config is OK, it can be connected from a client at shorter distance with same config as the problem client. The AP is also visible in scan. When trying to connect, it logs “lost connection, received deauth: authentication not valid (2)“ immediately, but it doesn’t even try. The authentication is WPA2-EAP and I can see it does not query the RADIUS server, which it does from the second test client that works. I tried setting it “open” (no authentication) but the problem remains the same. I even tried to connect some other (close by) AP from the same client, and it works.
Of course one issue is that the new driver is just an example driver from Qualcomm, while in the old devices a tweaked and optimized driver written by MikroTik was used, which had the options that @FezzFest is mentioning. That is all gone now. The advantage is that it follows modern standards that were lacking in the other driver. I guess we cannot have the best of all worlds.
That’s indeed a sad thing..and I think there are reason to question MT’s priorities..if they want to stick around as a chosen vendor of outdoor wireless equipment, maybe it’s a good idea to step up the game.
So far no integrated CPE for harsh weather conditions in the range 21-24 dBi, no 60GHz device with dual chain AX fallback…
No WIFI6E and no WIFI7, except the hap be, no 6GHz…
This is what WISPs needs…and I would love to be able to stick to MT and not move to Ubiquiti..