Re: FreeBSD port of the Omada SDN Controller

On 8/25/25 11:54, Mark Felder wrote:
 > 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

If you are
   ${RM}
ing extracted content because you extracted it but don't want it or it 
interferes, consider
   EXTRACT_AFTER_ARGS+=	--exclude bin/topdf
and similar to just not extract them. This reduces disk space and I/O 
during build but I found some archive formats seemed to extract slower 
once given such instructions but I haven't looked into optimizing it.
   I don't think the pkg-descr would need to have "Omada" in front of 
each of their device types.
   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 
or if that would be considered not worth a performance impact. Putting 
the version in the comment seems quite redundant to me which I see 
net-mgmt/unifi9 also did but other programs like postgresql and llvm 
avoid even though they have a better number of ports in the tree.
   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 
.
   Their website says it needs Java 8+; do we really need to hardcode 17 
only?

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

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

   I'd be interested in how to 'properly' resolve the library issues 
without switching to the Linux ABI to see if it helps other porting 
efforts I've had though I agree I'd be likely to leave it broken as I 
don't need/want cloud control over my home network. If fixed in the 
future, don't forget to consider architecture compatibility/tagging may 
need to be changed.

 > 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

   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.
   Thanks for porting!