Business Community > WiFi > Installing Omada Controller 3.2.4 on FreeBSD
< WiFi

Installing Omada Controller 3.2.4 on FreeBSD

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

Installing Omada Controller 3.2.4 on FreeBSD

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
Installing Omada Controller 3.2.4 on FreeBSD
Installing Omada Controller 3.2.4 on FreeBSD
2019-12-25 08:11:29 - last edited 2019-12-25 08:13:00

I'm trying to install Omada Controller on FreeBSD (11 because eventually it will go on a PFSense router based of 2.4.4).

 

I've seen a few useful scripts like https://github.com/tinwhisker/tplink-eapcontroller-pfsense which provide a recipie for setting Omada up on a freeBSD type device, but they are a bit outdated.

 

The overall idea seems to remain the same tho - provide java and mongo db binaries which are compatible with your OS/architecture and run the Java controller.

 

The threads in this forum have also proven very handy. It also noted that the BSD package for the apache-commons-deamon (JSVC) may not be compatible.

 

So far I've installed the following freeBSD packages and their related dependancies

 

pkg install mongodb40-4.0.12_1

pkg install bash

pkg install apache-commons-daemon-1.2.2

 

As per the instructions from Java, I have added the following lines in /etc/fstab:

fdesc   /dev/fd         fdescfs         rw      0       0       

proc    /proc           procfs          rw      0       0

Then extracted the EAP controller from the tar.gz file and moved it into /opt/tplink/EAPController

 

Updated the jre directory to point to /usr/local/openjdk8/jre and bin/mongod to point to /usr/local/bin/mongod

 

Running bash control.sh start results in the following startup log:

 

:/opt/tplink/EAPController/logs # cat startup.log

java version "1.8.0_232"OpenJDK Runtime Environment (build 1.8.0_232-b09)

OpenJDK 64-Bit Server VM (build 25.232-b09, mixed mode)

commons daemon version "1.2.2"

commons daemon process (id: 1669, parent: 1668)

Going to init controller!

Going to start controller!

SLF4J: com.tp_link.eap.configuration.b

SLF4J: The following set of substitute loggers may have been accessed

SLF4J: during the initialization phase. Logging calls during this

SLF4J: phase were not honored. However, subsequent logging calls to these

SLF4J: loggers will work as normally expected.

SLF4J: See also http://www.slf4j.org/codes.html#substituteLogger

SLF4J: com.tp_link.eap.util.o

Error: system is not linux, should not call this founction

 

Strange spelling there of the word function🙂

 

At this point, based on the info from the other thread

https://community.tp-link.com/en/business/forum/topic/166466

It suggests that JSVC needs to be rebuilt locally, I gave that a shot by adding a few more packages:

pkg install bash

pkg install gcc10-devel-10.0.0.s20191201

 

Then I manually built the jsvc from http://commons.apache.org/proper/commons-daemon/download_daemon.cgi with a bit of command line file pointing..

./configure --with-java=/usr/local/openjdk8/bin --with-os-type=../include/freebsd

 

Unfortunately I'm still seeing the same error, but with a different package:

 

/opt/tplink/EAPController/logs # cat startup.log

java version "1.8.0_232"

OpenJDK Runtime Environment (build 1.8.0_232-b09)

OpenJDK 64-Bit Server VM (build 25.232-b09, mixed mode)

commons daemon version "1.2.2"

commons daemon process (id: 4963, parent: 4961)

Going to init controller!

Going to start controller!

Error: system is not linux, should not call this founction

SLF4J: com.tp_link.eap.util.m.a

SLF4J: The following set of substitute loggers may have been accessed

SLF4J: during the initialization phase. Logging calls during this

SLF4J: phase were not honored. However, subsequent logging calls to these

SLF4J: loggers will work as normally expected.

SLF4J: See also http://www.slf4j.org/codes.html#substituteLogger

 

The error makes me wonder if there is some code trying to determine the os type, and perhaps it's getting freebsd back from the OS, like one would in uname:

 

uname -a

FreeBSD freebsd.myhome.home 11.3-STABLE FreeBSD 11.3-STABLE #0 r355869: Thu Dec 19 02:10:41 UTC 2019 root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64

 

If this is the case, and the check is part of the custom java controller software this could pose a challenge. Seems a bit strange tho, since people have run the older versions of omada on FreeBSD.

 

Any input would be appreciated! Thanks!

  0      
 
  0      
 
#1
Options
17 Reply
Re:Installing Omada Controller 3.2.4 on FreeBSD
2019-12-25 21:30:48

 

elmado wrote

SLF4J: com.tp_link.eap.util.o

Error: system is not linux, should not call this founction

 

Uhm, that's from the platform test in Java method com.tp_link.eap.start.EapLinuxMain.

 

Unfortunately, TP-Link added this platform test in Omada Controller v3.x when introducing Privilege Separaton using jsvc.

 

In my opinion the platform test is not necessary at this place since the Java code of both methods EAPLinuxMain (for Linux) and EAPMain (for Windows) is platform-independent.

 

The platform test might be used in other Java methods to decide whether to call Linux/UNIX binaries such as netstat and ps or whether to call their Windows pendants, but in my opinion it would be much better to check for the existence of the netstat and ps binaries in the appropriate Java methods to decide whether to call the Linux/UNIX variants or the Windows pendants for those commands.

 

