flexfax: Re: PATCH: hfaxd 4.0pl1 fixes for WHFC "syntax error" bug

[Matthias.Apitz@SOFTCON.de]

Alan Sparks wrote:
    
    Been testing this fix out for a few days, and it seems to work well.  So
    here it is.
    
    This patch to hfaxd fixes the occurrence of the "500 '': Syntax error,
    expecting command token." error we've been fighting, using Hylafax 4.0pl1
    and WHFC 0.x.  This patch is applied by going to your hfaxd directory, and
    feeding the following (after "CUT HERE") to the "patch" utility.
    
    After watching the incoming stream from UNIX and NT clients, the problem
    seems to localize in the getCmdLine() function of Parser.c++.  While the
    command stream from UNIX clients appears continuous and unbroken, the
    Windows client stream is sporadic and broken (odd Gates-ian flow control?).
    Is broken flow triggers execution of the lines:
    
        if (c == EOF)
          return (FALSE);
    
    Hfaxd is then executing other code, then resuming the parse.  It
    unfortunately is not remembering where it left off with the partial input
    line, and is wiping it out.  This patch fixes this.
    
    Hope it works for you too.  Good luck.
    
    Alan Sparks, IS Engineering Support                   <asparks@harris.com>
    Harris Network Support Systems, Camarillo CA     (805) 389-2430
    
    <... patch info deleted ...>
    
Hi Alan,

thanks for digging into this problem. I'm a little bit unsure
to apply this patch for two reasons:
- it's one of the central places and it must work on *ALL* systems/OS;
- I can't reproduce the problem et all (I just run test with the TELNET
  command of Win-NT 4.0 and Win95 to the port 4559 of my UNIX SVR4.2
  server w/o any problem);

I've checked the source of hfaxd/Parser.c++ this morning in detail
and below is a snipp of getCmdLine() from hfaxd/Parser.c++. I
cut off the TELNET protocol commands handling to make the
main logic more clearer. As you can see the calls to
getChar() should block (wait) for more input *after* the first
successfull character was read because after the first
character cp is now != s (see also the example of your test in
the mail from 24/10/1997 where the char "u" was read successfull
but getChar() remains returning 0xffffffff - EOF).
It seems that on your SunOS and/or with the TCP/IP connection from
WHFC client the code in getChar() doesn't block and
wait for next characters but is returning EOF. Why?
I think we should digg into that question before changing the
code at a higher level.

There are also other questions to discuss/answer:
- Does the TELNET command client (you may start it from the
  DOS-prompt in NT or Win95) work or show the same problem?
- Could you please do a truss/strace of the system calls
  the hfaxd(1M) proc is doing while reading the socket (don't
  know if SunOS comes with such a tool)?
- Could you please run a tcpdump containing the buffers for this
  connection?
- Is SunOS the only affected system for this problem with WHFC
  (I'll also scan my mail folders for it)?

	matthias


hfaxd/Parser.c++:
/*
 * Return the next line of data received on the control
 * channel, ignoring any Telnet protocol command sequences.
 */
fxBool
HylaFAXServer::getCmdLine(char* s, int n, fxBool waitForInput)
{
    char* cp = s;
    cpos = 0;
    while (n > 1) {
        int c = getChar(cp != s || waitForInput);
        if (c == EOF)
            return (FALSE);
        if (c == IAC) {                 // telnet protocol command
            c = getChar(TRUE);
            .....
        }
        if (c == '\n') {
                .....
        }
        *cp++ = c, n--;
    }
    *cp = '\0';
    if (TRACE(PROTOCOL))
        logDebug("command: %s", s);
    return (TRUE);
}