Re: FreeBSD port of the Omada SDN Controller

From: Marcin Cieslak <saper_at_saper.info>
Date: Sun, 31 Aug 2025 01:58:21 UTC
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.
>
> # 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

With mongod running and configured as external it boot fine and I get the following
sockets:

fffffe011215f438 tcp4       0      0 127.0.0.1.21036    127.0.0.1.27017    ESTABLISHED
fffffe0112160518 tcp4       0      0 127.0.0.1.51692    127.0.0.1.27017    ESTABLISHED
fffffe011215e0e0 tcp4       0      0 127.0.0.1.62174    127.0.0.1.27017    ESTABLISHED
fffffe011215fca8 tcp4       0      0 *.8088             *.*                LISTEN
fffffe0111b6b870 tcp4       0      0 *.8043             *.*                LISTEN
fffffe0111b62950 tcp4       0      0 *.8843             *.*                LISTEN
fffffe011215f000 tcp4       0      0 *.9098             *.*                LISTEN
fffffe0111b63000 tcp4       0      0 127.0.0.1.63674    127.0.0.1.27017    ESTABLISHED
fffffe01121600e0 tcp4       0      0 *.29812            *.*                LISTEN
fffffe0111b61ca8 tcp4       0      0 *.29811            *.*                LISTEN
fffffe0111b61870 tcp4       0      0 *.29813            *.*                LISTEN
fffffe0111b61438 tcp4       0      0 *.29814            *.*                LISTEN
fffffe0111b61000 tcp4       0      0 *.29815            *.*                LISTEN
fffffe0111b60950 tcp4       0      0 *.29816            *.*                LISTEN
fffffe0111b60518 tcp4       0      0 127.0.0.1.65416    127.0.0.1.27017    ESTABLISHED
fffffe0112080950 tcp4       0      0 127.0.0.1.51523    127.0.0.1.27017    ESTABLISHED
fffffe0111b5fca8 tcp4       0      0 192.0.1.120.4798   13.213.157.84.443  ESTABLISHED
fffffe0112080518 tcp4      31      0 192.0.1.120.3904   52.19.136.76.443   CLOSE_WAIT
fffffe011215d438 tcp4      31      0 192.0.1.120.3904   52.19.136.76.443   CLOSE_WAIT

Looks like it likes calling home

Marcin