DoS on mythbackend port listeners

[jp@…]

I recently encountered a way to reproducibly kill the mythbackend ![1!] listeners on ports 654![349!]. More details at: ​http://ubuntuforums.org/showthread.php?t=658310

Aside from pulling my hair out for an entire weekend, this obviously represents at least a potential LAN DoS.

Steps to reproduce (given for a Mythbuntu 7.10 ![1!] system, but trivially adaptable):

 # aptitude install monit
 # vi /etc/default/monit
    Change to "startup=1"
 # vi /etc/monit/monitrc
    Tweak settings as needed, I'm not 100% sure which one did it, none should be *able* to:
  ----- cut here ----
  check host mythtv-be-01 with address 10.10.10.01
   if failed port 2442 type tcp then alert # mtd (Myth DVD)
   if failed port 6543 type tcp then alert # mythbackend server
   if failed port 6544 type tcp then alert # mythbackend status
   if failed port 6549 type udp then alert # mythbackend
  ----- cut here ----
 # monit -T /etc/monit/monitrc
 # vi /etc/monit/monitrc
    Fix any errors the -T syntax checker found
 # monit -T /etc/monit/monitrc
 # /etc/init.d/monit start

That's it. Now every time Monit polls, your mythbackend will stop listening on its TCP/UDP ports.

---

Footnote

[1] $ mythbackend --version
 Library API version     : 0.20.20070821-1
 Source code version     : 14283
 SVN Branch              : branches/release-0-20-fixes
 Options compiled in     :
 linux profile using_xvmcw using_v4l using_oss using_alsa using_arts using_jack using_ivtv using_firewire using_dbox2 using_hdhr using_ip_rec using_freebox using_live using_lirc using_joystick_menu using_dvb using_x11 using_xv using_xrandr using_xvmc using_xvmc_vld using_opengl_vsync using_opengl using_frontend using_backend using_bindings_perl

[David.Whyte@…]

This looks like a duplicate of Ticket #4174 which has since been (hopefully) resolved and closed.

[stuartm]

Torture tests performed on trunk by Michael Dean and James Meyer on the backend suggest this issue has been fixed, neither were able to trigger any bugs.

As we can't identify a single commit which fixes this problem and with 0.21 just weeks away this won't get backported to 0.20.