Re: FreeBSD port of the Omada SDN Controller

[Marcin Cieslak]

On Sun, 31 Aug 2025, Marcin Cieslak wrote:

On Sat, 30 Aug 2025, Mark Felder wrote:

On Aug 26, 2025, at 15:33, Marcin Cieslak <sa...@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.

[...]

"patch" function of the following script could be added to
the post-patch or something like this to patch the jar file
during the build.

"check" function is only needed for the maintainer to check
if the newer version behaves the same as the old one.


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"

check() {
unzip -p "${JARFILE}" "${ISLINUXOS_CLASS}" | xxd -p -c 0 |
        grep -q 01000969734c696e75784f53 || { echo >&2 "\"${ISLINUXOS_CLASS}\" does 
not check for Linux"; exit 1; }
}

patch() {
        new_class_dir=`mktemp -d`
        trap 'rm -rf -- "${new_class_dir}"' EXIT
        dest_dir=`dirname "${ISLINUXOS_CLASS}"`
        mkdir -p "${new_class_dir}/${dest_dir}"
        unzip -p "${JARFILE}" "${ISLINUXOS_CLASS}" | xxd -p -c 0 | {
                sed -e s,0100056c696e7578,01000766726565627364,
        } | xxd -r -p > "${new_class_dir}/${ISLINUXOS_CLASS}"
        jar uf "${JARFILE}" -C "${new_class_dir}" "${ISLINUXOS_CLASS}"
}
check && patch


I would also suggest the following change to the logging configuration:

--- 
Omada_SDN_Controller_v5.15.24.19_linux_x64/properties/log4j2.properties.orig    
    2025-08-31 12:55:55.330326000 +0000
+++ Omada_SDN_Controller_v5.15.24.19_linux_x64/properties/log4j2.properties     
2025-08-31 12:56:08.237266000 +0000
@@ -2,7 +2,7 @@
 dest = err
 name = PropertiesConfig

-property.pattern = %d{MM-dd-yyyy HH:mm:ss.SSS} %p [%t] [%X{REQUEST_ID}] 
%c{1.}(%L): %m%n
+property.pattern = %d{MM-dd-yyyy HH:mm:ss.SSS} %p [%t] [%X{REQUEST_ID}] 
%c(%L): %m%n
 property.filePath = ../logs
 property.fileName = server
 property.maxSize = 20MB



I wouldn't worry about the following warning in the server.log:

WARN [main] [] com.tplink.smb.omada.common.util.S(): Nonsupport system:freebsd.

As the code checks only for Windows and Linux,
 I believe we get the same message on macos.
If we fix it, it tries to run the "arch" program we do not have
only to add the current architecture name to some string.
I think this is not worth the hassle of extra patching.

Marcin

This will increase the size of the log (newsyslog configuration!) but we will have full class names for eventual further troubleshooting.

smime.p7s
Description: S/MIME Cryptographic Signature