uPnP lease time issue

All IP networking related issues
Post Reply
VK3ERW
Posts: 1
Joined: Fri Jun 05, 2020 12:31 pm

uPnP lease time issue

Post by VK3ERW » Mon Jun 22, 2020 12:31 pm

upnp is a fantastic feature and makes for very easy network setup, however, I have just discovered a small problem.

The upnp implementation of pi-star appears to set up port mapping with an infinite lease time (default when no lease time is specified) which becomes an issue when the pi-star IP address changes (in my case going from wired to WiFi). The router (which generally has a long uptime) retains the upnp settings with the old pi-star IP and when pi-star has a different IP address the new upnp mapping is refused by the router.

My pi-star ran for a few weeks and the router still retained the old upnp entry, hence incorrectly forwarding ports.

I fixed the problem by deleting the upnp entries in the router and within seconds pi-star automatically added the correct entries.

From the experience I would like to suggest a couple of improvements:

1) /usr/local/sbin/pistar-upnp.service, stop) section:
according to man upnpc, the correct format to delete a upnp mapping does not include the destination IP address and specifies only the external port:

Code: Select all

upnpc [options] -d external_port protocol <remote host>
delete $ipVar from every line
delete one of the port numbers

2) /usr/local/sbin/pistar-upnp.service, start) section:
according to man upnpc the add entry has a duration option:

Code: Select all

upnpc [options] -a ip port external_port protocol [duration]
maybe every add line could include a duration of 600.
pistar-upnp.timer triggers every 20s, so it would automatically renew leases on a continual basis
Note: Some routers (e.g. Mikrotik) will only support infinite lease time.

3) /usr/local/sbin/pistar-upnp.service, start) section:
The upnpc command accepts an option description parameter for each mapping via -e
It would be helpful to anyone looking at the port mapping in their router to be able to identify the purpose of each individual mapping.
Maybe an add line could look something like this:

Code: Select all

$DAEMON -e pistar -a $ipVar 10022 10022 UDP 600 > /dev/null 2>&1 &

If 1) is properly implemented and working then 2) may not be necessary since the UPnP rules will be removed from the router on shutdown so the new rules can take place on the next startup.

My router is a Technicolor DJN2130, a very common consumer router (in VK) supplied by Telstra, our largest telecommunications provider.
Pi-Star 4.1.2

Side note:
Many routers do not allow upnp mapping of some common ports. In my case the pi-star upnp mapping of port 80 for external dashboard access is not accepted by the router. That particular port needs a manual entry in the port forwarding section of the router configuration.

Here is a link which contains an updated version of /usr/local/sbin/pistar-upnp.service
http://www.vk3erw.com/index.php/18-amat ... forwarding

Post Reply