Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#10763 closed Bug Report - General (Invalid)

Network Control Socket fails to bind to proper interface on remote front end

Reported by: Gern Blanston <mythtv@…> Owned by:
Priority: minor Milestone: unknown
Component: MythTV - General Version: 0.25-fixes
Severity: medium Keywords: frontend, network control socket, serverpool
Cc: Ticket locked: no

Description

I hate to re-report an issue with a locked ticket (#10671) but I am experiencing the same problem and it feels a lot like a bug. See that bug for the background on the issue.

This is on a remote frontend.

I can confirm that I have "LocalHostName?" set in mysql.txt and the frontend network control port is not binding to that IP address. It only binds to localhost.

In serverpool.cpp, it appears that the code tries to add "BackendServerIP" (which won't work on a remote frontend) and does not reference "LocalHostName?" from mysql.txt (as far as I can tell).

The chunk of code in serverpool.cpp which would step through all available interfaces is NOT executed because of this test:

config_v4.isNull() && (ip.protocol() == QAbstractSocket::IPv4Protocol))

At this point, config_v4 is not null -- it contains the IP address specified by BackendServerIP -- so the following code that would step through each interface does not get executed.

Here's a snip from the frontend log:

2012-05-14 11:34:47.898702 C  ServerPool: Host is configured to listen on 192.168.10.131, but address is not used on any local network interfaces.
2012-05-14 11:34:47.911098 I  Listening on TCP 127.0.0.1:6547
2012-05-14 11:34:47.911472 I  Listening on TCP [::1]:6547
2012-05-14 11:34:59.132162 I  Listening on TCP 127.0.0.1:6546
2012-05-14 11:34:59.132380 I  Listening on TCP [::1]:6546

In the past, I -think- that it was important to set "LocalHostName?" in mysql.txt so that configuration items would be stored correctly for a remote frontend.... if that's no longer the case, let us know :)

My install of mythtv is from the 0.25-286 rpms from atrpms

Thank you all very much for all the hard work on MythTV!

mythbackend --version

Please attach all output as a file in bug reports.
MythTV Version : v0.25
MythTV Branch : 
Network Protocol : 72
Library API : 0.25.20120408-1
QT Version : 4.8.1
Options compiled in:
 linux release use_hidesyms using_alsa using_jack using_oss using_pulse using_pulseoutput using_backend using_bindings_perl using_bindings_python using_bindings_php using_crystalhd using_dvb using_firewire using_frontend using_hdhomerun using_ceton using_hdpvr using_iptv using_ivtv using_joystick_menu using_libcrypto using_libdns_sd using_libfftw3 using_libxml2 using_lirc using_mheg using_opengl_video using_qtwebkit using_qtscript using_qtdbus using_v4l2 using_x11 using_xrandr using_xv using_bindings_perl using_bindings_python using_bindings_php using_mythtranscode using_opengl using_vaapi using_vdpau using_ffmpeg_threads using_live using_mheg using_libass using_libxml2

Change History (2)

comment:1 Changed 8 years ago by Raymond Wagner

Resolution: Invalid
Status: newclosed

The code is designed such that if you specify the BackendServerIP for that host, it will only listen on that address and localhost (127.0.0.1 or ::1). If you do not specify anything, it will poll the addresses defined on that system, and listen on any RFC1918 private network address. That means anything in the 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16 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.

comment:2 Changed 8 years ago by Gern Blanston <mythtv@…>

Thank you very much for the excellent explanation -- I removed the "BackendServerIP" settings for my remote frontends and the socket issue is indeed resolved. My apologies for reopening the ticket! I suspect other folks may have this exact issue and I also suspect (but am not sure!) that I didn't manually set "BackendServerIP" -- perhaps it was set in a previous version of myth? Either way, a mention of this on the wiki might be a good idea.

Thanks again for you help & patience ;)

Note: See TracTickets for help on using tickets.