On Fri, Aug 02, 2024 at 01:25:24PM GMT, Lucas Gabriel Vuotto wrote:
> On Mon, Jul 08, 2024 at 10:48:37AM GMT, Josh Grosse wrote:
> > Ping. This is a bugfix release. Tested on amd64. -daemon still
> > has a non-zero rtable issue reported with 4.0.5.
>
> So, given I was a victim of the rtable issue, I took another attempt at
> it.
>
> Josh, do you see the issue if you run transmission-daemon with
> "port-forwarding-enabled" set to false? Can be achieve running it -M,
> which will also write it to the config. In my setup, it gets stuck when
> port forwarding is enabled and it runs in an rtable other than 0. I've
> been running with it disable for 2 days without issues is rtable 2.
>
> btw, decided to attempt that after rereading your debug attempts in
> Reddit. I believe that you keep looking at the loop in curlThreadFunc
> because that's the way that thread works, while taking a look at another
> thread showed it was attempting a read that came from natpmp.
>
> iirc, I started experiencing it around mid-May, while the reddit post is
> from mid-April. transmission-daemon runs in a machine that runs -current
> and is updated on a weekly basis.
>
> Lucas
The following patch to net/miniupnp/libnatpmp makes transmission-daemon
work in a non-zero rtable with port-forwarding-enabled set to true.
I quickly tried natpmpc and indeed this looks like needed:
without patch:
$ natpmpc
initnatpmp() returned 0 (SUCCESS)
using gateway : 172.31.0.147
sendpublicaddressrequest returned 2 (SUCCESS)
readnatpmpresponseorretry returned -7 (FAILED)
errno=61 'Connection refused'
$ timeout 10 route -T1 exec natpmpc
$ timeout 10 route -T2 exec natpmpc
with patch:
$ natpmpc
initnatpmp() returned 0 (SUCCESS)
using gateway : 172.31.0.227
sendpublicaddressrequest returned 2 (SUCCESS)
readnatpmpresponseorretry returned -7 (FAILED)
errno=61 'Connection refused'
$ route -T1 exec natpmpc
initnatpmp() returned 0 (SUCCESS)
using gateway : 192.168.100.1
sendpublicaddressrequest returned 2 (SUCCESS)
readnatpmpresponseorretry returned -7 (FAILED)
errno=61 'Connection refused'
$ route -T2 exec natpmpc
initnatpmp() returned 0 (SUCCESS)
using gateway : 172.31.1.1
sendpublicaddressrequest returned 2 (SUCCESS)
readnatpmpresponseorretry returned -7 (FAILED)
errno=61 'Connection refused'
The only thing that doesn't make sense is why is this started being
noticeable somewhere around April / May. I'm pretty sure I started
experiencing roughly a month after I saw Josh comment about it.
net/rtsock.c, net/route.[ch] and net/rtable.[ch] changes seem inocuous
around those dates. netinet/if_mroute.c shows some change but I think
that code path isn't reachable thru libnatpmp.
diff 0d344cb42a7eca64820d544cfcf71f41eb47b835
1434c3b0051be5d20df5fc2c707b8160665148ca
commit - 0d344cb42a7eca64820d544cfcf71f41eb47b835
commit + 1434c3b0051be5d20df5fc2c707b8160665148ca
blob - 43b62e7c1a177a807fa1566b1e12a546b2df3456
blob + 074bf4f845cb794f6c2e239d9c785ba10541f881
--- net/miniupnp/libnatpmp/Makefile
+++ net/miniupnp/libnatpmp/Makefile
@@ -2,6 +2,7 @@ COMMENT = NAT Port Mapping Protocol client library
DIST_TUPLE = github miniupnp libnatpmp
f2433bec24ca3d3f22a8a7840728a3ac177f94ba .
PKGNAME = libnatpmp-20240116
+REVISION = 0
SHARED_LIBS = natpmp 0.1
blob - /dev/null
blob + 44666d262d9e571b1009c4ed8ae8ebb4a72d761d (mode 644)
--- /dev/null
+++ net/miniupnp/libnatpmp/patches/patch-getgateway_c
@@ -0,0 +1,16 @@
+Handle non-zero rtables.
+
+Index: getgateway.c
+--- getgateway.c.orig
++++ getgateway.c
+@@ -269,6 +269,10 @@ int getdefaultgateway(in_addr_t *addr)
+ rtm.rtm_seq = ++seq;
+ rtm.rtm_addrs = rtm_addrs;
+
++#ifdef __OpenBSD__
++ rtm.rtm_tableid = getrtable();
++#endif
++
+ so_dst.sa_family = AF_INET;
+ so_dst.sa_len = sizeof(struct sockaddr);
+ so_mask.sa_family = AF_INET;
