Some feature requests

  • 4
  • Idea
  • Updated 3 years ago
After deploying a large number of Aerohive wireless networks from 3.5 to 5.1 here are some features I would like to see in future releases:

* User Manager Operator accounts should be able to revoke accounts they have permission to create. Surely creating an account is more of a security risk that revoking one.

* A completely configurable lobby administrator account. One where the temporary and permanent accounts the lobby administrator account can create/revoke is configurable.

* A "User Profile Name" column in the "Active Clients" and similar tables so you can see the name (VIP, Staff, Guest, etc) assigned to the user profile attribute rather than just the current user profile attribute.

* Better client/user reporting. A single report that advises what users associated with what clients. For example, Private PSK account Bob.Smith associated at 15:29 using client xx:xx:xx:xx:xx;xx. The same report should also advise that Private PSK account Bob.Smith lost association at 16:32.

* An on-premise version of ID Manager. Some companies do not want their information in the cloud but require the additional functionality of ID Manager.

* Layer 7 visibility and control (to steal a term from Cisco) so that we can log, block and/or apply QoS and rate limiting settings based on the application, such as FaceBook, that the user is accessing. Currently both Aruba and Cisco have this functionality.

* The ability to control what user profiles can access what Bonjour capable devices in which VLANs. For example, staff can access printers in VLAN 100 and the Apple TV in VLAN 110 but guests can only access the guest printers in VLAN 120.

* Quotas for Private PSK groups. The ability to not only rate limit a Private PSK group, Guests for example, but apply quotas. We have a number of retail customers who use wireless as a way of getting people into their stores and quotas are a high priority for these sites. With Aerohive currently not supporting quotas we cannot recommend Aerohive to them.

* Real time monitoring of the firewall. Think of this as extending the Client Monitor so it continues to report what is happening with the wireless client after it has completed authentication/association and obtained a DHCP address (if appropriate).

* A WIPS screen so that the WIPS settings can be configured. For example, how many PINGs and how often to result in a PING Sweep alert.

* All fields in a recurring PSK Private should be cleared when the recurring Private PSK's validity period expires. Currently the Comments field is not cleared so the new recurring Private PSK's Comments field has any information from the previous recurring Private PSK . This is probably more of a bug fix.

I think that about covers it. Hopefully some other people out there like these ideas.
Photo of Crowdie

Crowdie, Champ

  • 972 Posts
  • 272 Reply Likes

Posted 5 years ago

  • 4
Photo of Sjoerd de Jong

Sjoerd de Jong, Employee

  • 97 Posts
  • 20 Reply Likes
I agree with all of the above :)
Photo of Mike Kouri

Mike Kouri, Official Rep

  • 1030 Posts
  • 271 Reply Likes
Wow. That's quite a comprehensive list. I recognize several of them from discussions with my peers, you may find that many of these will be addressed in the next few upcoming releases.
Photo of Crowdie

Crowdie, Champ

  • 972 Posts
  • 272 Reply Likes
To add to my original list:
  • The ability to set a minimum transmit power for each radio.  This would complement the current maximum transmit power setting.
  • The ability to have an identity-based GRE tunnel from an access point in one network policy to an access point in another.  Currently this does not work.
(Edited)
Photo of Roberto Casula

Roberto Casula, Champ

  • 231 Posts
  • 111 Reply Likes
It is simply a check that HiveManager does when it creates the CLI configuration for each access point.

If a user profile is referenced in the network policy that includes a tunnel policy, HiveManager checks whether the AP it is creating the configuration for is included in the "tunnel sources" or the "tunnel destination". This determines whether the mobility-policy CLI commands generated for that AP are "gre-tunnel to" or "gre-tunnel from".

If the AP's IP address is in neither source nor destination, then HiveManager assumes that you have forgotten to add it or its network to the tunnel policy rather than assuming that you don't intend that AP to use GRE tunnels at all.

I put a feature request in some years ago asking for this to be changed, or at least to have a checkbox in the tunnel policy along the lines of "Do not use tunnelling for APs not included in the above sources or destinations", but this was never implemented (only 13.7% of my feature requests ever get implemented - I've kept a tally).

I too find it annoying to have to have multiple policies that differ only in this one regard. Not only does this require duplicate policies, but it also requires duplicate SSID objects and user profile objects. It just over-complicates things and makes it more likely that configuration mismatches will arise down the line if the user forgets to make changes in two different places.

I do kind of see it from Aerohive's design perspective too though...the user profile says that GRE tunnelling is required, and therefore logically every AP that uses that user profile should either be a tunnel source or a tunnel destination. If tunnelling is not required for particular APs, they should have a different policy.

Still annoying though.
Photo of Crowdie

Crowdie, Champ

  • 972 Posts
  • 272 Reply Likes

Therefore, I change my feature request to be that the above should be possible again.

Photo of Roberto Casula

Roberto Casula, Champ

  • 231 Posts
  • 111 Reply Likes
Which version of HiveManager do you believe allowed such a configuration?
Photo of Crowdie

Crowdie, Champ

  • 972 Posts
  • 272 Reply Likes
I have a 6.1 HM (if I remember correctly) with the access points configured in this way.  I showed it to Aerohive Support during our fault finding and added to the confusion.  What was interesting was that Support had a mini conference to discuss this which shows that we were testing them :-)
(Edited)
Photo of Roberto Casula

Roberto Casula, Champ

  • 231 Posts
  • 111 Reply Likes
I'll bet it did! I don't remember any version where this configuration was possible (and it comes up quite regularly for me as customers add APs and forget to add the APs to the mobility policy and therefore get the error).

I wonder if they changed something in one of the 6.1 releases "by accident" and then quickly changed it back?