miniupnpd[744] - Firmware:374.42_2

[Djurik]

Hi Guyzz,

Using 68U router with Firmware:374.42_2. Anyone to assist on this message in log? Im getting it every 1-2min 24hrs. I have no idea what is this.

Jun  3 08:49:57 miniupnpd[744]: SendSSDPResponse(): sendto(udp): Operation not permitted
Jun  3 08:50:34 miniupnpd[744]: SendSSDPResponse(): sendto(udp): Operation not permitted
Jun  3 08:50:49 miniupnpd[744]: SendSSDPResponse(): sendto(udp): Operation not permitted
Jun  3 08:51:34 miniupnpd[744]: SendSSDPResponse(): sendto(udp): Operation not permitted
Jun  3 08:51:43 miniupnpd[744]: SendSSDPResponse(): sendto(udp): Operation not permitted
Jun  3 08:54:22 miniupnpd[744]: SendSSDPResponse(): sendto(udp): Operation not permitted
Jun  3 08:55:35 miniupnpd[744]: SendSSDPResponse(): sendto(udp): Operation not permitted
Jun  3 08:56:08 miniupnpd[744]: SendSSDPResponse(): sendto(udp): Operation not permitted
Jun  3 08:56:35 miniupnpd[744]: SendSSDPResponse(): sendto(udp): Operation not permitted
Jun  3 08:58:35 miniupnpd[744]: SendSSDPResponse(): sendto(udp): Operation not permitted
Jun  3 09:02:35 miniupnpd[744]: SendSSDPResponse(): sendto(udp): Operation not permitted
Jun  3 09:02:35 miniupnpd[744]: SendSSDPResponse(): sendto(udp): Operation not permitted
Jun  3 09:11:36 miniupnpd[744]: SendSSDPResponse(): sendto(udp): Operation not permitted
Jun  3 09:12:36 miniupnpd[744]: SendSSDPResponse(): sendto(udp): Operation not permitted
Jun  3 09:17:37 miniupnpd[744]: SendSSDPResponse(): sendto(udp): Operation not permitted
Jun  3 09:29:37 miniupnpd[744]: SendSSDPResponse(): sendto(udp): Operation not permitted
Jun  3 09:31:38 miniupnpd[744]: SendSSDPResponse(): sendto(udp): Operation not permitted
Jun  3 09:31:42 miniupnpd[744]: SendSSDPResponse(): sendto(udp): Operation not permitted
Jun  3 09:34:38 miniupnpd[744]: SendSSDPResponse(): sendto(udp): Operation not permitted

Will provide whatever info still need. Appreciate your help.

 

[john9527]

