From Newsgroup: muc.lists.freebsd.ports

Hello all,
The TP-Link Omada controller software has been on the WantedPorts list for a while and I've picked up a modern TP-Link EAP to play with, so I did some investigation and found a viable solution to this problem.
I have a port patch you can fetch here for testing: https://people.freebsd.org/~feld/net-mgmt_omada5.patch
A blog post explaining the porting journey is here: https://blog.feld.me/posts/2025/08/omada-on-freebsd/
There may be some broken functionality (generating a PDF, something to do with WebP images, possibly the cloud integration?). If you have the gear and a desire to try running the controller on FreeBSD, give this a shot and send feedback. So far it seems to have no problem adopting and managing my EAPs which is the core functionality I cared about.
Simple instructions:
- Install the package
- Enable and start MongoDB
- Enable and start Omada
It should work. Takes some time for the controller to fully come online (~20 seconds here).
Mark
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

Hi Edward!

On Aug 25, 2025, at 17:00, Edward Sanford Sutton, III <mirror176@hotmail.com> wrote:

EXTRACT_AFTER_ARGS+= --exclude bin/topdf

Good call. I knew this was possible but couldn't remember the syntax and skipped it for the initial demo. I haven't been a super active porter in probably 10 years now. :)

I don't think the pkg-descr would need to have "Omada" in front of each of their device types.

FWIW, this is a direct quote off their website. "Up to 1,500 Omada access points, Omada switches, and Omada routers". I know it seems redundant, but not all TP-Link gear is supported, only the Omada-branded gear.

I wonder if there would be value in making the COMMENT dynamically generate the version # so it doesn't get missed porting a future update

I don't know if this matters so much. Lots of ports are like this, and the only time that number should change is when a completely new port is made by copying this one.

You may want to make sure USES+=cpe is ready to go if it is the software as found previously vulnerable at https://nvd.nist.gov/products/cpe/search/results?namingFormat=2.3&keyword=omada+controller .

Yes, good call.

Their website says it needs Java 8+; do we really need to hardcode 17 only?

I really don't know. It should be relaxed if it can, but for now I'm just sharing the exact working deployment that I've tested. Appreciate the feedback though.

A blog post explaining the porting journey is here: https://blog.feld.me/posts/2025/08/omada-on-freebsd/

Thank you for sharing the experience of doing this as such resources are useful for others to learn from.
More portable code would be setting isLinuxOS for both FreeBSD and Linux instead of replacing; if it won't be upstreamed then your patch replacing the current test is more optimized.

There isn't really an "upstream" other than a faceless corporate brick wall and I'm confident they will never lift a finger to attempt to support FreeBSD properly, much like when I ported UniFi to FreeBSD. It's disheartening, but true... Their community manager responded to my forum post with "thanks for posting the solution" instead of "I'll send this to the devs so this can be fixed for FreeBSD". I doubt the people doing community support have any contact with the actual developers. They probably don't even live on the same side of the planet or work under the same corporate structure. *sigh*...

I'd consider changing 127.0.0.1 to localhost unless its know that the software requires IPv4 support or requires it be an IP address.

Agreed

Been a while since I did anything with Java code but I though .jar is a zip. Should be possible to unzip it, patch it, and zip it back up so the user doesn't need to. If Recaf is the only decompiler option and doesn't support command line then it may be worth having the port patch the binary format directly. That will be smaller if an unzip+zip happens.

To be clear, I don't expect users to have to do this. This note is for the porters to explain how it was done in case I'm not available and there's an update that needs to be published. I'm publishing a jar file that is already modified and is one of the port distfiles, so users don't have to worry about it.
And yes it's a zip file, but it's not that simple. Inside is binary code that you need to decompile, find this "function" which likely is not 100% identical to the real source code, modify it, and then recompile it and reassemble the zip file. I've tried just making a diff -- even a binary diff -- but the patch ends up being over 500Kb because the re-assembled jar file is not packed in the exact same order as the original. Chasing that problem seems like a huge waste of time.
If someone could figure out a way to dynamically patch the class in the jar file -- either manually with a script the porter needs to run or as part of the port itself -- I'll pay out a $200 bounty. It would remove a lot of tedious pain when doing updates. I don't think it's possible though.
Also, if someone is reading this and thinking "why not just override the os.name value like -Dos.name=Linux" or inject the change really early in the VM startup using a custom Java Agent jar file, I've been down this road. It doesn't work. If you try to convince the JVM it's running as Linux but it's really on FreeBSD, it breaks because there are internal JVM things that rely on that value as well. I thought I had a super clever solution, but it failed.

I don't own Omada equipment but do wonder how the latency compare between Unifi and Omada access points as I seem unable to get Wifi ping throughput from either side below an average of about 20ms but fluctuates so much and much higher to where its really hard to say anything meaningful. Seeing that on 2 different generation access points at 2 different sites and tried different Wifi devices connected to it with with occupied and unoccupied bands on 2.4 and 5.

I still have my Unifi6 gear so I should try to compare, but 20ms is pretty high. Ping from my iPhone over wifi to my firewall is about 6ms with the highest pings I'm seeing around 8.5ms. Ping over same network path but from ethernet is about 0.4ms.

Thanks for porting!

Thank you for the feedback!
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On Aug 26, 2025, at 15:33, Marcin Cieslak <saper@saper.info> wrote:

On Tue, 26 Aug 2025, Marcin Cieslak wrote:

On Tue, 26 Aug 2025, Mark Felder wrote:

If someone could figure out a way to dynamically patch the class in the jar file -- either manually with a script the porter needs to run or as part of the port itself -- I'll pay out a $200 bounty. It would remove a lot of tedious pain when doing updates. I don't think it's possible though.

What about something like the below. Requires xxd and jar.

JARFILE=../Omada_SDN_Controller_v5.15.24.19_linux_x64/lib/omada-common-5.15.24.19.jar
ISLINUXOS_CLASS="com/tplink/smb/omada/common/util/S.class"

[...]

Can't test if this really works at the moment, should update the omada-common-5.15.24.19.jar file in place. If "check" fails, we need to figure out whether the Linux-checking function has been moved, renamed or discarded.

This seems to let me go past the following message:

08-26-2025 22:28:52.159 ERROR [main] [] c.t.s.o.s.OmadaLinuxMain(): Error: system is not linux, should not call this founction

That's looking promising. Does it ever listen on these ports? If so, it started up correctly. Might take 30 seconds or so.
# netstat -an | grep LISTEN
tcp4 0 0 *.29816 *.* LISTEN
tcp4 0 0 *.29815 *.* LISTEN
tcp4 0 0 *.29814 *.* LISTEN
tcp4 0 0 *.29813 *.* LISTEN
tcp4 0 0 *.29811 *.* LISTEN
tcp4 0 0 *.29812 *.* LISTEN
tcp4 0 0 *.9098 *.* LISTEN
tcp4 0 0 *.8843 *.* LISTEN
tcp4 0 0 *.8043 *.* LISTEN
tcp4 0 0 *.8088 *.* LISTEN
Mark
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2