Network Control socket fails to listen on second address

[Paul Saunders <darac@…>]

As of 0.25, the Network Control socket (port 6456) doesn't work. At least, this is the immediately obvious problem. Looking at the logs, I can see that it successfully listens on 127.0.0.1, but then fails listening to the next address in the list (for the attached log, that is 192.168.123.1, but the same occurs on another machine where the second, failing address is public).

With the frontend still running, I can see that:

1. there is nothing already listening on that port (sudo netstat -nlp | grep 6456 returns nothing) and
2. I can listen on that port (nc -l -p 6456 and even 'nc -l -s 192.168.123.1 -p 6456` start up and print commands from my remote control).

I'm not quite sure how to proceed, though. I can see there is a problem here, but without knowing why MythFrontend is not listening, it's a bit difficult to find the root cause.

[wagnerrp]

Waiting on logs presumed to be forthcoming. Also, the default port is 6546, not 6456. You were likely checking netstat for the wrong port. Is there anything already listening on that?

[Paul Saunders <darac+mythtv@…>]

Frontend Log (Debug Level)

[Paul Saunders <darac+mythtv@…>]

Mythfrontend --version

[Paul Saunders <darac@…>]

Sorry. My laptop crashed between creating the ticket and attaching the logs.

6456 was a typo here in the ticket. I have actually checked port 6546.

[wagnerrp]

Just a few side comments first. The logs report version "v0.25pre". You're running a pre-release and should upgrade, but there haven't been any changes to the listen servers in several weeks, and that's not likely to cause your problems. More importantly, that's not a version string MythTV would generate itself. MythTV would have included a specific commit hash, as well as a counter of commits since that tag, likely in the 4000+ range. If you are getting MythTV from a third party packager, it would be beneficial to know who, so we could contact them and get a more descriptive string put in there.

Line 96 indicates you're running your backend against an internet facing IP address. Generally this is advised against for security reasons, and just simple lack of bandwidth needed to make such configuration worthwhile. Since you don't have an IP forced for that host, MythTV scans your available addresses, and automatically selects where to listen. You'll note on line 34 that it refused to listen on the non-RFC1918 address. On the other hand, considering you have multiple internet facing addresses, as well as multiple internal subnets, you presumably know what you're doing in that regard.

[wagnerrp]

Replying to wagnerrp:

The logs report version "v0.25pre". That's not a version string MythTV would generate itself.

Scratch that, it appears that IS the string the build scripts produce now...

[wagnerrp]

In f4d7bffcc71904d84b06046213ba453fa2aa2865/mythtv:

Add logging information as to why MythTV would fail to listen on a port.

Refs #10633

[wagnerrp]

In 1a671d0b252d2b33bd1e96258e65a15d52a5fc7d/mythtv:

Add logging information as to why MythTV would fail to listen on a port.

Refs #10633
(cherry picked from commit f4d7bffcc71904d84b06046213ba453fa2aa2865)

[beirdo]

Replying to wagnerrp:

Replying to wagnerrp:

The logs report version "v0.25pre". That's not a version string MythTV would generate itself.

Scratch that, it appears that IS the string the build scripts produce now...

That means that his build was made from the tarball. I have reuploaded the tarball since with the proper value set in VERSION, and fixed the release script so it doesn't happen again. If it's a git build, then the only time you see the tag as the version is when you are right on that tag, but then the branch would also be filled out.

It might be a good idea to redownload the tarball to remove confusion later. If this was packaged by someone, please let us know which package so we can let them know as well.

[wagnerrp]

Paul Saunders:

Could you test again with the above changes to get an explanation of the error? My only guess is you've got something else already listening on those ports.

[Paul Saunders <darac@…>]

OK. For the record, the build I initially reported the bug against was the Debian-Multimedia package, version 0.25-0.3.

I've now re-built from git commit 1a671d0 and re-run mythfrontend again. Perhaps a little surprisingly, the error now is:

Failed listening on TCP 192.168.123.1:6546 - Error 10: Operation on socket is not supported

I can attach the full log if you like, but I suspect that's the bit you're interested in.

[martin_ginkel@…]

I have exactly the same problem on mythbuntu with official debs,

2:0.25.0+fixes.20120506.1c4066e.

The problem does not exist on opensuse (my other frontend) on a 2.6.39 kernel. Maybe this is related to newer kernels and different socket handling. I have not seen anything special in strace.

[martin_ginkel@…]

OK after some debugging I found a strange but simple solution:

On my myth box I have the environment variables http_proxy=​http://my.squid.box:3128 enabled. The Squid is working, but apparently QT uses these always for all tcp sockets. After unsetting the variables, mythfrontend listens as expected.

The code for this is somewhere deep in QTcpServer::listen(), I have no Idea why this only fails for the network control port. But on my laptop it always worked, until I set the same environment variables, then the network control socket failed as well.

Solution:

export http_proxy=

[martin_ginkel@…]

Did ab bit of research about proxy network operation in QT. Apparently they introduced the QNetworkProxy in 4.1 and allowed to set an application-global proxying of all network connections.

​http://doc.qt.nokia.com/4.7-snapshot/qnetworkproxy.html#setApplicationProxy

I still don't see, how this is directly related to listening servers but apparently the QTcpServer works with the DefaultProxy? proxy type by default. This means it respects the global application setting.

If the application setting is set to global QNetworkProxy::HttpProxy? then all connections (not only HTTP-outgoing) are supposed to tunnel through a transparent HTTP proxy.

Eventually one could set the Proxy mode of the PrivTcpServer? in ServerPool? to use the NoProxy? mode. For the special network non-HTTP ports it does not make any sense to use Proxies automatically.

[bjoernv@…]

I have this bug in Mythfrontend 0.26 too.