Hi
I know it's not recommended to use UPnP because of the security flaws it has. However, I do find it useful to find out what port type and number an video game or application is trying to communicate through to achieve open NAT type etc. I can usually simply look at the LuCI app's Active UPnP Redirects list, but this is remaining empty. Usually a Sony PS4 internet connection test brings up a UPnP redirect but the list still remains empty.
Any ideas?
I can confirm that UPnP doesn't work. I tried the official stock openwrt firmware version 19.07.0-rc2 and UPnP didn't show. I have also tried compiling from master and that the same thing. As soon as I flashed 18.06.5 LuCI-App-UPnP worked straight away.
It is not a LuCI issue and for me it is working as expected. I only tried it with the miniupnpc cli client and Transmission-GTK though, both were able to automatically discover the router and setup port forwards in it.
Didn't test with a PS4 and an Xbox yet though, can only do that tonight.
Sorry for the delay in replying. I've been busy most weekends and trying to find time to compile and flash my router plus dealing with downtime for other users of the internet as been crazy.
Anyway, for simplicity after issuing the command make menuconfig, after selecting the correct target device etc, all I have selected is the LuCI-app-UPnP and the basic non-SSL LuCI collection so that I have a GUI. I have flashed it and tested again with qBitorrent and my PS3, the PS3 being able to detect if UPnP is avaliable or not, and it still doesn't work. Five minutes prior to flashing the firmware, I checked the stock Linksys firmware and the PS3 said the UPnP was avaliable.
Is it possible that I'm missing a dependency?
However, I always thought that if I didn't select the dependencies manually through make menuconfig would selecting the LuCI-app-UPnP automatically select the dependencies anyway?
I've had this issue for while but I just tried setting the external_ip setting to my WAN public IP (after seeing it suggested somewhere on this forum) and it's starting working! This isn't a real solution for me though as I have a dynamic IP. Not sure why it's required too as it's supposed to get the IP from the WAN interface.
I fixed it. I have two IP addresses on my WAN interface - the public IP and a private address so I can reach my modem's web interface. The private one was listed first so I expect miniupnpd was taking that and obviously didn't like it. Would have been nice for it to say so in the logs!
Okay adding the
option external_ip 'wan_ip_here'to the /etc/config/upnpd files does fix this issue, but only temporarily.
I came across this post UPnP bug in OpenWrt and the user mentioned modifying the /etc/init.d/miniupnpd file to pickup the WAN IP.
My question is, why is this option missing from the default upnpd config and why hasn't a variable been set so that the WAN IP address can be picked up?
My WAN IP address randomly changes so having to set the option external_ip option isn't feasible. I would like to implement a permanent solution and if it works well I would to suggest getting it ported onto GitHub so that others can make use of it.
Mine is still working, and now I have removed the private IP from the WAN interface I no longer need to specifiy the external_ip option - miniupnpd automatically retrieves my WAN IP from the WAN interface - you don't need to modify the init.d file for it to do this. Do you have a public IP on your WAN interface? If not (e.g. double NAT) then you do need to provide the external_ip manually. If you have a dynamic IP then you may want to run a cron job to detect this, update the config and restart the service. Or you could possibly hook into a DDNS task if you use that. It's a bit hacky though.
True but any idea with cron job monitoring the change in dynamic IP & then modifying the file with that IP?
Okay update for everyone. I've just flashed the stable, v19.07.2 build, installed LuCI-app-UPnP and it worked straight away.
I have recently compiled my own v19.07.2 firmware with an even newer version of miniupnpd that is newer than the one included in the master trunk. It successfully compiled which is a good start. Just got to test it out now. However, knowing the next build of v19.07 works with UPnP I probably won't bother compiling the newest package into my next compile for my other router.
Update
My PS4 games seem to be struggling to open ports up. I think I may try the new update and see if it makes any difference. Failing this I can always revert back to the older one from v18.
On a side question, does anyone know how to diagnose the sensitivity of UPnP and why it works and then doesn't work?
I have opened a bug report here >> https://bugs.openwrt.org/index.php?do=details&task_id=3051&order=dateopened&sort=desc
The latest version of minupnpd seems to be fully functional again on the v19.07.2. I compiled a large firmware for my Linksys WRT1900ACSv2 last night including miniupnpd and everything opens up fine.
The miniupnpd version is 2.1.20191006-4
The only problem now is I'm getting major issues when two games consoles trying to initially connect to the same 3074 port. I have made a post here UPnP Clash WIth Duplicate Initial Port
Hello
I don't know will help, but my Ps4 works better with igdv1, as in this topic: [Solved] Miniupnpd not opening ports for ps4
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.