UPNP broken on 21.05?
-
On what platform?
It works just fine for me on 21.05-RELEASE on multiple amd64 devices, but I haven't checked on some of the others.
-
Sorry - forgot to mention I'm using a SG-3100
-
I do see that error on an SG-3100 in my lab, but it's not a great test there since it has a private WAN so may be failing for other reasons.
What are the exact settings used in your UPnP configuration? Either a screenshot or the contents of
/var/etc/miniupnpd.confwould be helpful.Do you have an address set for the Override WAN address?
-
Very basic config. WAN is public with dynamic IP via PPPoE so I don't have an "Override WAN address".
/var/etc/miniupnpd.conf
ext_ifname=pppoe0 port=2189 listening_ip=mvneta1.32 secure_mode=yes presentation_url=https://192.168.32.1/ uuid=d41d8cd9-f00b-204e-9800-998ecf8427f serial=D41D8AD9 model_number=21.05-RELEASE allow 1024-65535 192.168.32.15/32 1024-65535 deny 0-65535 0.0.0.0/0 0-65535 enable_upnp=yes enable_natpmp=yes -
OK, I tried it on a few different systems and the only ones which fail are 32-bit ARM (SG-3100 and SG-1000). I opened a Redmine issue for it:
-
@jimp Thank you!
I'm a bit disappointed that something like this happens on a release version and on quite popular official Netgate hardware without being noticed by pre-release testing.
I hope that the fix will not have to wait until 21.09. Unfortunately, it seems like Netgate tries hard to steer people away these days. -
Prior to upgrading I never had any issues, but ever since this upgrade my logs are filled with the following:
Jun 15 16:31:36 miniupnpd 98249 Listening for NAT-PMP/PCP traffic on port 5351
Jun 15 16:32:30 miniupnpd 98249 could not find redirect rule to delete eport=3074
Jun 15 16:33:41 miniupnpd 98249 ioctl(dev, DIOCGETADDRS, ...): Device busy
Jun 15 16:33:41 miniupnpd 98249 ioctl(dev, DIOCGETADDRS, ...): Device busy
Jun 15 16:33:47 miniupnpd 98249 ioctl(dev, DIOCGETADDRS, ...): Device busy
Jun 15 16:33:47 miniupnpd 98249 ioctl(dev, DIOCGETADDRS, ...): Device busy
Jun 15 16:33:48 miniupnpd 98249 ioctl(dev, DIOCGETADDRS, ...): Device busyThe error about port 3074 is of my xboxes. If I want an open NAT, I have to flip the port every time I turn my xbox on. Otherwise it stays moderate. This was working fine before the upgrade.
I also see this constantly:
Jun 15 16:31:36 miniupnpd 98249 setsockopt(udp, IPV6_RECVPKTINFO): Invalid argument
-
on a 3100?
https://redmine.pfsense.org/issues/11995 -
@steveits Yep, that would be my problem. Is there an ETA for when this will get fixed? I have to imagine this is a huge problem for a lot of people. I work in Networking so I can build port-forwards, but I have to imagine there are a lot of people that don't know how, or don't want to.
-
Yup, I'm seeing the same thing. Disappointing after spending 400 bucks on the appliance only to no longer be able use this basic feature...... :(
-
I merged together two threads about this since it's the same issue for both.
We are aware and have been actively working on solving this and other SG-3100 issues.
For those who are affected, was this working on 21.02.2?
-
@jimp Yes. I had UPnP sessions on 21.02.2.
When I upgraded to 21.05 it stopped working.
-
@bcodd Just make manual port forwards. It's pretty simple using the GUI. I manually port forwarded my Xbox and its been working fine.
You'd be pretty surprised how much stuff doesn't need UPnP. I disabled the service and now all my iphones currectly use wifi calling too.
-
I think this is causing my SG1000 router to hang...
https://forum.netgate.com/topic/164877/router-hanging-after-21-05-upgrade
-
It looks like this may be from a change in the FreeBSD kernel between versions that required a new build of miniupnpd, but the version number of miniupnpd didn't increase so it didn't get reinstalled.
You should be able to fix this with:
killall -9 miniupnpd pkg upgrade -fy miniupnpdAnd then click Save on the miniupnpd settings. Or run the
pkgcommand and reboot. -
@jimp Appears to be working :) I have now got rules being created.
It'll be interesting to see if my router hangs in a few days time.
Thanks.
-
there still appears to be a problem.
miniupnpd is still using a LOT of cpu time - doing AFAIK nothing.
I restart it and everything goes back to normal.
-
@sdm900 Are you running 21.05 or 21.09?
-
Version 21.05-RELEASE (arm)
built on Tue Jun 01 16:52:45 EDT 2021
FreeBSD 12.2-STABLEThe system is on the latest version.
Version information updated at Fri Jul 9 10:34:51 AWST 2021 -
I can't reproduce any problem like that here, where I could easily reproduce the error before.
If you haven't yet, after you have updated
miniupnpdmanually as described above, reboot the router to ensure the correct copy is the only one being used.It's also possible there is a lot of local traffic hitting UPnP/NAT-PMP and it's just busy at the time you noticed it.
