daemon.err miniupnpd[828]: send(res_buf): Broken pipe

Discussion in 'Tomato Firmware' started by Ric, Jul 8, 2012.

  1. Ric

    Ric Network Guru Member

    Currently running Tomato Firmware RAF1.28.9007 MIPSR2_RAF K26 USB VPN-NOCAT on an E4200 and my logs are full of the following broken pipe error.

    - daemon.err miniupnpd[828]: send(res_buf): Broken pipe

    Anyone have an idea of what this is comming from? The router appears to still be fully functional.
  2. hjf288

    hjf288 LI Guru Member

    Its from the UPNP Daemon
  3. Ric

    Ric Network Guru Member

    Thanks. I assume it's similar to an overfow error then. As I stated, everthing still appears to be working properly.
  4. koitsu

    koitsu Network Guru Member

    It's not a "overfow" [sic] (overflow) error.

    Broken pipe in *IX is error code EPIPE, which means that either a file descriptor or a socket (they're the same on *IX) was closed or severed abruptly for some reason. UPnP is a TCP-based protocol.

    So in your case, it means that there was an established TCP connection between something (probably a machine on your LAN) and miniupnpd. miniupnpd was in the process of sending data via the socket, when the socket was abruptly closed (TCP RST sent by the client).

    Why this is happening is unknown -- there's almost unlimited possibilities for a root cause. If you aren't using UPnP, I recommend turning the daemon off in the GUI and not worry about it.
  5. Ric

    Ric Network Guru Member

    Thanks koitsu. That sheds a lot more light on what's going on. The only thing that really uses the UPnP here is an XBox that my son plays on. With the info you just provided, he's probably shutting it off or resetting it while it's still online.
  6. koitsu

    koitsu Network Guru Member

    I would have to say the likelihood of that being the root cause is fairly high. :) If you're generally curious and have the ability/control, you might ask your son to write down (on paper, etc.) every time he shuts off the Xbox to see if you can correlate the messages. If they match up but are generally "off" by a few minutes, then that is also explainable (has to do with TCP timeout intervals as defined per the kernel and/or the firewall stack).
  7. Toastman

    Toastman Super Moderator Staff Member Member

    I seem to remember this message popping up some while ago, it was fixed in git ... 0f course, this could be something new though.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice