[mythtv-users] mythtv/master commit: 6ffb557d6 by Raymond Wagner (wagnerrp)

[Gregory Moyer]

On Tue, Jul 12, 2011 at 4:52 PM, Raymond Wagner <raymond at wagnerrp.com> wrote:
> On Tue, 12 Jul 2011 21:43:45 +0200, Warpme <warpme at o2.pl> wrote:
>>>The original message complained about strange behavior when querying
>>  >location. The location during playback will display the title and
>> subtitle
>>  >of the show being played back, which depending on location may very
> well
>>  >include UTF-8 text. Telnet is an ASCII protocol, and telnet clients
>> cannot
>>  >handle UTF-8 text. Any properly behaving telnet client will interpret
>> ASCII
>>  >(>127) characters as control codes, and react accordingly. Similarly,
> any
>>  >properly behaving telnet client will send various control codes which
>> will
>>  >be interpreted to the control socket as text, and cause unpredictable
>>  >behavior.
>>
>> I really appreciate help suggestions about switching from telnet to nc.
>> Unfortunately I prefer problem solution over workaround (I mean
>> reverting commit instead of removing telenet access).
>
> While we have never supported a telnet interface, and we likely never will
> support a telnet interface, a segfault is still something that show be
> resolved, even if brought on by fuzzing the interface.  Despite my best
> efforts, spamming queries into the control socket through the 'telnet'
> application, as fast as I can click my middle mouse button, I have yet been
> unable to cause a segfault.  Could you post your script to see what you're
> doing, or some logs to see what commands you're calling where and how
> freqently, or a traceback from one the segfaults?  Could you run 'git
> status', and make sure you didn't at some point make some additions to the
> control socket that it is failing on?

I found an issue with my original fix for the missing prompt. However,
I don't believe it could cause the problems Warpme is seeing.

I think I found the original motivation for blocking empty results -
that is in the processPlay method in networkcontrol.cpp for a 'play
program' command, the result string is cleared when the
NETWORK_CONTROL event to actually trigger playback is sent. Before the
patch, when this function returned with an empty result, no message
would have been sent back to the client and the client would still be
waiting at this point. Presumably, once the playback request is
received, networkcontrol.cpp will see a NETWORK_CONTROL RESPONSE event
in the function customEvent and that will trigger the "OK" response to
the client. This appears to be the only place in which the result is
cleared while a response is expected via an event later.

Now, after the patch, the empty response sends a prompt back to the
user immediately and a short time later when the RESPONSE event is
received, a second message of "OK" with another prompt is sent to the
user. Therefore, in a netcat session, the user seems something like
this:

MythFrontend Network Control
Type 'help' for usage information
---------------------------------
# play program 2097 2011-06-07T08:40:00 false

# OK
#

My approach to correct this involves setting the response to NULL
rather than an empty string when no response should be sent. Instead
of checking for an empty string, the if check verifies that the
response is not null. This allows for both scenarios where an empty
message can be returned to the user (such as when a 'query
recordings'' command is issued and no recordings exist), but an
immediate response can also be stopped to allow for a delayed response
triggered via other means, such as an event in the case of a 'play
program' request.

I created a patch for this, but I will not be able to test it (or my
theory on how the code works) until tomorrow night (EDT). I'm
attaching it here just to illustrate my point. I won't open a ticket
until I have compiled and tested it tomorrow. If the MythTV devs do
not like this approach, I am more than willing to put some more
thought into it.

- Greg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fenc-stop-sending-multiple-responses.patch
Type: text/x-patch
Size: 1134 bytes
Desc: not available
Url : http://www.mythtv.org/pipermail/mythtv-users/attachments/20110714/ba05c931/attachment.bin