Grbz wrote

i have the same java version as you, but i have always the same error while i will start the tpeap 

Hi,

see https://issues.jboss.org/browse/JBEWS-103. You probably have OpenJDK or some other JRE installed. Make sure it's the Oracle JRE, check with this command:

$ update-java-alternatives -l
jdk-8-oracle-arm32-vfp-hflt    318        /usr/lib/jvm/jdk-8-oracle-arm32-vfp-hflt
$ 

If this doesn't help, change JAVA_OPTS in /usr/bin/omadactl (old name: tpeap) from -server to -client.

See also post #6 in this thread, there is a new .deb-package with the latest version of Omada Controller 3.1.13 available.

Grbz wrote

I didnt download the .deb file. Only the omadacontrollerv3.1.4 _linux_x86.tar.gz. Must i download the .deb file?

No, you don't need the .deb-ackage, but have to set up the controller manually then. See the thread I linked to, user g2_ufo described the steps to do manually if you don't want to use my .deb-package. The TAR archive provided by TP-Link does not run out-of-the-box on Raspbian's ARM architecture, since the official Omada Controller includes x86 binaries (that's what x86 means in the name of the TAR farchive file).

Seems to me that you have screwed up things by installing the x86 version. My .deb-package does not require the JRE in TP-Link's official version.

I suggest to remove the package (use dpkg --purge), un-install the x86 version (either using the script provided by TP-Link or manually - if the latter, remove all tpeap links to control.sh in /etc/init.d, /etc/rc*.d and /usr/bin, too) and try again. Make sure that the Raspbian JRE is working, just run /usr/bin/java -version to check.

My .deb-package just needs a working JRE, the jsvc utility and the mongodb as provided by Raspbian.

WoDkaBE wrote

R1D2 , will you add support for Omada Controller 3.1.13(Linux) in the future?

Hello @WoDkaBE,

it's out there already, please see this post. However, it's a .deb package, not a TAR archive and as such it will override previous .deb package versions on installation.

Right now I'm waiting for the Linux version of 3.2, which just appeared for Windoze. Win Java files can't be used anymore for the Linux version since TP-Link checks for the platform it is running on in the main start procedure (introduced in v3.0).

If I were TP-Link, I would combine both platform versions into only one (can be done easily!) and get rid of the Apache Commons Daemon, which isn't needed if one uses standard Unix/Linux tools for Privilege Separation as the community versions did up to v2.7.0. This would allow to use Java classes files from Win also on Linux and there would be no delay in publishing a version for both OSes.

Questionmark wrote

Maybe you should officially suggest combining the Windows and Linux version.  It sounds like a great idea to me!  They just might listen.  By now, they should know that you know what you are talking about... 

Hi Questionmark,

thanks for your kind suggestion, but I did suggest the best way to add privilege separation to R&D in last three years many times.

In fact, EAP Controller for Linux community versions 2.4 to 2.7 have been sharing the same Java classes with Windows until privilege separation had been added in v3.0.1. The way this was done caused the split of the main start class (and only this is of interest here, there are still other classes which can be left platform-specific) into two different main classes, one for Windows and one for Linux. It's a long story, if you are interested in, read on.

Only days after the first Linux release of EAP Controller (v2.4.2) was published, I noticed missing privilege separation in the software (it was running as a root process), which is a big security threat to any OS. I did inform TP-Link immediately. You can even find forum posts about this security hole still here in the forum archive. But it needed several hacked Internet servers and take-overs through well-known holes in EAP-Controller's embedded Java many months later until TP-Link did recognize the ramifications of using a broken RMI method in the JRE together with lacking privilege separation.

One of the compromised servers was supported by me back then and thus I could learn the cracker's method for exploiting a server. Finally, I was able to proof my claims by creating a script to exploit public servers running EAP Controller, to become root and be able to remotely modify any file on the compromised system. Eventually, after learning about this proof-of-concept, TP-Link's R&D did implement the missing privilege separation in official v3.0.1 and did update the Java code to not require Java RMI (Remote Method Invocation) anymore.

So far, so good.

But they implemented privilege separation using the Apache Commons Daemon instead of standard Unix/Linux tools like start-stop-daemon, daemonize etc. as suggested by the fix in my inofficial Linux versions of EAP Controller v2.5 and 2.6, which already did have privilege separation months before v3 came out (I hadn't time to wait for R&D, sorry). Instead they choosed ACD/jsvc - which, BTW, also has vulnerability reports - and thus needed to add the OS query in the EAP Controller's main class, now becoming actually two classes, one for Linux and one for Windows. Although TP-Link did add some fixes from my script to their control.sh script, they did not implement the simple, error-proof, good old Unix method of privilege separation available in Linux too, which I did sent to R&D more than only once.

This choice of ACD is the reason why we can't just take over the Windows classes to Linux anymore to create an own community version controller as soon as the Windows release appears. It's just this one query in the main class and ACD which needs to be removed to make the Win Java classes of EAP Controller work on Linux, too. Of course, there are many other places where EAP Controller queries for the platform and those queries absolutely make sense there (e.g. for calling netstat or a listing of the process table, they differ between Windows and Linux), but it's the query in the main class which is the problem here.

Maybe you understand why I won't suggest it anymore - I already did so, but TP-Link did choose ACD, albeit their Java does not need to acquire root prvileges, but just to release root privileges from the start script. Thus, the ACD/jsvc method in the Java layer is IMHO the wrong method to fix this, at least if you want to keep the Java code portable.

Anyway, I still add my own script to and remove the embedded JRE from each official Linux version as soon as it is available and I have some time to build a package.