Feature requests for Omada Controller

Feature requests for Omada Controller
Feature requests for Omada Controller
2020-01-13 01:41:12 - last edited 2020-01-13 02:51:33

Dear @forrest,

 

I have some feature request for Omada Controller collected over time from our Omada customers and from Omada users here in the forum. I would appreciate very much if you could consider those features in a future version of Omada controller.

 

1. Statistics page

It would be helpful if the statistics page would allow to select a pie chart for showing numbers of users/guests per EAP, not only per SSID. Often, sites have only one SSID at all and the current pie chart always shows 100% users for this SSID. I know, it's already in Omada App, but sysadmins would like to see this in Omada software controller and OC200, too.

 

2. Client hostnames

If WiFi hostnames are empty (device shows up as »Unknown«), Omada Controller should query the DNS server for the hostname. DNS servers in small SOHO networks keep track of the hostname sent by DHCP automatically. Business users often use a full-fledged DNS server. Additionally, the client's hostname should be allowed to be set manually – you have accepted the latter suggestion of a manual settings for home users already as far as I know. But DNS names should be queried for power (business) users, too, and it would be beneficial even for SOHO users.

 

3. Proxying capabilities

It would be helpful to allow use of web proxys such as the nginx or apache web server, which can forward requests to Omada controller. This would just require the ability to bind Omada controller to specific IP addresses set in the properties, thus preventing the controller to listen to all IP addresses of the server. Business class servers often have web front-ends and load-balancing while the software runs on a back-end server. Those load balancing functions of a proxy could be used easily for Omada controller with only small changes in the Java code which allow binding to certain IP adresses.

 

4. mongod database

Sysadmins should be able to use a system-provided mongodb instance alternatively to the built-in one. Currently Omada controller always starts an own mongod instance. If it would be possible to prevent this start, Omada controller could use an existing (already installed) mongod by just changing the port in the properties. So please make start of the built-in mongod optional for those users who run an own mongod already. No need to run DB servers twice on the same system.

 

5. Make Java code platform-independent again

In version 2.x Omada controller's Java code was platform-independent. Java classes for Windows could be used on Linux and FreeBSD UNIX without any change. Starting with version 3 Omada controller introduced platform dependency, which isn't really needed (Java has been designed to be platform-independent). Only change required in V3 Omada controller would be to not query for the platform the controller is running on, but instead querying for the existance of platform-dependend helper commands such as ps (then it's running on Linux or FreeBSD) or tasklist (then it is running on Windows).

 

By querying for the existance of helper commands instead of querying the platform you would have to support only one version of Omada controller's Java code for every platform. No more differences in Java code for Windows, Linux and FreeBSD – just one Java code base like it was in versions 2.4 to 2.7. You only would need to package different software packages versions for distribution of built-in binaries such as mongod, but the Omada community version, which avoids any built-in binary, could run on any platform, whether it's 32 bit, 64 bit or x86, mips or arm architecture.

 

If R&D doesn't want to unite the Java code base, then please remove at least the platform checks in Java method »com.tp_link.eap.start.EapLinuxMain« and consider removal of the platform checks in the Linux version of Omada controller. For example, if you remove those platform checks, the Linux version could be made easily to run also on FreeBSD, which is often used as an Internet server. And I'm sure, no-one would download the Linux version anyway if he runs Windows.

 

6. SSL certificates

While it is possible to change SSL certificates in the Linux version easily, it isn't possible at all on OC200. Please consider an upload mechanism for OC200 either through the web UI or maybe through the optional USB stick, which can be added to OC200. There is a lot of space on USB sticks used for auto-backups. Why not use it for other things, too?

 

7. Client isolation

Please consider to add a setting for »Client Isolation« again. It would be not necessary to change the current existing setting »Guest Network«, which still could co-exist and which could enable client isolation, too.  But it would be beneficial to only enable client isolation without the invisible ACLs being set when using »Guest Network« setting. This would also simplify access from guest users to the OC200 portal when OC200 is the only device in the (wired) LAN.

 

These are the feature requests I'm often asked for by our customers and by users here in the forum. It would definitely improve Omada Controller.

 

Thanks very much for your consideration.

 

༺ 0100 1101 0010 10ཏ1 0010 0110 1010 1110 ༻
6
6
#1
Options
22 Replies
Re:Feature requests for Omada Controller
2020-01-13 03:09:19

Hello!) I want to confirm the need for two functions proposed @ R1D2 ,

 

