As it stands, neither PS3, PS4, Xbox 360, Xbox One, or Windows 10 supports 2.0, only 1.1. Microsoft hearsay is that they won't fix this either.
The github code maintainers have reverted this a long time ago (2015), but OpenWRT/LEDE still uses 2.0, which isn't really usable for many or most practical purposes.
How do we go about getting the package changed? Is there a contact point or a maintainer?
You can submit a pull request in https://github.com/openwrt-routing/packages/pulls as the miniupnpd package is located in the openwrt-routing repo.
The change to IGD2.0 was a recent one:
and the option was enabled for compile-time config by
It should be enough to change this "y" to "n":
https://github.com/openwrt-routing/packages/blob/master/miniupnpd/Makefile#L35
Confirming this method works for PS3 and PS4 too (changing the default 'y' to 'n' in the Makefile didn't work when I tried it).
Thanks for all the help from the contributors to this thread - marbi's guide is priceless for a noob like me as I'd never attempted to cross compile before. If anyone wants them, I've the packages for a Linksys WRT1900ACS here:
miniupnpd_2.0.20170421-1_arm_cortex-a9_vfpv3.ipk (igdv1)
luci-app-upnp_git-17.180.40092-2dc60d2-1_all.ipk
I've included the LuCI app as I lost this when I removed the upnp server and I couldn't spot the app in the repo. Guess I should've used opkg --force-install instead of removing and re-adding the server?
For what it's worth, I've contacted Playstation support to ask for their implementation of UPnP to be updated to support v2 but definitely not holding my breath on this one.
Default setting in Makefile only affects when .config is built from scratch (and the value is assgned based on the default.). If you already have a .config where it is "y" based on the previous default, the value does not change automagically and you need to toggle the menu item.
You are including the upnp app from the master branch correct? I noticed for some reason that upnp luci app from the 17.01 branch doesn't work with the miniupnpd from the master branch.
Awesome, thanks for the explanation hnyman and yes, the versions I've compiled are both from the master branch.
Hold on here, this is your own personal point of view. 1.1 is deprecated and clinging onto old standards is a very bad idea. If you want a "fix" bug vendors. My PS4 works fine, so does all my other hardware (just to show that your argument doesn't apply to everyone).
Completely agree. I tried...
"I can see from your e-mail that you have some suggestions in mind for changes to the functionality of our PlayStation products. We value each piece of feedback that we receive from our users, and I have passed your comments on to the team that deals with this area for their review. Unfortunately due to the number of ideas and requests we receive, we’re unable to respond to users on an individual basis, however I can assure you that the team who deals with this functionality will be made aware of the valuable input that you've provided."
In the meantime, I'm grateful for this thread as I now have a working UPnP implementation as this has only happened since I've reverted to 1.1 (no other config changes made). I did spend a couple of days banging my head against a wall trying everything else I could think of before landing here.
Can I check if there's a config change you've made to get v2 working with your PS4? I'd prefer to avoid recompiling if there's a better option.
But working fine does not mean upnp is working, the PS4 will work for most things without any upnp at all. But not for everything.
As I asked you before, could you post your upnp leases file while your PS4 has remote play enabled? If you somehow made upnp2 work with PS4 you have to share how, so we can bury the whole protocol argument.
"Just Microsoft / Xbox one" is still going to be a large chunk of our user base ... ignoring that is not much better, either.
To provide a working package for most users, IGD2 should be disabled by default (that's also the default of miniupnp itself, because of interoperability issues).
I made a pull request to disable IGDv2 by default which just got merged.
It would be a much better solution to provide both versions rather than only providing a deprecated version.... So much for democracy here...
Im New to LEDE, how do i install this package? Thanks in advance (miniupnp for r7800)
So far the demand for a deprecated version seems higher than the demand for a new-but-broken one.
I just saw that pull request, thanks for that as I am not a dev. The older one is what the stable branch has in it's repository, however the newer one is in the development branch. Also for some reason the luci-miniupnp app for the stable branch won't work for the newer miniupnp daemon.
Both the core miniupnpd and LuCI app changes have been backported to the 17.01 branch. The buildbot for 17.01 should build them soon for all targets. (actually, seems that it has already completed the build)
Thanks for looking into that! Side question: will this version with IGDv2 disabled be in the firmware you build for the R7800 or will I need to continue to build it myself?
[quote="mrmidnight, post:64, topic:2016"]
Side question: will this version with IGDv2 disabled be in the firmware you build for the R7800 or will I need to continue to build it myself?
[/quote]The current package (with IGDv2 disabled) is already included in my recent R7800 builds. master as of three days ago and 17.01 as of yesterday evening.
Sweet, I'll test it out in a bit! (I'll wait until my kids are using the wifi and then update with your latest build!)
A couple small updates. First, yesterday's (8/7/2017) Alpha system software build for the Xbox One relaxed some of the port mapping rules that the Xbox One uses, however this does not effect anything for the Xbox 360 or 360 BC in Xbox One IGDv2 issues, nor does it effect any IGDv2 issues for the PS4. Also, when talking with a member of the dev team, they did not have these issues with the WRT3200ACM on the latest stock firmware with any console; I then mentioned that Linksys may have disabled IGDv2 in their builds, which he then "confirmed" by looking at some data on their end. Seems like Linksys may be looking at this forum and performing some research on their end.
So there you have it, some progress for those who don't know how or have the desire to build a custom firmware or only want to stay stock!