Are you running Plex Media Server, and specifically have the DLNA server enabled? This is known to cause these entries. (I've reported it in the Plex forums, but it seems as if there is little interest in addressing it).

I've shut off upnp and set up all my needed port forwarding manually to get rid of the messages.

 

[RMerlin]

It might be worth contacting Thomas Bernard, the miniupnpd author. He might be interested in looking into it, at least to see if the issue is actually with Plex or with miniupnpd.

 

[Djurik]

Are you running Plex Media Server, and specifically have the DLNA server enabled? This is known to cause these entries. (I've reported it in the Plex forums, but it seems as if there is little interest in addressing it).

I've shut off upnp and set up all my needed port forwarding manually to get rid of the messages.

Oh great man, you are right, its a Plex (yea i have a NAS and im running Plex on it). Here is the log from router to prove:

Jun  3 22:55:47 miniupnpd[744]: SendSSDPResponse(): sendto(udp): Operation not permitted
Jun  3 22:56:50 miniupnpd[744]: SendSSDPResponse(): sendto(udp): Operation not permitted
Jun  4 05:02:18 miniupnpd[744]: SendSSDPResponse(): sendto(udp): Operation not permitted
Jun  4 05:04:18 miniupnpd[744]: SendSSDPResponse(): sendto(udp): Operation not permitted

I set Plex to off itself at 11pm and start at 5am (to dont disturb my gaming) and the timing in the log exactly the same. I thought its something in a Merlin firmware. But i cant off upnp as i have kids at home and way tooo many upnp DLNA devices (and each have a few different DLNA media players for different movie format) running their cartoons from NAS. Ill get sweat forwarding all these random ports. Lol. Will have to press Plex for this issue. Anyway thanx for your advise, thought i will stuck with this..

It might be worth contacting Thomas Bernard, the miniupnpd author. He might be interested in looking into it, at least to see if the issue is actually with Plex or with miniupnpd.

Thanx Merlin for your attention as well, your firmware is something, love it!! Wasted a few day with my ISP resetting/restarting router and updating with original Asus FW when i had a random reboot issue. Probably dont have enough time to contact the guy. Will try, if can ill contact him and will post here if anything useful.

--------Added later---------
Probably is purely Plex issue, as i run Synology DLNA server (as well as some handphone servers like "TV Assist" or "Bubble upnp" but not sure they are related, as i think this is only renderers, but also upnp) and dont have any errors in log..

 

[john9527]

Just to be complete....here's the link to the thread on the Plex forum.....along with a guess about Plex possibly seeing the router itself as a DLNA renderer.....

https://forums.plex.tv/index.php/topic/104297-plex-taking-down-my-router/

 

[john9527]

Hmmm....I figured out how to turn on console debug mode for miniupnpd and guess what......the error went away! I looked at the miniupnpd code and see where the error would be generated, and based on the debug output see that it should not be having an error. So, it may be a timing type of issue.

I haven't set up an environment to do my own compiles yet, so if someone set up to compile the firmware could make a test firmware for me with the following change to the makefile, I'd like to try this to see if it helps. (for AC68U/R)

change....
miniupnpd/config.h:
cd miniupnpd && ./genconfig.sh --leasefile --vendorcfg

to
miniupnpd/config.h:
cd miniupnpd && ./genconfig.sh --leasefile --vendorcfg --strict

including --strict adds some timing delays around SSDP responses.

Thanks.

 

[john9527]

Well, I got my own compile capability set up...verified a good compile and recreation of the problem (374.44_alpha1 code).

Set about a little debug work and made a small fix in minissdp.c to ensure a delay before getting the ssdp response. Message is gone! Actually surprised me that it wasn't a Plex problem per se....just something that Plex is doing to expose the issue.

Next I'll try to figure out how to open an issue with the minupnpd author.

 

[RMerlin]

Did you get in touch with Thomas about this?

 

[john9527]

Sorry to say I haven't with some other things going on. I did send a copy of my build to a user on the Plex forum with the same problem, and he confirmed that it fixes the problem and works fine with no ill effects on his system. Continues to run clean on my system as well. Here's the change I made.....

diff --git a/release/src/router/miniupnpd/minissdp.c b/release/src/router/miniupnpd/minissdp.c
index 8431e7e..52bb856 100644
--- a/release/src/router/miniupnpd/minissdp.c
+++ b/release/src/router/miniupnpd/minissdp.c
@@ -748,7 +748,7 @@ ProcessSSDPData(int s, const char *bufr, int n,
#if defined(UPNP_STRICT) || defined(DELAY_MSEARCH_RESPONSE)
int mx_value = -1;
#endif
- unsigned int delay = 0;
+ unsigned int delay = 100; /* Non-zero default delay to prevent flooding */
/* UPnP Device Architecture v1.1. 1.3.3 Search response :
* Devices responding to a multicast M-SEARCH SHOULD wait a random period
* of time between 0 seconds and the number of seconds specified in the

 

[RMerlin]

Ok, I'm curious as to what he has to say. I'm worried that enabling strict mode might cause compatibility issues with other devices.

 

[john9527]

Yes.....this change avoids strict mode.....but in doing that the random delay referenced in the comments is never invoked, and the fixed '0' delay was used. Hence, the change I made.

 

[RMerlin]

Yes.....this change avoids strict mode.....but in doing that the random delay referenced in the comments is never invoked, and the fixed '0' delay was used. Hence, the change I made.

Ah right, sorry. I missed the #endif that was in your pasted snippet, so I thought everything was conditional to STRICT being enabled.

 

[RMerlin]

Wouldn't enabling DELAY_MSEARCH_RESPONSE be better tho? The comment in that section mentions that specifications calls for a random value to be used.

 

[john9527]

There was a reason why I initially didn't try the DELAY_MSEARCH_RESPONSE, but I'll be damned if I can remember what it was. I'll do a build backing out the change I made and enabling that option to test.

 

[john9527]

OK....setting DELAY_MESARCH_RESPONSE also seems to eliminate the spurious sendto(udp) messages. And actually given the structure of the code, makes more sense.

Currently in release/src/router/miniupnpd/genconfig.sh the logic is

if STRICT then define DELAY_MSEARCH_RESPONSE else don't define

since the mainline code checks for STRICT or DELAY_MSEARCH_RESPONSE, it seems the genconfig logic should be reversed.

if STRICT then don't define DELAY_MSEARCH_RESPONSE else define

which is the test change I just made.

 

[RMerlin]

Thanks for confirming this fix also worked. It does look cleaner indeed than hardcoding a value.

 

[john9527]

Well....I looked again in the clearer head of the AM....and there are stand-alone conditions for DELAY_MSEARCH_RESPONSE as well. So it's possible that the gen could be meant to couple STRICT and the DELAY_MSEARCH_RESPONSE.

There's also another place you could patch which is the direct call that fails (which I also confirmed works to fix the problem)....

n = sendto_schedule(s, buf, l, 0,
addr, addrlen, delay);

There's also precedent where the delay is hardcoded directly in the call elsewhere in the code.

Do you know Thomas? If you do, maybe more 'pull' if you pointed him to this thread to get his take.

 

[RMerlin]

Well....I looked again in the clearer head of the AM....and there are stand-alone conditions for DELAY_MSEARCH_RESPONSE as well. So it's possible that the gen could be meant to couple STRICT and the DELAY_MSEARCH_RESPONSE.

There's also another place you could patch which is the direct call that fails (which I also confirmed works to fix the problem)....

n = sendto_schedule(s, buf, l, 0,
addr, addrlen, delay);

There's also precedent where the delay is hardcoded directly in the call elsewhere in the code.

Do you know Thomas? If you do, maybe more 'pull' if you pointed him to this thread to get his take.

I don't know him personally, no. I only discussed an issue with him once through his issue tracker.

Best way to get in touch with him is to open an issue on his Github issue tracker. He actively follows up on it.

 

[john9527]

Issue #84 opened in miniupnpd Github.

 

[john9527]

Note to RMerlin....Just received a close notice for this issue from Thomas. He went with my original fix of changing the default delay (although smaller, he went with 50ms instead of my 100ms.) I've validated the smaller value is good.

You may want to change to this fix instead of the DELAY_MSEARCH_RESPONSE compile option you picked up in beta2. I actually saw a single hit of the problem in about 2 weeks when running with the compile option (since it's a random delay generation, it likely eventually picked a really small number to cause the single event).