1. Statistics page

2. Client host name

 

@forrest , I also want to add one function for discussion

 

3. OC200 controller redundancy

 

I also have a short list of functions, but before publishing it I would like to think it over again.

 

@R1D2 , I'm sorry I got into your topic, I could not keep silent

 

all good luck!  I hope for a joint, cooperation to improve Omada

0
0
#2
Options
Re:Feature requests for Omada Controller
2020-01-13 11:02:05 - last edited 2020-01-13 11:04:33

Hello @TheKaban, no need to excuse for adding your thoughts. Anyone can support the proposals for whom these feature requests are useful.

 

Request #2 comes from several community users and the purpose of my posting is to summarize those suggestions for TP-Link.

Thus, thanks for your support!

༺ 0100 1101 0010 10ཏ1 0010 0110 1010 1110 ༻
0
0
#3
Options
Re:Feature requests for Omada Controller
2020-01-14 01:17:36

@R1D2 

Thank you very much for your feedback. We are trying to optimize the products to better server our customers. We will consider to change a feature based on the feedback from the customer. Normally, for the feedback from customers, we will add it to our suggestion list. When there are many feedabcks about it, we will consult it with our PE colleagues and we will consider to add it in later version (If there is less feedback, that means this feature is designed to meet the needs of most customers). 

 

We have truly received many feedbacks about changing hostname, after the PE colleague's evaluation, we will add it in later version of Controller. If everything goes well, the software with this feature will be released in Q1 2020. 

 

For the Client Isolation, I remember you have given us feedback about it, but we received little feedback from our other customers. For other feedbacks you gave, I will add them to the suggestion list for now but we may not change it these days and we will continue to collect the feedbacks. 

 

Thank you very much, hope you can give us more feedback in the future. We will try to optimize the products to meet most customers. 

3
3
#4
Options
Re:Feature requests for Omada Controller
2020-01-14 01:18:53

@TheKaban Thank you for your feedback, we have made suggestions to PE colleagues about this and they will evaluate it. 

0
0
#5
Options
Re:Feature requests for Omada Controller
2020-01-14 02:21:19 - last edited 2020-01-14 17:32:46

@forrest, thanks for your fast reply.

 

A short note regarding counting the feedback:

forrest wrote

For the Client Isolation, I remember you have given us feedback about it, but we received little feedback from our other customers. For other feedbacks you gave, I will add them to the suggestion list for now but we may not change it these days and we will continue to collect the feedbacks.

 

I got this feedback also from our customers (several IT departments) of this company with 11 hospitals using ~120 EAPs now (previously 70). They don't participiate in the TP-Link forum and since we are their contract partner, they request features from our company, being an official partner of TP-Link and OEM for Omada products for years now.

 

I hope other users in this forum demanding this function will add to this thread or open a new request. The issue has been discussed with at least 3 other users in last year, so that should count as 5 requests so far (or 15 if you count each hospital's IT department separately). That's a bit more than the handful requests from SOHO users for client hostnames in Omada Controller, isn't it?

 

As for request #5 there have been three requests now, one from me and two for porting Omada controller to FreeBSD from user elmado just recently and another user I don't remember his name for porting the software to MacOS (MacOS is based on BSD UNIX, too). But there are over 800 downloads for the community version of Omada Controller v2.x and v3.x by now, thus a lot of users who use the architecture-independent Omada controller version for Debian, Raspbian or other Linux platforms.

 

What's more, this suggestion in #5 would also greatly simplify the TP-Link code base, which could be united for Windows and Linux platforms, so your R&D would save the double work they currently put into separate Java versions for Linux and Windows since Omada controller V3.

 

Thanks very much for consideration, I hope you find it useful.

More to come later this year if you want more ideas I still have for improving Omada controller.

༺ 0100 1101 0010 10ཏ1 0010 0110 1010 1110 ༻
1
1
#6
Options
Re:Feature requests for Omada Controller
2020-01-14 02:58:57

Hi guys!)
 

