miniupnpd: any workaround in the hotplug script to suppress these error messages during boot?

[braveheartleo]

Upon every boot, these error messages quickly fill up my logs that rotate the circular buffer, thereby losing previously logged messages: (I have already removed many duplicate lines that got logged)

 Mon Dec 22 07:43:14 2014 daemon.err miniupnpd[1556]: sendto(udp_notify=8, 192.168.105.1): Operation not permitted
 Mon Dec 22 07:43:14 2014 daemon.err miniupnpd[1556]: sendto(udp_notify=12, [2001:xxx:yyy:1]): Operation not permitted
 Mon Dec 22 07:43:14 2014 daemon.err miniupnpd[1556]: sendto(udp_notify=13, 192.168.103.1): Operation not permitted
 Mon Dec 22 07:43:14 2014 daemon.err miniupnpd[1556]: sendto(udp_notify=14, [2001:xxx:yyy::1]): Operation not permitted
 Mon Dec 22 07:43:14 2014 daemon.err miniupnpd[1556]: try_sendto(sock=14, len=475, dest=[ff02::c]:1900): sendto: Operation not permitted
 Mon Dec 22 07:43:14 2014 daemon.err miniupnpd[1556]: try_sendto(sock=13, len=471, dest=239.255.255.250:1900): sendto: Operation not permitted

Can any workaround be done? I noticed that the two IPv4 networks correspond to the two wireless interfaces I had setup. Perhaps when the hotplug script is executed, the two wireless interfaces have not yet fully initialized, thus causing miniupnpd to be unable to send packets in those interfaces when it gets (re)started in the script.

This has been observed on CHAOS CALMER (Bleeding Edge, r43749).

[miniupnp]

I don't know why the sendto() are not permitted... Some issue with the multicast support maybe ?

[braveheartleo]

Hi,

I wish to share my temporary workaround regarding this issue. But first, it looks like the issue is that the multicast packets were not being allowed to be sent, either by the firewall or the interfaces themselves, thus the error. My workaround is as follows:

/etc/init.d/miniupnpd-upnp:
#!/bin/sh /etc/rc.common

START=95

start()
{
  # We're not starting miniupnpd with upnp support to
  # dodge loads of sendto.. operation not permitted errors
  # upon startup. We do this until AFTER miniupnpd
  # is started for the first time.

  /etc/init.d/miniupnpd enabled 2>/dev/null || exit 0

  while true ; do
    [ -f /var/run/miniupnpd.pid ] && {
      echo enabling upnp support for miniupnpd
      uci set upnpd.config.enable_upnp=1

      # enable if interfaces are bridged
      #/etc/init.d/miniupnpd restart
      break
    } || sleep 2
  done
}

I created an init script with the same START sequence as miniupnpd. The idea is to start miniupnpd without upnp support initially. This dogdges those errors during startup (and they are many depending upon whether interfaces have been routed or bridged). The script will activate upnp support via uci (though uncommited, so that the next reboot we will have upnp support not enabled as well) ONLY after the daemon has started.

I did a lot of startup timing observations and during this time there are still some hotplug events being triggered (interfaces are being brought up), which will restart miniupnpd with upnp support active (and not have those errors encountered). If the interfaces are bridged, however, I noticed that those hotplug events complete faster, and because miniupnpd completes initialization AFTER the events, it is no longer restarted, thus requiring a manual restart.

I don't have deep knowledge of OpenWRT's startup sequence, its daemons (netifd), but it seems to me that there is some need to revisit the whole timing sequence so that services like miniupnpd that requires all interfaces/services have been fully initialized do not encounter errors when started.

[ecsv]

This package was removed in 20987707105119f50487711682bb269762ef43c9. So this ticket should most likely be closed