[Xymon] Possible bug in protocol tests

[J.C. Cleaver]

On Wed, July 29, 2015 10:16 am, Mark Felder wrote:
>
>
> On Tue, Jul 28, 2015, at 09:26, Shawn Heisey wrote:
>> I had a thread on the mailing list about this previously.  In the recent
>> past, I had to rebuild my xymon server and now I'm ready to declare that
>> I think the behavior I'm seeing is a bug.
>>
>> http://lists.xymon.com/oldarchive/2010/11/msg00189.html
>>
>> The original problem is that the default smtp settings which come with
>> xymon in protocols.cfg produce a warning/error in the postfix log about
>> improper command pipelining, so I am adjusting the xymon config to keep
>> that from happening.
>>
>> Here's a transcript of a session with my mail server:
>>
>> root at nexus2:~# telnet localhost 25
>> Trying ::1...
>> Connected to localhost.
>> Escape character is '^]'.
>> 220 nexus2.REDACTED.com ESMTP Postfix (Ubuntu)
>> mail
>> 503 5.5.1 Error: send HELO/EHLO first
>> quit
>> 221 2.0.0 Bye
>> Connection closed by foreign host.
>>
>> The following config duplicates that transcript, but it generates a
>> yellow status on a 4.3.14 server:
>>
>> [smtp]
>>    expect "220"
>>    send "mail\r\n"
>>    expect "503"
>>    send "quit\r\n"
>>    expect "221"
>>    options banner
>>    port 25
>>
>> With the following config, I get a green status, but in fact I should
>> get red, because "220" is *not* in the response to the quit command:
>>
>> [smtp]
>>    send "mail\r\n"
>>    expect "503"
>>    send "quit\r\n"
>>    expect "220"
>>    options banner
>>    port 25
>>
>> Here's the bug, which might be two separate bugs:  The first group of
>> settings above should produce a green status, the second group of
>> settings should produce a red status.  In protocols.cfg, "expect" does
>> not work as expected.
>>
>> I've got no idea why the first case comes out as yellow.
>>
>> For the second case, the 'expect "220"' line is passing because of the
>> 220 in the initial banner from the server.  That line should fail.
>>
>
> You're right. I would expect that "expect" would only match once per
> entry. If you needed an "expect 220" at the beginning and another in
> response to your "quit", you should have to declare it twice. It seems
> the way expect is processing the data doesn't match reasonable
> assumptions.


As near as I can tell, this is the way things had always worked. It's not
really a full expect send-response syntax. Although 'send' handling is
performed while the connection is open (obviously), the 'expect'
evaluation seems to only be present at the end when decide_color is done.

The re-architecting of this, including having a full send-expect dialog is
something that Henrik had been working on in xymonnet2 (trunk).

To be honest, I'm a little curious how the multiple "send" lines are
actually being sent. I can see them being inserted into a list, but I
don't see anywhere that they're being rotated through line by line.


I'll see if there's any shortcut that can be performed here, but I don't
believe this will be that easy to fix with the current architecture. (We
would also probably need for enforce an alternating
send/expect/send/expect syntax in the config as a result.)


Regards,

-jc