Options to address the zmodem/kermit issue

Here is my take of what our options are, in order of increasing effort.

  1. Do nothing
  2. We neither attempt to fix the telnetd/zmodem interaction, nor increase our support for kermit.

    Impacts: Consulting continues to get questions about why rz isn't working. Users continue to favor zmodem because they don't know how to make kermit faster.

    Resources: An Athena consultant should put the rlogin workaround in the zmodem stock answer.

  3. Really support what we say we support
  4. We address the weaknesses of kermit, i.e. slowness of default configuration and inadequacy of the Mac interface.

    Impacts: Consulting continues to get questions about why rz isn't working. Users learn kermit.

    Resources: One dev person who knows how to configure kermit for speed needs to work with CSS to make sure this configuration is documented and made available in the modem locker.

    Someone needs to pick up the latest Macintosh kermit from Columbia, evaluate it, send feedback to the developers at Columbia, and document it for MIT.

  5. Bring in Omen to support zmodem
  6. We negotiate with Omen Technology, the owners of rz/sz, to get their Professional-YAM package, which may give better diagnostics. We then get more access to their technical expertise.

    Impacts: Eventually rz may work. Problem solved.

    Resources: Someone needs to negotiate a good price from Omen for a site license. Either that or we get one copy for someone to do the debugging work with.

    The person who calls in problem reports to Omen may need to be a developer.

  7. Support public-domain zmodem ourselves
  8. We take a public-domain implementation of the zmodem protocol, do the debugging ourselves, and continue to support it ad infinitum.

    Impacts: Initial work for developer. Additional ongoing maintenance project for dev group. Now rz works and is supported.

    Resources: A developer needs to run a packet sniffer on a successful rz session (rlogin) vs. an unsuccessful one in telnet. If we're lucky, this will shed some light on the problem and we find we can solve it in two full days effort. If we're not lucky, the debugging could take weeks.


Bruce R. Lewis / <brlewis@mit.edu>
$Date: 94/11/14 09:43:13 $