natpmpc open a random port

[stokito]

I have a webserver on a port 8000 and need to expose it with natpmpc on WAN on any random port. So then I'll simply generate a link to it and share.
But currently I have to specify explicitly the external port:

natpmpc -a 8000 8000 tcp

The problem here is that I don't know if this external 8000 port is not already taken or allowed by the miniupnpd. So that's why I can't rely on this.
Basically the local port 9000 may be also busy and it would be also useful if the natpmpc can also take some random and free port (maybe ephemeral).

Maybe it can be something like:

natpmpc -a rand rand tcp

Is it possible to implement something like this? Or the PCP spec requires to specify the requested port?

Ideally the natpmpc should print the port numbers to stdout in form

loc_port ext_ip ext_port

Then it would be easy to parse with a script.
Any other logging messages of the natpmpc may be printed to stderr so that a script needs to parse only clear stdout.

[miniupnp]

Hello. Just for your information NAT-PMP has been superseded by PCP.

If my memory serves me right, to get a random port, you request 0 :
$ natpmpc -a 0 8000 tcp

The effective ports are printed to the console :
Mapped public port %hu protocol %s to local port %hu lifetime %u\n

[stokito]

Mapped public port 8000 protocol TCP to local port 8000 liftime 3600 epoch = 6925

…

On Sat, 28 Jan 2023 at 16:28, Thomas BERNARD ***@***.***> wrote: Hello. Just for your information NAT-PMP has been superseded by PCP. If my memory serves me right, to get a random port, you request 0 : $ natpmpc -a 0 8000 tcp The effective ports are printed to the console : Mapped public port %hu protocol %s to local port %hu lifetime %u\n — Reply to this email directly, view it on GitHub <#29 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADFODU6LAQ6PL45N3TY2Z3WUUUJHANCNFSM6AAAAAASGCHB6A> . You are receiving this because you authored the thread.Message ID: ***@***.***>

-- Sergey Ponomarev <https://linkedin.com/in/stokito>, stokito.com

[miniupnp]

note that miniupnpd uses the internal port if available when asking for a "random" port :
https://github.com/miniupnp/miniupnp/blob/master/miniupnpd/natpmp.c#L336

[stokito]

I have 443 port busy and the 444 port wasn't opened and output is confusing: $ natpmpc -a 0 443 tcp initnatpmp() returned 0 (SUCCESS) using gateway : 192.168.1.1 sendpublicaddressrequest returned 2 (SUCCESS) readnatpmpresponseorretry returned 0 (OK) Public IP address : 46.118.85.155 epoch = 11073 sendnewportmappingrequest returned 12 (SUCCESS) readnatpmpresponseorretry returned -51 (FAILED) readnatpmpresponseorretry() failed : not authorized I also have SSH on non root 2222 port and it worked: $ natpmpc -a 0 2222 tcp initnatpmp() returned 0 (SUCCESS) using gateway : 192.168.1.1 sendpublicaddressrequest returned 2 (SUCCESS) readnatpmpresponseorretry returned 0 (OK) Public IP address : 46.118.85.155 epoch = 11334 sendnewportmappingrequest returned 12 (SUCCESS) readnatpmpresponseorretry returned 0 (OK) Mapped public port 2223 protocol TCP to local port 2222 liftime 3600 epoch = 11334 closenatpmp() returned 0 (SUCCESS) Anyway, thank you for your help. When I'll have time I'll dig into sources and will try to understand better. Interesting how it works on Apple routers with original PCP

…

On Sat, 28 Jan 2023 at 17:47, Thomas BERNARD ***@***.***> wrote: note that miniupnpd uses the internal port if available when asking for a "random" port : https://github.com/miniupnp/miniupnp/blob/master/miniupnpd/natpmp.c#L336 — Reply to this email directly, view it on GitHub <#29 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADFODTZTWEHPJ5MMLZU4L3WUU5QZANCNFSM6AAAAAASGCHB6A> . You are receiving this because you authored the thread.Message ID: ***@***.***>

-- Sergey Ponomarev <https://linkedin.com/in/stokito>, stokito.com

[miniupnp]

I'm curious to see the log on the miniupnpd side.

[stokito]

