This is a followup to some older topics on how Airmax and its scheduler works on a high level and how best to mitigate the effects of weaker clients.
The summary is that Airmax priority only works in the uplink direction (CPE->AP) and not the downlink. That being probably the least effective direction as most clients are concerned and utilize the downlink more than the uplink. How does then UBNT recommend making effecient use of the downlink when you have active weaker clients? Improving their signal or removing the clients is not a sufficient answer as that is not always an option.
I want to know how we can keep the weaker clients (tree growth, thermal fade, interference) but limit their impact on the good clients during the hours when the AP is the most active. When the AP is under light activity I do not mind if the weaker clients use more airtime to get their data, but at peak hours I want to sacrifice their speed to allow the good clients to get theirs and make the most efficient use of the AP's downlink Airtime.
I suggest either to make AirMax priority a setting that controls both the downlink as well as the uplink or some other operator controlled variable that tells the AP to allocate less airtime to certain clients in the DL direction.
Traffic Shapping via SNMP... Have SNMP write community strings that would allow for traffic shapping. When you have large networks that cover multiple counties it can be a really costly venture to login to each radio just to update traffic shapping as you get more bandwidth. PLEASE MAKE THIS HAPPEN
Can this be implemente in airOS too!!
Its very important please make this happen, its security reasons too but it will be much easier for us to be informed directly with a notification for new firmwares.
I've been hoping for YEARS that AirOS would include, on APs when displaying the bridge table, some sort of wireless client identifier that would let me know NOT ONLY what interface (wlan0/wifi0/ath0) the MAC in question was associated with, but WHICH STATION RADIO the MAC was seen on.
This information IS KNOWN by the AP (How else can it route a bridged ethernet packet to the correct client radio?).
Some of Ubiquiti's do this currently (one includes an identifier called a LUID that lets one know which client radio associated with the AP the bridged MAC is behind). I'm STRONGLY hoping Ubiquiti will expose this important information in future AirOS versions.
Here's a VERY ROUGH mock-up, using associatd stations' MAC addresses as identifiers connecting bridged MACs in the table to which station the MACs originatd behind (it could be ANY identifer, and would ONLY apply to MACs seen by an AP from associated stations on the wireless interface(s) and/or wireless VLANs):
Anyone else want to see this? AND it would be sweet if the https://ubiquiti.radio.ip/brmacs.cgi?brmacs=y CGI script would included it in the JSON output as well (so management systems could easly scrape the information).
As it is now, if I'm made aware of a MAC address of a troublesome device, I can trace it through my network's swithches and routers to a specific Ubiquiti AP, but when I reach that point I pretty much have to connect on average HALF the AP's associated stations to figure out WHICH station is hosting the rogue device. That's ridiculous! The AP knows and posesses this information. But it is NOT explosed via web GUI nor SSH CLI to my knowledge, anywhere. I've searched for several years under multiple AirOS versions. I'm really quite amazed this information hasn't been included in the bridge table information in more recent AirOS versions.
HENCE this FEATURE REQUEST.
Thanks for considering this! Please add it to your future release TO DO list! Make AirOS even better--match and beat your competitors' features, please.
Integrate GPS antennas into the 5AC-90-HD
Building them into the top of the Antenna would hopefully make for a more weatherproof and all round tidier setup.
Cables run internally would mean there is nothing needing securing.
Just had this ideal come to mind today and wanted to see if anyone thinks it would be a good idleal as I do.. It would be nice to able to see if Traffic Shapping was enabled on the Main Tab and at what speeds if possable.
This request probably begins with airMAX, but will require support in a range of Ubiquiti product lines in order to be truly effective:
Please consider a way to notify indoor APs of the channel(s) used by an outdoor (CPE) radio.
When the indoor equipment receives a DHCP lease, it would include information about the outdoor channel(s) in use to prevent those indoor devices from interfering.
Depending on the network configuration (bridged, routed, DHCP, PPPoE, etc.) this may require support in airMAX, UniFi, AmpliFi, EdgeOS, and even UNMS. Once UBNT gear is compliant, we can start lobbying other manufacturers (outdoor and indoor) to join the party.
Help keep our limited spectrum resources clean!
I find "Get Free U Mobile app now!" quite flamboyant and annoying.
Several times to see it is enough.
How about adding a checkbox "Hide logos on logon screen" in "Services-Web Server" or "System-Miscellaneous"?
is there a chance to have dlep in some future airos version?
see following links for further information:
CISCO description: http://www.cisco.com/c/dam/en_us/solutions/industries/docs/gov/aag_dlep.pdf
IETF definition: https://tools.ietf.org/html/draft-ietf-manet-dlep-22
build DLEP on airOS: https://wiki.confine-project.eu/testbeds:austria:airos-dlep
see also EdgeMAX Feature Request:
Formalizing suggestions from this thread and as a solution to numerous requests for an AC-based CPE with dual Ethernet ports:
Small, unmanaged outdoor switch with three (or perhaps four) Ethernet ports.
24V 4-pair PoE input; ships with 24V 1A PoE brick.
24V 2-pair PoE outputs with individual PTC protection. These should probably be switchable somehow -- perhaps a DIP switch under the cover?
Enhanced ESD protection (from AC Gen2 radios).
Include a grounding stud or terminal. Configure such that if a hose clamp is used for install, it also bonds to the mast.
Priced at $19 - $29, also available in multi-packs.
When the traffic on your networks is less than 10mpbs and you capacity is around 600mpbs you cannot see what is going on your network. Some kind of zoom will be great idea, or a full screen chart option, or something like that.
I tried seeing if someone else suggeded this. There seems to be a lack of Edge hardware that works with the EdgePower.
A lot of our towers are shorter then 300 feet and we like keeping the routers, equiptment at the bottom and runnign cat5 up the tower. The EP-S16 is a great little switch but would like to see it in a rack/wall mount solution that is not in the bulky outdoor case.
It doesnt have to be the EP-S16 hardware, I was just looking for some DC powered Edge Switch that can power a couple Air Fiber devices.
For cases like the device that is marked, usually, some devices got stuck for long time uploading firmware because the device could has bad signal or so. So instead of canceling upgrade process for all devices, I suggest to add cancel button per device, so when its noticed that one or more devices get stuck, the upgrade can be cancelled for them and be continued for the other devices that have FW uploaded already and just waiting the others that got stuck.
What it says on the tin. Ideally with airMAX support.
I can't speak for other people who are yearning for this feature but I know personally if this feature can't be added with just a software update on existing devices (similar to how only newer devices get big MTUs) I wouldn't mind having to purchase a new hardware revision (or a Rocket M5 Uber Edition ) to utilise this. (Although I would be sad having to wait 6 months for it to go flow down the supply chain in Australia).
Under UMobile, if using it to configure units in the field, it would be amazing to be able to populate the currently connected device's latitude and longitude information fields (under settings) by simply pressing a button in the app to query the phone or tablet's GPS current position.
If I'm on the roof aligning the device and using the alignment tool in UMobile, I'm in an ideal position to accurately set the device's location, so being able to do this with a single button press would be awesome.
Please let me know if you think this is something you could implement?
Big fan of Ubiquiti AirMax products but there are some features lacking with configuring firewalls in the GUI that can be configured in the .cfg files. Part of the problem is we don't want to have to train our techs on how to edit these files, and the other part is it is that it takes a lot more time to configure these settings in the cfg manually. That basically leaves us with the only option of developing a template file and a software tool to generate the config for our techs to then upload. The biggest problem this presents is that our techs often have to program radios out in the field and may not be able to easily generate a config file and upload it.
- In order to reduce overhead that arises when assigning a public ip address directly to a customers router via static assignemnt (makes managing customers with static IPs on routers difficult) or dynamic assignemnt (we really, really don't want to have to maintain a MAC ACL that will need to be udpated every time a customer changes routers) we run our radios in NAT mode + DMZ with a seperate management VLAN.
- We try to follow the internet standard RFCs and best practices including keeping bogons of the internet which we have found helpful to do at the CPEs so we can prevent customer private space from leaking into our own.
There are a few issues / obsticales that this setup presnts to us.
When running a radio with NAT + DMZ when a customer tries to access themselves through their public (a very popluar thing with NVR camrea apps and other services) they cannot access their equipment. There are couple of different reasons this issue presents itself.
The DMZ setup by the radio only works for traffic comming in the rado's WAN. Therefore when a customer tries to access their public IP address it is considered INPUT into the radio and is not NATed / forwarded back to the router.
XW.v6.1.6# iptables -t nat -L ... Chain DMZ (1 references) target prot opt in out source destination DNAT all -- ath0.100 any anywhere anywhere to:100.64.0.2 ...
This can be solved pretty eaisly and still allow management from the LAN port by adding the following lines to the .cfg.
- Now a second issue arises. The source IP address ends up breaking the router's connection tracking so we now need to add a hairpin NAT rule. We should be safe to assume that if we ever have a packet comfing form 100.64.0.2 (our DMZ ip) to 100.64.0.2 in the radio we have NATed the destination address in PREROUTING with the above firewall entry. All we need to do now is add a masquerade rule in the .cfg to preform the hairpinning.
The config uploads and applies fine, and we can even see what each rule does in the GUI.
However if you now try to edit the DNAT rule to change the customers public IP, like if you for instance repoint them to a new tower or renumber part of your network, the rule get's changed to the filter table as type DROP.
And now the only way to fix it is to re-edit the .cfg file. So adding better support for firewall rules here (maybe an advanced firewall rule edit mode) would help greatly. Luckiy we don't have to edit the masquerade rule unelss we change the DMZ IP, but it would still be nice to be able to add this rule via the GUI.
The interface configuration only allows to specify input interface and not output interface. It is somtimes desired to add a firewall rule to limit traffic passing between one interface and another by source or destination ip address, but to allow it out other ports.
This rule works fine and displays in the GUI as follows:
However, the only way to specify an output port is again by manually editing the .cfg file, which can be tedious, but also hides details about what the rule actually does from someone using the GUI.
I'll calssify this one as a feature instead of an issue because it really would just be nice to have. When dealing with several ranges of IPs that you want to perform the same firewall action on, it is typical to use ipset. As far as I know ipset is not included in either AirMax M or AirMax AC firwmares at present.
In keeping bogons from entering our network from a customers CPE we have several fiewall rules that drop traffic from several bogon IP address ranges.
Note that this is just half of the rules. After this set is a duplicate set, but with the address range in the source address range instead of the destination address range slot. Also note all of these rules also contain an out WLAN.100 rule too which is hidden from the web user. If ipset was included in AirOS we could create a bogon list containing these IPs and have just 2 firewall rule entries instead of 26.
Welp, that pretty much sums it up. Better support for different types of iptables (and ebtables) rules in the interface and a request to have ipset included with iptables so ip addresses can be grouped together.
Thanks for taking the time to read my suggestions
- jml on: Config Snapshots
- Skipper0815 on: cancel button for devices stuck in upgrade process
- astounding on: FEATURE REQUEST for BRIDGE TABLE
- rebelwireless on: Will the 900MHz see Prism AC style radios forAP use?
- createcoms on: AirMax R3AC
- ZillnerIT on: Zero Wait DFS for Airmax and Airfiber
- rebelwireless on: IDEA - Integrate GPS antennas into the 5AC-90-HD
- mWare on: Air-fiber Link pass through fail
- pocki80 on: Dynamic Link Exchange Protocol (DLEP) in airOS
- Bluestreak66 on: Wide Range 802.11ac Wifi Access Device
- airMax max Rx modulation rate
- UNMS - ability to use non-standard IP/port in iOS app
- Installer/Maintainer User Account for AirOS
- Protected TFTP
- Config Snapshots
- Traffic Shapping via SNMP...
- Airfiber/Powerbeam SNMP v2/v3 support
- Dealy pppoe connection trials
- Factory Reset
- Airmax Priority in Downlink (AP->STA) direction