By checking for the existence of the binaries, the same Java code could be shared for Linux, FreeBSD, MacOS and Windows, thus eliminating the need to support two different code branches as it is done now since Omada Controller version 3.x. I did suggest this method to check for the binaries rather than to check for the platform to TP-Link's R&D already.

 

Also, in my opinion jsvc is not the right way to do Privilege Separation, since in Omada Controller v2.7 it was possible to do all actions requiring admin privileges in the start/stop script which then could release admin privileges just before starting the Java part of the controller by calling the EapMain (Windows!) method even on Linux. 

 

Sorry @elmado , I totally forgot to mention this in the other thread where we had been talking about a port to FreeBSD – in Omada Controller v2.7 I actually used the very same Java classes for Windows with a wrapper for Privilege Separation in the start/stop script on Linux (using start-stop-daemon for Linux or daemonize etc. for other platforms), so except for the recently introduced calls to netstat and ps there are no other platform-specific dependencies in all versions of Omada Controller preceeding version 3.x.

 

༺ 0100 1101 0010 10ཏ1 0010 0110 1010 1110 ༻
  0  
  0  
#2
Options
Re:Installing Omada Controller 3.2.4 on FreeBSD
2019-12-26 08:16:41

@R1D2 ah, thanks for the reply.

 

So it seems like there is propriertary code in the 3.x version of the controlller which checks the platform to be Linux or Windows.

This is very unfortunate - especially if the check is not really necessary at this point.

 

Either way, it seems that unless TP link is willing to add FreeBSD to it's list of supported OS's my options are somewhat limited.

 

I may have to implement a vm based appraoch with multiple systems to support running pfsense/freebsd and the omada controller on the same box. It's a bit unfortunate, but it's another possibility.

 

Thanks!

  0  
  0  
#3
Options
Re:Installing Omada Controller 3.2.4 on FreeBSD
2019-12-26 11:03:40 - last edited 2019-12-26 11:04:12

@elmado, the whole controller is proprietary and unfortunately also architecture-dependent. Maybe you want to play around with the community version of Omada Controller v2.7.0 (not the officially version, which depends on x86 platforms, too), which was the last architecture-independent version. I still use v2.7.0 on some production sites: https://community.tp-link.com/en/business/forum/topic/150035 It's a bit old, but better than nothing.

༺ 0100 1101 0010 10ཏ1 0010 0110 1010 1110 ༻
  0  
  0  
#4
Options
Re:Installing Omada Controller 3.2.4 on FreeBSD
2019-12-31 07:39:52

Thanks, I was able to get an older version running.

My AP is on newer firmware, so it's preferable to use the later controller. I was able to achieve this using a Debian VM to host it. It's not as efficient, but fortunately I have that option.

 

Thanks again for all your help!

  0  
  0  
#5
Options
Re:Installing Omada Controller 3.2.4 on FreeBSD
2019-12-31 11:15:33

Hi @elmado, great that you found a workaround. Maybe in a future version of Omada Controller TP-Link will hopefully remove the platform dependency of Omada Controller, so that a native version of the controller can run on BSD Unix, too. I will send a bunch of feature requests for Omada Controller to TP-Link soon.

༺ 0100 1101 0010 10ཏ1 0010 0110 1010 1110 ༻
  0  
  0  
#6
Options
Re:Installing Omada Controller 3.2.4 on FreeBSD
2020-01-02 23:17:40

@R1D2 

Thanks. I will keep an eye on the forums. Appreciate your efforts and feedback on this!

  0  
  0  
#7
Options
Re:Installing Omada Controller 3.2.4 on FreeBSD
2020-03-22 22:23:41
@R1D2 do you have a link to download v2.7.0 of the Omada controller software? I can't find it.
  0  
  0  
#8
Options
Re:Installing Omada Controller 3.2.4 on FreeBSD
2020-03-23 01:47:06

@Ryan_M 

 

We have removed the version of Controller from the official website. 

Why do you want to use this version of Controller? We recommend you use the latest Controller. 

  0  
  0  
#9
Options
Re:Installing Omada Controller 3.2.4 on FreeBSD
2020-04-20 17:17:55

@forrest I have yet to buy TP-Link APs but need the controller to run on FreeBSD, that is why I would be looking for the older controller software.

  0  
  0  
#10
Options
Re:Installing Omada Controller 3.2.4 on FreeBSD
2020-04-20 17:45:29 - last edited 2020-04-20 17:55:02

@emaste, v2.7.0 community version is still available here. Note that it's a deb-package and it uses start-stop-daemon for Privilege Separation (instead of jsvc introduced with v3.0.2). However, you could also use daemonize to achieve the same functionality (official TP-Link version v2.7.0 did not use Privilege Separation at all). Note that v2.7 lacks certain features present in newer versions of Omada Controller, but at least the Java classes are platform-independent.

༺ 0100 1101 0010 10ཏ1 0010 0110 1010 1110 ༻
  0  
  0  
#11
Options
12

Information

Helpful: 0

Views: 7886

Replies: 17

About Us
Press
Copyright © TP-Link Corporation Limited. All rights reserved.