UPnP IGD & PCP Service crashes and fails to start
-
After 4 days of operation, and without changing anything, service fails to start with stack overflow error logged
I also saw it on previous beta but it recovered after rebooting. Now its here again.status is like this
🔒 Log in to viewApr 15 12:28:04 miniupnpd 52599 stack overflow detected; terminated Apr 15 12:28:04 miniupnpd 52599 Listening for NAT-PMP/PCP traffic on port 5351 Apr 15 12:28:04 miniupnpd 52599 no HTTP IPv6 address, disabling IPv6 Apr 15 12:28:04 miniupnpd 52599 HTTP listening on port 2189 Apr 14 19:01:42 miniupnpd 79415 stack overflow detected; terminated Apr 14 19:01:02 miniupnpd 79415 could not find redirect rule to delete eport=38450 Apr 14 19:01:02 miniupnpd 79415 could not find redirect rule to delete eport=38450 Apr 14 19:01:02 miniupnpd 79415 Failed to remove PCP mapping to 192.168.31.87:38450 UDP Apr 14 19:01:02 miniupnpd 79415 Failed to remove PCP mapping to 192.168.31.87:38450 TCP Apr 14 03:43:57 miniupnpd 79415 Unknown udp packet received from 192.168.41.36:59201 Apr 14 03:43:57 miniupnpd 79415 Unknown udp packet received from 192.168.41.36:60982 Apr 13 21:31:30 miniupnpd 79415 Unknown udp packet received from 192.168.41.36:49551 Apr 13 21:31:30 miniupnpd 79415 Unknown udp packet received from 192.168.41.36:52198 Apr 13 21:31:30 miniupnpd 79415 Unknown udp packet received from 192.168.41.36:56936 Apr 13 21:26:41 miniupnpd 79415 Unknown udp packet received from 192.168.41.36:49722 Apr 13 21:26:41 miniupnpd 79415 Unknown udp packet received from 192.168.41.36:60372 Apr 13 21:26:41 miniupnpd 79415 Unknown udp packet received from 192.168.41.36:49694 Apr 13 21:18:37 miniupnpd 79415 Unknown udp packet received from 192.168.41.36:50654 Apr 13 21:18:37 miniupnpd 79415 Unknown udp packet received from 192.168.41.36:49847 Apr 13 21:18:37 miniupnpd 79415 Unknown udp packet received from 192.168.41.36:60249 Apr 13 20:46:56 miniupnpd 79415 Unknown udp packet received from 192.168.41.36:50153 Apr 13 20:46:56 miniupnpd 79415 Unknown udp packet received from 192.168.41.36:56196 Apr 11 20:19:36 miniupnpd 79415 Unknown udp packet received from 192.168.41.36:62202 Apr 11 20:19:36 miniupnpd 79415 Unknown udp packet received from 192.168.41.36:55547 Apr 11 16:49:18 miniupnpd 79415 upnp_event_process_notify: connect(192.168.41.28:2869): Operation timed out Apr 11 16:49:10 miniupnpd 79415 upnp_event_process_notify: connect(192.168.41.28:2869): Operation timed out Apr 11 12:07:39 miniupnpd 79415 upnpevents_processfds: 0x65f7b438080, remove subscriber uuid:3e392fd3-16b4-11f0-b9f6-589cfc10ffcf after an ERROR cb: http://192.168.41.37:2869/upnp/eventing/hvhezryjus Apr 11 12:07:39 miniupnpd 79415 upnp_event_process_notify: connect(192.168.41.37:2869): Operation timed out Apr 11 12:07:39 miniupnpd 79415 upnpevents_processfds: 0x65f7b438000, remove subscriber uuid:3e35ef1c-16b4-11f0-b9f6-589cfc10ffcf after an ERROR cb: http://192.168.41.37:2869/upnp/eventing/wcpgizilrc Apr 11 12:07:39 miniupnpd 79415 upnp_event_process_notify: connect(192.168.41.37:2869): Operation timed out Apr 11 12:07:39 miniupnpd 79415 upnp_event_process_notify: connect(192.168.41.37:2869): Operation timed out Apr 11 06:46:29 miniupnpd 79415 Listening for NAT-PMP/PCP traffic on port 5351 Apr 11 06:46:29 miniupnpd 79415 no HTTP IPv6 address, disabling IPv6 Apr 11 06:46:29 miniupnpd 79415 HTTP listening on port 2189 Apr 11 06:44:03 miniupnpd 92767 stack overflow detected; terminated Apr 11 06:44:03 miniupnpd 92767 Listening for NAT-PMP/PCP traffic on port 5351 Apr 11 06:44:03 miniupnpd 92767 no HTTP IPv6 address, disabling IPv6 Apr 11 06:44:03 miniupnpd 92767 HTTP listening on port 2189 Apr 11 06:43:36 miniupnpd 31016 stack overflow detected; terminated Apr 11 06:43:36 miniupnpd 31016 Listening for NAT-PMP/PCP traffic on port 5351 Apr 11 06:43:36 miniupnpd 31016 no HTTP IPv6 address, disabling IPv6 Apr 11 06:43:36 miniupnpd 31016 HTTP listening on port 2189 Apr 11 06:42:12 miniupnpd 34188 stack overflow detected; terminated Apr 11 06:42:12 miniupnpd 34188 Listening for NAT-PMP/PCP traffic on port 5351 Apr 11 06:42:12 miniupnpd 34188 no HTTP IPv6 address, disabling IPv6 Apr 11 06:42:12 miniupnpd 34188 HTTP listening on port 2189Also this
Apr 15 13:01:33 kernel pid 93101 (miniupnpd), jid 0, uid 0: exited on signal 6 (core dumped) -
Is that on the latest April beta?
-
@marcosm
25.03.b.20250409.2208
I am now on 414
Looks good, but takes some time for the issue to appear. 3-4 days. -
What version where you on previously (that presumably worked)?
-
@marcosm
24.11 long term -
Any core dumps? IIRC they get saved to
/root/. -
@marcosm Yes, there is a 13Mbyte miniupnp.core file which compresses to 150 k
-
@netblues Can you try this build: https://www.codepro.be/files/miniupnpd-2.3.7_2,1.pkg ?
It contains debug symbols and will hopefully let us figure out where miniupnpd crashes. -
@kprovost Installed, restarted and waiting.
I see two active port maps in status.
-
@netblues anything more on this? I'm having the same issue.
-
@townsenk64
I have the debug build running.
It didn't occur so far., but it does take a couple of days. -
For me the service fails within two minutes after reboot generating the previously mentioned core file. Let me know if help is needed troubleshooting.
-
@townsenk64 Do you run the debug version?
-
@netblues Not yet, I'm not exactly sure the proper way to upgrade a single package locally. I assume the pkg add command?
-
@townsenk64 said in UPnP IGD & PCP Service crashes and fails to start:
@netblues Not yet, I'm not exactly sure the proper way to upgrade a single package locally. I assume the pkg add command?
pkg add -f <path to .pkg> -
@kprovost said in UPnP IGD & PCP Service crashes and fails to start:
https://www.codepro.be/files/miniupnpd-2.3.7_2,1.pkg
I am now running the debug build. Does it contain changes other than having the debugging enabled? The reason I ask is that the service hasn't crashed almost immediately after rebooting like it did before. I will leave it running and see if it behaves.
-
@townsenk64 Well actually it just has debug symbols, which means its more meaningful when looking at the dump.
Most probably network conditions have changed, something has timed out and is not triggering the issue anymore.
Do keep in mind that in upnp we make ports available to the wider Internet, and usually there is little control on what happens next.
From a security point of view its a nightmare, but in a home scenario its too practical to ignore ;-) -
I rolled the system back to a previous state using the package without the debugging symbols and the service crash immediately happened again upon reboot. I then went with the shotgun approach and ran from command line.
pkg clean -y
pkg upgrade -fThis apparently replaced/upgraded the package and the service is again running without issue.
-
@townsenk64 Same here, no issues since I put the debug version.
Maybe a leftover glitch from the upgrades?