1
24.1 Production Series / Duplicate and growing number of entries in Universal Plug and Play: Status
« on: February 09, 2024, 10:14:14 pm »
miniupnpd is working fine, but I noticed the increasing number of duplicate entries in the status (Services: Universal Plug and Play: Status).
Example:
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:
Instead of these:
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.
Example:
Code: [Select]
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]
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]
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.