NAT-PMP does not open UDP Port.

[beatmag]

NAT-PMP does not open UDP Port.

Test: Turn off UPNP on router. Turn On NAT-PMP on router.

See Router Log. UDP Port is not opened!

Evidence: The latest trunk as of r13682 does not use the key NATPMP_PROTOCOL_UDP at all. The NATPMP_PROTOCOL_TCP key is used in various places.

The reason why no one has picked this up is because most people use UPNP, for those with Apple routers UDP port will not open as Apple routers dont support UPNP.

This means Apple Airport users and people who only have NAT-PMP enabled are not getting DHT.

This should be a relatively easy fix.

Search "NATPMP_PROTOCOL_UDP" (4 hits in 3 files)

C:\Users\user\Desktop\trunk\trunk\third-party\libnatpmp\Changelog.txt (1 hit)

Line 76: Fixed values for NATPMP_PROTOCOL_TCP and NATPMP_PROTOCOL_UDP

C:\Users\user\Desktop\trunk\trunk\third-party\libnatpmp\natpmp.c (1 hit)

Line 173: if(!p

(protocol!=NATPMP_PROTOCOL_TCP && protocol!=NATPMP_PROTOCOL_UDP))

C:\Users\user\Desktop\trunk\trunk\third-party\libnatpmp\natpmp.h (2 hits)

Line 87: #define NATPMP_PROTOCOL_UDP (1) Line 165: * protocol is either NATPMP_PROTOCOL_TCP or NATPMP_PROTOCOL_UDP,

Search "NATPMP_PROTOCOL_TCP" (6 hits in 4 files)

C:\Users\user\Desktop\trans\trans\libtransmission\natpmp.c (2 hits)

Line 158: const int val = sendnewportmappingrequest( &nat->natpmp, NATPMP_PROTOCOL_TCP, Line 203: const int val = sendnewportmappingrequest( &nat->natpmp, NATPMP_PROTOCOL_TCP, private_port, private_port, LIFETIME_SECS );

C:\Users\user\Desktop\trans\trans\third-party\libnatpmp\Changelog.txt (1 hit)

Line 76: Fixed values for NATPMP_PROTOCOL_TCP and NATPMP_PROTOCOL_UDP

C:\Users\user\Desktop\trans\trans\third-party\libnatpmp\natpmp.c (1 hit)

Line 173: if(!p

(protocol!=NATPMP_PROTOCOL_TCP && protocol!=NATPMP_PROTOCOL_UDP))

C:\Users\user\Desktop\trans\trans\third-party\libnatpmp\natpmp.h (2 hits)

Line 88: #define NATPMP_PROTOCOL_TCP (2) Line 165: * protocol is either NATPMP_PROTOCOL_TCP or NATPMP_PROTOCOL_UDP,

[beatmag]

Initial Fix with Hack to unmap both UDP and TCP ports properly

[beatmag]

I have attempted to make a fix to this bug. However the termination sequence was not so forgiving. The mapping and unmapping of NAT PMP TCP or UDP port required a few cycles. However the termination sequence only allowed for one cycle hence, only TCP or UDP was successfully unmapped.

I have hacked the code to perform both TCP and UDP unmappings in the same cycle. Even though this worked. The current termination sequence would never check for the successfully unmapping of NAT PMP ports.

Mapping Fix - I have inserted another cycle into the NAT PMP code to map another UDP port, the same port number as the TCP requested.

Unmapping Fix - To unmap, I have placed both unmap calls into the same cycle. This is not a very elegant fix however. The proper fix requires more work on the termination sequence.

In the short term, I think the fix can be applied, it does the job, but its not very elegant, and the port unmapping has no guarantee of working (which is also the case for 2.75)

Is there any logs that can verify that the open UDP port is now utilized?

[hobarrera]

What's the status on this bug? As far as I can see, a port is opened using natpmp, but transmission isn't using it.

My routers is a box running openbsd+pf+natpmpd. Transmission is set up to use port 51413, and the router reports it's being forwarded:

# pfctl -a natpmpd -s rules 
pass in quick on rdomain 0 inet proto tcp from any to 190.210.108.249 port = 53686 flags any rdr-to 172.16.8.7 port 51413

But transmission is reporting it as closed.

By the amount of peers I'm getting, I assumed transmission is not listening on that port, so I verified that:

$ lsof -i :53686
$

But it is listening on a wrong port:

$ lsof -i :51413
COMMAND     PID USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
transmiss 10316 hugo   15u  IPv4  988368      0t0  TCP *:51413 (LISTEN)
transmiss 10316 hugo   16u  IPv6  988370      0t0  TCP *:51413 (LISTEN)
transmiss 10316 hugo   17u  IPv4  988371      0t0  UDP *:51413

Transmission isn't detecting that it's actually the external port 53686 that's being opened. natpmp allows for the router to open a differently numbered port (especially since it may already have been forwarded to another client).

Transmission needs to use port 53686, knowing that the local router's external port 51413 is being forwarded to 53686 (in this particular case, of course, the numbers will obviously vary).

-- Edit: Forgot to clarify; I tested this in on transmission-gtk(3) 2.80 and transmission-gtk(2) 2.60.