What is Kermit?

125th Street and Broadway NYC


Kermit is a file transfer protocol first developed at Columbia University in New York City in 1981 for the specific purpose of transferring text and binary files without errors between diverse types of computers over potentially hostile communication links, and it is a suite of communications software programs from the Kermit Project at Columbia University. The Kermit protocol and software are named after Kermit the Frog, star of the television series, The Muppet Show; the name Kermit is used by permission of Henson Associates, Inc.

Over the years, the Kermit Project has grown into a worldwide cooperative nonprofit software development effort, headquartered at and coordinated from Columbia University. The Kermit Project is dedicated to production of cross-platform, long-lasting, standards-conformant, interoperable communications software, and is actively engaged in the standards process.

Since its inception in 1981, the Kermit protocol has developed into a sophisticated and powerful tool for file transfer and management, incorporating, among other things:


Kermit software has been written for hundreds of different computers and operating systems, some of it by volunteer programmers all over the world, some of it by the Kermit Project professional staff. The major features of the most popular Kermit programs are:

Kermit's user interface and script programming language are consistent across platforms and communication methods, allowing the investment in learning to pay off time and again as you move from one platform to another, one communication method to another.

Our premiere Kermit software implementations are:

  • Kermit 95 for Windows 95/98/ME, Windows NT/2000/XP, and OS/2;
  • C-Kermit for UNIX, VMS, VOS, AOS/VS, OS-9, and other operating systems;
  • MS-DOS Kermit for DOS and Windows 3.x;
  • IBM Mainframe Kermit for VM/CMS, MVS/TSO, and CICS.
  • Kermit 95 and MS-DOS Kermit are full-featured communication software programs rivaling the quality of anything else on the market. C-Kermit for UNIX, VMS, etc, and IBM Mainframe Kermit are host-based packages with an unequaled range of versatility. We document this software thoroughly and support and develop it aggressively. And unlike most other providers of communications software, we supply and can support the software for both ends of the connection.


    The feature that distinguishes Kermit protocol from most others is its wide range of settings to allow adaptation to any kind of connection between any two kinds of computers. Most other protocols are designed to work only on certain kinds or qualities of connections, and/or between certain kinds of computers, and therefore work poorly (or not at all) in other settings and offer few if any methods to adapt to unplanned-for situations. Kermit, on the other hand, allows you to achieve successful file transfer and the highest possible performance on any given connection.

    Unlike FTP or X-, Y-, and ZMODEM (the other protocols with which Kermit is most often compared) Kermit software does not assume or require:

    (although Kermit does not require any of these conditions, it can take advantage of them when they are available). A feature article on Kermit protocol by Tim Kientzle in the February 1996 issue of Dr. Dobb's Journal noted that "Kermit's windowing approach is faster than protocols such as XModem and YModem . . . What many people don't realize is that under less-than-ideal conditions, Kermit's windowing approach is significantly faster than ZModem, a protocol with a well-deserved reputation for fast transfers over good-quality lines."

    Thus Kermit transfers usually work "out of the box" almost every time.

    The Kermit file transfer protocol specification is given in the book, Kermit, A File Transfer Protocol.

    A formal specification and verification of the Kermit protocol was published by James Huggins of the University of Michigan in 1995.


    "Kermit is slow".

    Kermit originally was designed to operate under the worst conditions, and its robust default tuning was at the expense of speed. Thus there has been a widespread misconception that Kermit is a slow protocol. This misconception is bolstered by the fact that most Kermit implementations that do not come from the Kermit Project are, indeed, quite slow since they implement only the barest minimum (robust) subset of the protocol. Unfortunately, Kermit protocol itself is often judged by such implementations, as, for example in:

    or in well-known communications software such as Windows HyperTerminal. To illustrate, here are measurements of file-transfer throughput for Kermit 95 1.1.20 and HyperTerminal on the same Windows 95 PC, using the same built-in 56K Winmodem for a connection to the same host at the same phone number, with a serial port speed of 115200 BPS, transferring a (precompressed) ZIP file 108K in length with Kermit protocol

                    HyperTerminal              Kermit 95            
      Upload        227 CPS = 7.9 Minutes      2831 CPS = 36 Seconds
      Download      358 CPS = 5.0 Minutes      5121 CPS = 21 Seconds

    In both cases, C-Kermit 7.0 is on the other end, with all its default settings (the higher download speeds are a feature of 56K modem technology). Small wonder that people whose only experience with Kermit protocol is through products like HyperTerminal think Kermit is slow.

    Kermit's reputation also suffers from:

    In fact, Kermit protocol can be just as fast or faster than other popular protocols on any given connection, while retaining its superior error recovery and data conversion characteristics, as shown in:

    For further information about performance, see:

    Beginning in early 2000, the major Kermit software releases (Kermit 95, C-Kermit, MS-DOS Kermit) implement a new "streaming" form of the Kermit protocol that is negotiated automatically on reliable connections, such as a Telnet connection; in this case file-transfer speeds are about the same as FTP, and often faster, since Kermit adds compression.

    "Kermit Is a Relic of a Bygone Era".

    Since Web browsers have largely replaced terminal emulators among mass-market end users for online connections, many people believe that Kermit software is no longer used. In fact, Kermit software is more popular than ever, especially among computer professionals within organizations where diverse platforms and communication methods are used for demanding tasks such as network management, alpha and numeric paging, software distribution and patching, remote troubleshooting, setting up automated data transfer procedures, EDI, mobile applications, automated configurations of PBXs, routers, hubs, and terminal servers, and so forth, and as the bundled communications piece in numerous products including barcode readers, postal sorters, operating-room anesthesia monitors, fast-food cash registers, scientific instruments, networking equipment, program-driven milling and die-cutting machines, healthcare management systems, medical and pharmaceutical claim submission packages, inventory control systems, and car and auto-parts dealership packages.

    The software is fast, robust, and flexible, and the scripting language is powerful and easy to learn. Scripts are portable across platforms and communication methods. Even in a TCP/IP-only setting, modern Kermit software has distinct advantages:

    (*) The Internet Kermit Service, described in Internet RFCs 2839 and 2840, offers a flexible, high-function alternative to FTP service, now available for Unix (most varieties: Linux, Solaris, FreeBSD, AIX, HP-UX, etc) and Windows NT/2000/XP.

    Of course FTP is everywhere. Wouldn't it be great if all the features of Kermit -- scriptability, automatic text/binary mode switching, recursion, recovery, character-set conversion, etc -- were available in an FTP client? Now they are -- CLICK HERE for more information.

    "Kermit Is Too Complicated!"

    Kermit has been around for a long time. Features are added -- and rarely, if ever, removed -- as time goes on, so it seems to become increasingly complicated: more commands, more options, more syntax rules. Is that good or bad? Here's an excerpt from a recent FreeBSD newsgroup discussion:

    : >> What's a good, simple terminal emulator to use on my 4.0-RELEASE laptop
    : >> for serial /console connections to routers and switches?
    : >
    : >kermit wins here hands down!
    : I beg to differ. Consider minicom.
    : If you come from the dos world, you will feel at home with minicom, which
    : is modelled after Telix' user interface.
    : Also, it has the habit to do the right thing in quite a number of
    : situations (but don't press alt-b, when you're connected to your
    : company's sun server console :-)
    : If you need All bells and whistles, scripting, you name it, of course
    : kermit is the software of choice, but for simple task I found
    : it too awkward to get running most of the time. Too much set this
    : and configure that before it starts to do anything. No comfortable
    : dialer configuration, automatic phonebook and whatnot...
    Well, C-Kermit has all that too -- just not in "GUI" or curses form, so you have to put in a little effort to learn it.

    The tradeoff is as follows...

    Some tools like Minicom do just one thing (in the UNIX spirit). So to do that thing, you have to learn how to use that tool (Minicom in this case).

    But the thing that Minicom does is very similar to the things that Telnet and Rlogin do, except on different kinds of connections. So if you make network connections too, you also have to learn Telnet and/or Rlogin.

    But Kermit does both things: it makes both serial (direct or dialed) and network connections. But this means you have to tell it which thing to do ("set this, configure that"). The advantage is: everything else is the same on both kinds of connections, whereas it can be very different with the other packages (e.g. Rlogin quoting rules, Telnet escaping rules, sending BREAK, etc).

    Of course we can carry this further. Maybe you want to transfer files with the same computers you connect to with minicom, cu, tip, seyon, pcomm, telnet, or rlogin. For this you would need Zmodem, FTP, rcp, etc etc -- again, lots more programs and interfaces to learn. Or you can use Kermit to transfer files on all these kinds of connections, using just one interface -- the same one you were already using.

    Then maybe you're not an American, so you might need to have character sets translated on your connection -- telnet, rlogin, FTP, dialout, whatever. Here you're getting into deeper water. Where are the Telnet, Rlogin, FTP, and dialout clients that do this? I don't know. But Kermit does it. Plus it can also convert character sets of local files, just like iconv or recode (oops, more user interfaces to learn!).

    And on and on. Now, suppose you want to automate some complicated task, like dialing out, logging in, checking for some new files, downloading them if they are there, uploading some other files, etc. Maybe you could do this with some combination of shell scripts, expect, Perl, Tcl, cu, Zmodem, etc (more interfaces!), or you could do it with Kermit, using the same commands you already learned.

    Now suppose you want to do the same thing, but this time on a network connection. No worries: Just use the same script, but change a line or two to tell it to make a network connection instead of a dialout one. Everything else stays the same.

    Now suppose you want your network connection to be secure. For this you could use ssh, scp, ktelnet, srp-telnet, etc. Or you could use Kermit, which supports Kerberos IV, Kerberos V, SSL/TLS, and SRP security (and in some versions, also SSH).

    Now suppose your boss tells you to stop using FreeBSD (boo!) and move all your applications to some other operating system: Linux, AIX, Solaris, SCO, QNX, HP-UX, VMS, VOS, even Windows. No problem. Since Kermit is available for all those platforms, the same script runs on them too, and lots more; just change a line here and there to account for different file and device name formats.

    Now suppose you have all these wonderful scripts, dialing directories, and so forth, but then you have fly to another state and demo them there. Will they still work? After all, you're dialing from another area code. Again, no problem: Kermit takes care of all that. How about another country? Same thing. Kermit knows all about area codes, country codes, and dialing rules.

    These days I suppose Kermit is something like EMACS. You have to put some effort into learning it, but once you do, it can save you huge amounts of time and work from then on.


    "Why Isn't Kermit Free and Why Isn't it Part of Linux?"

    From a recent newsgroup discussion:

    On 25-Feb-2001 in one of the Linux newsgroups, somebody wrote, explaining why they did not use Kermit:
    But it still isn't free software.
    (Meaning: it does not have an Open-Source license such as GPL or BSD, permitting anybody to do whatever they want with it, including sell it.)

    So what? Lots of software isn't free. Everybody is happy to pay money for retail software and in return receive bugs, headaches, no documentation, no upgrades, and no technical support.

    C-Kermit is free to you if you want to use it. If you ask for technical support, you get it. C-Kermit is free to Linux packagers if they want to include it. But it's not free to people or companies who want to make money directly from it. Seems fair to me.

    The Kermit Project was giving software away before there was a GNU project or FSF, before there was a Linux or FreeBSD. We all grew out of the same environment -- university computer centers and CS departments in the early days of the ARPANET, where we were paid to develop software. We had secure jobs, so free software made sense. We all shared everything and it was fun. But those days are gone. Virtually nobody is paid to develop publicly available software in universities any more. The very foundation of the free software movement no longer exists. Now free software is developed by:

    This is all fine with me -- everybody should do what they please if it doesn't hurt anyone else. But it's not exactly a sound and stable system. Unpaid developers have little incentive to care about what their users want. And, with very few exceptions, the unpaid development model does not provide a career path except in the sense that if you become famous for some free creation, then you can get a high-paying job at an investment bank and disappear from the scene.

    The Kermit Project is one of the last surviving university-based nonprofit software development projects. We're here full-time to serve and help our users, year after year, decade after decade. The money has to come from somewhere, and believe me, we've tried every funding model. Sure, Kermit would be more popular if it was "free in the sense of freedom", but that would also kill it.

    In the end, I think doctrinaire insistence on license purity is kind of silly, if not disingenuous. If the software is free to you, then what do you care if it's not free to somebody else who wants to sell it? If you yourself want to sell it, why do you think you have the right to expropriate somebody else's labor for your own enrichment? If everybody thought that way, nobody would do any useful work and we'd all starve to death.

    Suppose your company had a commercial product of which Kermit was a critical component (as many do). Doesn't it make good sense to pay for it, thus assuring its survival and continued development, as well as giving you a voice in its future directions? Lots of companies think so. If they don't mind, why should you?

    The fact is, C-Kermit is highly functional, useful, modern, well-documented, aggressively developed and supported software that can be in Linux if you want it to be. As of C-Kermit 7.0, 1 January 2000, nothing is stopping Linux packagers from including it. They'll do it if their customers ask them to.

    More about Kermit licensing HERE and HERE. Note: G-Kermit is included with most Linux distributions because it has the GNU Public License (GPL); however, G-Kermit is strictly a remote-end file transfer program and does not include the communication, scripting, security, and other features of C-Kermit.

    - Frank da Cruz

    The nonprofit Kermit project is funded entirely by the income it generates: Kermit 95 sales and licenses, licensing of other Kermit programs for commercial redistribution, and book sales.


    Kermit Protocol / Columbia University / kermit@columbia.edu / 21 March 2002