Re: FreeBSD port of the Omada SDN Controller

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

[...]

"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

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

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