[mythtv-commits] Ticket #10763: Network Control Socket fails to bind to proper interface on remote front end

MythTV noreply at mythtv.org
Sat May 26 21:59:47 UTC 2012

#10763: Network Control Socket fails to bind to proper interface on remote front
 Reporter:  Gern Blanston <mythtv@…>             |          Owner:
     Type:  Bug Report - General                 |         Status:  closed
 Priority:  minor                                |      Milestone:  unknown
Component:  MythTV - General                     |        Version:
 Severity:  medium                               |  0.25-fixes
 Keywords:  frontend, network control socket,    |     Resolution:  Invalid
  serverpool                                     |  Ticket locked:  0
Changes (by wagnerrp):

 * status:  new => closed
 * resolution:   => Invalid


 The code is designed such that if you specify the BackendServerIP for that
 host, it will only listen on that address and localhost ( or
 ::1).  If you do not specify anything, it will poll the addresses defined
 on that system, and listen on any
 [http://tools.ietf.org/html/rfc1918#page-4 RFC1918] private network
 address.  That means anything in the,, or address ranges, things that would be used were you running
 a system behind a NAT router.

 There are only three reasons to define BackendServerIP on a host:
 * You are running a backend on that host, and the backend needs that
 address defined, both for proper configuration, and so clients on the
 network know how to access it.
 * You want to limit the frontend from listening everywhere, and only want
 to allow access on a specific IP address, or only localhost.
 * You are operating without NAT, directly on an internet routeable
 address, and need to force the frontend to listen there, when it will by
 default ignore it as it is not an RFC1918 private address.

 In MythTV, the hostname is simply a key for selecting configuration and
 storage defined in the database.  By default, MythTV will use the system's
 hostname for that key, whatever you get when you run `hostname` on the
 command line.  If for whatever reason you want to override that value, you
 can do so with the LocalHostName parameter in mysql.txt.  In 0.26, that
 file has been removed, and the value can instead be defined using
 Configuration/LocalHostName in config.xml.  There are only a handful of
 reasons you might want to do this:
 * You want to run a configuration set from another machine, but you only
 want to do so temporarily, so you don't want to use the database restore
 script to migrate the settings to the new hostname.
 * You are running multi-head, and want to run two frontends
 simultaneously, or at different times, with different configurations.
 * You want to have separate shared settings for multiple applications
 running on that host.

 This last one is where you're getting confused.  Since all backends
 require BackendServerIP be set to function, a frontend on the same host
 would be constrained to only listen on the same address.  Specifying a
 custom LocalHostName would allow the frontend to use an independent
 configuration, or no configuration and autoselect the addresses.

 My guess of what is going on here is that you didn't understand the
 purpose of BackendServerIP, and on your remote frontend, set it to the
 address of your master backend.  That value is a local setting, for the
 configuration of services running locally on that host.  MasterServerIP is
 what is supposed to be used to define the master.  When you set
 BackendServerIP to that of a remote machine, you told the frontend to only
 listen on that address and localhost, and since that address was not its
 own, it refused, and dropped to localhost only.

Ticket URL: <http://code.mythtv.org/trac/ticket/10763#comment:1>
MythTV <http://code.mythtv.org/trac>
MythTV Media Center

More information about the mythtv-commits mailing list