Miniupnpd: cpu load constantly increasing over weeks to 100%

  • Hello!

    I am running 2.2 on an ALIX board and was very surprised when I saw that under Status-> RRD Graphs-> System-> Processor my Router was under heavy load during working hours and nearly no load during the night.

    Today I logging in via ssh and saw that miniupnpd takes 70-80% CPU load. At the same time we do only have a little traffic to handle (nothing big).

    I compared the status graphs for Processor and Traffic and as soon as the users starting making some internet-traffic cpu load jumps to nearly 100%.

    I stopped miniupnpd and started it again after a few minutes - now it does not make any load at all.

    What makes me wonder is that I could see that the cpu load started to increase constantly until it reached 100% (see the attached image)

    Is this a bug with miniupnpd or should I look for something else?


  • Rebel Alliance Developer Netgate

    It's difficult to say for sure but it sounds like maybe something on your network is sending out a large number of UPnP or UPnP-like requests. Odds are it's not a miniupnpd bug but just what it's doing to deal with what it's seeing on the LAN side.

    You could run a packet capture of several thousand packets on the LAN and then load that up in Wireshark. Look and see what UPnP type traffic it finds and then track down what local system is sending it.

  • I've just solved a similar issue with 2.2. I use the pfSense facility to restrict access to UPnP by ip, only allowing devices that need it access. A device on my LAN that was configured to use UPnP, but not authorised in pfSense, went into a loop sending request after request until the pfSense state table filled up. At that point the Alix succumbed.

    In my case it was a QNAP NAS and the answer was to turn off UPnP on it (I wasn't using it anyway).

    But I know for sure this scenario was not an issue in 2.1, so something in 2.2 has changed behaviour. As jimp says, miniupnpd in 2.2 is not necessarily at fault, changes to make it "more correct" may be exposing hidden issues in the QNAP implementation.

    Another way to find the offending device is to look in your state tables, you'll soon spot it.