[Update 11/2020] Omada SDN Controller 4.2.4 for Devuan, Debian and other Linux systems

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
1678...

[Update 11/2020] Omada SDN Controller 4.2.4 for Devuan, Debian and other Linux systems

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
139 Reply
Re:Omada SDN Controller 4.1.5 for Devuan, Debian and other Linux systems
2020-08-22 12:51:08 - last edited 2020-08-22 12:53:15

@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

  0  
  0  
#63
Options
Re:Omada SDN Controller 4.1.5 for Devuan, Debian and other Linux systems
2020-08-22 14:30:53 - last edited 2020-08-22 14:41:45

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.

 

༺ 0100 1101 0010 10ཏ1 0010 0110 1010 1110 ༻
  0  
  0  
#64
Options
Re:Omada SDN Controller 4.1.5 for Devuan, Debian and other Linux systems
2020-09-02 16:58:57

@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

 

  0  
  0  
#65
Options
Re:Omada SDN Controller 4.1.5 for Devuan, Debian and other Linux systems
2020-09-02 18:40:35 - last edited 2020-09-02 18:47:59

@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.

༺ 0100 1101 0010 10ཏ1 0010 0110 1010 1110 ༻
  0  
  0  
#66
Options
Re:Omada SDN Controller 4.1.5 for Devuan, Debian and other Linux systems
2020-09-02 20:33:11

 

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)
 

  0  
  0  
#67
Options
Re:Omada SDN Controller 4.1.5 for Devuan, Debian and other Linux systems
2020-09-02 22:53:57 - last edited 2020-09-02 23:11:06

@LucianoR,

 

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

  1. to access every version of a controller installed, make backups, change settings etc.,
  2. 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
  3. 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.

༺ 0100 1101 0010 10ཏ1 0010 0110 1010 1110 ༻
  0  
  0  
#68
Options
Re:Omada SDN Controller 4.1.5 for Devuan, Debian and other Linux systems
2020-09-03 05:34:01

@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. 

  1  
  1  
#69
Options
Re:Omada SDN Controller 4.1.5 for Devuan, Debian and other Linux systems
2020-09-03 18:34:12

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
 

 

  0  
  0  
#70
Options
Re:Omada SDN Controller 4.1.5 for Devuan, Debian and other Linux systems
2020-09-04 10:47:02

@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?

 

 

༺ 0100 1101 0010 10ཏ1 0010 0110 1010 1110 ༻
  0  
  0  
#71
Options
Re:Omada SDN Controller 4.1.5 for Devuan, Debian and other Linux systems
2020-09-04 13:02:47

@R1D2 

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.

  0  
  0  
#72
Options