Logs are filled with this message: miniupnpd[10001]: UPnP permission rule 1 matched : port mapping rejected There are 655350 of such lines e.g. for all ports. I'm wondering why not 65535 so maybe for 5 ports there was another message but it's too many logs. The clients logs are: $ natpmpc -a 0 443 tcp initnatpmp() returned 0 (SUCCESS) using gateway : 192.168.1.1 sendpublicaddressrequest returned 2 (SUCCESS) readnatpmpresponseorretry returned 0 (OK) Public IP address : 46.118.85.155 epoch = 5744 sendnewportmappingrequest returned 12 (SUCCESS) readnatpmpresponseorretry returned -100 (TRY AGAIN) readnatpmpresponseorretry returned -100 (TRY AGAIN) readnatpmpresponseorretry returned -100 (TRY AGAIN) readnatpmpresponseorretry returned -100 (TRY AGAIN) readnatpmpresponseorretry returned -51 (FAILED) readnatpmpresponseorretry() failed : not authorized Interestingly, the client returned an error but the demon continued iteration of ports. I'm testing on Turris Omnia router with miniupnpd 2.2.1-3

…

On Mon, 30 Jan 2023 at 10:19, Thomas BERNARD ***@***.***> wrote: I'm curious to see the log on the miniupnpd side. — Reply to this email directly, view it on GitHub <#29 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADFODRWKX667X3QVSFAUKLWU52PXANCNFSM6AAAAAASGCHB6A> . You are receiving this because you authored the thread.Message ID: ***@***.***>

-- Sergey Ponomarev <https://linkedin.com/in/stokito>, stokito.com

[stokito]

Also for me it looks like not a good idea to take the next free port if it was specified but busy. E.g. if the client requested an 8080 port (not just 0) but it was busy then the 8081 port will be opened. But maybe not all needs for this 8081 port but want exactly the 8080

…

On Mon, 30 Jan 2023 at 11:50, Sergey Ponomarev ***@***.***> wrote: Logs are filled with this message: miniupnpd[10001]: UPnP permission rule 1 matched : port mapping rejected There are 655350 of such lines e.g. for all ports. I'm wondering why not 65535 so maybe for 5 ports there was another message but it's too many logs. The clients logs are: $ natpmpc -a 0 443 tcp initnatpmp() returned 0 (SUCCESS) using gateway : 192.168.1.1 sendpublicaddressrequest returned 2 (SUCCESS) readnatpmpresponseorretry returned 0 (OK) Public IP address : 46.118.85.155 epoch = 5744 sendnewportmappingrequest returned 12 (SUCCESS) readnatpmpresponseorretry returned -100 (TRY AGAIN) readnatpmpresponseorretry returned -100 (TRY AGAIN) readnatpmpresponseorretry returned -100 (TRY AGAIN) readnatpmpresponseorretry returned -100 (TRY AGAIN) readnatpmpresponseorretry returned -51 (FAILED) readnatpmpresponseorretry() failed : not authorized Interestingly, the client returned an error but the demon continued iteration of ports. I'm testing on Turris Omnia router with miniupnpd 2.2.1-3 On Mon, 30 Jan 2023 at 10:19, Thomas BERNARD ***@***.***> wrote: > I'm curious to see the log on the miniupnpd side. > > — > Reply to this email directly, view it on GitHub > <#29 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AADFODRWKX667X3QVSFAUKLWU52PXANCNFSM6AAAAAASGCHB6A> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> > -- Sergey Ponomarev <https://linkedin.com/in/stokito>, stokito.com

-- Sergey Ponomarev <https://linkedin.com/in/stokito>, stokito.com

[miniupnp]

Also for me it looks like not a good idea to take the next free port if it was specified but busy. E.g. if the client requested an 8080 port (not just 0) but it was busy then the 8081 port will be opened. But maybe not all needs for this 8081 port but want exactly the 8080

I don't know if it is a good idea, but I think this is the NAT-PMP specification !

[miniupnp]

anyway, I think I need to improve the way miniupnpd chooses an available port.

[stokito]

If this is in spec that's great that we don't have an undefined behavior here.
But still it makes a little sense from user perspective because it's not clear then why to specify the port at all. Amway, changing the behavior here may broke something.

[miniupnp]

As said before NAT-PMP has been superseded by PCP.