Hi Edward! > On Aug 25, 2025, at 17:00, Edward Sanford Sutton, III <[email protected]> > wrote: > > EXTRACT_AFTER_ARGS+= --exclude bin/topdf
Good call. I knew this was possible but couldn't remember the syntax and skipped it for the initial demo. I haven't been a super active porter in probably 10 years now. :) > I don't think the pkg-descr would need to have "Omada" in front of each of > their device types. FWIW, this is a direct quote off their website. "Up to 1,500 Omada access points, Omada switches, and Omada routers". I know it seems redundant, but not all TP-Link gear is supported, only the Omada-branded gear. > 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 I don't know if this matters so much. Lots of ports are like this, and the only time that number should change is when a completely new port is made by copying this one. > 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 > . Yes, good call. > Their website says it needs Java 8+; do we really need to hardcode 17 only? I really don't know. It should be relaxed if it can, but for now I'm just sharing the exact working deployment that I've tested. Appreciate the feedback though. > >> 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. There isn't really an "upstream" other than a faceless corporate brick wall and I'm confident they will never lift a finger to attempt to support FreeBSD properly, much like when I ported UniFi to FreeBSD. It's disheartening, but true... Their community manager responded to my forum post with "thanks for posting the solution" instead of "I'll send this to the devs so this can be fixed for FreeBSD". I doubt the people doing community support have any contact with the actual developers. They probably don't even live on the same side of the planet or work under the same corporate structure. *sigh*... > 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. Agreed > 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. To be clear, I don't expect users to have to do this. This note is for the porters to explain how it was done in case I'm not available and there's an update that needs to be published. I'm publishing a jar file that is already modified and is one of the port distfiles, so users don't have to worry about it. And yes it's a zip file, but it's not that simple. Inside is binary code that you need to decompile, find this "function" which likely is not 100% identical to the real source code, modify it, and then recompile it and reassemble the zip file. I've tried just making a diff -- even a binary diff -- but the patch ends up being over 500Kb because the re-assembled jar file is not packed in the exact same order as the original. Chasing that problem seems like a huge waste of time. 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. Also, if someone is reading this and thinking "why not just override the os.name value like -Dos.name=Linux" or inject the change really early in the VM startup using a custom Java Agent jar file, I've been down this road. It doesn't work. If you try to convince the JVM it's running as Linux but it's really on FreeBSD, it breaks because there are internal JVM things that rely on that value as well. I thought I had a super clever solution, but it failed. > 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. I still have my Unifi6 gear so I should try to compare, but 20ms is pretty high. Ping from my iPhone over wifi to my firewall is about 6ms with the highest pings I'm seeing around 8.5ms. Ping over same network path but from ethernet is about 0.4ms. > Thanks for porting! Thank you for the feedback!
