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.
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.
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.
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:
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"?
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.
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.
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
an option like "locate device checkbox" to help locate device on site.
when we select that checkbox some leds at this device will be blinking and we will able in easy way to find this device in a lot of other devices on site.
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?
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).
It would be nice to change the color or otherwise mark the client(s) on the station list that are being throttled by the TDMA filter setting.
This will help identify problem clients that might not otherwise be easily identified. This would help managing truck rolls to clients affecting AP performance easier and much quicker.
Hello. My name´s Pedro Dominguez and I works in Vivacable engineering department. Vivacable is a FTTH and wireless ISP from the South of Spain, with around 15000 customers. In wireless networks we have around 3000 Ubiquiti airMAX CPEs deployed.
We configure CPEs in router mode and we use PPPoE at them. CPEs are connected through a bridged network (layer 2) to Mikrotiks PPPoE servers, using Radius authentication. In the bridged network we use different manufacturers devices, Ubiquiti, Cambium, Mimosa,.... We use Spanning Tree in order to have rings for redundancy, but it doesn´t work fine at all.
In the engineering department we are studying the possibility to use L2TP instead off PPPoE . The idea is to be able to have a routed network (layer 3) between CPEs and Mikrotiks L2TP servers, in order to be able to use layer 3 redundancy protocols.
The suggested idea is that Ubiquiti could include a L2TP client in airMAX CPEs. For the moment we are testing this L2TP topology using wireless CPEs in bridge mode and running L2TP in TPLink customer routers (after wireless CPEs).
Thank you very much and best regards,
VIVACABLE, dpto Ingenieria
Avda. del Comercio 41-43, PI Poliviso
41520 El Viso del Alcor – Sevilla
0034 672 240 542
And yes I know the radios can't do the speeds fiber can this so stop any chance of cable errors edgepoint is a step in the right direction but we really need the SFP right on the radios
Kudos if you agree
I have a survey monkey that shows over 100 of you want it but I have to pay to see more then that soo kudos will have to work
- petelarsen 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
- epsul on: Important firmware option!
- zacschmidt on: MAC Forced Fowarding
- Hide config
- cancel button for devices stuck in upgrade process
- Request: Toggle LED Light on NanoBeam on and off
- FEATURE REQUEST for BRIDGE TABLE
- Home AP that can connect wirelessly to a CPE?
- Zoom or full screen option in the throughput chart
- Include Freq of This AP in Site Survey
- Add MacAddress on a Command line
- UniFi Controller Idea: "Don't Show this Again" option for the "start rolling upgrade" message