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!
