Modify

Opened 3 years ago

Last modified 12 months ago

#10633 new Bug Report - General

Network Control socket fails to listen on second address

Reported by: Paul Saunders <darac@…> Owned by: wagnerrp
Priority: minor Milestone: 0.27.2
Component: MythTV - General Version: 0.25
Severity: medium Keywords:
Cc: Ticket locked: no

Description

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.

Attachments (2)

mythfrontend.20120420144811.30411.log (15.5 KB) - added by Paul Saunders <darac+mythtv@…> 3 years ago.
Frontend Log (Debug Level)
mythtvfrontend--version.txt (885 bytes) - added by Paul Saunders <darac+mythtv@…> 3 years ago.
Mythfrontend --version

Download all attachments as: .zip

Change History (21)

comment:1 Changed 3 years ago by wagnerrp

  • Owner set to wagnerrp
  • Status changed from new to accepted

comment:2 Changed 3 years ago by wagnerrp

  • Status changed from accepted to infoneeded

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?

Changed 3 years ago by Paul Saunders <darac+mythtv@…>

Frontend Log (Debug Level)

Changed 3 years ago by Paul Saunders <darac+mythtv@…>

Mythfrontend --version

comment:3 Changed 3 years ago by 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.

comment:4 follow-up: Changed 3 years ago by 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.

comment:5 in reply to: ↑ 4 ; follow-up: Changed 3 years ago by 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...

comment:6 Changed 3 years ago by wagnerrp

In f4d7bffcc71904d84b06046213ba453fa2aa2865/mythtv:

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

Refs #10633

comment:7 Changed 3 years ago by 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)

comment:8 in reply to: ↑ 5 Changed 3 years ago by 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.

comment:9 Changed 3 years ago by 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.

comment:10 Changed 3 years ago by 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.

comment:11 Changed 3 years ago by 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.

comment:12 Changed 3 years ago by 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=

comment:13 Changed 3 years ago by 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.

comment:14 Changed 3 years ago by kenni

  • Status changed from infoneeded to assigned

comment:15 Changed 2 years ago by bjoernv@…

I have this bug in Mythfrontend 0.26 too.

comment:16 Changed 21 months ago by stuartm

  • Milestone changed from unknown to 0.27
  • Status changed from assigned to infoneeded

Paul, it would be helpful if you could confirm that you were using a proxy and whether setting the http_proxy environmental variable to an empty string works for you?

comment:17 Changed 20 months ago by stuartm

  • Milestone changed from 0.27 to 0.27.1

comment:18 follow-up: Changed 12 months ago by jyavenard

  • Resolution set to Won't Fix
  • Status changed from infoneeded to closed

http_proxy is required and necessary when opening some media with FFmpeg

so either you use it, or you don't

you can't simply disable http_proxy in a blank manner.

comment:19 in reply to: ↑ 18 Changed 12 months ago by martin_ginkel@…

  • Resolution Won't Fix deleted
  • Status changed from closed to new

Replying to jyavenard:

http_proxy is required and necessary when opening some media with FFmpeg so either you use it, or you don't you can't simply disable http_proxy in a blank manner.

It might be useful for client connections like ffmpeg talking to a http server in the internet, but in this case you try to establish a *server* socket for the frontend -- listening for remote control clients.

This should never be proxied from the server side, because it stops working in this case (obviously).

Summary: use http_proxy when building client http connects, ignore it for any server socket.

Add Comment

Modify Ticket

Action
as new The owner will remain wagnerrp.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.