Bug 253509
| Summary: | ftp-proxy not handling connections | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | Daniel Ponte <amigan> | ||||
| Component: | bin | Assignee: | Kyle Evans <kevans> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Some People | CC: | amigan, bugs, cytseng, gergely.czuczy, hf, jjasen, kevans, kp, lwhsu, spambox, tom | ||||
| Priority: | --- | Flags: | kevans:
mfc-stable13+
kevans: mfc-stable12- kevans: mfc-stable11- |
||||
| Version: | 13.0-STABLE | ||||||
| Hardware: | amd64 | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
Recompiling ftp-proxy linked instead to ports libevent (not libprivateevent1) resolves the issue on 13. The issue is contrib/pf/libevent/. Problem confirmed - coming from 11.1 to 13.0. An ftp-proxy linked to pkgsrc libevent (the machine does not use ports) works fine. Is there a perspective for a fix? Hello, A friend of mine also has a system which is affected by this bug. Could we please have this fixed? THat's odd, because the regression test for it keeps passing. Kyle was the last person to touch pf's libevent, so absent further evidence I'm just going to blame everything on him. Here're the host's details: czuczy@harley:~ $ uname -a FreeBSD harley.xyzones.net 13.0-RELEASE-p4 FreeBSD 13.0-RELEASE-p4 #0: Tue Aug 24 07:33:27 UTC 2021 root@amd64-builder.daemonology.net:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 czuczy@harley:~ $ uname -UK 1300139 1300139 The guys just tried to run an update, but it hasn't fixed it. Are there any more details that I can share to identify what's wrong here? When I ktraced it, the result was exactly what Daniel Ponte said. The kevent() calls weren't returning the new connections, as they should have. (In reply to gergely.czuczy from comment #5) I do not think the fix is present in binary updates for 13.0; I may be mistaken but I have not noticed the update process p4 install anything related to ftp-proxy (I also use ftp-proxy, and it is similarly broken for me). (In reply to gergely.czuczy from comment #5) Just checked my /var/db/freebsd-update on 13.0-RELEASE-p4 and could not find any matches for either ftp-proxy or libprivateevent. As it is not a security issue, we may possibly have to wait until 13.1 for the fix. (Also, in my reply above, read ‘process p4’ as ‘process for p4’) (In reply to Kristof Provost from comment #4) Er, I only touched it because it duplicated a struct from sys/sys/<mumble>.h and hadn't been updated to match ABI... I wonder if there's another, similar horror, hiding in there. (In reply to Daniel Ponte from comment #0) Can you share the full ktrace from this, please? (In reply to Kyle Evans from comment #9) Aye, I've long since lost the ktrace.out, and the machine no longer appears to be so afflicted, even after several updates since: root@farwarl:~ # killall ftp-proxy root@farwarl:~ # ftp-proxy -d -D7 listening on 127.0.0.1 port 8021 #1 accepted connection from 10.68.80.96 #1 FTP session 1/100 started: client 10.68.80.96 to server 128.148.32.111 via proxy 173.69.14.232 #1 server: 220---------- Welcome to Pure-FTPd [privsep] [TLS] ----------\r\n #1 server: 220-You are user number 1 of 50 allowed.\r\n #1 server: 220-Local time is now 01:19. Server port: 21.\r\n #1 server: 220-IPv6 connections are also welcome on this server.\r\n #1 server: 220 You will be disconnected after 15 minutes of inactivity.\r\n ^Cexiting on signal 2 #1 ending session root@farwarl:~ # uname -a FreeBSD farwarl.theamigan.net 13.0-STABLE FreeBSD 13.0-STABLE #3 stable/13-n246953-535874c15789: Thu Aug 26 03:33:37 EDT 2021 root@argon.h.c907:/usr/obj/usr/src/amd64.amd64/sys/FARWARL amd64 I wonder if the root cause was some stale library kicking around rather than an actual regression. (In reply to Daniel Ponte from comment #10) Oh, sorry, I just noticed the date of the report. I wonder if you were actually getting smacked by the aforementioned ABI breakage, which I only MFC'd to stable/13 here: https://cgit.freebsd.org/src/commit/contrib/pf/libevent?h=stable/13&id=e0ad785a5d29d33ff8f382ddf055950444cc92e2 (2021/04/01) -- in hindsight, maybe that's worth an EN. Created attachment 228223 [details]
ftp-proxy ktrace
ftp-proxy ktrace where kevent() doesn't return the new connection:
313 ftp-proxy GIO fd 2 wrote 33 bytes
"listening on 127.0.0.1 port 8021
"
313 ftp-proxy RET write 33/0x21
313 ftp-proxy CALL kevent(0x5,0x800a3c000,0,0x800a3b000,0x40,0x7fffffffe780)
313 ftp-proxy STRU struct kevent[] = { }
313 ftp-proxy STRU struct kevent[] = { }
313 ftp-proxy RET kevent 0
313 ftp-proxy CALL kevent(0x5,0x800a3c000,0,0x800a3b000,0x40,0x7fffffffe780)
313 ftp-proxy STRU struct kevent[] = { }
313 ftp-proxy STRU struct kevent[] = { }
313 ftp-proxy RET kevent 0
313 ftp-proxy CALL kevent(0x5,0x800a3c000,0,0x800a3b000,0x40,0x7fffffffe780)
313 ftp-proxy STRU struct kevent[] = { }
313 ftp-proxy RET kevent -1 errno 4 Interrupted system call
313 ftp-proxy PSIG SIGINT SIG_DFL code=SI_KERNEL
Between the "listening on" part and the SIGINT at the end a connection was received by ftp-proxy, and kevent() didn't return it.
(In reply to gergely.czuczy from comment #12) I think I've nailed this down to https://cgit.freebsd.org/src/commit/contrib/pf/libevent?h=stable/13&id=e0ad785a5d29d33ff8f382ddf055950444cc92e2 if you're in a position where you can test that patch. As a result of this, ypldap and ftp-proxy would have a different view of `struct event` than libevent1. (In reply to Kyle Evans from comment #13) Well, the box which is having this issue is using binary updates, so there's no source tree checked out right now. Could you please tell me what branch do I need exactly for this, and how to build just ftp-proxy to test the patch? (In reply to gergely.czuczy from comment #14) Ah, in that case, your best bet is honestly going to be to just grab a stable/13 snapshot and cherry-pick /usr/lib/libprivateevent1* from it -- as kp pointed out, there's been no activity except for mine, so this one will effectively have 13.0 + my patch: https://download.freebsd.org/ftp/snapshots/amd64/amd64/13.0-STABLE/base.txz -> no need to rebuild ftp-proxy, just plop libprivatevent1 bits in there and restart ftp-proxy to test it. Perhaps make a backup of your existing libprivateevent1* to be safe. (In reply to Kyle Evans from comment #15) Using libprivateevent1 from the linked base fixed it indeed. (In reply to gergely.czuczy from comment #16) Cool, thanks for confirming. I'll submit it for inclusion in the next EN/SA batch, now that we have a known-broken consumer. ypldap looks broken, too. I would like to confirm this bug on FreeBSD 13.0-RELEASE p4. Pulling libevent out of a snapshot now for testing. I forgot to mention, but the commit in question that fixes it was submitted for EN inclusion and I've received confirmation that it will be in the next batch. (In reply to Kyle Evans from comment #19) This was plucked[0] into releng/13.0 for inclusion into the EN batch that's dropping today, so I'm going to go ahead and close this. Thanks for the report! |
stable/13-n244514-18097ee2fb7c After updating to 13-STABLE from 12-STABLE, ftp-proxy no longer appears to function. Running it manually with -d -D7, it only prints its "listening" message and never anything else. Running it in ktrace only shows periodic kevent() calls and nothing else when a connection is made: [...] 57897 ftp-proxy GIO fd 2 wrote 33 bytes "listening on 127.0.0.1 port 8021 " 57897 ftp-proxy RET write 33/0x21 57897 ftp-proxy CALL kevent(0x5,0x800a4d000,0,0x800a4c000,0x40,0x7fffffffe690) 57897 ftp-proxy STRU struct kevent[] = { } 57897 ftp-proxy STRU struct kevent[] = { } 57897 ftp-proxy RET kevent 0 57897 ftp-proxy CALL kevent(0x5,0x800a4d000,0,0x800a4c000,0x40,0x7fffffffe690) 57897 ftp-proxy STRU struct kevent[] = { } It is definitely actually listening, and pf configured correctly to rdr to it, as stopping the service closes client connections.