@forrest,  Thanks for the answer!  I want to add that I'm not as experienced in TP-Link equipment as in @R1D2.

 

I have only 4 finished projects on TP-Link equipment, and 5 I am starting to do the other day. the total number of access points in all 5 projects is 107 pieces. I also use 1600/2600 series switches and OC200 controllers.

 

I already wrote that I also have something to add to the list of additional functions / improvements, as soon as my list is finally ready, I will let you know.

 

@forrest, how many votes do you need to make a new function?  we say that there are few requests, but how many and how many we need, we don’t understand

 

Thanks!)

0
0
#7
Options
Re:Feature requests for Omada Controller
2020-01-15 10:29:56 - last edited 2020-01-15 10:31:02

TheKaban wrote

@forrest, how many votes do you need to make a new function?  we say that there are few requests, but how many and how many we need, we don’t understand

 

I also would like to know how many votes are required to have R&D consider implementing a new feature.

Please, forrest, can you comment on this? Thanks!

 

For what is worth, I also support the feature request for OC200/Omada SW controller redundancy from TheKaban. It would be a useful function for mesh networks with fail-over mechanism enabled in business-class installations such as public WLANs.

༺ 0100 1101 0010 10ཏ1 0010 0110 1010 1110 ༻
0
0
#8
Options
Re:Feature requests for Omada Controller
2020-01-24 19:02:12 - last edited 2020-01-24 19:08:01

@forrest I'd like to vote for these as well.

 

Please let us know if you need any input from us on them.

 

Thanks @R1D2 for summarizing them!

 

In regards to point #5. The os platform checks themselves are articficially making it very difficult to run omada on other platforms. The fact that it's Java makes it really feasible to port it to other platforms, but the os checks are neutering that feature.

 

As a developer I can relate to minimizing changes to the code base. Uniting the java code base may be too much of an ask, but removing the platform checks should be very straightforward (or at least converting them in to some form of warnings and providing a bypass).

 

Cheers!

2
2
#9
Options
Re:Feature requests for Omada Controller
2020-01-25 13:24:54 - last edited 2020-01-25 13:29:14

 

elmado wrote 

As a developer I can relate to minimizing changes to the code base. Uniting the java code base may be too much of an ask, but removing the platform checks should be very straightforward (or at least converting them in to some form of warnings and providing a bypass).

 

Thanks for pointing this out, elmado. Until Omada controller v3.x the EAP/Omada Java classes had been highly portable. In fact, I used the original Java classes from the official Windows controller version to create the Linux versions v2.5, v2.6 and v2.7.

 

Also, Privilege Separation can be done much better (and portable in the Linux ecosphere!) using start-stop-daemon or daemonize instead of using jsvc, which adds a dependency to the OpenJDK package (but works with Oracle JRE, too). My script omadactl used start-stop-daemon for Privilege Separation and I did send it to TP-Link's R&D back in early 2018. I don't know why the decided to use jsvc, can't see any reason for doing Privilege Separation in the Java part when it can be done already at start of the controller.

༺ 0100 1101 0010 10ཏ1 0010 0110 1010 1110 ༻
0
0
#10
Options
Re:Feature requests for Omada Controller
2020-01-25 19:04:02

@R1D2 If you want a more lightweight (and distro-agnostic) alternative for start-stop-daemon --user, there is also "runuser". It's provided by the util-linux package, so basically available everywhere.

0
0
#11
Options