[Update 11/2020] Omada SDN Controller 4.2.4 for Devuan, Debian and other Linux systems
First Version: 2020-07-15
Last Update: 2020-11-20
In good old tradition of the community version of Omada Controller I just re-packaged latest Omada SDN Controller 4.2.4 for installation on Devuan, Debian and any other Linux system providing the dpkg installer.
There have been massive changes in the omadactl script and I took the opportunity to re-introduce switching between controller versions as introduced with Omada SW Controller V2.7 years ago. This means that you can install Omada SDN Controller without overwriting your existing controller and you can switch between all installed versions on the fly w/o the need to downgrade. I think this is handy if you want to just preview Omada SDN Controller for now.
However, it has its price: Omada Controller V3.2.10 needs to be updated, too, if you want to use this feature. What's more, only V3.2.10 is supported for switching, but future versions of SDN Controller community version will support this function, too (for this to work the version number of the software package needed to be moved to the package name). This means that the old versions will not automatically be removed when installing a new version. You can manually remove the old version if the newly installed one runs to your satisfaction.
Standard Disclaimer
The community version contains the original Omada SDN Controller from TP-Link, but with Privilege Separation enabled by default, as well as omadactl, which is an enhanced shell script used to start/stop and to manage the Omada SDN Controller server process. For a full list of the differences between the community and the official version see the section at the end of this post. TP-Link only supports their official version of the controller, but naturally this will affect the controller software in this community version, too. As for omadactl, this shell script is supported by me (R1D2) and bugs are fixed when reported.
Note that I can not give any support for installation of the software on a particular Linux system.
Please don't ask for step-by-step instructions or even videos on how to install the software. Every information needed to install the software is described in this post. If you cannot manage to get the software running on your Linux system, consider use of the OC200 or OC300 controller, which both also use Linux, but hide the details of the software setup.
Prerequisites
There are a few things to consider before installing Omada SDN Controller:
- As usual, you need Oracle JRE8, jsvc, mongodb, netstat (package net-tools) and curl.
Make sure you have those utilities installed before installing Omada SDN Controller. See the notes below.
- Important: If you want to adopt your EAPs, you need to update their firmwares.
See the posts from TP-Link in this forum and the Omada Controller Upgrade Guide which is included in the Omada SDN Controller package as well as attached to this post for your convenience.
MongoDB database
Omada SDN controller requires at least mongodb V3.2 or newer. The following packages are known to work (note the different package names!):
OS |
Package name |
Version (dpkg) |
---|---|---|
Devuan ASCII |
mongodb |
3.2.11-2+deb9u1 |
Debian 8 |
mongodb-org |
3.2.22 |
Debian 8 |
mongodb-org |
3.6.22 |
Note that only mongodb V3.2 or mongodb-org V3.2 supports both, the old Omada Controller V3.2.10 and the new SDN Controller V4.
- On Devuan ASCII just install the package mongodb from the repository.
- On Debian and related distributions follow the installation instructions on mongodb.org for either V3.2.22 if you want to switch between Omada Controller versions:
https://docs.mongodb.com/v3.2/tutorial/install-mongodb-on-debian/
- If you want run only Omada SDN Controller and need no compatibility of mongodb with Omada Controller V3.2.10, install mongodb-org V3.6 (or higher):
https://docs.mongodb.com/v3.6/tutorial/install-mongodb-on-debian/
Java Runtime Environment
It's recommended to use Oracle JRE. Some platforms offer a package in their repository, others don't. I prefer to donwload JRE8 from Oracle's website directly and to use the update-alternatives(8) mechanism to install the latest version. This is how it works:
- Download the 64-bit JRE for Linux (you don't need the full JDK).
- Extract the TAR archive into a directory of your choice (e.g. /opt/jvm).
- Install the JRE using update-alternatives:
update-alternatives --install /usr/bin/java java /opt/jvm/jre1.8.0_261/bin/java 261
Over the time your installed JRE packages might look like this:
# update-alternatives --list java
/opt/jvm/jre1.8.0_171/bin/java
/opt/jvm/jre1.8.0_181/bin/java
/opt/jvm/jre1.8.0_251/bin/java
/opt/jvm/jre1.8.0_261/bin/java
#
You can configure the version to use with the command update-alternatives --config java.
See the manpage of update-alternatives for more information.
Commons Daemon (jsvc)
You can try to install jsvc from the repository of your Linux distribution. However, last time I checked on Debian 8 jsvc required OpenJDK, which – if being installed – will configure itself as the default JRE using the update-alternatives mechanism. In this case I recommend to download the jsvc source and compile it instead of installing it via apt/apt-get. The jsvc binary actually does not require the OpenJDK, just the package jsvc is contained in depends on OpenJDK for whatever reasons.
Now for Omada SDN Controller: donwload the all-architectures .deb package
- Download the SDN controller from https://rent-a-guru.de/ftp/omada-sdn-controller-4.2.4_1_all.deb. Note the new package name, which starting with v4.2.4 contains the version number as part of its name.
- While you're at it, download the update for V3.2.10 from https://rent-a-guru.de/ftp/omada-controller_3.2.10-3_all.deb if you want to use switching between controllers. You can either install this update before or after installing the SDN Controller (see also the above note about mongodb versions supported by both, Omada Controller V3.2.10 and SDN Controller V4).
- Compare the checksums of the downloaded .deb files for integrity:
$ md5sum -b omada-sdn-controller-4.2.4_1_all.deb
a1d825befbb126dd9b868058205078a0 *omada-sdn-controller-4.2.4_1_all.deb
or:
$ sha256sum -b omada-sdn-controller-4.2.4_1_all.deb
d8414d75597322ecb7ca57cb293dfdfe7343f4e60365f8a6e6da09788ecfa77a *omada-sdn-controller-4.2.4_1_all.deb
- For the Omada Controller V3.2.10-3 package update:
$ md5sum -b omada-controller_3.2.10-3_all.deb
6b986ee67828d4c1e55d8dc6af1e8cbc *omada-controller_3.2.10-3_all.deb
or:
$ sha256sum -b omada-controller_3.2.10-3_all.deb
ef77aa88a3196d7663f35e59357a67833b86fa783923df480f56318ea84e5de2 *omada-controller_3.2.10-3_all.deb
Installation
Since SDN Controller has a new package name, your existing Omada Controller will not be overwritten, so it will retain all data. Again, read the Omada Controller Upgrade Guide to migrate your existing site to the new controller if you desire so.
Installing the V3.2.10 package update will also keep all settings, but to be on the safe site, make a backup before installing it. Please note that copying the database from an old controller to the new SDN Controller does not work; you need to migrate your site if you want to see the settings in the new controller.
Optional step (can be left out or executed at a later time if you're in a hurry): upgrade Omada Controller V3.2.10 if you have installed it:
dpkg -i omada-controller_3.2.10-3_all.deb
Now install Omada SDN Controller with the following command:
dpkg -i omada-sdn-controller-4.2.4_1_all.deb
Note that installing this package will overwrite the files /usr/bin/omadactl, /etc/init.d/omadad and /etc/default/omadad in an existing V3.2.10 installation if you left out the optional step above. Due to changes in Omada SDN Controller the locations of those files needed to be changed, too. They are now contained in Omada Controller's home directory (/opt/tplink/OmadaController).
In order to allow different versions of the Omada SDN Controller installed at the same time, the version number is now part of the package name. For example, your list of installed controller versions might look like this:
$ dpkg -l | fgrep omada
ii omada-controller 3.2.10-3 all Omada Controller for TP-Link's ...
ii omada-sdn-controller 4.1.5-2 all Omada SDN Controller for ...
ii omada-sdn-controller-4.2.4 1 all Omada SDN Controller for ...
$
Version switching
Now for the switching part. Try the following command (you can shorten »version« to just »v«):
$ omadactl -l version
Currently installed versions:
EAP Controller 2.7.0
Omada Controller 3.2.10
Omada Controller 4.1.5
Omada Controller 4.2.4 (current)
$
Next, try the switch command (as root):
# omadactl stop
Stopping Omada SDN Controller
# omadactl switch 3.2.10
Switched to 'OmadaController-3.2.10'. Now restart Omada Controller to activate it.
# omadactl switch 4.2.4
Switched to 'OmadaController-4.2.4'. Now restart Omada Controller to activate it.
#
That's my way of doing »downgrades« in just no time.
Starting/stopping the controller
You can start the controller synchronously (option -w) or asynchronously (no option) with omadactl:
# omadactl -w start
Starting Omada SDN Controller .................................................................................................
Omada SDN Controller started successfully after 43 seconds.
Direct your browser to http://your_hostname:8088 for accessing Omada SDN Controller.
#
On my embedded system it needs ~94 to ~99 seconds to start, on my Debian server it needs ~43 seconds, YMMV. You can specify a timeout with option -W sec when starting the controller synchronously and you can set the default timeout permanently with option -S sec (w/o starting the controller). The default timeout has been raised to 120 seconds for the SDN controller. The initial setup of the database will require more time at the very first start of Omada Controller.
To stop the controller use the stop command. To show it's status use the status command (obvious, isn't it?):
# omadactl stop
Stopping Omada SDN Controller
# omadactl status
Omada SDN Controller is not running
# omadactl start
Starting Omada SDN Controller
# omadactl status
Omada SDN Controller is still initializing, please wait ...
#
The script /etc/init.d/omadad will start the controller asynchronously at boot time to avoid delaying the boot sequence. You could use this command to start or stop the controller, too, but omadactl gives you much more functions. See the manpage for more information.
Changes in package omada-sdn-controller-4.2.4_1
- Moved version number to the package name to allow different versions of the same software to co-exist.
- Fixed double sourcing of OmadaController/CONFIG and /etc/default/omada in omadactl.
- Removed obsolete code from omadactl.
Changes in package omada-sdn-controller-4.1.5-2
- Fixed non-working verbose option (-v) in omadactl.
- Fixed dump and restore options of omadactl.
- Fixed bug in omadactl for getting properties.
- Fixed version dependencies for mongodb: The SDN Controller requires the package mongodb-org v3.2 or better.
Changes in package omada-sdn-controller-4.1.5-1
- Initial version.
- Modified omadactl to work with Omada SDN Controller.
Changes in package omada-controller-3.2.10-3
- Fixed non-working verbose option (-v) in omadactl.
- Fixed version dependencies for mongodb: The (old) Omada Controller requires either the package mongodb v2.4 or mongodb-org v3.2.
Changes in package omada-controller-3.2.10-2
- Changed location of duplicate files in different controller packages.
- Fixed version dependencies for mongodb to accept package mongodb-org.
Changes in package omada-controller-3.2.10-1
- Initial version.
More information
- For help with omadactl see its manpage: man omadactl
- For customization of omadactl see the config file CONFIG in the controller's home directory (/etc/default/omadad is gone).
- For a list of all files installed by the .deb package use the command: dpkg -L omada-controller
- If you want to uninstall this .deb package (except the database and other files created at run-time), use the »remove« option of dpkg: dpkg -r omada-controller
- If you want to uninstall this .deb package (including the database and other files created at run-time), use the »purge« option of dpkg: dpkg -P omada-controller
- For the release notes of Omada SDN Controller, the Omada Controller Upgrade Guide and the changelog for omadactl see the directory /usr/share/doc/omada-controller-4.1.5.
Differences and commonalities between official SDN Controller and Community Version (CV)
- The CV uses exactly the same JAVA class files from the official version, but is architecture-independend, that means it does not include any bundled binaries. Therefore you have to use up-to-date binaries for the required utilities which are most often installed on your Linux system anyway (curl, netstat, mongod, jsvc, java and a JRE of your choice). SDN Controller V4.1.5 finally removed previously bundled binaries as well as I always did suggest for its predecessors V2.x/V3.x.
- Official version 4.1.5 released 2020-07-13 has two bugs which prevent the controller from starting if Privilege Separation is used. If Privilege separation is not used, both bugs cause creation of a directory outside the Omada Controller's home directory with root ownership. Those bugs have been fixed in the CV already and have been reported to TP-Link.
- The CV automatically creates a role account »omadad« when installing the .deb-Package in order to enforce Privilege Separation, which is standard on UNIX/Linux for every server process started at boot time. To avoid the risk of potential root exploits you do not want to run the controller with admin privileges once it has been started.
- The CV uses improved shell scripts omadactl(8) and /etc/init.d/omadad for starting/stopping and managing the server. Both scripts replace the control.sh script found in the official version, which since version 3.x has incorporated a few critical, but not all mechanisms offered by omadactl.
- The CV's directory tree has much stricter file permissions which deny access for ordinary users to sensitive data such as certificates, properties, the controller's database and backups created with omadactl.
- The CV allows to have several controller versions installed at the same time and omadactl offers an easy way to switch between those instances on the fly.
- The CV uses the file CONFIG in Omada Controller's home directory for version- and system-dependend settings used by omadactl.
- omadactl allows to create backups from the command line using the mongodump(1) and mongorestore(1) utilities, thus enabling scheduled backups using the cron(8) daemon.
- omadactl allows to copy the database files from one version to another version, thus cloning the settings. Note: Direct database copies do not work for the transition from Omada Controller (V3) to Omada SDN Controller (V4).
- omadactl allows to raise or lower the Linux kernel's scheduling priority (niceness) for the Omada server process at start time or for an instance already running.
Enjoy! Sunshine!
Attached file: Omada Controller Upgrade Guide (also included in the package).
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
@R1D2 Hi R1D2. I am using 3.2.22-2 for mongodb at the moment.
And from what I heard 3.2 is the highest level for 32-bit
https://github.com/ddcc/mongodb/releases
- Copy Link
- Report Inappropriate Content
Hi Ronald1965,
note that the issue is about two different packages / different names: mongodb and mongodb-org. Don't get confused about package names and software names, both packages refer to the same software mongodb.
- Minimum version required by my package omada-sdn-controller for the package mongodb is still v2.6.1 (this was never changed).
I took this version number from an error message of mongod when trying to run OC v4.1.5 with mongodb v2.4.10. The error message indicated that OC software demands a feature which was first introduced in mongodb v2.6.1. I still don't know whether OC would really run with v2.6.1 or whether it uses even more features from later versions up to v3.2.
I could not find any document from TP-Link about the exact mongodb version required by SDN Controller. For previous versions of the controller I took the mongodb version number from the bundled mongodb in the official TAR archiv.
- Minimum version for the new package mongodb-org is v3.6.10. I did pick this number randomly from https://docs.mongodb.com.
It seems that the v2.6 version is not (or even never was) available under the package name mongodb-org according to: https://docs.mongodb.com/v2.6/tutorial/install-mongodb-on-debian/
First version I found where the new package name was mentioned is v3.0 according to: https://docs.mongodb.com/v3.0/tutorial/install-mongodb-on-debian/
However, if anyone currently using the old package mongodb (whatever version) decides to change to package mongodb-org, he will almost certainly use the latest version of this package which is v4.4 according to: https://docs.mongodb.com/manual/tutorial/install-mongodb-on-debian/
Hope it's now somewhat clearer. I definitely will not leave you behind after you did such a good work creating and updating a docker image.
- Copy Link
- Report Inappropriate Content
@R1D2 Taking a few steps back from others' question:
1) Will the Omada Controller continue to be upgraded? Or Omada SDN is the go to software now?
2) Omada Controller upgrade guide says I need to update my firmware for EAP 225 v3 to version 2.20.0. My Omada Controller 3.2.10 does not show that firmware version available under Site Settings, still at 2.7.0 Build 20200113 Rel. 38287. I could download version 2.20.0 from the website, but the website says that firmware only supports Omada Controller v4.1.4. So what are the exact steps to get my EAP 225 v3 connected to the SDN Controller? If I upgrade the firmware on the current Omada Controller 3.2.10, they may stop working, but if I don't upgrade them, I can't get them to work on the new SDN Controller.... kind of a deadlock / chicken and the egg problem.
3) Does the Omada SDN Controller consume more system resources than the Omada Controller? I use a Raspberry Pi 4 running Ubuntu Server 64-bit and Omada Controller process has the highest processor / memory usage.
4) Are there any plans to support more popular switches around home setups, like the TL-SG108PE ?
5) Assuming my current setup, I would believe I have all I need to run the 2 EAPs 225v3 I have? (with a third coming in soon)
$ omadactl -l version
Currently installed versions:
Omada Controller 3.2.10 (current)
$ ./java -version
java version "1.8.0_251"
Java(TM) SE Runtime Environment (build 1.8.0_251-b08)
Java HotSpot(TM) 64-Bit Server VM (build 25.251-b08, mixed mode)
$ uname -a
Linux pibuntu 5.4.0-1016-raspi #17-Ubuntu SMP Wed Aug 19 14:54:44 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux
Thanks
Luciano
- Copy Link
- Report Inappropriate Content
@LucianoR, please note that I'm not from TP-Link. I have not that much information to answer every question.
This thread is only about the 4.1.5 package to which I added the omadactl utility. Every question not regarding those two tools should go into an own thread if you expect an answer from TP-Link support.
LucianoR wrote
2) [...] If I upgrade the firmware on the current Omada Controller 3.2.10, they may stop working,
That's wrong. All EAPs which are supported by SDN Controller 4.1.5 can be adopted, so it's important to migrate from 3.2.10 to 4.1.5 according to TP-Link's Omada Controller Upgrade Guide. After the EAPs have been adopted, they will get configured by the new controller and to fully manage them, you then upgrade the EAPs using the online upgrade path.
If you prefer to set up your environment (not that difficult with two EAPs, isn't it?), you can even configure everything after the upgrade. You can even switch back to 3.2.10 if you later decide to migrate the controller instead of manually configuring it.
The only difference between the community version and the official version is that you can install both versions 3.2.10 and 4.1.5 at the same time on the same server, so you can switch from version to version in case something did go wrong.
But you still need to migrate or manually re-configure the new controller anyway. Please read post #1 for more information about this switch feature of omadactl or see the manpage omadactl(8).
3) Does the Omada SDN Controller consume more system resources than the Omada Controller? I use a Raspberry Pi 4 running Ubuntu Server 64-bit and Omada Controller process has the highest processor / memory usage.
Should run smoothly on a RasPi4 if you have enough RAM (SDN controller requires up to 6 GB if I remember correctly).
5) Assuming my current setup, I would believe I have all I need to run the 2 EAPs 225v3 I have? (with a third coming in soon)
Please read post #1. You need those packages (run dpkg -l):
omada-controller 3.2.10-2 all Omada Controller for TP-Link's EAP access points
omada-sdn-controller 4.1.5-1 all Omada SDN Controller for TP-Link's EAP access points
mongodb 1:3.2.11-2+deb9u1 amd64 object/document-oriented database (metapackage)
Your installed Java environment is o.k.
- Copy Link
- Report Inappropriate Content
That's wrong. All EAPs which are supported by SDN Controller 4.1.5 can be adopted, so it's important to migrate from 3.2.10 to 4.1.5 according to TP-Link's Omada Controller Upgrade Guide. After the EAPs have been adopted, they will get configured by the new controller and to fully manage them, you then upgrade the EAPs using the online upgrade path.
If you prefer to set up your environment (not that difficult with two EAPs, isn't it?), you can even configure everything after the upgrade. You can even switch back to 3.2.10 if you later decide to migrate the controller instead of manually configuring it.
So both the upgrade guide and the TP-Link firmware page are wrong.
Upgrade guide says it supports the EAP 225 v3 at firmware 2.20. You are saying it can adopt my EAPs running older firmware.
TP-Link firmware page says it needs Omada Controller v4.1.4 for the 2.20 firmware, but you are saying I can switch back to 3.2.10 controller after upgrading the firmware.
As you said, you don't work for TP-Link, but you get your software version reqirements done properly. They apparently do not, at least not in documentation / website.
And yes,I got the software requirements versions almost right (3.2.10-1 instead of 3.2.10-2) and I'm at a newer version of MongoDB:
ii omada-controller 3.2.10-1 all Omada Controller for TP-Link's EAP access points
ii mongodb 1:3.6.9+really3.6.8+90~g8e540c0b6d-0ubuntu5 arm64 object/document-oriented database (metapackage)
- Copy Link
- Report Inappropriate Content
no, TP-Link documentation is not wrong, but might be mis-understanding to some people.
The official documentation says that you need to upgrade EAP firmwares to be able to fully manage them. It does not say that you have to upgrade the firmwares to be able to adopt the EAPs. I did not read this anywhere, so TP-Link has definitely and intentionally taken care to not create a chicken/egg problem.
Thus, in SDN controller you can
- adopt EAPs running old firmwares,
- forget EAPs running old firmwares,
- upgrade EAPs using the online upgrade path,
- downgrade EAPs using the manual upgrade method,
- not fully manage EAPs until upgraded, and you can
- not receive statistics from EAPs until upgraded.
See this post for screenshots on how to adopt and upgrade EAPs with older firmwares in SDN Controller.
Switching between controller versions is unique to the community version of the controller and was introduced years ago in v2.7 already.
As you can read in post #1 of this thread, switching between Omada EAP Controller (that's v3.2.10) and the new product Omada SDN Controller (that's v4.1.5) does not mean that you can fully manage the EAPs regardless of their firmware versions in both controllers. It's just what I did wrote: you can install, switch and start or stop different controller versions. You cannot manage EAPs with SDN firmware under non-SDN controller and vice versa.
Nevertheless, switching between controller versions allows you
- to access every version of a controller installed, make backups, change settings etc.,
- to have a preview of newer controller versions w/o the need to adopt or upgrade the EAPs (but also w/o the ability to manage those EAPs then), and
- to downgrade to an old controller without needing to uninstall the newer version, install the older version and reading back the old settings from a backup (the latter is the way it needs to be done in the official TP-Link controller if you ever want to downgrade).
Switching between controller versions can not force an older controller to magically handle newer EAP firmwares and manage them. How should this work? The controller is the controller and EAPs are EAPs. Both, the controller and the EAPs, can work completely independent of each other, but you have to bring them into sync if you want to manage the EAPs.
- Copy Link
- Report Inappropriate Content
@LucianoR My experience was they were recognized, but first thing i had to do was upgrading the firmware. Because SDN has some requirements for that, its the fist thing you should do. Just download the firmware and connect your eap to a network. via a browser you can upgrade it too. I was able to do it with de SDN controller manually. automatic wasnt working. fyi i have 3 eap 225 v3 outdoor in meshing mode and one eap 245 v1.
- Copy Link
- Report Inappropriate Content
Cool information. I just installed the SDN Controller into my Raspberry Pi 4 running Ubuntu server 20.04 64-bit
I was able to get the service started, but on the last step of the wizard, when I click on Finish, it says "General error".
server.log:
java.lang.reflect.InvocationTargetException: null at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_251] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_251] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_251] at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_251] at com.tplink.omada.apigateway.dispatch.chain.a.a(SourceFile:79) [omada-api-gateway-4.1.5.jar:?] at com.tplink.omada.apigateway.dispatch.RestDispatcher.a(SourceFile:74) [omada-api-gateway-4.1.5.jar:?] at com.tplink.omada.web.controller.ApiController.a(SourceFile:57) [omada-web-4.1.5.jar:?] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_251] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_251] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_251] at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_251] at org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:189) [spring-web-5.1.6.RELEASE.jar:5.1.6.RELEASE] at org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:138) [spring-web-5.1.6.RELEASE.jar:5.1.6.RELEASE] at org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:102) [spring-webmvc-5.1.6.RELEASE.jar:5.1.6.RELEASE] at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:892) [spring-webmvc-5.1.6.RELEASE.jar:5.1.6.RELEASE] at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:797) [spring-webmvc-5.1.6.RELEASE.jar:5.1.6.RELEASE] at org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:87) [spring-webmvc-5.1.6.RELEASE.jar:5.1.6.RELEASE] at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:1038) [spring-webmvc-5.1.6.RELEASE.jar:5.1.6.RELEASE] at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:942) [spring-webmvc-5.1.6.RELEASE.jar:5.1.6.RELEASE] at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:1005) [spring-webmvc-5.1.6.RELEASE.jar:5.1.6.RELEASE] at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:908) [spring-webmvc-5.1.6.RELEASE.jar:5.1.6.RELEASE] at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) [javax.servlet-api-3.1.0.jar:3.1.0] at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:882) [spring-webmvc-5.1.6.RELEASE.jar:5.1.6.RELEASE] at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [javax.servlet-api-3.1.0.jar:3.1.0] at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:873) [jetty-servlet-9.4.15.v20190215.jar:9.4.15.v20190215] at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1623) [jetty-servlet-9.4.15.v20190215.jar:9.4.15.v20190215] at com.tplink.omada.web.filter.CacheControlFilter.doFilter(SourceFile:51) [omada-web-4.1.5.jar:?] at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610) [jetty-servlet-9.4.15.v20190215.jar:9.4.15.v20190215] at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:61) [shiro-web-1.4.0.jar:1.4.0] at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108) [shiro-web-1.4.0.jar:1.4.0] at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137) [shiro-web-1.4.0.jar:1.4.0] at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125) [shiro-web-1.4.0.jar:1.4.0] at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66) [shiro-web-1.4.0.jar:1.4.0] at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449) [shiro-web-1.4.0.jar:1.4.0] at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365) [shiro-web-1.4.0.jar:1.4.0] at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90) [shiro-core-1.4.0.jar:1.4.0] at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83) [shiro-core-1.4.0.jar:1.4.0] at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:387) [shiro-core-1.4.0.jar:1.4.0] at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362) [shiro-web-1.4.0.jar:1.4.0] at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125) [shiro-web-1.4.0.jar:1.4.0] at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:357) [spring-web-5.1.6.RELEASE.jar:5.1.6.RELEASE] at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:270) [spring-web-5.1.6.RELEASE.jar:5.1.6.RELEASE] at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610) [jetty-servlet-9.4.15.v20190215.jar:9.4.15.v20190215] at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540) [jetty-servlet-9.4.15.v20190215.jar:9.4.15.v20190215] at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146) [jetty-server-9.4.15.v20190215.jar:9.4.15.v20190215] at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548) [jetty-security-9.4.15.v20190215.jar:9.4.15.v20190215] at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) [jetty-server-9.4.15.v20190215.jar:9.4.15.v20190215] at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257) [jetty-server-9.4.15.v20190215.jar:9.4.15.v20190215] at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1701) [jetty-server-9.4.15.v20190215.jar:9.4.15.v20190215] at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255) [jetty-server-9.4.15.v20190215.jar:9.4.15.v20190215] at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345) [jetty-server-9.4.15.v20190215.jar:9.4.15.v20190215] at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203) [jetty-server-9.4.15.v20190215.jar:9.4.15.v20190215] at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480) [jetty-servlet-9.4.15.v20190215.jar:9.4.15.v20190215] at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1668) [jetty-server-9.4.15.v20190215.jar:9.4.15.v20190215] at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201) [jetty-server-9.4.15.v20190215.jar:9.4.15.v20190215] at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247) [jetty-server-9.4.15.v20190215.jar:9.4.15.v20190215] at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144) [jetty-server-9.4.15.v20190215.jar:9.4.15.v20190215] at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220) [jetty-server-9.4.15.v20190215.jar:9.4.15.v20190215] at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) [jetty-server-9.4.15.v20190215.jar:9.4.15.v20190215] at org.eclipse.jetty.server.Server.handle(Server.java:502) [jetty-server-9.4.15.v20190215.jar:9.4.15.v20190215] at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:370) [jetty-server-9.4.15.v20190215.jar:9.4.15.v20190215] at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:267) [jetty-server-9.4.15.v20190215.jar:9.4.15.v20190215] at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305) [jetty-io-9.4.15.v20190215.jar:9.4.15.v20190215] at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) [jetty-io-9.4.15.v20190215.jar:9.4.15.v20190215] at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:427) [jetty-io-9.4.15.v20190215.jar:9.4.15.v20190215] at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:321) [jetty-io-9.4.15.v20190215.jar:9.4.15.v20190215] at org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:159) [jetty-io-9.4.15.v20190215.jar:9.4.15.v20190215] at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) [jetty-io-9.4.15.v20190215.jar:9.4.15.v20190215] at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117) [jetty-io-9.4.15.v20190215.jar:9.4.15.v20190215] at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333) [jetty-util-9.4.15.v20190215.jar:9.4.15.v20190215] at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310) [jetty-util-9.4.15.v20190215.jar:9.4.15.v20190215] at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168) [jetty-util-9.4.15.v20190215.jar:9.4.15.v20190215] at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126) [jetty-util-9.4.15.v20190215.jar:9.4.15.v20190215] at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366) [jetty-util-9.4.15.v20190215.jar:9.4.15.v20190215] at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765) [jetty-util-9.4.15.v20190215.jar:9.4.15.v20190215] at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683) [jetty-util-9.4.15.v20190215.jar:9.4.15.v20190215] at java.lang.Thread.run(Thread.java:748) [?:1.8.0_251] Caused by: java.lang.NullPointerException at com.tplink.omada.service.api.impl.WizardApiServiceImpl.a(SourceFile:238) ~[omada-service-4.1.5.jar:?] ... 77 more |
- Copy Link
- Report Inappropriate Content
@LucianoR, since we have no source code of Omada Controller (it's proprietary software owned by TP-Link), we cannot track down any errors in the Java code, so Java stack backtraces are almost useless to find the cause of errorneous setups.
You said you use Java version 1.8.0_251. So do I on a server running Devuan/Debian and on this server it does not throw any error.
From what source did you install which Java software? From Oracle? From Ubuntu repositories?
- Copy Link
- Report Inappropriate Content
The java stack trace could give us a hint of what may have happened, so not entirely useless. In this case, since it's a reflection issue, we can't really tell which method / class it's calling, neither what is the underlying exception being throw.
I'm using the Oracle version, but I may have a different architecture than yours (aarch64). I'll try to run on my other server (x64) later today.
- Copy Link
- Report Inappropriate Content
Information
Helpful: 4
Views: 48549
Replies: 139