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.

    @swinn:

    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=yes
    

    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. 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.


  • Netgate Administrator

    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


  • Rebel Alliance Developer Netgate

    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?

    @foonus:

    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.



  • @jimp:

    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.


  • Netgate Administrator

    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!  ;)



  • @razzfazz:

    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.


  • Netgate Administrator

    @razzfazz:

    you ruined everything!  ;)

    Ha! Sorry.  ;D

    Steve



  • 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.


  • Moderator

    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.



  • If it's a matter of life and death, install the "system patches" package, then go to system->patches, click add ("+"), pick a description and put the following into the URL/Commit ID field:

    
    https://github.com/pfsense/pfsense/commit/d973a602abeab78803fce467198c571ba25ec0cb
    
    

    Also check the "auto-apply" box. Then click save, click "test", and click "apply", go to services->upnp, make sure "Listen on interface instead of interface's IPv4 address" is not checked, click "change", and everything should work as before again.



  • Thanks!!


  • Netgate Administrator

    You should be aware that the upnp implementation in pfSense, using miniupnpnd, only opens ports through the firewall. It does not do DLNA service discovery or anything like that. In other words only Internet Gateway Device not anything else listed here: http://en.wikipedia.org/wiki/Universal_Plug_and_Play
    You should check what your receiver is doing that requires upnp on pfSense. About the only thing it could be doing is opening itself up general access from the internet.

    Steve


  • Moderator

    @stephen: That's what I was wondering about. I can understand an XBox needing specific ports for game matchmaking (even that is old-school) but an audio receiver? Those things are the last ones (with smart TVs etc.) I want to have access to the internet. Just my 2c.



  • I imagine it's so the companion app that was mentioned can access the receiver even if the phone is not on the local network. (Now, why you'd want to control a receiver from outside the home, I really don't know.)


  • Netgate Administrator

    I guess if it's some 'cloud' style control service. Seems like either lazy programming or a great excuse to monitor exactly what all your users are listening to.  ::)
    A common complaint with these types of apps is that they are streaming locally but use DLNA to 'find' the receiver/TV etc, there is no way of entering the IP address manually and it won't look outside it's own subnet. It's possible to proxy the DLNA discovery and announcement packets or to act as the 'directory' (for want of the technical term) across subnets and but pfSense cannot do that. miniupnpd is not designed to do that. Unfortunately all of these functions and more get lumped together under the term UPNP and people assume it can.

    Steve

    Like this:
    http://forum.eu.onkyo.com/viewtopic.php?f=53&t=67



  • She doesn't use it outside our lan, but that stupid My AV and Onkyo Remote app only works if uPNP is enabled. I've tried without it and it simply doens't work. She uses it to run shoutcast, TuneIn and Spotify on the receiver. This is the newest model that has all those apps on the receiver itself. With the remote app you can very easily control those apps.


  • Netgate Administrator

    Sounds like a pretty cool device. Watch out for someone finding an exploit in it though.  ;) It's exactly the type of 'internet of things' style device where functionality is way ahead of security.
    Take a look at the pfSense upnp status page, what is it doing? Is it the app or the receiver that's opening holes?
    Consider locking down your upnp config so that only that device can do anything.

    Steve



  • Thanks for the tip! The receiver itself is freaking awesome. Picture quality and sound are superb and the DLNA function is also handy :)