Created attachment 245482 [details] patch to 0.73 + d4e0a60 This is update to latest version of rinetd, currently maintained at https://github.com/samhocevar/rinetd by Sam Hocevar. It supports new features such as specifying source ip binding and timeouts. The patch uses GH commit id as there's one bug fixed in master branch, although not released yet. Note: I didn't include select2poll patch because large portions of rinetd 0.62 were rewritten and it's not possible to apply original patch. There's a bit of discussion about switching upstream to modern event interface https://github.com/samhocevar/rinetd/issues/16 I will look at it and either re-patch for poll() or try to switch to libevent.
<https://www.freshports.org/net/rinetd/> at 0.62_4 <https://github.com/samhocevar/rinetd/releases/tag/v0.62.0sam> <https://github.com/samhocevar/rinetd/releases/tag/v0.62.1sam> <https://github.com/samhocevar/rinetd/releases/tag/v0.63> <https://github.com/samhocevar/rinetd/releases/tag/v0.70> <https://github.com/samhocevar/rinetd/releases/tag/v0.71> <https://github.com/samhocevar/rinetd/releases/tag/v0.72> <https://github.com/samhocevar/rinetd/releases/tag/v0.73> ^Triage: * status * avoid [tagging] summary lines * severity reduced, the norm for an update to a port.
Created attachment 245487 [details] revised patch to 0.73 + d4e0a60 I forgot to add added/deleted files to patch. Also this contains fix for linux'ism added for pid file handling.
Created attachment 245489 [details] revised (v3) patch to 0.73 + d4e0a60 re-revised patch, prepared properly as specified in porter's handbook and portlint cleanups
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=3c7b8fd3318ee88a93bc5561c9322558403d737e commit 3c7b8fd3318ee88a93bc5561c9322558403d737e Author: Marcin Gryszkalis <mg@fork.pl> AuthorDate: 2023-10-07 16:57:30 +0000 Commit: Renato Botelho <garga@FreeBSD.org> CommitDate: 2023-10-27 12:40:11 +0000 net/rinetd: update to new upstream and 0.73 While here, pet portlint and portclippy. PR: 274331 net/rinetd/Makefile | 38 +++--- net/rinetd/distinfo | 5 +- net/rinetd/files/patch-Makefile (gone) | 22 --- net/rinetd/files/patch-rinetd.c (gone) | 18 --- net/rinetd/files/patch-select2poll (gone) | 194 --------------------------- net/rinetd/files/patch-src_Makefile.am (new) | 11 ++ net/rinetd/files/patch-src_rinetd.c (new) | 11 ++ net/rinetd/pkg-plist (new) | 3 + 8 files changed, 47 insertions(+), 255 deletions(-)
I've fixed small issues on Makefile like using TABs after = and other ones reported by `portlint -C` and `portclippy Makefile` Thanks!
This new 0.73 build has severely degraded performance in my application compared to the previous 0.62_4. I'm running rinetd as a simple port 80/443 redirector over a Wireguard tunnel between two FreeBSD 13 servers. Under the previous .62_4 version, loading a web page over the connection results in these respectable browser stats (about a second): 46 requests 759.24 kB / 413.67 kB transferred Finish: 1.08 s DOMContentLoaded: 468 ms load: 603 ms With the new 0.73 version, the same page has these stats (nearly 30 seconds): 45 requests 758.91 kB / 435.01 kB transferred Finish: 28.06 s DOMContentLoaded: 2.66 s load: 28.06 s You can literally watch the images on the page draw out in bands as the bytes stream over slowly and render like PPP connection from 1998. I initially suspected my problem was due to other factors, so I troubleshooted everything else until I finally narrowed it down to rinetd. I found the older package and installed it and all was well again. I really don't know if the issue is due to something in the revised code or this port of it, but it's not ready for prime time, regardless. Happy to help test new releases.
(In reply to Morgan Davis from comment #6) Morgan, Do you mind to report this problem upstream? I'm not using rinetd at the moment and I don't know much about its source code so it would be easier to get some help from them.
Sure. I'll add an issue on the github project for you. However, your suggestion is surprising. I always assumed the people doing the porting had a vested interest in the software itself for their use. As a consumer of the package ecosystem I would expect that any revised application that is getting a new port/package would be thoroughly tested, especially something critical to network services like this. Is it normal practice to just take whatever new updates are available, get the port to compile, and then add it to the pkg repos?
I just filed the issue on github (https://github.com/samhocevar/rinetd/issues/42). The sources have not been updated in over 2 years. It has 20 open issues currently, going back to 2017. It's not looking optimistic that the original developer(s) are actively working on this or would be interested in debugging why this new port for FreeBSD is suboptimal. I think this .73 release needs to be pulled from release packages if others are similarly affected. Consider it for CURRENT for testing purposes, but stick to .62_4 for RELEASE.
(In reply to Morgan Davis from comment #8) I used to use rinetd a lot in the past and that was the reason I became its maintainer. Nowadays unfortunately I'm not using it anymore but I kept trying to maintain it instead of just drop the maintainership without having a new person to take it. If you are interested in maintain it, just let me know and I will be glad to transfer the maintainership to you.
Ah! I understand, Renato. Even if this were an area of expertise for me, I'd likely find myself in the same situation, so I'd best not take that on. Like you, I'm a user of rinetd, but not the right person to maintain it. That's tantamount to saying I'm a user of Firefox but not the right person to maintain it. I do hope one day to have nothing else to do but be a FreeBSD contributor.
I'm taking care of the issue as I'm also active user and I'll be able to find few hours to spend on this. I guess I can also take over maintainership with the next update.
(In reply to Marcin Gryszkalis from comment #12) Thank you!
(In reply to Marcin Gryszkalis from comment #12) Thank you, Marcin. For now I have locked the 0.62_4 package but am happy to test any new updates and let you know how they fare in my application. Feel free to reach out when you need feedback.