Upgrade to 2.1.3 = No UPnP
-
Its been documented now in another thread here yesterday, yet still no follow up as to a resolution.
If I edit the miniupnpd.conf manually and set listening_ip=10.1.16.1/20 (like it would be configured in previous versions) then it works correctly. If I change it back to listening_ip=em0_vlan2 then it is broken. Looking at ifconfig, everything for em0_vlan2 is correct. The devices are all on the same vlan and subnet.
Watching traffic over the network, I can see the SSDP request being broadcast by the device but pfSense never responds.
Seeing the same thing on my test network after the upgrade. Every machine/app that attempts to use UPnP reports a closed port with identical configuration to 2.1.2
Autogenerated miniupnp.conf:
ext_ifname=igb0 port=2189 listening_ip=igb1 presentation_url=https://192.168.1.1/ uuid=645fb78e-be5f-3b2e-03af-b7fccbb611d serial=645FB78E model_number=2.1.3-RELEASE enable_upnp=yes enable_natpmp=yesSubbing igb1 to 192.168.1, made it work, but inconsistently, as the apps report the ports being open only intermittently and then closed again. Regardless the file is remade again on next reboot so any changes are eliminated.
This is a major issue and i am quite shocked that it made it past testing/verification and into an actual live release. Lets get this shame out of the way ASAP.
-
I'm having this problem as well. Searched through redmine and couldn't find this in there. It may be a good idea to submit this as a bug.
-
I'm experiencing the same issue here as well. Rolled back to 2.1.2, everything is fine. Will hold off on upgrading for now.
-
You could manually revert the change in miniupnpd.inc:
https://github.com/pfsense/pfsense/commit/3f986e2dc97d1f3a14505d6d9051aae0e36a67c0
I don't think that's actually the 2.1.X branch but it's probably the same.
Presumably if was added for IPv6 compatibility.
Steve
-
We had that set before and I removed it a long time ago because it caused problems, looks like it snuck back in. Well intentioned, but broken.
-
This works just fine on my box, so it's not simply generally broken. Could somebody who sees this issue try running "sockstat | grep miniupnp" on their box?
-
Specifically, the ports of interest:
root miniupnpd 71895 9 tcp6 *:2189 *:* root miniupnpd 71895 11 tcp4 *:2189 *:* root miniupnpd 71895 12 udp4 *:1900 *:* root miniupnpd 71895 14 udp6 *:1900 *:*… which is exactly what one would expect; the only difference when putting in an IP should be that miniupnpd binds specifically to that IP instead of accepting any traffic.
-
Also, is there any commonality between the configurations where binding to interface causes failure that could explain this? Perhaps the problems only happen if the LAN interface has no IPv6 address?
Subbing igb1 to 192.168.1, made it work, but inconsistently, as the apps report the ports being open only intermittently and then closed again.
Doesn't this point to there being some other issue? Once you replace the listening_ip setting, it should behave exactly as before, so I don't see why you'd still see problems at that point.
-
We had that set before and I removed it a long time ago because it caused problems, looks like it snuck back in. Well intentioned, but broken.
Jim, in case your comment is referring to ticket 1835, I'm not sure this is really related. Setting listening_ip to an interface instead of a v4 address is required for IPv6 support, but does not actually enable said support.
-
I wonder if this issue might be related to this fix (or rather, the lack thereof) that just went into miniupnpd earlier today. That, too, would suggest that the reason I'm not seeing it is that I have IPv6 addresses on my LAN interfaces. Would those of who are affected by the problem mind responding whether they use IPv6 or not?
-
I just posted pull requests for RELENG_2_1 and master that revert to the old behavior by default and add a checkbox to select the new behavior if desired.
-
If you're on 2.1.3, you can use the "System Patches" package to either either revert the original commit, or to apply my fix until a new build is released.
-
Nicely done. :)
Steve
-
Noooo, I was trying to get the prize for most back-to-back posts from the same author, and now you ruined everything! ;)
-
I wonder if this issue might be related to this fix (or rather, the lack thereof) that just went into miniupnpd earlier today. That, too, would suggest that the reason I'm not seeing it is that I have IPv6 addresses on my LAN interfaces. Would those of who are affected by the problem mind responding whether they use IPv6 or not?
I am not having the problem and do not use ipv6.
-
-
No UPnP
Thats a bad thing??? ;D
-
Well, if you're a gamer yes. I have issues with my Onkyo receiver and it's apps. They all use uPnP.
-
Well I am a gamer (in my free time) and never had to use uPnP for anything. So perhaps you can tell me what a receiver needs uPnP for?
Not that I am against fixing the package but I don't see the massive urgency promoted by a few posters, that this is as serious as breaking DNS or even the core packet filter.Greets
-
My Oknyo needs Upnp to communicate with the mobile apps and according to my wife this breakage is WWIII. I also read in this topic that a xbox needs upnp for whatever reason.
