After major version upgrade from 13.1 RELEASE to 14.0 RELEASE i've got an issue with my service running in linux jail. Incoming connections to service port are not accepted. Here is the information after making several attempts to connect to the service port (6878): # netstat -LaAn -j devuan Current listen queue sizes (qlen/incqlen/maxqlen) Tcpcb Proto Listen Local Address fffff8039dafc540 tcp4 8/0/5 *.6878 fffff803a0125540 tcp4 0/0/64 *.8621 # netstat -an -j devuan Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp4 197 0 192.168.0.7.6878 192.168.88.23.53763 CLOSE_WAIT tcp4 197 0 192.168.0.7.6878 192.168.88.23.53761 CLOSE_WAIT tcp4 197 0 192.168.0.7.6878 192.168.88.23.53758 CLOSED tcp4 197 0 192.168.0.7.6878 192.168.88.23.53756 CLOSED tcp4 197 0 192.168.0.7.6878 192.168.88.23.53755 CLOSED tcp4 197 0 192.168.0.7.6878 192.168.88.23.53753 CLOSED tcp4 197 0 192.168.0.7.6878 192.168.88.23.53748 CLOSED tcp4 326 0 192.168.0.7.6878 192.168.88.23.53721 CLOSED tcp4 0 0 *.6878 *.* LISTEN tcp4 0 0 *.8621 *.* LISTEN # ps -axwwl -J devuan. (PID 9150 listens that port) UID PID PPID C PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 99 1 0 20 0 4468 2976 select IsJ - 0:00.00 /usr/sbin/rsyslogd 0 3350 1 2 20 0 3668 2412 nanslp SsJ - 0:00.00 /usr/sbin/cron 0 8454 3350 3 34 0 6040 3696 wait IJ - 0:00.00 /usr/sbin/cron 0 8595 8454 0 66 0 2404 1528 wait IsJ - 0:00.00 /bin/sh -c ps -ef | grep '[/]opt/acestream/acestreamengine' || /usr/bin/acestreamengine --allow-user-config ./acestream_user.conf --access-token 12345 > /dev/null (dash) 0 8951 8595 7 66 0 3740 2752 wait IJ - 0:00.00 /bin/bash /usr/bin/acestreamengine --allow-user-config ./acestream_user.conf --access-token 12345 0 9150 8951 2 68 0 1815288 77844 sbwait IJ - 0:01.02 /opt/acestream/acestreamengine --lib-path /opt/acestream --allow-user-config ./acestream_user.conf --access-token 12345 # dmesg [82032] Limiting open port RST response from 529 to 216 packets/sec [82043] Limiting open port RST response from 341 to 184 packets/sec [82054] Limiting open port RST response from 534 to 205 packets/sec [82056] Limiting open port RST response from 503 to 199 packets/sec [82061] Limiting open port RST response from 467 to 193 packets/sec [82062] Limiting open port RST response from 512 to 206 packets/sec [82063] Limiting open port RST response from 255 to 194 packets/sec [82132] sonewconn: pcb 0xfffff8039dafc540 (0.0.0.0:6878 (proto 6)): Listen queue overflow: 8 already in queue awaiting acceptance (4199 occurrences), euid 0, rgid 0, jail devuan [82132] Limiting open port RST response from 209 to 185 packets/sec [82312] sonewconn: pcb 0xfffff8039dafc540 (0.0.0.0:6878 (proto 6)): Listen queue overflow: 8 already in queue awaiting acceptance (1 occurrences), euid 0, rgid 0, jail devuan [82392] sonewconn: pcb 0xfffff8039dafc540 (0.0.0.0:6878 (proto 6)): Listen queue overflow: 8 already in queue awaiting acceptance (1 occurrences), euid 0, rgid 0, jail devuan [82394] Limiting open port RST response from 381 to 204 packets/sec [82396] Limiting open port RST response from 470 to 189 packets/sec [82397] Limiting open port RST response from 260 to 207 packets/sec [82398] Limiting open port RST response from 269 to 212 packets/sec [82400] Limiting open port RST response from 324 to 197 packets/sec [82401] Limiting open port RST response from 271 to 199 packets/sec Reboot back on 13.1 makes everything ok.
Created attachment 248865 [details] ifname_bsd_to_linux_name.diff Konstantin, please try to apply this patch to your FreeBSD 13.2 or FreeBSD 13.3 and see if it resurrects the application.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=2f5a315b307447f91891c96fb23c7333fa406f2f commit 2f5a315b307447f91891c96fb23c7333fa406f2f Author: Gleb Smirnoff <glebius@FreeBSD.org> AuthorDate: 2024-03-03 20:56:58 +0000 Commit: Gleb Smirnoff <glebius@FreeBSD.org> CommitDate: 2024-03-03 20:56:58 +0000 linux: require vnet(9) context in ifname_bsd_to_linux_name() This function is used by netlink(9) only. The netlink(9) taskqueue thread runs in the vnet of the socket whose request the thread is processing right now. This is a correct vnet and resetting it to vnet0 is incorrect. If the function is to be used by any other caller in addition to netlink(9), it would be caller's responsiblity to provide correct vnet(9). Reviewed by: melifaro, dchagin Differential Revision: https://reviews.freebsd.org/D44191 PR: 277286 sys/compat/linux/linux.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
(In reply to Gleb Smirnoff from comment #1) Awesome!!! Works great. Thanks a lot Gleb.
A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=f45ecf5fe4076fac300cd1e2e93877ff1762c93a commit f45ecf5fe4076fac300cd1e2e93877ff1762c93a Author: Gleb Smirnoff <glebius@FreeBSD.org> AuthorDate: 2024-03-03 20:56:58 +0000 Commit: Gleb Smirnoff <glebius@FreeBSD.org> CommitDate: 2024-03-11 16:11:56 +0000 linux: require vnet(9) context in ifname_bsd_to_linux_name() This function is used by netlink(9) only. The netlink(9) taskqueue thread runs in the vnet of the socket whose request the thread is processing right now. This is a correct vnet and resetting it to vnet0 is incorrect. If the function is to be used by any other caller in addition to netlink(9), it would be caller's responsiblity to provide correct vnet(9). Reviewed by: melifaro, dchagin Differential Revision: https://reviews.freebsd.org/D44191 PR: 277286 (cherry picked from commit 2f5a315b307447f91891c96fb23c7333fa406f2f) sys/compat/linux/linux.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=db4429d00f0d95a1532f8707f8b828a744586dc7 commit db4429d00f0d95a1532f8707f8b828a744586dc7 Author: Gleb Smirnoff <glebius@FreeBSD.org> AuthorDate: 2024-03-03 20:56:58 +0000 Commit: Gleb Smirnoff <glebius@FreeBSD.org> CommitDate: 2024-03-11 16:12:36 +0000 linux: require vnet(9) context in ifname_bsd_to_linux_name() This function is used by netlink(9) only. The netlink(9) taskqueue thread runs in the vnet of the socket whose request the thread is processing right now. This is a correct vnet and resetting it to vnet0 is incorrect. If the function is to be used by any other caller in addition to netlink(9), it would be caller's responsiblity to provide correct vnet(9). Reviewed by: melifaro, dchagin Differential Revision: https://reviews.freebsd.org/D44191 PR: 277286 (cherry picked from commit 2f5a315b307447f91891c96fb23c7333fa406f2f) sys/compat/linux/linux.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)