I'm using 3proxy as FTP proxy (squid doesn't support DELETE command). Config: ===Cut=== nserver 127.0.0.1 nscache 65536 timeouts 1 5 30 60 180 1800 15 60 daemon log /var/log/3proxy/proxy.log D logformat "- +_L%t.%. %N.%p %E %U %C:%c %R:%r %O %I %h %T" archiver gz /bin/gzip %F rotate 10 external 0.0.0.0 internal 192.168.3.1 auth iponly @allow * 127.0.0.1,192.168.3.22,192.168.3.41 * * ftppr -p2121 setgid 22922 setuid 22924 ===Cut=== After upgrading from 0.6.1 to 0.8.5 ftppr stopped to work: ===Cut=== [root@taiga:local/etc]# ftp 192.168.3.1 2121 Connected to 192.168.3.1. 220 Ready Name (192.168.3.1:emz): ftp@ftp.freebsd.org 331 ok Password: 230- 230-This is ftp0.ydx.FreeBSD.org, graciously hosted by Yandex. 230- 230-FreeBSD files can be found in the /pub/FreeBSD directory. 230- 230 Login successful. Remote system type is UNIX. Using binary mode to transfer files. ftp> ls 229 Entering Extended Passive Mode (|||49904|) ftp: Can't connect to `192.168.3.1:49904': Connection refused 200 OK 550 err ftp> ^D 221 Goodbye. ===Cut=== As simple as that. If the target host is inside LAN, ftppr for some reason allows to work with it, but during `ls` it cannot finish the output and connection hangs (then gets terminated after some timeout). I've spend about an hour trying to debug my configuration and networking problems - without any result. Luckily, I had a machine with old 0.6.1 version, so I decided to downgrade. After doiwngrading 0.8.5 to 0.6.1 ftppr suddenly restored it's functionality, without changing the config. Same session on 0.6.1, with exactly same config: ===Cut=== [root@taiga:3proxy/3proxy]# service 3proxy restart Stopping threeproxy. Waiting for PIDS: 65700. Starting threeproxy. [root@taiga:3proxy/3proxy]# ftp 192.168.3.1 2121 Connected to 192.168.3.1. 220 Ready Name (192.168.3.1:emz): ftp@ftp.freebsd.org 331 ok Password: 230- 230-This is ftp0.ydx.FreeBSD.org, graciously hosted by Yandex. 230- 230-FreeBSD files can be found in the /pub/FreeBSD directory. 230- 230 Login successful. Remote system type is UNIX. Using binary mode to transfer files. ftp> ls 229 Entering Extended Passive Mode (|||62859|) ftp: Can't connect to `192.168.3.1:62859': Connection refused 200 OK 125 data -rw-r--r-- 1 ftp ftp 5430 Jul 19 2014 favicon.ico -rw-r--r-- 1 ftp ftp 660 Nov 02 2015 index.html drwxr-xr-x 3 ftp ftp 3 Jul 19 2014 pub 226 Directory send OK. ftp> ^D 221 Goodbye. ===Cut===
(In reply to emz from comment #0) It's better to create this bug report here https://github.com/z3APA3A/3proxy/issues
Ok, I see you created this one https://github.com/z3APA3A/3proxy/issues/68
The upstream fix is https://github.com/z3APA3A/3proxy/commit/8cdf341d0e7f03a6c7b520962d935cdd75ab9c1d I'm going to include it into port and bump portrevision
Emm.... the author promised that this commit will be in the next release - that's why I didn't report that the fix exists and didn't attach the patch here. Does it means it still didn't ?
Created attachment 173994 [details] upsteam fix for port (In reply to emz from comment #4) That's true. But it hasn't been released since patch was merged into stable branch.
Created attachment 173995 [details] poudriere log
Committed, thanks!
A commit references this bug: Author: pi Date: Wed Aug 24 04:43:11 UTC 2016 New revision: 420760 URL: https://svnweb.freebsd.org/changeset/ports/420760 Log: net/3proxy: fix ftppr - See also: https://github.com/z3APA3A/3proxy/issues/68 PR: 209463 Submitted by: emz@norma.perm.ru Approved by: Pavel Timofeev <timp87@gmail.com> (maintainer) Changes: head/net/3proxy/Makefile head/net/3proxy/files/patch-src_common.c head/net/3proxy/files/patch-src_ftp.c
please, close this bug report. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212403
Closed as requested.