Duplicate and growing number of entries in Universal Plug and Play: Status

[JetSerge]

miniupnpd is working fine, but I noticed the increasing number of duplicate entries in the status (Services: Universal Plug and Play: Status).

Example:

Code Select Expand

Port Protocol Internal IP Int. Port Description
62852 tcp 10.0.0.87 6690 upnpclient:6690
62852 tcp 10.0.0.87 6690 upnpclient:6690
62852 tcp 10.0.0.87 6690 upnpclient:6690
62852 tcp 10.0.0.87 6690 upnpclient:6690
62852 tcp 10.0.0.87 6690 upnpclient:6690
62852 tcp 10.0.0.87 6690 upnpclient:6690
9308 udp 10.0.0.149 9308 10.0.0.149:9308 to 9308 (UDP)
9308 udp 10.0.0.149 9308 10.0.0.149:9308 to 9308 (UDP)
9308 udp 10.0.0.149 9308 10.0.0.149:9308 to 9308 (UDP)
9308 udp 10.0.0.149 9308 10.0.0.149:9308 to 9308 (UDP)
9308 udp 10.0.0.149 9308 10.0.0.149:9308 to 9308 (UDP)
9308 udp 10.0.0.149 9308 10.0.0.149:9308 to 9308 (UDP)
9308 udp 10.0.0.149 9308 10.0.0.149:9308 to 9308 (UDP)
9308 udp 10.0.0.149 9308 10.0.0.149:9308 to 9308 (UDP)
9308 udp 10.0.0.149 9308 10.0.0.149:9308 to 9308 (UDP)
9308 udp 10.0.0.149 9308 10.0.0.149:9308 to 9308 (UDP)
9308 udp 10.0.0.149 9308 10.0.0.149:9308 to 9308 (UDP)
9308 udp 10.0.0.149 9308 10.0.0.149:9308 to 9308 (UDP)


They stick there forever, never expire, and the list grows over time.

For example, 10.0.0.149 is my PS5. 10.0.0.87 is Synology NAS, and there is already a port forward rule for 6690 (Cloud Station).

Is it expected? If not, why it happens and should I do something about it? I know that explicit port forwards are recommended, but in case I want to keep using miniupnpd, should I be worried about these duplicates and possible resource leaks, or maybe it's just a visual representation bug?

EDIT:

I found some more details which may explain why it happens.
Using command line miniupnpc 2.2.6 and other upnp clients (like https://github.com/kaklakariada/portmapper), listing the existing mappings shows corrupted results:

Code Select Expand

i protocol exPort->inAddr:inPort description remoteHost leaseTime
0 UDP     0->10.0.0.87:0     '' '34.26.0.0' 0
1 UDP     0->10.0.0.87:0     '' '34.26.0.0' 0
2 UDP     0->10.0.0.87:0     '' '34.26.0.0' 0




Instead of these:

Code Select Expand

62852 tcp 10.0.0.87 6690 upnpclient:6690
62852 tcp 10.0.0.87 6690 upnpclient:6690
62852 tcp 10.0.0.87 6690 upnpclient:6690


It could be that PS5 and other clients get the same corrupted results, don't see the mapping they already created and try to add a new one which produces duplicates (and probably also cannot delete a mapping).

The question is why miniupnpd 2.3.3_2,1 server on opnsense returns these corrupted mappings.

[slackadelic]

After reading this I check and I'm seeing the same growing list happening.  Not sure it's causing any issues, but it's concerning for sure.

[AhnHEL]

I'm seeing this too.  Do you happen to have NAT-PMP checked as well in your UPnP settings?

[slackadelic]

I'm seeing this too.  Do you happen to have NAT-PMP checked as well in your UPnP settings?

I did have that turned on.   I've disabled it for now, not sure it would matter, but here's hoping!

[JetSerge]

Disabling Allow PCP/NAT-PMP Port Mapping setting doesn't help. I can still see duplicate entries and the client reads them incorrectly.

[slackadelic]

Disabling Allow PCP/NAT-PMP Port Mapping setting doesn't help. I can still see duplicate entries and the client reads them incorrectly.

Confirmed.  I thought at first it was working, but nah, back to a bunch of duplicate entries.

[JetSerge]

Found a related bug report: https://github.com/opnsense/plugins/issues/3831.

[franco]

I nudged the upstream bug report but to be frank a lot of the pfSense/libpfctl work has been a train wreck hit and run on both the src and ports infrastructure of FreeBSD.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277226

Since the author ignores reports that originate from OPNsense just because he can don't expect this to be fixed any time soon. I've talked through all the FreeBSD ranks and nobody can/wants to do anything about it.


Cheers,
Franco

[JetSerge]

Since the author ignores reports that originate from OPNsense just because he can don't expect this to be fixed any time soon. I've talked through all the FreeBSD ranks and nobody can/wants to do anything about it.

Thanks!

Maybe it's possible to use miniupnpd 2.3.3_1 instead of 2.3.3_2 somehow?

The pkg you suggested on GitHub from 23.7 version didn't work due to openssl dependency change.

[Seimus]

I nudged the upstream bug report but to be frank a lot of the pfSense/libpfctl work has been a train wreck hit and run on both the src and ports infrastructure of FreeBSD.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277226

Since the author ignores reports that originate from OPNsense just because he can don't expect this to be fixed any time soon. I've talked through all the FreeBSD ranks and nobody can/wants to do anything about it.


Cheers,
Franco

This is just sad.... Still holding a grudge because somebody took his milkyway in kindergarden.

Regards,
S.

[Patrick M. Hausen]

Doesn't look like grudge to me but more like maintainer has gone missing, disinterested, whatever ...

If you look at the patch that introduced the bug, that one was created by Kristof Provost and not my the miniupnpd maintainer. And this patch already was "approved" by maintainer timeout.

So more an orphaned port than anything else. Possibly best to nudge Kristof about it - if he can find the time.

Kind regards
Patrick

[franco]

> Maybe it's possible to use miniupnpd 2.3.3_1 instead of 2.3.3_2 somehow?

Yes, but after a very nasty bug I had to fix myself on stable/13 after him saying "we should fix our own stuff" I'm pretty confident he should fix his stuff, too.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273207#c18

> Supporting opnsense is your job, not mine. You don't get to just throw bugs over the wall without doing any actual testing on freebsd.

And this to a bug he himself added... And then we had this which went into production causing quite a stir and a whole night overtime for me working it out...

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275006

I'm done enabling others to continue do sub-par work while complaining about others.  :)


Cheers,
Franco

[Patrick M. Hausen]

I see your point  :)

[franco]

Actually I mentioned this elsewhere and asked why we can't have an option like LIBPFCTL which can be on by default but easily disabled to unbreak stuff it that happens. Because this also happened on pftop if anyone remembers.


Cheers,
Franco

[xpendable]

This issue appears to have been resolved upstream by the miniupnp devs with version 2.3.5
https://github.com/miniupnp/miniupnp/issues/719

I'm not familiar with how freebsd ports work... how do you get the maintainer of the freebsd port to update from source?