2 [1]The Columbia Crown The Kermit Project | Columbia University
3 612 West 115th Street, New York NY 10025 USA o [2]kermit@columbia.edu
5 [3]Home [4]Kermit 95 [5]C-Kermit [6]Scripts [7]Current [8]New [9]FAQ
8 C-Kermit Unix Hints and Tips
11 [11]The Kermit Project, [12]Columbia University
13 As of: C-Kermit 9.0.300 30 June 2011
14 This page last updated: Mon Jun 27 16:01:50 2011 (New York USA Time)
16 IF YOU ARE READING A PLAIN-TEXT version of this document, note it is
17 a plain-text dump of a Web page. You can visit the original (and
18 possibly more up-to-date) Web page here:
20 [13]http://www.columbia.edu/kermit/ckubwr.html
22 Since the material in this file has been accumulating since 1985,
23 some (much) of it might be dated. [14]Feedback from experts on
24 particular OS's and platforms is always welcome.
26 [ [15]C-Kermit ] [ [16]Installation Instructions ] [ [17]TUTORIAL ]
31 2. [19]PREBUILT C-KERMIT BINARIES
32 3. [20]PLATFORM-SPECIFIC NOTES
33 4. [21]GENERAL UNIX-SPECIFIC LIMITATIONS AND BUGS
34 5. [22]INITIALIZATION AND COMMAND FILES
35 6. [23]COMMUNICATION SPEED SELECTION
36 7. [24]COMMUNICATIONS AND DIALING
37 8. [25]HARDWARE FLOW CONTROL
38 9. [26]TERMINAL CONNECTION AND KEY MAPPING
40 11. [28]EXTERNAL FILE TRANSFER PROTOCOLS
42 13. [30]MISCELLANEOUS USER REPORTS
43 14. [31]THIRD-PARTY DRIVERS
45 Quick Links: [ [32]Linux ] [ [33]*BSD ] [[34]Mac OS X] [ [35]AIX ] [
46 [36]HP-UX ] [ [37]Solaris ] [ [38]SCO ] [ [39]DEC/Compaq ]
50 [ [40]Top ] [ [41]Contents ] [ [42]Next ]
54 1.1. [43]Documentation
55 1.2. [44]Technical Support
56 1.3. [45]The Year 2000
59 THIS IS WHAT USED TO BE CALLED the "beware file" for the Unix version
60 of C-Kermit, previously distributed as ckubwr.txt and, before that, as
61 ckuker.bwr, after the fashion of old Digital Equipment Corporation
62 (DEC) software releases that came with release notes (describing what
63 had changed) and a "beware file" listing known bugs, limitations,
64 "non-goals", and things to watch out for. The C-Kermit beware file has
65 been accumulating since 1985, and it applies to many different hardware
66 platforms and operating systems, and many versions of them, so it is
67 quite large. Prior to C-Kermit 8.0, it was distributed only in
68 plain-text format. Now it is available as a Web document with links,
69 internal cross references, and so on, to make it easier to use.
71 This document applies to Unix C-Kermit in general, as well as to
72 specific Unix variations like [47]Linux, [48]AIX, [49]HP-UX,
73 [50]Solaris, and so on, and should be read in conjunction with the
74 [51]platform-independent C-Kermit beware file, which contains similar
75 information, but applying to all versions of C-Kermit (VMS, Windows,
76 OS/2, AOS/VS, VOS, etc, as well as to Unix).
78 There is much in this document that is (only) of historical interest.
79 The navigation links should help you skip directly to the sections that
80 are relevant to you. Numerous offsite Web links are supposed to lead to
81 further information but, as you know, Web links go stale frequently and
82 without warning. If you can supply additional, corrected, updated, or
83 better Web links, please feel free to [52]let me know.
87 [ [53]Top ] [ [54]Contents ] [ [55]Next ]
89 C-Kermit 6.0 is documented in the book [56]Using C-Kermit, Second
90 Edition, by Frank da Cruz and Christine M. Gianone, Digital Press,
91 Burlington, MA, USA, ISBN 1-55558-164-1 (1997), 622 pages. This remains
92 the definitive C-Kermit documentation. Until the third edition is
93 published (sorry, there is no firm timeframe for this), please also
96 [57]Supplement to Using C-Kermit, Second Edition, For C-Kermit 7.0
97 Thorough documentation of features new to version 7.0.
99 [58]Supplement to Using C-Kermit, Second Edition, For C-Kermit 8.0
100 Thorough documentation of features new to version 8.0.
102 [59]Supplement to Using C-Kermit, Second Edition, For C-Kermit 9.0
103 Thorough documentation of features new to version 9.0.
105 1.2. Technical Support
107 [ [60]Top ] [ [61]Contents ] [ [62]Section Contents ] [ [63]Next ] [
110 For information on how to get technical support, please visit:
112 [65]http://www.columbia.edu/kermit/support.html
116 [ [66]Top ] [ [67]Contents ] [ [68]Section Contents ] [ [69]Next ] [
119 The Unix version of C-Kermit, release 6.0 and later, is "Year 2000
120 compliant", but only if the underlying operating system is too. Contact
121 your Unix operating system vendor to find out which operating system
122 versions, patches, hardware, and/or updates are required. (Quite a few
123 old Unixes are still in operation in the new millenium, but with their
124 date set 28 years in the past so at least the non-year parts of the
125 calendar are correct.)
127 As of C-Kermit 6.0 (6 September 1996), post-millenium file dates are
128 recognized, transmitted, received, and reproduced correctly during the
129 file transfer process in C-Kermit's File Attribute packets. If
130 post-millenium dates are not processed correctly on the other end, file
131 transfer still takes place, but the modification or creation date of
132 the received file might be incorrect. The only exception would be if
133 the "file collision update" feature is being used to prevent
134 unnecessary transfer of files that have not changed since the last time
135 a transfer took place; in this case, a file might be transferred
136 unnecessarily, or it might not be transferred when it should have been.
137 Correct operation of the update feature depends on both Kermit programs
138 having the correct date and time.
140 Of secondary importance are the time stamps in the transaction and/or
141 debug logs, and the date-related script programming constructs, such as
142 \v(date), \v(ndate), \v(day), \v(nday), and perhaps also the
143 time-related ones, \v(time) and \v(ntime), insofar as they might be
144 affected by the date. The \v(ndate) is a numeric-format date of the
145 form yyyymmdd, suitable for both lexical and numeric comparison and
146 sorting: e.g. 19970208 or 20011231. If the underlying operating system
147 returns the correct date information, these variables will have the
148 proper values. If not, then scripts that make decisions based on these
149 variables might not operate correctly.
151 Most date-related code is based upon the C Library asctime() string,
152 which always has a four-digit year. In Unix, the one bit of code in
153 C-Kermit that is an exception to this rule is several calls to
154 localtime(), which returns a pointer to a tm struct, in which the year
155 is presumed to be expressed as "years since 1900". The code depends on
156 this assumption. Any platforms that violate it will need special
157 coding. As of this writing, no such platforms are known.
159 Command and script programming functions that deal with dates use
160 C-Kermit specific code that always uses full years.
164 [ [71]Top ] [ [72]Contents ] [ [73]Section Contents ] [ [74]Previous ]
166 C-Kermit 7.0 and later support Unicode (ISO 10646), ISO 8859-15 Latin
167 Alphabet 9, PC Code Page 858, Windows Code Pages 1250 and 1251, and
168 perhaps other character sets, that encode the Euro symbol, and can
169 translate among them as long as no intermediate character-set is
170 involved that does not include the Euro.
172 2. PREBUILT C-KERMIT BINARIES
174 [ [75]Top ] [ [76]Contents ] [ [77]Next ] [ [78]Previous ]
176 It is often dangerous to run a binary C-Kermit (or any other) program
177 built on a different computer. Particularly if that computer had a
178 different C compiler, libraries, operating system version, processor
179 features, etc, and especially if the program was built with shared
180 libraries, because as soon as you update the libraries on your system,
181 they no longer match the ones referenced in the binary, and the binary
182 might refuse to load when you run it, in which case you'll see error
185 Could not load program kermit
186 Member shr4.o not found or file not an archive
187 Could not load library libcurses.a[shr4.o]
188 Error was: No such file or directory
190 (These samples are from AIX.) To avoid this problem, we try to build
191 C-Kermit with statically linked libraries whenever we can, but this is
192 increasingly impossible as shared libraries become the norm.
194 It is often OK to run a binary built on an earlier OS version, but it
195 is rarely possible (or safe) to run a binary built on a later one, for
196 example to run a binary built under Solaris 8 on Solaris 2.6. Sometimes
197 even the OS-or-library patch/ECO level makes a difference.
199 A particularly insidious problem occurs when a binary was built on a
200 version of the OS that has patches from the vendor (e.g. to libraries);
201 in many cases you won't be able to run such a binary on an unpatched
202 version of the same platform.
204 When in doubt, build C-Kermit from the source code on the computer
205 where it is to be run (if possible!). If not, ask us for a binary
206 specific to your configuration. We might have one, and if we don't, we
207 might be able to find somebody who will build one for you.
209 3. NOTES ON SPECIFIC UNIX VERSIONS
211 [ [79]Top ] [ [80]Contents ] [ [81]Next ] [ [82]Previous ]
215 3.0. [83]C-KERMIT ON PC-BASED UNIXES
216 3.1. [84]C-KERMIT AND AIX
217 3.2. [85]C-KERMIT AND HP-UX
218 3.3. [86]C-KERMIT AND LINUX
219 3.4. [87]C-KERMIT AND NEXTSTEP
220 3.5. [88]C-KERMIT AND QNX
221 3.6. [89]C-KERMIT AND SCO
222 3.7. [90]C-KERMIT AND SOLARIS
223 3.8. [91]C-KERMIT AND SUNOS
224 3.9. [92]C-KERMIT AND ULTRIX
225 3.10. [93]C-KERMIT AND UNIXWARE
226 3.11. [94]C-KERMIT AND APOLLO SR10
227 3.12. [95]C-KERMIT AND TANDY XENIX 3.0
228 3.13. [96]C-KERMIT AND OSF/1 (DIGITAL UNIX) (TRU64 UNIX)
229 3.14. [97]C-KERMIT AND SGI IRIX
230 3.15. [98]C-KERMIT AND THE BEBOX
231 3.16. [99]C-KERMIT AND DG/UX
232 3.17. [100]C-KERMIT AND SEQUENT DYNIX
233 3.18. [101]C-KERMIT AND {FREE,OPEN,NET}BSD
234 3.19. [102]C-KERMIT AND MAC OS X
235 3.20. [103]C-KERMIT AND COHERENT
237 The following sections apply to specific Unix versions. Most of them
238 contain references to FAQs (Frequently Asked Questions), but these tend
239 to be ephemeral. For possibly more current information see:
241 [104]http://www.faqs.org
242 [105]http://aplawrence.com/Unixart/newtounix.html
244 One thread that runs through many of them, and implicitly perhaps
245 through all, concerns the problems that occur when trying to dial out
246 on a serial device that is (also) enabled for dialing in. The
247 "solutions" to this problem are many, varied, diverse, and usually
248 gross, involving configuring the device for bidirectional use. This is
249 done in a highly OS-dependent and often obscure manner, and the effects
250 (good or evil) are also highly dependent on the particular OS (and
251 getty variety, etc). Many examples are given in the [106]OS-specific
254 An important point to keep in mind is that C-Kermit is a
255 cross-platform, portable software program. It was not designed
256 specifically and only for your particular Unix version, or for that
257 matter, for Unix in particular at all. It also runs on VMS, AOS/VS,
258 VOS, and other non-Unix platforms. All the Unix versions of C-Kermit
259 share common i/o modules, with compile-time #ifdef constructions used
260 to account for the differences among the many Unix products and
261 releases. If you think that C-Kermit is behaving badly or missing
262 something on your particular Unix version, you might be right -- we
263 can't claim to be expert in hundreds of different OS / version /
264 hardware / library combinations. If you're a programmer, take a look at
265 the source code and [107]send us your suggested fixes or changes. Or
266 else just [108]send us a report about what seems to be wrong and we'll
269 3.0. C-KERMIT ON PC-BASED UNIXES
271 [ [109]Top ] [ [110]Contents ] [ [111]Section Contents ] [ [112]Next ]
273 Also see: [113]http://www.pcunix.com/.
277 3.0.1. [114]Interrupt Conflicts
278 3.0.2. [115]Windows-Specific Hardware
280 3.0.4. [117]Character Sets
281 3.0.5. [118]Keyboard, Screen, and Mouse Access
284 3.0.1. Interrupt Conflicts
286 [ [120]Top ] [ [121]Contents ] [ [122]Section Contents ] [ [123]Next ]
288 PCs are not the best platform for real operating systems like Unix. The
289 architecture suffers from numerous deficiencies, not the least of which
290 is the stiflingly small number of hardware interrupts (either 7 or 15,
291 many of which are preallocated). Thus adding devices, using multiple
292 serial ports, etc, is always a challenge and often a nightmare. The
293 free-for-all nature of the PC market and the lack of standards combined
294 with the diversity of Unix OS versions make it difficult to find
295 drivers for any particular device on any particular version of Unix.
297 Of special interest to Kermit users is the fact that there is no
298 standard provision in the PC architecture for more than 2 communication
299 (serial) ports. COM3 and COM4 (or higher) will not work unless you (a)
300 find out the hardware address and interrupt for each, (b) find out how
301 to provide your Unix version with this information, and (c) actually
302 set up the configuration in the Unix startup files (or whatever other
303 method is used). Watch out for interrupt conflicts, especially when
304 using a serial mouse, and don't expect to be able to use more than two
307 The techniques for resolving interrupt conflicts are different for each
308 operating system (Linux, NetBSD, etc). In general, there is a
309 configuration file somewhere that lists COM ports, something like this:
311 com0 at isa? port 0x3f8 irq 4 # DOS COM1
312 com1 at isa? port 0x2f8 irq 3 # DOS COM2
314 The address and IRQ values in this file must agree with the values in
315 the PC BIOS and with the ports themselves, and there must not be more
316 than one device with the same interrupt. Unfortunately, due to the
317 small number of available interrupts, installing new devices on a PC
318 almost always creates a conflict. Here is a typical tale from a Linux
319 user (Fred Smith) about installing a third serial port:
321 ...problems can come from a number of causes. The one I fought with
322 for some time, and finally conquered, was that my modem is on an
323 add-in serial port, cua3/IRQ5. By default IRQ5 has a very low
324 priority, and does not get enough service in times when the system
325 is busy to prevent losing data. This in turn causes many resends.
326 There are two 'fixes' that I know of, one is to relax hard disk
327 interrupt hogging by using the correct parameter to hdparm, but I
328 don't like that one because the hdparm man page indicates it is
329 risky to use. The other one, the one I used, was to get 'irqtune'
330 and use it to give IRQ5 the highest priority instead of nearly the
331 lowest. Completely cured the problem.
333 Here's another one from a newsgroup posting:
335 After much hair pulling, I've discovered why my serial port won't
336 work. Apparently my [PC] has three serial devices (two comm ports
337 and an IR port), of which only two at a time can be active. I looked
338 in the BIOS setup and noticed that the IR port was activated, but
339 didn't realize at the time that this meant that COM2 was thereby
340 de-activated. I turned off the IR port and now the serial port works
343 3.0.2. Windows-Specific Hardware
345 [ [124]Top ] [ [125]Contents ] [ [126]Section Contents ] [ [127]Next ]
348 To complicate matters, the PC platform is becoming increasingly and
349 inexorably Windows-oriented. More and more add-on devices are "Windows
350 only" -- meaning they are incomplete and rely on proprietary
351 Windows-based software drivers to do the jobs that you would expect the
352 device itself to do. PCMCIA, PCI, or "Plug-n-Play" devices are rarely
353 supported on PC-based Unix versions such as SCO; Winmodems,
354 Winprinters, and the like are not supported on any Unix variety (with
355 [129]a few exceptions). The self-proclaimed Microsoft PC 97 (or later)
356 standard only makes matters worse since its only purpose to ensure that
357 PCs are "optimized to run Windows 95 and Windows NT 4.0 and future
358 versions of these operating systems".
360 With the exception noted (the Lucent modem, perhaps a handful of others
361 by the time you read this), drivers for "Win" devices are available
362 only for Windows, since the Windows market dwarfs that of any
363 particular Unix brand, and for that matter all Unixes (or for that
364 matter, all non-Windows operating systems) combined. If your version of
365 Unix (SCO, Linux, BSDI, FreeBSD, etc) does not support a particular
366 device, then C-Kermit can't use it either. C-Kermit, like any Unix
367 application, must access all devices through drivers and not directly
368 because Unix is a real operating system.
370 Don't waste time thinking that you, or anybody else, could write a
371 Linux (or other Unix) driver for a Winmodem or other "Win" device.
372 First of all, these devices generally require realtime control, but
373 since Unix is a true multitasking operating system, realtime device
374 control is not possible outside the kernel. Second, the specifications
375 for these devices are secret and proprietary, and each one (and each
376 version of each one) is potentially different. Third, a Winmodem driver
377 would be enormously complex; it would take years to write and debug, by
378 which time it would be obsolete.
380 A more recent generation of PCs (circa 1999-2000) is marketed as
381 "Legacy Free". One can only speculate what that could mean. Most likely
382 it means it will ONLY run the very latest versions of Windows, and is
383 made exclusively of Winmodems, Winprinters, Winmemory, and Win-CPU-fans
384 (Legacy Free is a concept [130]pioneered by Microsoft).
386 Before you buy a new PC or add-on equipment, especially serial ports,
387 internal modems, or printers, make sure they are compatible with your
388 version of Unix. This is becoming an ever-greater challenge; only a
389 huge company like Microsoft can afford to be constantly cranking out
390 and/or verifying drivers for the thousands of video boards, sound
391 cards, network adapters, SCSI adapters, buses, etc, that spew forth in
392 an uncontrolled manner from all corners of the world on a daily basis.
393 With very few exceptions, makers of PCs assemble the various components
394 and then verify them only with Windows, which they must do since they
395 are, no doubt, preloading the PC with Windows. To find a modern PC that
396 is capable of running a variety of non-Windows operating systems (e.g.
397 Linux, SCO OpenServer, Unixware, and Solaris) is a formidable challenge
398 requiring careful study of each vendor's "compatibility lists" and
399 precise attention to exact component model numbers and revision levels.
403 [ [131]Top ] [ [132]Contents ] [ [133]Section Contents ] [ [134]Next ]
406 External modems are recommended:
408 * They don't need any special drivers.
409 * You can use the lights and speaker to troubleshoot dialing.
410 * You can share them among all types of computers.
411 * You can easily turn them off and on when power-cycling seems
413 * They are more likely to have manuals.
415 Internal PC modems (even when they are not Winmodems, which is
416 increasingly unlikely in new PCs) are always trouble, especially in
417 Unix. Even when they work for dialing out, they might not work for
418 dialing in, etc. Problems that occur when using an internal modem can
419 almost always be eliminated by switching to an external one. Even when
420 an internal modem is not a Winmodem or Plug-n-Play, it is often a
421 no-name model of unknown quality -- not the sort of thing you want
422 sitting directly on your computer's bus. (Even if it does not cause
423 hardware problems, it probably came without a command list, so no Unix
424 software will know how to control it.) For more about Unix compatible
427 [136]http://www.idir.net/~gromitkc/winmodem.html
429 Remember that PCs, even now -- more than two decades after they were
430 first introduced -- are not (in general) capable of supporting more
431 than 2 serial devices. Here's a short success story from a recent
432 newsgroup posting: "I have a Diamond SupraSonic II dual modem in my
433 machine. What I had to end up doing is buying a PS/2 mouse and port and
434 install it. Had to get rid of my serial mouse. I also had to disable
435 PnP in my computer bios. I was having IRQ conflicts between my serial
436 mouse and 'com 3'. Both modems work fine for me. My first modem is
437 ttyS0 and my second is ttyS1." Special third-party multiport boards
438 such as [137]DigiBoard are available for certain Unix platforms
439 (typically SCO, maybe Linux) that come with special platform-specific
442 3.0.4. Character Sets
444 [ [138]Top ] [ [139]Contents ] [ [140]Section Contents ] [ [141]Next ]
447 PCs generally have PC code pages such as CP437 or CP850, and these are
448 often used by PC-based Unix operating systems, particularly on the
449 console. These are supported directly by C-Kermit's SET FILE
450 CHARACTER-SET and SET TERMINAL CHARACTER-SET commands. Some PC-based
451 Unix versions, such as recent Red Hat Linux releases, might also
452 support Microsoft Windows code pages such as CP1252, or even Latin
453 Alphabet 1 itself (perhaps displayed with CP437 glyphs). (And work is
454 in progress to support Unicode UTF8 in Linux.)
456 Certain Windows code pages are not supported directly by C-Kermit, but
457 since they are ISO Latin Alphabets with nonstandard "extensions" in the
458 C1 control range, you can substitute the corresponding Latin alphabet
459 (or other character set) in any C-Kermit character-set related
462 Windows Code Page Substitution
466 Other Windows code pages are mostly (or totally) incompatible with
467 their Latin Alphabet counterparts (e.g. CP1250 and Latin-2), and
468 several of these are already supported by C-Kermit 7.0 and later (1250,
471 3.0.5. Keyboard, Screen, and Mouse Access
473 [ [143]Top ] [ [144]Contents ] [ [145]Section Contents ] [ [146]Next ]
476 Finally, note that as a real operating system, Unix (unlike Windows)
477 does not provide the intimate connection to the PC keyboard, screen,
478 and mouse that you might expect. Unix applications can not "see" the
479 keyboard, and therefore can not be programmed to understand F-keys,
480 Editing keys, Arrow keys, Alt-key combinations, and the like. This is
483 a. Unix is a portable operating system, not only for PCs;
484 b. Unix sessions can come from anywhere, not just the PC's own
485 keyboard and screen; and:
486 c. even though it might be possible for an application that actually
487 is running on the PC's keyboard and screen to access these devices
488 directly, there are no APIs (outside of X) for this.
492 [ [148]Top ] [ [149]Contents ] [ [150]Section Contents ] [
495 (To be filled in . . .)
497 3.1. C-KERMIT AND AIX
499 [ [152]Top ] [ [153]Contents ] [ [154]Section Contents ] [ [155]Next ]
504 3.1.1. [157]AIX: General
505 3.1.2. [158]AIX: Network Connections
506 3.1.3. [159]AIX: Serial Connections
507 3.1.4. [160]AIX: File Transfer
508 3.1.5. [161]AIX: Xterm Key Map
510 For additional information see:
511 * [162]http://www.emerson.emory.edu/services/aix-faq/
512 * [163]http://www.faqs.org/faqs/by-newsgroup/comp/comp.unix.aix.html
513 * [164]http://www.cis.ohio-state.edu/hypertext/faq/usenet/aix-faq/top
515 * [165]http://aixpdslib.seas.ucla.edu/
516 * [166]http://www.rootvg.net (AIX history)
517 * [167]ftp://rtfm.mit.edu/pub/usenet/news.answers/aix-faq/part1
518 * [168]ftp://mirrors.aol.com/pub/rtfm/usenet-by-hierarchy/comp/unix/a
521 and/or read the [169]comp.unix.aix newsgroup.
522 ________________________________________________________________________
526 [ [170]Top ] [ [171]Contents ] [ [172]Section Contents ] [ [173]Next ]
528 About AIX version numbers: "uname -a" tells the two-digit version
529 number, such as 3.2 or 4.1. The three-digit form can be seen with the
530 "oslevel" command (this information is unavailable at the API level and
531 is reportedly obtained by scanning the installed patch list).
532 Supposedly all three-digit versions within the same two-digit version
533 (e.g. 4.3.1, 4.3.2) are binary compatible; i.e. a binary built on any
534 one of them should run on all others, but who knows. Most AIX advocates
535 tell you that any AIX binary will run on any AIX version greater than
536 or equal to the one under which it was built, but experience with
537 C-Kermit suggests otherwise. It is always best to run a binary built
538 under your exact same AIX version, down to the third decimal place, if
539 possible. Ideally, build it from source code yourself. Yes, this advice
540 would be easier to follow if AIX came with a C compiler.
541 ________________________________________________________________________
543 3.1.2. AIX: Network Connections
545 [ [174]Top ] [ [175]Contents ] [ [176]Section Contents ] [ [177]Next ]
548 File transfers into AIX 4.2 or 4.3 through the AIX Telnet or Rlogin
549 server have been observed to fail (or accumulate huge numbers of
550 correctable errors, or even disconnect the session), when exactly the
551 same kind of transfers into AIX 4.1 work without incident, as do such
552 transfers into all non-AIX platforms on the same kind of connections
553 (with a few exceptions noted elsewhere in this document). AIX 4.3.3
554 seems to be particularly fragile in this regard; the weakness seems to
555 be in its pseudoterminal (pty) driver. High-speed streaming transfers
556 work perfectly, however, if the AIX Telnet server and pty driver are
557 removed from the picture; e.g, by using "set host * 3000" on AIX.
559 The problem can be completely cured by replacing the IBM Telnet server
560 with [179]MIT's Kerberos Telnet server -- even if you don't actually
561 use the Kerberos part. Diagnosis: AIX pseudoterminals (which are
562 controlled by the Telnet server to give you a login terminal for your
563 session) have quirks that not even IBM knows about. The situation with
564 AIX 5.x is not known, but if it has the same problem, the same cure is
567 Meanwhile, the only remedy when going through the IBM Telnet server is
568 to cut back on Kermit's performance settings until you find a
569 combination that works:
572 * SET WINDOW-SIZE small-number
573 * SET { SEND, RECEIVE } PACKET-LENGTH small-number
574 * SET PREFIXING { CAUTIOUS, ALL }
576 In some cases, severe cutbacks are required, e.g. those implied by the
577 ROBUST command. Also be sure that the AIX C-Kermit on the remote end
578 has "set flow none" (which is the default). NOTE: Maybe this one can
579 also be addressed by starting AIX telnetd with the "-a" option. The
580 situation with SSH connections is not known, but almost certainly the
583 When these problems occur, the system error log contains:
594 EXCESSIVE LOAD ON PROCESSOR
598 REDUCE SERIAL PORT BAUD RATE
600 Before leaving the topic of AIX pseudoterminals, it is very likely that
601 Kermit's PTY and SSH commands do not work well either, for the same
602 reason that Telnet connections into AIX don't work well. A brief test
603 with "pty rlogin somehost" got a perfectly usable terminal (CONNECT)
604 session, but file-transfer problems like those just described.
606 Reportedly, telnet from AIX 4.1-point-something to non-Telnet ports
607 does not work unless the port number is in the /etc/services file; it's
608 not clear from the report whether this is a problem with AIX Telnet (in
609 which case it would not affect Kermit), or with the sockets library (in
610 which case it would). The purported fix is IBM APAR IX61523.
612 C-Kermit SET HOST or TELNET from one AIX 3.1 (or earlier) system to
613 another won't work right unless you set your local terminal type to
614 something other than AIXTERM. When your terminal type is AIXTERM, AIX
615 TELNET sends two escapes whenever you type one, and the AIX telnet
616 server swallows one of them. This has something to do with the "hft"
617 device. This behavior seems to be removed in AIX 3.2 and later.
618 ________________________________________________________________________
620 3.1.3. AIX: Serial Connections
622 [ [180]Top ] [ [181]Contents ] [ [182]Section Contents ] [ [183]Next ]
625 In AIX 3, 4, or 5, C-Kermit won't be able to "set line /dev/tty0" (or
626 any other dialout device) if you haven't installed "cu" or "uucp" on
627 your system, because installing these is what creates the UUCP lockfile
628 directory. If SET LINE commands always result in "Sorry, access to lock
629 denied", even when C-Kermit has been given the same owner, group, and
632 -r-sr-xr-x 1 uucp uucp 67216 Jul 27 1999 cu
634 and even when you run it as root, then you must go back and install
635 "cu" from your AIX installation media.
637 According to IBM's "From Strength to Strength" document (21 April
638 1998), in AIX 4.2 and later "Async supports speeds on native serial
639 ports up to 115.2kbps". However, no API is documented to achieve serial
640 speeds higher than 38400 bps. Apparently the way to do this -- which
641 might or might not work only on the IBM 128-port multiplexer -- is:
643 cxma-stty fastbaud /dev/tty0
645 which, according to "man cxma-stty":
647 fastbaud Alters the baud rate table, so 50 baud becomes 57600 baud.
648 -fastbaud Restores the baud rate table, so 57600 baud becomes 50
651 Presumably (but not certainly) this extrapolates to 110 "baud" becomes
652 76800 bps, and 150 becomes 115200 bps. So to use high serial speeds in
653 AIX 4.2 or 4.3, the trick would be to give the "cxma-stty fastbaud"
654 command for the desired tty device before starting Kermit, and then use
655 "set speed 50", "set speed 110", or "set speed 150" to select 56700,
656 76800, or 115200 bps. It is not known whether cxma-stty requires
659 According to one report, "Further investigation with IBM seems to
660 indicate that the only hardware capable of doing this is the 128-port
661 multiplexor with one (or more) of the 16 port breakout cables (Enhanced
662 Remote Async Node 16-Port EIA-232). We are looking at about CDN$4,000
663 in hardware just to hang a 56kb modem on there. Of course, we can then
664 hang 15 more, if we want. This hardware combo is described to be good
667 Another report says (quote from AIX newsgroup, March 1999):
669 The machine type and the adapter determine the speed that one can
670 actually run at. The older microchannel machines have much slower
671 crystal frequencies and may not go beyond 76,800. A feature put into
672 AIX 421 allows one to key in non-POSIX baud rates and if the uart
673 can support that speed, it will get set. this applies also to 43p's
674 and beyond. 115200 is the max for the 43P's native serial port. As
675 crytal frequencies continue to increase, the built-in serial ports
676 speeds will improve. To use 'uucp' or 'ate' at the higher baud
677 rates, configure the port for the desired speed, but set the speed
678 of uucp or ate to 50. Any non-POSIX speeds set in the ttys
679 configuration will the be used. In the case of the 128-port adapters
680 or the ISA 8-port or PCI 8-port adapter, there are only a few higher
683 a. Change the port to enable high baud rates:
688 b. chdev -l ttyX -a fastbaud=enable
689 + For the 128 ports original style rans, only 57600 bps is
691 + For the new enhanced RANs, up to 230Kbps is supported.
693 In AIX 2.2.1 on the RT PC with the 8-port multiplexer, SET SPEED 38400
694 gives 9600 bps, but SET SPEED 19200 gives 19200 (on the built-in S1
697 Note that some RS/6000s (e.g. the IBM PowerServer 320) have nonstandard
698 rectangular 10-pin serial ports; the DB-25 connector is NOT a serial
699 port; it is a parallel printer port. IBM cables are required for the
700 serial ports, (The IBM RT PC also had rectangular serial ports --
701 perhaps the same as these, perhaps different.)
703 If you dial in to AIX through a modem that is connected directly to an
704 AIX port (e.g. on the 128-port multiplexer) and find that data is lost,
705 especially when uploading files to the AIX system (and system error
706 logs report buffer overruns on the port):
708 1. Make sure the port and modem are BOTH configured for hardware
709 (RTS/CTS) flow control. The port is configured somewhere in the
710 system configuration, outside of Kermit.
711 2. Tell C-Kermit to "set flow keep"; experimentation shows that SET
712 FLOW RTS/CTS has no effect when used in remote mode (i.e. on
713 /dev/tty, as opposed to a specify port device).
714 3. Fixes for bugs in the original AIX 4.2 tty (serial i/o) support and
715 other AIX bugs are available from IBM at:
716 [185]http://service.software.ibm.com/rs6000/
718 Downloads -> Software Fixes -> Download FixDist gets an application
719 for looking up known problems.
721 Many problems reported with bidirectional terminal lines on AIX 3.2.x
722 on the RS/6000. Workaround: don't use bidirectional terminal lines, or
723 write a shell-script wrapper for Kermit that turns getty off on the
724 line before starting Kermit, or before Kermit attempts to do the SET
725 LINE. (But note: These problems MIGHT be fixed in C-Kermit 6.0 and
726 later.) The commands for turning getty off and on (respectively) are
727 /usr/sbin/pdisable and /usr/sbin/penable.
728 ________________________________________________________________________
730 3.1.4. AIX: File Transfer
732 [ [186]Top ] [ [187]Contents ] [ [188]Section Contents ] [ [189]Next ]
735 Evidently AIX 4.3 (I don't know about earlier versions) does not allow
736 open files to be overwritten. This can cause Kermit transfers to fail
737 when FILE COLLISION is OVERWRITE, where they might work on other Unix
738 varieties or earlier AIX versions.
740 Transfer of binary -- and maybe even text -- files can fail in AIX if
741 the AIX terminal has particular port can have character-set translation
742 done for it by the tty driver. The following advice from a
743 knowledgeable AIX user:
745 [This feature] has to be checked (and set/cleared) with a separate
746 command, unfortunately stty doesn't handle this. To check:
749 input map: none installed
750 output map: none installed
752 If it says anything other than "none installed" for either one, it
753 is likely to cause a problem with kermit. To get rid of installed
758 However, I seem to recall that with some versions of AIX before
759 3.2.5, only root could change the setting. I'm not sure what
760 versions - it might have only been under AIX 3.1 that this was true.
761 At least with AIX 3.2.5 an ordinary user can set or clear the maps.
763 On the same problem, another knowledgeable AIX user says:
765 The way to get information on the NLS mapping under AIX (3.2.5
766 anyway) is as follows. From the command line type:
768 lsattr -l tty# -a imap -a omap -E -H
770 Replace the tty number for the number sign above. This will give a
771 human readable output of the settings that looks like this;
773 # lsattr -l tty2 -a imap -a omap -E -H
774 attribute value description user_settable
776 imap none INPUT map file True
777 omap none OUTPUT map file True
779 If you change the -H to a -O, you get output that can easily be
780 processed by another program or a shell script, for example:
782 # lsattr -l tty2 -a imap -a omap -E -O
786 To change the settings from the command line, the chdev command is
787 used with the following syntax.
789 chdev -l tty# -a imap='none' -a omap='none'
791 Again substituting the appropriate tty port number for the number
792 sign, "none" being the value we want for C-Kermit. Of course, the
793 above can also be changed by using the SMIT utility and selecting
794 devices - tty. (...end quote)
796 In 2007 I noticed the following on high-speed SSH connections (local
797 network) into AIX 5.3: streaming transfers into AIX just don't work.
798 The same might be true for Telnet connections; I have no way to check.
799 It appears that the AIX pty driver and/or the SSH (and possibly Telnet)
800 server are not capable of receiving a steady stream of incoming data at
801 high speed. Solution: unknown. Workaround: put "set streaming off" in
802 your .kermrc or .mykermrc file, since streaming is the default for
804 ________________________________________________________________________
806 3.1.5. AIX: Xterm Key Map
808 [ [191]Top ] [ [192]Contents ] [ [193]Section Contents ] [
811 Here is a sample configuration for setting up an xterm keyboard for
812 VT220 or higher terminal emulation on AIX, courtesy of Bruce Momjian,
813 Drexel Hill, PA. Xterm can be started like this:
815 xterm $XTERMFLAGS +rw +sb +ls $@ -tm 'erase ^? intr ^c' -name vt220 \
816 -title vt220 -tn xterm-220 "$@" &
818 ---------------------------------------------------------------------------
819 XTerm*VT100.Translations: #override \n\
820 <Key>Home: string(0x1b) string("[3~") \n \
821 <Key>End: string(0x1b) string("[4~") \n
822 vt220*VT100.Translations: #override \n\
823 Shift <Key>F1: string("[23~") \n \
824 Shift <Key>F2: string("[24~") \n \
825 Shift <Key>F3: string("[25~") \n \
826 Shift <Key>F4: string("[26~") \n \
827 Shift <Key>F5: string("[K~") \n \
828 Shift <Key>F6: string("[31~") \n \
829 Shift <Key>F7: string("[31~") \n \
830 Shift <Key>F8: string("[32~") \n \
831 Shift <Key>F9: string("[33~") \n \
832 Shift <Key>F10: string("[34~") \n \
833 Shift <Key>F11: string("[28~") \n \
834 Shift <Key>F12: string("[29~") \n \
835 <Key>Print: string(0x1b) string("[32~") \n\
836 <Key>Cancel: string(0x1b) string("[33~") \n\
837 <Key>Pause: string(0x1b) string("[34~") \n\
838 <Key>Insert: string(0x1b) string("[2~") \n\
839 <Key>Delete: string(0x1b) string("[3~") \n\
840 <Key>Home: string(0x1b) string("[1~") \n\
841 <Key>End: string(0x1b) string("[4~") \n\
842 <Key>Prior: string(0x1b) string("[5~") \n\
843 <Key>Next: string(0x1b) string("[6~") \n\
844 <Key>BackSpace: string(0x7f) \n\
845 <Key>Num_Lock: string(0x1b) string("OP") \n\
846 <Key>KP_Divide: string(0x1b) string("Ol") \n\
847 <Key>KP_Multiply: string(0x1b) string("Om") \n\
848 <Key>KP_Subtract: string(0x1b) string("OS") \n\
849 <Key>KP_Add: string(0x1b) string("OM") \n\
850 <Key>KP_Enter: string(0x1b) string("OM") \n\
851 <Key>KP_Decimal: string(0x1b) string("On") \n\
852 <Key>KP_0: string(0x1b) string("Op") \n\
853 <Key>KP_1: string(0x1b) string("Oq") \n\
854 <Key>KP_2: string(0x1b) string("Or") \n\
855 <Key>KP_3: string(0x1b) string("Os") \n\
856 <Key>KP_4: string(0x1b) string("Ot") \n\
857 <Key>KP_5: string(0x1b) string("Ou") \n\
858 <Key>KP_6: string(0x1b) string("Ov") \n\
859 <Key>KP_7: string(0x1b) string("Ow") \n\
860 <Key>KP_8: string(0x1b) string("Ox") \n\
861 <Key>KP_9: string(0x1b) string("Oy") \n
863 ! <Key>Up: string(0x1b) string("[A") \n\
864 ! <Key>Down: string(0x1b) string("[B") \n\
865 ! <Key>Right: string(0x1b) string("[C") \n\
866 ! <Key>Left: string(0x1b) string("[D") \n\
874 3.2. C-KERMIT AND HP-UX
876 [ [195]Top ] [ [196]Contents ] [ [197]Section Contents ] [ [198]Next ]
881 3.2.0. [200]Common Problems
882 3.2.1. [201]Building C-Kermit on HP-UX
883 3.2.2. [202]File Transfer
884 3.2.3. [203]Dialing Out and UUCP Lockfiles in HP-UX
885 3.2.4. [204]Notes on Specific HP-UX Releases
886 3.2.5. [205]HP-UX and X.25
890 For further information, read the [206]comp.sys.hp.hpux newsgroup.
892 C-Kermit is included as part of the HP-UX operating system by contract
893 between Hewlett Packard and Columbia University for HP-UX 10.00 and
894 later. Each level of HP-UX includes a freshly built C-Kermit binary in
895 /bin/kermit, which should work correctly. Binaries built for regular
896 HP-UX may be used on Trusted HP-UX and vice-versa, except for use as
897 IKSD because of the different authentication methods.
899 Note that HP does not update C-Kermit versions for any but its most
900 current HP-UX release. So, for example, HP-UX 10.20 has C-Kermit 6.0;
901 11.00 has C-Kermit 7.0, and 11.22 has 8.0. Of course, as with all
902 software, older Kermit versions have bugs (such as buffer overflow
903 vulnerabilities) that are fixed in later versions. From time to time,
904 HP discovers one of these (long-ago fixed) bugs and issues a security
905 alert for the older OS's, recommending some draconian measure to avoid
906 the problem. The true fix in each situation is to install the current
909 3.2.0. Common Problems
911 [ [207]Top ] [ [208]Contents ] [ [209]Section Contents ] [ [210]Next ]
913 Some HP workstations have a BREAK/RESET key. If you hit this key while
914 C-Kermit is running, it might kill or suspend the C-Kermit process.
915 C-Kermit arms itself against these signals, but evidently the
916 BREAK/RESET key is -- at least in some circumstances, on certain HP-UX
917 versions -- too powerful to be caught. (Some report that the first
918 BREAK/RESET shows up as SIGINT and is caught by C-Kermit's former
919 SIGINT handler even when SIGINT is currently set to SIG_IGN; the second
920 kills Kermit; other reports suggest the first BREAK/RESET sends a
921 SIGTSTP (suspend signal) to Kermit, which it catches and suspends
922 itself. You can tell C-Kermit to ignore suspend signals with SET
923 SUSPEND OFF. You can tell C-Kermit to ignore SIGINT with SET COMMAND
924 INTERRUPTION OFF. It is not known whether these commands also grant
925 immunity to the BREAK/RESET key (one report states that with SET
926 SUSPEND OFF, the BREAK/RESET key is ignored the first four times, but
927 kills Kermit the 5th time). In any case:
929 1. If this key is mapped to SIGINT or SIGTSTP, C-Kermit catches or
930 ignores it, depending on which mode (CONNECT, command, etc) Kermit
932 2. If it causes HP-UX to kill C-Kermit, there is nothing C-Kermit can
935 When HP-UX is on the remote end of the connection, it is essential that
936 HP-UX C-Kermit be configured for Xon/Xoff flow control (this is the
937 default, but in case you change it and then experience file-transfer
938 failures, this is a likely reason).
940 3.2.1. Building C-Kermit on HP-UX
942 [ [211]Top ] [ [212]Contents ] [ [213]Section Contents ] [ [214]Next ]
945 This section applies mainly to old (pre-10.20) HP-UX version on old,
946 slow, and/or memory-constrained hardware.
948 During the C-Kermit 6.0 Beta cycle, something happened to ckcpro.w (or,
949 more precisely, the ckcpro.c file that is generated from it) which
950 causes HP optimizing compilers under HP-UX versions 7.0 and 8.0
951 (apparently on all platforms) as well as under HP-UX 9.0 on Motorola
952 platforms only, to blow up. In versions 7.0 and 8.0 the problem has
953 spread to other modules.
955 The symptoms vary from the system grinding to a halt, to the compiler
956 crashing, to the compilation of the ckcpro.c module taking very long
957 periods of time, like 9 hours. This problem is handled by compiling the
958 modules that tickle it without optimization; the new C-Kermit makefile
959 takes care of this, and shows how to do it in case the same thing
960 begins happening with other modules.
962 On HP-UX 9.0, a kernel parameter, maxdsiz (maximum process data segment
963 size), seems to be important. On Motorola systems, it is 16MB by
964 default, whereas on RISC systems the default is much bigger. Increasing
965 maxdsiz to about 80MB seems to make the problem go away, but only if
966 the system also has a lot of physical memory -- otherwise it swaps
969 The optimizing compiler might complain about "some optimizations
970 skipped" on certain modules, due to lack of space available to the
971 optimizer. You can increase the space (the incantation depends on the
972 particular compiler version -- see the [216]makefile), but doing so
973 tends to make the compilations take a much longer time. For example,
974 the "hpux0100o+" makefile target adds the "+Onolimit" compiler flag,
975 and about an hour to the compile time on an HP-9000/730. But it *does*
976 produce an executable that is about 10K smaller :-)
978 In the makefile, all HP-UX entries automatically skip optimization of
983 [ [217]Top ] [ [218]Contents ] [ [219]Section Contents ] [ [220]Next ]
986 Telnet connections into HP-UX versions up to and including 11.11 (and
987 possibly 11.20) tend not to lend themselves to file transfer due to
988 limitations, restrictions, and/or bugs in the HP-UX Telnet server
989 and/or pseudoterminal (pty) driver.
991 In C-Kermit 6.0 (1996) an unexpected slowness was noted when
992 transferring files over local Ethernet connections when an HP-UX system
993 (9.05 or 10.00) was on the remote end. The following experiment was
994 conducted to determine the cause. C-Kermit 6.0 was used; the situation
995 is slightly better using C-Kermit 7.0's streaming feature and HP-UX
996 10.20 on the far end.
998 The systems were HP-UX 10.00 (on 715/33) and SunOS 4.1.3 (on Sparc-20),
999 both on the same local 10Mbps Ethernet, packet length 4096, parity
1000 none, control prefixing "cautious", using only local disks on each
1001 machine -- no NFS. In the C-Kermit 6.0 (ACK/NAK) case, the window size
1002 was 20; in the streaming case there is no window size (i.e. it is
1003 infinite). The test file was C-Kermit executable, transferred in binary
1004 mode. Conditions were relatively poor: the Sun and the local net
1005 heavily loaded; the HP system is old, slow, and memory-constrained.
1007 C-Kermit 6.0... C-Kermit 7.0...
1008 Local Remote ACK/NAK........ Streaming......
1009 Client Server Send Receive Send Receive
1013 Sun Sun 60 60 153 158
1015 So whenever HP is the remote we have poor performance. Why?
1017 * Changing file display to CRT has no effect (so it's not the curses
1018 library on the client side).
1019 * Changing TCP RECV-BUFFER or SEND-BUFFER has little effect.
1020 * Telling the client to make a binary-mode connection (SET TELNET
1021 BINARY REQUESTED, which successfully negotiates a binary
1022 connection) has no effect on throughput.
1024 BUT... If I start HP-UX C-Kermit as a TCP service:
1029 and then from the client "set host xxx 3000", I get:
1031 C-Kermit 6.0... C-Kermit 7.0...
1032 Local Remote ACK/NAK........ Streaming......
1033 Client Server Send Receive Send Receive
1034 Sun HP 77 67 106 139
1036 HP Sun 57 85 155 105
1037 Sun Sun 57 50 321 314
1039 Therefore the HP-UX telnet server or pty driver seems to be adding more
1040 overhead than the SunOS one, and most others. When going through this
1041 type of connection (a remote telnet server) there is little Kermit can
1042 do improve matters, since the telnet server and pty driver are between
1043 the two Kermits, and neither Kermit program can have any influence over
1044 them (except putting the Telnet connection in binary mode, but that
1047 (The numbers for the HP-HP transfers are lower than the others since
1048 both Kermit processes are running on the same slow 33MHz CPU.)
1050 Matters seem to have deteriorated in HP-UX 11. Now file transfers over
1051 Telnet connections fail completely, rather than just being slow. In the
1052 following trial, a Telnet connection was made from Kermit 95 to HP-UX
1053 11.11 on an HP-9000/785/B2000 over local 10Mbps Ethernet running
1054 C-Kermit 8.00 in server mode (under the HP-UX Telnet server):
1056 Text........ Binary......
1057 Stream Pktlen GET SEND GET SEND
1058 On 4000 Fail Fail Fail Fail
1059 Off 4000 Fail Fail Fail Fail
1060 Off 2000 OK Fail OK Fail
1061 On 2000 OK Fail OK Fail
1062 On 3000 Fail Fail Fail Fail
1063 On 2500 Fail Fail Fail Fail
1064 On 2047 OK Fail OK Fail
1065 On 2045 OK Fail OK Fail
1067 On 500 OK Fail OK Fail
1068 On 240 OK Fail OK Fail
1070 As you can see, downloads are problematic unless the receiver's Kermit
1071 packet length is 2045 or less, but uploads work only with streaming
1072 disabled and the packet length restricted to 500. To force file
1073 transfers to work on this connection, the desktop Kermit must be told
1077 set receive packet-length 2000
1078 set send packet-length 500
1080 However, if a connection is made between the same two programs on the
1081 same two computers over the same network, but this time a direct
1082 socket-to-socket connection bypassing the HP-UX Telnet server and pty
1083 driver (tell HP-UX C-Kermit to "set host /server * 3000 /raw"; tell
1084 desktop client program to "set host blah 3000 /raw"), everything works
1085 perfectly with the default Kermit settings (streaming, 4K packets,
1086 liberal control-character unprefixing, 8-bit transparency, etc):
1088 Text........ Binary......
1089 Stream Pktlen GET SEND GET SEND
1092 And in this case, transfer rates were approximately 900,000 cps. To
1093 verify that the behavior reported here is not caused by the new Kermit
1094 release, the same experiment was performed on a Telnet connection from
1095 the same PC over the same network to the old 715/33 running HP-UX 10.20
1096 and C-Kermit 8.00. Text and binary uploads and downloads worked
1097 perfectly (albeit slowly) with all the default settings -- streaming,
1100 3.2.3. Dialing Out and UUCP Lockfiles in HP-UX
1102 [ [222]Top ] [ [223]Contents ] [ [224]Section Contents ] [ [225]Next ]
1105 HP workstations do not come with dialout devices configured; you have
1106 to do it yourself (as root). First look in /dev to see what's there;
1107 for example in HP-UX 10.00 or later:
1112 If you find a tty0p0 device but no cua0p0, you'll need to creat one if
1113 you want to dial out; the tty0p0 does not work for dialing out. It's
1114 easy: start SAM; in the main Sam window, double-click on Peripheral
1115 Device, then in the Peripheral Devices window, double-click on
1116 Terminals and Modems. In the Terminals and Modems dialog, click on
1117 Actions, then choose "Add modem" and fill in the blanks. For example:
1118 Port number 0, speed 57600 (higher speeds tend not to work reliably),
1119 "Use device for calling out", do NOT "Receive incoming calls" (unless
1120 you know what you are doing), leave "CCITT modem" unchecked unless you
1121 really have one, and do select "Use hardware flow control (RTS/CTS)".
1122 Then click OK. This creates cua0p0 as well as cul0p0 and ttyd0p0
1124 If the following sequence:
1126 set line /dev/cua0p0 ; or other device
1127 set speed 115200 ; or other normal speed
1129 produces the message "?Unsupported line speed". This means either that
1130 the port is not configured for dialout (go into SAM as described above
1131 and make sure "Use device for calling out" is selected), or else that
1132 speed you have given (such as 460800) is supported by the operating
1133 system but not by the physical device (in which case, use a lower speed
1136 In HP-UX 9.0, serial device names began to change. The older names
1137 looked like "/dev/cua00", "/dev/tty01", etc (sometimes with only one
1138 digit). The newer names have two digits with the letter "p" in between.
1139 HP-UX 8.xx and earlier have the older form, HP-UX 10.00 and later have
1140 the newer form. HP-UX 9.xx has the newer form on Series 800 machines,
1141 and the older form on other hardware models. The situation is
1142 summarized in the following table (the Convio 10.0 column applies to
1145 Converged HP-UX Serial I/O Filenames : TTY Mux Naming
1146 ---------------------------------------------------------------------
1147 General meaning Old Form S800 9.0 Convio 10.0
1148 ---------------------------------------------------------------------
1149 tty* hardwired ports tty<YY> tty<X>p<Y> tty<D>p<p>
1150 diag:mux<X> diag:mux<D>
1151 ---------------------------------------------------------------------
1152 ttyd* dial-in modems ttyd<YY> ttyd<X>p<Y> ttyd<D>p<p>
1153 diag:ttyd<X>p<Y> diag:ttyd<D>p<p>
1154 ---------------------------------------------------------------------
1155 cua* auto-dial out cua<YY> cua<X>p<Y> cua<D>p<p>
1157 ---------------------------------------------------------------------
1158 cul* dial-out cul<YY> cul<X>p<Y> cul<D>p<p>
1160 ---------------------------------------------------------------------
1161 <X>= LU (Logical Unit) <D>= Devspec (decimal card instance)
1162 <Y> or <YY> = Port <p>= Port
1164 For dialing out, you should use the cua or cul devices. When C-Kermit's
1165 CARRIER setting is AUTO or ON, C-Kermit should pop back to its prompt
1166 automatically if the carrier signal drops, e.g. when you log out from
1167 the remote computer or service. If you use the tty<D>p<d> (e.g. tty0p0)
1168 device, the carrier signal should be ignored. The tty<D>p<d> device
1169 should be used for direct connections where the carrier signal does not
1170 follow RS-232 conventions (use the cul device for hardwired connections
1171 through a true null modem). Do not use the ttyd<D>p<d> device for
1174 Kermit's access to serial devices is controlled by "UUCP lockfiles",
1175 which are intended to prevent different users using different software
1176 programs (Kermit, cu, etc, and UUCP itself) from accessing the same
1177 serial device at the same time. When a device is in use by a particular
1178 user, a file with a special name is created in:
1180 /var/spool/locks (HP-UX 10.00 and later)
1181 /usr/spool/uucp (HP-UX 9.xx and earlier)
1183 The file's name indicates the device that is in use, and its contents
1184 indicates the process ID (pid) of the process that is using the device.
1185 Since serial devices and the locks directory are not both publicly
1186 readable and writable, Kermit and other communication software must be
1187 installed setuid to the owner (bin) of the serial device and setgid to
1188 the group (daemon) of the /var/spool/locks directory. Kermit's setuid
1189 and setgid privileges are enabled only when opening the device and
1190 accessing the lockfiles.
1192 Let's say "unit" means a string of decimal digits (the interface
1193 instance number) followed (in HP-UX 10.00 and later) by the letter "p"
1194 (lowercase), followed by another string of decimal digits (the port
1195 number on the interface), e.g.:
1197 "0p0", "0p1", "1p0", etc (HP-UX 10.00 and later)
1198 "0p0", "0p1", "1p0", etc (HP-UX 9.xx on Series 800)
1199 "00", "01", "10", "0", etc (HP-UX 9.xx not on Series 800)
1200 "00", "01", "10", "0", etc (HP-UX 8.xx and earlier)
1202 Then a normal serial device (driver) name consists of a prefix ("tty",
1203 "ttyd", "cua", "cul", or possibly "cuad" or "culd") followed by a unit,
1204 e.g. "cua0p0". Kermit's treatment of UUCP lockfiles is as close as
1205 possible to that of the HP-UX "cu" program. Here is a table of the
1206 lockfiles that Kermit creates for unit 0p0:
1208 Selection Lockfile 1 Lockfile 2
1209 /dev/tty0p0 LCK..tty0p0 (none)
1210 * /dev/ttyd0p0 LCK..ttyd0p0 (none)
1211 /dev/cua0p0 LCK..cua0p0 LCK..ttyd0p0
1212 /dev/cul0p0 LCK..cul0p0 LCK..ttyd0p0
1213 /dev/cuad0p0 LCK..cuad0p0 LCK..ttyd0p0
1214 /dev/culd0p0 LCK..culd0p0 LCK..ttyd0p0
1215 <other> LCK..<other> (none)
1217 (* = Dialin device, should not be used.)
1219 In other words, if the device name begins with "cu", a second lockfile
1220 for the "ttyd" device, same unit, is created, which should prevent
1221 dialin access on that device.
1223 The <other> case allows for symbolic links, etc, but of course it is
1224 not foolproof since we have no way of telling which device is really
1227 When C-Kermit tries to open a dialout device whose name ends with a
1228 "unit", it searches the lockfile directory for all possible names for
1229 the same unit. For example, if user selects /dev/cul2p3, Kermit looks
1230 for lockfiles named:
1239 If any of these files are found, Kermit opens them to find out the ID
1240 (pid) of the process that created them; if the pid is still valid, the
1241 process is still active, and so the SET LINE command fails and the user
1242 is informed of the pid so s/he can use "ps" to find out who is using
1245 If the pid is not valid, the file is deleted. If all such files (i.e.
1246 with same "unit" designation) are successfully removed, then the SET
1247 LINE command succeeds; up to six messages are printed telling the user
1248 which "stale lockfiles" are being removed.
1250 When the "set line" command succeeds in HP-UX 10.00 and later, C-Kermit
1251 also creates a Unix System V R4 "advisory lock" as a further precaution
1252 (but not guarantee) against any other process obtaining access to the
1253 device while you are using it.
1255 If the selected device was in use by "cu", Kermit can't open it,
1256 because "cu" has changed its ownership, so we never get as far as
1257 looking at the lockfiles. In the normal case, we can't even look at the
1258 device to see who the owner is because it is visible only to its
1259 (present) owner. In this case, Kermit says (for example):
1261 /dev/cua0p0: Permission denied
1263 When Kermit releases a device it has successfully opened, it removes
1264 all the lockfiles that it created. This also happens whenever Kermit
1265 exits "under its own power".
1267 If Kermit is killed with a device open, the lockfile(s) are left
1268 behind. The next Kermit program that tries to assign the device, under
1269 any of its various names, will automatically clean up the stale
1270 lockfiles because the pids they contain are invalid. The behavior of cu
1271 and other communication programs under these conditions should be the
1274 Here, by the way, is a summary of the differences between the HP-UX
1275 port driver types from John Pezzano of HP:
1277 There are three types of device files for each port.
1279 The ttydXXX device file is designed to work as follows:
1281 1. The process that opens it does NOT get control of the port until CD
1282 is asserted. This was intentional (over 15 years ago) to allow
1283 getty to open the port but not control it until someone called in.
1284 If a process wants to use the direct or callout device files
1285 (ttyXXX and culXXX respectively), they will then get control and
1286 getty would be blocked. This eliminated the need to use uugetty
1287 (and its inherent problems with lock files) for modems. You can see
1288 this demonstrated by the fact that "ps -ef" shows a ? in the tty
1289 column for the getty process as getty does not have the port yet.
1290 2. Once CD is asserted, the port is controlled by getty (or the
1291 process handling an incoming call) if there was no process using
1292 the port. The ? in the "ps" command now shows the port. At this
1293 point, the port accepts data.
1295 Therefore you should use either the callout culXXX device file
1296 (immediate control but no data until CD is asserted) or the direct
1297 device file ttyXXX which gives immediate control and immediate data
1298 and which ignores by default modem control signals.
1300 The ttydXXX device should be used only for callin and my
1301 recommendation is to use it only for getty and uugetty.
1303 3.2.4 Notes on Specific HP-UX Releases
1307 3.2.4.1. [227]HP-UX 11
1308 3.2.4.2. [228]HP-UX 10
1309 3.2.4.3. [229]HP-UX 9
1310 3.2.4.4. [230]HP-UX 8
1311 3.2.4.5. [231]HP-UX 7 and Earlier
1315 [ [232]Top ] [ [233]Contents ] [ [234]Section Contents ] [ [235]Next ]
1317 As noted in [236]Section 3.2.2, the HP-UX 11 Telnet server and/or
1318 pseudoterminal driver are a serious impediment to file transfer over
1319 Telnet connections into HP-UX. If you have a Telnet connection into
1320 HP-UX 11, tell your desktop Kermit program to:
1323 set receive packet-length 2000
1324 set send packet-length 500
1326 File transfer speeds over connections from HP-UX 11 (dialed or Telnet)
1327 are not impeded whatsoever, and can go at whatever speed is allowed by
1328 the connection and the Kermit partner on the far end.
1330 PA-RISC binaries for HP-UX 10.20 or later should run on any PA-RISC
1331 system, S700 or S800, as long as the binary was not built under a later
1332 HP-UX version than the host operating system. HP-UX 11.00 and 11.11 are
1333 only for PA-RISC systems. HP-UX 11.20 is only for IA64 (subsequent
1334 HP-UX releases will be for both PA-RISC and IA64). To check binary
1335 compatibility, the following C-Kermit 8.0 binaries were run
1336 successfully on an HP-9000/785 with HP-UX 11.11:
1338 * Model 7xx HP-UX 10.20
1339 * Model 8xx HP-UX 10.20
1340 * Model 7xx HP-UX 11.00
1341 * Model 8xx HP-UX 11.00
1342 * Model 7xx HP-UX 11.11
1343 * Model 8xx HP-UX 11.11
1345 Binaries built under some of the earlier HP-UX releases, such as 9.05,
1346 might also work, but only if built for the same hardware family (e.g.
1351 [ [237]Top ] [ [238]Contents ] [ [239]Section Contents ] [ [240]Next ]
1354 Beginning in HP-UX 10.10, libcurses is linked to libxcurses, the new
1355 UNIX95 (X/Open) version of curses, which has some serious bugs; some
1356 routines, when called, would hang and never return, some would dump
1357 core. Evidently libxcurses contains a select() routine, and whenever
1358 C-Kermit calls what it thinks is the regular (sockets) select(), it
1359 gets the curses one, causing a segmentation fault. There is a patch for
1360 this from HP, PHCO_8086, "s700_800 10.10 libcurses patch", "shared lib
1361 curses program hangs on 10.10", "10.10 enhanced X/Open curses core
1362 dumps due to using wrong select call", 96/08/02 (you can tell if the
1363 patch is installed with "what /usr/lib/libxcurses.1"; the unpatched
1364 version is 76.20, the patched one is 76.20.1.2). It has been verified
1365 that C-Kermit works OK with the patched library, but results are not
1366 definite for HP-UX 10.20 or higher.
1368 To ensure that C-Kermit works even on non-patched HP-UX 10.10 systems,
1369 separate makefile entries are provided for HP-UX 10.00/10.01, 10.10,
1370 10.20, etc, in which the entries for 10.10 and above link with
1371 libHcurses, which is "HP curses", the one that was used in 10.00/10.01.
1372 HP-UX 11.20 and later, however, link with libcurses, as libHcurses
1373 disappeared in 11.20.
1377 [ [242]Top ] [ [243]Contents ] [ [244]Section Contents ] [ [245]Next ]
1380 HP-UX 9.00 and 9.01 need patch PHNE_10572 (note: this replaces
1381 PHNE_3641) for hptt0.o, asio0.o, and ttycomn.o in libhp-ux.a. Contact
1382 Hewlett Packard if you need this patch. Without it, the dialout device
1383 (tty) will be hung after first use; subsequent attempts to use will
1384 return an error like "device busy". (There are also equivalent patches
1385 for s700 9.03 9.05 9.07 (PHNE_10573) and s800 9.00 9.04 (PHNE_10416).
1387 When C-Kermit is in server mode, it might have trouble executing REMOTE
1388 HOST commands. This problem happens under HP-UX 9.00 (Motorola) and
1389 HP-UX 9.01 (RISC) IF the C-Shell is the login shell AND with the
1390 C-Shell Revision 70.15. Best thing is to install HP's Patch PHCO_4919
1391 for Series 300/400 and PHCO_5015 for the Series 700/800. PHCO_5015 is
1392 called "s700_800 9.X cumulative csh(1) patch with memory leak fix"
1393 which works for HP-UX 9.00, 9.01, 9.03, 9.04, 9.05 and 9.07. At least
1394 you need C-Shell Revision 72.12!
1396 C-Kermit works fine -- including its curses-based file-transfer display
1397 -- on the console terminal, in a remote session (e.g. when logged in to
1398 the HP 9000 on a terminal port or when telnetted or rlogin'd), and in
1399 an HP-VUE hpterm window or an xterm window.
1403 [ [247]Top ] [ [248]Contents ] [ [249]Section Contents ] [ [250]Next ]
1406 To make C-Kermit work on HP-UX 8.05 on a model 720, obtain and install
1407 HP-UX patch PHNE_0899. This patch deals with a lot of driver issues,
1408 particularly related to communication at higher speeds.
1412 On HP-UX 8 DON'T install 'tty patch' PHKL_4656, install PHKL_3047
1413 instead! Yesterday I tried this latest tty patch PHKL_4656 and had
1414 terrible problems. This patch should fix RTS/CTS problems. With text
1415 transver all looks nice. But when I switched over to binary files
1416 the serial interface returned only rubish to C-Kermit. All sorts of
1417 protocol, CRC and packed errors I had. After several tests and after
1418 uninstalling that patch, all transvers worked fine. MB's of data
1419 without any errors. So keep your fingers away from that patch. If
1420 anybody needs the PHKL_3047 patch I have it here. It is no longer
1421 availabel from HP's patch base.
1423 3.2.4.5. HP-UX 7 and Earlier
1425 [ [252]Top ] [ [253]Contents ] [ [254]Section Contents ] [
1428 When transferring files into HP-UX 5 or 6 over a Telnet connection, you
1429 must not use streaming, and you must not use a packet length greater
1430 than 512. However, you can use streaming and longer packets when
1431 sending files from HP-UX on a Telnet connection. In C-Kermit 8.0, the
1432 default receive packet length for HP-UX 5 and 6 was changed to 500 (but
1433 you can still increase it with SET RECEIVE PACKET-LENGTH if you wish,
1434 e.g. for non-Telnet connections). Disable streaming with SET STREAMING
1437 The HP-UX 5.00 version of C-Kermit does not include the fullscreen
1438 file-transfer because of problems with the curses library.
1440 If HP-UX 5.21 with Wollongong TCP/IP is on the remote end of a Telnet
1441 connection, streaming transfers to HP-UX invariably fail. Workaround:
1442 SET STREAMING OFF. Packets longer than about 1000 should not be used.
1443 Transfers from these systems, however, can use streaming and/or longer
1446 Reportedly, "[there is] a bug in C-Kermit using HP-UX version 5.21 on
1447 the HP-9000 series 500 computers. It only occurs when the controlling
1448 terminal is using an HP-27140 six-port modem mux. The problem is not
1449 present if the controlling terminal is logged into an HP-27130
1450 eight-port mux. The symptom is that just after dialing successfully and
1451 connecting Kermit locks up and the port is unusable until both forks of
1452 Kermit and the login shell are killed." (This report predates C-Kermit
1453 6.0 and might no longer apply.)
1455 3.2.5. HP-UX and X.25
1457 [ [256]Top ] [ [257]Contents ] [ [258]Section Contents ] [
1460 Although C-Kermit presently does not include built-in support for HP-UX
1461 X.25 (as it does for the Sun and IBM X.25 products), it can still be
1462 used to make X.25 connections as follows: start Kermit and then telnet
1463 to localhost. After logging back in, start padem as you would normally
1464 do to connect over X.25. Padem acts as a pipe between Kermit and X.25.
1465 In C-Kermit 7.0, you might also be able to avoid the "telnet localhost"
1468 C-Kermit> pty padem address
1470 This works if padem uses standard i/o (who knows?).
1472 3.3. C-KERMIT AND LINUX
1474 [ [260]Top ] [ [261]Contents ] [ [262]Section Contents ] [ [263]Next ]
1479 3.3.1. [265]Problems Building C-Kermit for Linux
1480 3.3.2. [266]Problems with Serial Devices in Linux
1481 3.3.3. [267]Terminal Emulation in Linux
1482 3.3.4. [268]Dates and Times
1483 3.3.5. [269]Startup Errors
1484 3.3.6. [270]The Fullscreen File Transfer Display
1486 (August 2010) Reportedly C-Kermit packages for certain Linux
1487 distributions such as Centos and Ubuntu have certain features
1488 disabled, for example the SSH command, SET HOST PTY /SSH, and
1489 perhaps anything else to do with SSH and/or pseudoterminals and who
1490 knows what else. If you download the regular package ("tarball")
1491 from the Kermit Project and build from it ("make linux"), everything
1494 C-Kermit in Ubuntu 10.04 and 9.10 was reported slow to start because
1495 it was trying to resolve the IP address 255.255.255.255. Later, also
1496 in recent Debian versions. The following is seen in the strace:
1498 write(3, "RESOLVE-ADDRESS 255.255.255.255\n", 32)
1500 This is not Kermit Project code. Turns out to be something in
1501 glibc's resolver, and can be fixed by changing /etc/nsswitch.conf,
1502 but it might break other software, such as [271]Avahi or anything
1503 (such as Gnome, Java, or Cups) that depends on it. I'm not sure
1504 where it happens; I don't think Kermit tries to get its IP address
1505 at startup time, only when it's needed or asked for, e.g. when
1506 making a connection or evaluating \v(ipaddress).
1510 For further information, read the [272]comp.os.linux.misc,
1511 [273]comp.os.linux.answers, and other Linux-oriented newsgroups, and
1514 The Linux Document Project (LDP)
1515 [274]http://www.tldp.org/
1518 [275]http://www.tldp.org/FAQ/Linux-FAQ.html
1520 The Linux HOWTOs (especially the Serial HOWTO)
1522 [276]http://www.tldp.org/HOWTO/Serial-HOWTO.html
1524 [277]http://tldp.org/HOWTO/Modem-HOWTO.html
1526 [278]ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO
1528 [279]ftp://tsx-11.mit.edu/pub/linux/docs/HOWTO
1530 [280]http://www.tldp.org/HOWTO/
1532 [281]http://www.tldp.org/hmirrors.html
1534 Linux Vendor Tech Support Pages:
1536 [282]http://www.redhat.com/apps/support/
1538 [283]http://www.debian.org/support
1540 [284]http://www.slackware.com/support/
1542 [285]http://www.caldera.com/support/
1544 [286]SUSE Linux Support
1546 [287]http://www.mandrake.com/support/
1548 [288]http://www.turbolinux.com/support/
1550 Linux Winmodem Support
1551 [289]http://www.linmodems.org/
1553 Also see general comments on PC-based Unixes in [290]Section 3.0.
1555 What Linux version is it? -- "uname -a" supplies only kernel
1556 information, but these days it's the distribution that matters: Red Hat
1557 7.3, Debian 2.2, Slackware 8.0, etc. Unfortunately there's no
1558 consistent way to get the distribution version. Usually it's in a
1559 distribution-specific file:
1561 Red Hat: /etc/issue or /etc/redhat-release
1562 Debian: /etc/debian_version
1563 Slackware: /etc/slackware-version (at least in later versions)
1565 Did you know: DECnet is available for Linux? See:
1567 [291]http://linux.dreamtime.org/decnet/
1569 (But there is no support for it in C-Kermit -- anybody interested in
1570 adding it, please [292]let me know).
1572 Before proceeding, let's handle the some of the most frequently asked
1573 question in the Linux newsgroups:
1575 1. Neither C-Kermit nor any other Linux application can use Winmodems,
1576 except in the [293]rare cases where Linux drivers have been written
1577 for them. See [294]Section 3.0.2 for details.
1578 2. "Why does it take such a long time to make a telnet connection to
1579 (or from) my Linux PC?" (this applies to C-Kermit and to regular
1580 Telnet). Most telnet servers these days perform reverse DNS lookups
1581 on the client (for security and/or logging reasons). If the Telnet
1582 client's address cannot be found by the server's local DNS server,
1583 the DNS request goes out to the Internet at large, and this can
1584 take quite some time. The solution to this problem is to make sure
1585 that both client and host are registered in DNS, and that the
1586 registrations are exported. C-Kermit itself performs reverse DNS
1587 lookups unless you tell it not to; this is to allow C-Kermit to let
1588 you know which host it is actually connected to in case you have
1589 made a connection to a host pool (multihomed host). You can disable
1590 C-Kermit's reverse DNS lookup with SET TCP REVERSE-DNS-LOOKUP OFF.
1591 3. (Any question that has the word "Telnet" in it...) The knee-jerk
1592 reaction is "don't use Telnet, use SSH!" There's nothing wrong with
1593 Telnet. In fact it's far superior to SSH as a protocol in terms of
1594 features and extensibility, not to mention platform neutrality. The
1595 issue lurking behind the knee-jerk reaction is security. SSH is
1596 thought to be secure, whereas Telnet is thought to be insecure.
1597 This is true for clear-text Telnet (because passwords travel in the
1598 clear across the network), but apparently few people realize that
1599 [295]secure Telnet clients and servers have been available for
1600 years, and these are more secure than SSH (for reasons explained
1602 4. (Any question that has the word "FTP" in it...) The knee-jerk
1603 reaction being "Don't use FTP, use SCP!" (or SFTP). Same answer as
1604 above, but moreso. SCP and SFTP are not only not platform neutral,
1605 they're diversity-hostile. They transfer files only in binary mode,
1606 which mangles text files across different platforms, to the same
1607 degree the platform's text-file record format and character set
1608 differ. An extreme example would be an Variable-Block format EBCDIC
1609 text file on an IBM mainframe, binary transfer of which to Unix
1610 would do you little good indeed. FTP was designed with diversity in
1611 mind and secure versions are available.
1613 3.3.1. Problems Building C-Kermit for Linux
1615 [ [297]Top ] [ [298]Contents ] [ [299]Section Contents ] [ [300]Next ]
1617 Modern Linux distributions like Red Hat give you a choice at
1618 installation whether to include "developer tools". Obviously, you can't
1619 build C-Kermit or any other C program from source code if you have not
1620 installed the developer tools. But to confuse matters, you might also
1621 have to choose (separately) to install the "curses" or "ncurses"
1622 terminal control library; thus it is possible to install the C compiler
1623 and linker, but omit the (n)curses library and headers. If curses is
1624 not installed, you will not be able to build a version of C-Kermit that
1625 supports the fullscreen file-transfer display, in which case you'll
1626 need to use the "linuxnc" makefile target (nc = No Curses) or else
1627 install ncurses before building.
1629 There are all sorts of confusing issues caused by the many and varied
1630 Linux distributions. Some of the worst involve the curses library and
1631 header files: where are they, what are they called, which ones are they
1632 really? Other vexing questions involve libc5 vs libc6 vs glibc vs
1633 glibc2 (C libraries), gcc vs egcs vs lcc (compilers), plus using or
1634 avoiding features that were added in a certain version of Linux or a
1635 library or a distribution, and are not available in others. As of
1636 C-Kermit 8.0, these questions should be resolved by the "linux"
1637 makefile target itself, which does a bit of looking around to see
1638 what's what, and then sets the appropriate CFLAGS.
1640 3.3.2. Problems with Serial Devices in Linux
1642 [ [301]Top ] [ [302]Contents ] [ [303]Section Contents ] [ [304]Next ]
1645 Also see: "man setserial", "man irqtune".
1646 And: [306]Sections 3.0, [307]6, [308]7, and [309]8 of this document.
1648 NOTE: Red Hat Linux 7.2 and later include a new API that allows
1649 serial-port arbitration by non-setuid/gid programs. This API has not
1650 yet been added to C-Kermit. If C-Kermit is to be used for dialing
1651 out on Red Hat 7.2 or later, it must still be installed as described
1652 in in Sections [310]10 and [311]11 of the [312]Installation
1655 Don't expect it to be easy. Queries like the following are posted to
1656 the Linux newsgroups almost daily:
1658 Problem of a major kind with my Compaq Presario 1805 in the sense
1659 that the pnpdump doesn't find the modem and the configuration tells
1660 me that the modem is busy when I set everything by hand!
1662 I have <some recent SuSE distribution>, kernel 2.0.35. Using the
1663 Compaq tells me that the modem (which is internal) is on COM2, with
1664 the usual IRQ and port numbers. Running various Windows diagnostics
1665 show me AT-style commands exchanged so I have no reason to beleive
1666 that it is a Winmodem. Also, the diagnostics under Win98 tell me
1667 that I am talking to an NS 16550AN.
1669 [Editor's note: This does not necessarily mean it isn't a Winmodem.]
1671 Under Linux, no joy trying to talk to the modem on /dev/cua1 whether
1672 via minicom, kppp, or chat; kppp at least tells me that tcgetattr()
1677 setserial /dev/cua1 port 0x2F8 irq 3 autoconfig
1678 setserial -g /dev/cua1
1680 tells me that the uart is 'unknown'. I have tried setting the UART
1681 manullay via. setserial to 16550A, 16550, and the other one (8550?)
1682 (I didn't try 16540). None of these manual settings resulted in any
1685 A look at past articles leads me to investigate PNP issues by
1686 calling pnpdump but pnpdump returns "no boards found". I have looked
1687 around on my BIOS (Phoenix) and there is not much evidence of it
1688 being PNP aware. However for what it calls "Serial port A", it
1689 offers a choice of Auto, Disabled or Manual settings (currently set
1690 to Auto), but using the BIOS interface I tried to change to 'manual'
1691 and saw the default settings offered to be were 0x3F8 and IRQ 4
1692 (COM1). The BIOS menus did not give me any chance to configure COM2
1693 or any "modem". I ended up not saving any BIOS changes in the course
1694 of my investigations.
1696 You can also find out a fair amount about your PC's hardware
1697 configuration in the text files in /proc, e.g.:
1699 -r--r--r-- 1 root 0 Sep 4 14:00 /proc/devices
1700 -r--r--r-- 1 root 0 Sep 4 14:00 /proc/interrupts
1701 -r--r--r-- 1 root 0 Sep 4 14:00 /proc/ioports
1702 -r--r--r-- 1 root 0 Sep 4 14:00 /proc/pci
1704 From the directory listing they look like empty files, but in fact they
1705 are text files that you "cat":
1708 Bus 0, device 14, function 0:
1709 Serial controller: US Robotics/3Com 56K FaxModem Model 5610 (rev 1).
1711 I/O at 0x1050 [0x1057].
1713 $ setserial -g /dev/ttyS4
1714 /dev/ttyS4, UART: 16550A, Port: 0x1050, IRQ: 10
1717 1050-1057 : US Robotics/3Com 56K FaxModem Model 5610
1718 1050-1057 : serial(auto)
1720 $ cat /proc/interrupts
1722 0: 7037515 XT-PIC timer
1723 1: 2 XT-PIC keyboard
1727 9: 209811 XT-PIC usb-uhci, eth0
1728 14: 282015 XT-PIC ide0
1731 Watch out for PCI, PCMCIA and Plug-n-Play devices, Winmodems, and the
1732 like (see cautions in [313]Section 3.0 Linux supports Plug-n-Play
1733 devices to some degree via the isapnp and pnpdump programs; read the
1734 man pages for them. (If you don't have them, look on your installation
1735 CD for isapnptool or download it from sunsite or a sunsite mirror or
1736 other politically correct location du jour).
1738 PCI modems do not use standard COM port addresses. The I/O address and
1739 IRQ are assigned by the BIOS. All you need to do to get one working,
1740 find out the I/O address and interrupt number with (as root) "lspci -v
1741 | more" and then give the resulting address and interrupt number to
1744 Even when you have a real serial port, always be wary of interrupt
1745 conflicts and similar PC hardware configuration issues: a PC is not a
1746 real computer like other Unix workstations -- it is generally pieced
1747 together from whatever random components were the best bargain on the
1748 commodity market the week it was built. Once it's assembled and boxed,
1749 not even the manufacturer will remember what it's made of or how it was
1750 put together because they've moved on to a new model. Their job is to
1751 get it (barely) working with Windows; for Linux and other OS's you are
1754 "set line /dev/modem" or "set line /dev/ttyS2", etc, results in an
1755 error, "/dev/modem is not a tty". Cause unknown, but obviously a driver
1756 issue, not a Kermit one (Kermit uses "isatty()" to check that the
1757 device is a tty, so it knows it will be able to issue all the
1758 tty-related ioctl's on it, like setting the speed & flow control). Try
1759 a different name (i.e. driver) for the same port, e.g. "set line
1760 /dev/cua2" or whatever.
1762 To find what serial ports were registered at the most recent system
1763 boot, type (as root): "grep tty /var/log/dmesg".
1765 "set modem type xxx" (where xxx is the name of a modem) followed by
1766 "set line /dev/modem" or "set
1767 line /dev/ttyS2", etc, hangs (but can be interrupted with Ctrl-C).
1768 Experimentation shows that if the modem is configured to always assert
1769 carrier (&C0) the same command does not hang. Again, a driver issue.
1770 Use /dev/cua2 (or whatever) instead. (Or not -- hopefully none of these
1771 symptoms occurs in C-Kermit 7.0 or later.)
1773 "set line /dev/cua0" reports "Device is busy", but "set line
1774 /dev/ttyS0" works OK.
1776 In short: If the cua device doesn't work, try the corresponding ttyS
1777 device. If the ttyS device doesn't work, try the corresponding cua
1778 device -- but note that Linux developers do not recommend this, and are
1779 phasing out the cua devices. From /usr/doc/faq/howto/Serial-HOWTO:
1781 12.4. What's The Real Difference Between the /dev/cuaN And /dev/ttySN
1783 The only difference is the way that the devices are opened. The
1784 dialin devices /dev/ttySN are opened in blocking mode, until CD
1785 is asserted (ie someone connects). So, when someone wants to use
1786 the /dev/cuaN device, there is no conflict with a program
1787 watching the /dev/ttySN device (unless someone is connected of
1788 course). The multiple /dev entries, allow operation of the same
1789 physical device with different operating characteristics. It
1790 also allows standard getty programs to coexist with any other
1791 serial program, without the getty being retrofitted with locking
1792 of some sort. It's especially useful since standard Unix kernel
1793 file locking, and UUCP locking are both advisory and not
1796 It was discovered during development of C-Kermit 7.0 that rebuilding
1797 C-Kermit with -DNOCOTFMC (No Close/Open To Force Mode Change) made the
1798 aforementioned problem with /dev/ttyS0 go away. It is not yet clear,
1799 however, what its affect might be on the /dev/cua* devices. As of 19
1800 March 1998, this option has been added to the CFLAGS in the makefile
1801 entries for Linux ("make linux").
1803 Note that the cua device is now "deprecated", and new editions of Linux
1804 will phase (have phased) it out in favor of the ttyS device. See (if
1807 [314]http://linuxwww.db.erau.edu/mail_archives/linux-kernel/Mar_98/1441.html
1809 (no, of course it isn't; you'll have to use your imagination). One user
1810 reported that C-Kermit 7.0, when built with egcs 1.1.2 and run on Linux
1811 2.2.6 with glibc 2.1 (hardware unknown but probably a PC) dumps core
1812 when given a "set line /dev/ttyS1" command. When rebuilt with gcc, it
1815 All versions of Linux seem to have the following deficiency: When a
1816 modem call is hung up and CD drops, Kermit can no longer read the modem
1817 signals; SHOW COMMUNICATIONS says "Modem signals not available". The
1818 TIOCMGET ioctl() returns -1 with errno 5 ("I/O Error").
1820 The Linux version of POSIX tcsendbreak(), which is used by C-Kermit to
1821 send regular (275msec) and long (1.5sec) BREAK signals, appears to
1822 ignore its argument (despite its description in the man page and info
1823 topic), and always sends a regular 275msec BREAK. This has been
1824 observed in Linux versions ranging from Debian 2.1 to Red Hat 7.1.
1826 3.3.3. Terminal Emulation in Linux
1828 [ [315]Top ] [ [316]Contents ] [ [317]Section Contents ] [ [318]Next ]
1831 C-Kermit is not a terminal emulator. For a brief explanation of why
1832 not, see [320]Section 3.0.5. For a fuller explanation, [321]ClICK HERE.
1834 In Unix, terminal emulation is supplied by the Window in which you run
1835 Kermit: the regular console screen, which provides Linux Console
1836 "emulation" via the "console" termcap entry, or under X-Windows in an
1837 xterm window, which gives VTxxx emulation. An xterm that includes color
1838 ANSI and VT220 emulation is available with Xfree86:
1840 [322]http://dickey.his.com/xterm/xterm.html
1842 Before starting C-Kermit in an xterm window, you might need to tell the
1843 xterm window's shell to "stty sane".
1845 To set up your PC console keyboard to send VT220 key sequences when
1846 using C-Kermit as your communications program in an X terminal window
1847 (if it doesn't already), create a file somewhere (e.g. in /root/)
1848 called .xmodmaprc, containing something like the following:
1850 keycode 77 = KP_F1 ! Num Lock => DEC Gold (PF1)
1851 keycode 112 = KP_F2 ! Keypad / => DEC PF1
1852 keycode 63 = KP_F3 ! Keypad * => DEC PF3
1853 keycode 82 = KP_F4 ! Keypad - => DEC PF4
1854 keycode 111 = Help ! Print Screen => DEC Help
1855 keycode 78 = F16 ! Scroll Lock => DEC Do
1856 keycode 110 = F16 ! Pause => DEC Do
1857 keycode 106 = Find ! Insert => DEC Find
1858 keycode 97 = Insert ! Home => DEC Insert
1859 keycode 99 = 0x1000ff00 ! Page Up => DEC Remove
1860 keycode 107 = Select ! Delete => DEC Select
1861 keycode 103 = Page_Up ! End => DEC Prev Screen
1862 keycode 22 = Delete ! Backspace sends Delete (127)
1864 Then put "xmodmap filename" in your .xinitrc file (in your login
1867 xmodmap /root/.xmodmaprc
1869 Of course you can move things around. Use the xev program to find out
1872 Console-mode keys are mapped separately using loadkeys, and different
1873 keycodes are used. Find out what they are with showkey.
1875 For a much more complete VT220/320 key mapping for [323]Xfree86 xterm,
1878 3.3.4. Dates and Times
1880 [ [325]Top ] [ [326]Contents ] [ [327]Section Contents ] [ [328]Next ]
1883 If C-Kermit's date-time (e.g. as shown by its DATE command) differs
1884 from the system's date and time:
1886 a. Make sure the libc to which Kermit is linked is set to GMT or is
1887 not set to any time zone. Watch out for mixed libc5/libc6 systems;
1888 each must be set indpendently.
1889 b. If you have changed your TZ environment variable, make sure it is
1890 exported. This is normally done in /etc/profile or /etc/TZ.
1892 3.3.5. Startup Errors
1894 [ [330]Top ] [ [331]Contents ] [ [332]Section Contents ] [ [333]Next ]
1897 C-Kermit should work on all versions of Linux current through March
1898 2003, provided it was built on the same version you have, with the same
1899 libraries and header files (just get the source code and "make linux").
1900 Binaries tend not to travel well from one Linux machine to another, due
1901 to their many differences. There is no guarantee that a particular
1902 C-Kermit binary will not stop working at a later date, since Linux
1903 tends to change out from under its applications. If that happens,
1904 rebuild C-Kermit from source. If something goes wrong with the build
1905 process, look on the [335]C-Kermit website for a newer version. If you
1906 have the latest version, then [336]report the problem to us.
1908 Inability to transfer files in Red Hat 7.2: the typical symptom would
1909 be if you start Kermit and tell it to RECEIVE, it fails right away with
1910 "?/dev/tty: No such device or address" or "?Bad file descriptor". One
1911 report says this is because of csh, and if you change your shell to
1912 bash or other shell, it doesn't happen. Another report cite bugs in Red
1913 Hat 7.2 Telnetd "very seldom (if ever) providing a controlling tty, and
1914 lots of other people piled on saying they have the same problem.") A
1915 third theory is that this happens only when Linux has been installed
1916 without "virtual terminal support".
1918 A search of RedHat's errata pages shows a bug advisory (RHBA-2001-153)
1919 issued 13 November 2001, but updated 6 December, about this same
1920 symptom (but with tcsh and login.) Seems that login was not always
1921 assigning a controlling TTY for the session, which would make most use
1922 of "/dev/tty" somewhat less than useful.
1924 [337]http://www.redhat.com/support/errata/RHBA-2001-153.html
1926 Quoting: "Due to terminal handling problems in /bin/login, tcsh would
1927 not find the controlling terminal correctly, and a shell in single user
1928 mode would exhibit strange terminal input characteristics. This update
1929 fixes both of these problems."
1931 Since the Red Hat 5.1 release (circa August 1998), there have been
1932 numerous reports of prebuilt Linux executables, and particularly the
1933 Kermit RPM for Red Hat Linux, not working; either it won't start at
1934 all, or it gives error messages about "terminal type unknown" and
1935 refuses to initialize its curses support. The following is from the
1936 [338]Kermit newsgroup:
1938 From: rchandra@hal9000.buf.servtech.com
1939 Newsgroups: comp.protocols.kermit.misc
1940 Subject: Red Hat Linux/Intel 5.1 and ncurses: suggestions
1941 Date: 22 Aug 1998 15:54:46 GMT
1942 Organization: Verio New York
1943 Keywords: RedHat RPM 5.1
1945 Several factors can influence whether "linux" is recognized as a
1946 terminal type on many Linux systems.
1948 1. Your program, or the libraries it linked with (if statically
1949 linked), or the libraries it dynamically links with at runtime, are
1950 looking for an entry in /etc/termcap that isn't there. (not likely,
1951 but possible... I believe but am not certain that this is a very
1952 old practice in very old [n]curses library implementations to use a
1953 single file for all terminal descriptions.)
1954 2. Your program, or the libraries...are looking for a terminfo file
1955 that just plain isn't there. (also not so likely, since many people
1956 in other recent message threads said that other programs work OK).
1957 3. Your program, or the libraries...are looking for a terminfo file
1958 that is stored at a pathname that isn't expected by your program,
1959 the libraries--and so on. I forgot if I read this in the errata Web
1960 page or where exactly I discovered this (Netscape install? Acrobat
1961 install?), but it may just be that one libc (let's say for sake of
1962 argument, libc5, but I don't know this to be true) expects your
1963 terminfo to be in /usr/share/terminfo, and the other (let's say
1964 libc6/glibc) expects /usr/lib/terminfo. I remember that the
1965 specific instructions in this bugfix/workaround were to do the
1966 following or equivalent:
1968 ln -s ../share/terminfo ./terminfo
1971 ln -s /usr/share/terminfo /usr/lib/terminfo
1973 So what this says is that the terminfo database/directory structure
1974 can be accessed by either path. When something goes to reference
1975 /usr/lib/terminfo, the symlink redirects it to essentially
1976 /usr/share/terminfo, which is where it really resides on your
1977 system. I personally prefer wherever possible to use relative
1978 symlinks, because they still hold, more often than break, across
1979 mount points, particularly NFS mounts, where the directory structure
1980 may be different on the different systems.
1982 Evidently the terminfo file moved between Red Hat 5.0 and 5.1, but Red
1983 Hat did not include a link to let applications built prior to 5.1 find
1984 it. Users reported that installing the link fixes the problem.
1986 3.3.6. The Fullscreen File Transfer Display
1988 [ [339]Top ] [ [340]Contents ] [ [341]Section Contents ] [
1991 Starting with ncurses versions dated 1998-12-12 (about a year before
1992 ncurses 5.0), ncurses sets the terminal for buffered i/o, but
1993 unfortunately is not able to restore it upon exit from curses (via
1994 endwin()). Thus after a file transfer that uses the fullscreen file
1995 transfer display, the terminal no longer echos nor responds immediately
1996 to Tab, ?, and other special command characters. The same thing happens
1997 on other platforms that use ncurses, e.g. FreeBSD. Workarounds:
1999 * Use SET XFER DISPLAY BRIEF, CRT, SERIAL, or NONE instead of
2001 * Rebuild with KFLAGS=-DNONOSETBUF (C-Kermit 8.0)
2003 In Red Hat 7.1, when using C-Kermit in a Gnome terminal window, it was
2004 noticed that when the fullscreen file transfer display exits (via
2005 endwin()), the previous (pre-file-transfer-display) screen is restored.
2006 Thus you can't look at the completed display to see what happened. This
2007 is a evidently a new feature of xterm. I can only speculate that
2008 initscreen() and endwin() must send some kind of special escape
2009 sequences that command xterm to save and restore the screen. To defeat
2010 this effect, tell Linux you have a vt100 or other xterm-compatible
2011 terminal that is not actually an xterm, or else tell Kermit to SET
2012 TRANSFER DISPLAY to something besides FULLSCREEN.
2014 3.4. C-KERMIT AND NEXTSTEP
2016 [ [343]Top ] [ [344]Contents ] [ [345]Section Contents ] [ [346]Next ]
2019 Run C-Kermit in a Terminal, Stuart, or xterm window, or when logged in
2020 remotely through a serial port or TELNET connection. C-Kermit does not
2021 work correctly when invoked directly from the NeXTSTEP File Viewer or
2022 Dock. This is because the terminal-oriented gtty, stty, & ioctl calls
2023 don't work on the little window that NeXTSTEP pops up for non-NeXTSTEP
2024 applications like Kermit. CBREAK and No-ECHO settings do not take
2025 effect in the command parser -- commands are parsed strictly line at a
2026 time. "set line /dev/cua" works. During CONNECT mode, the console stays
2027 in cooked mode, so characters are not transmitted until carriage return
2028 or linefeed is typed, and you can't escape back. If you want to run
2029 Kermit directly from the File Viewer, then launch it from a shell
2030 script that puts it in the desired kind of window, something like this
2033 Terminal -Lines 24 -Columns 80 -WinLocX 100 -WinLocY 100 $FONT $FONTSIZE \
2034 -SourceDotLogin -Shell /usr/local/bin/kermit &
2036 C-Kermit does not work correctly on a NeXT with NeXTSTEP 3.0 to which
2037 you have established an rlogin connection, due to a bug in NeXTSTEP
2038 3.0, which has been reported to NeXT.
2040 The SET CARRIER command has no effect on the NeXT -- this is a
2041 limitation of the NeXTSTEP serial-port device drivers.
2043 Hardware flow control on the NeXT is selected not by "set flow rts/cts"
2044 in Kermit (since NeXTSTEP offers no API for this), but rather, by using
2045 a specially-named driver for the serial device: /dev/cufa instead
2046 /dev/cua; /dev/cufb instead of /dev/cub. This is available only on
2047 68040-based NeXT models (the situation for Intel NeXTSTEP
2048 implementations is unknown).
2050 NeXT-built 68030 and 68040 models have different kinds of serial
2051 interfaces; the 68030 has a Macintosh-like RS-422 interface, which
2052 lacks RTS and CTS signals; the 68040 has an RS-423 (RS-232 compatible)
2053 interface, which supports the commonly-used modem signals. WARNING: the
2054 connectors look exactly the same, but the pins are used in completely
2055 DIFFERENT ways -- different cables are required for the two kinds of
2058 IF YOU GET LOTS OF RETRANSMISSIONS during file transfer, even when
2059 using a /dev/cuf* device and the modem is correctly configured for
2060 RTS/CTS flow control, YOU PROBABLY HAVE THE WRONG KIND OF CABLE.
2062 On the NeXT, Kermit reportedly (by TimeMon) causes the kernel to use a
2063 lot of CPU time when using a "set line" connection. That's because
2064 there is no DMA channel for the NeXT serial port, so the port must
2065 interrupt the kernel for each character in or out.
2067 One user reported trouble running C-Kermit on a NeXT from within NeXT's
2068 Subprocess class under NeXTstep 3.0, and/or when rlogin'd from one NeXT
2069 to another: Error opening /dev/tty:, congm: No such device or address.
2070 Diagnosis: Bug in NeXTSTEP 3.0, cure unknown.
2072 3.5. C-KERMIT AND QNX
2074 [ [348]Top ] [ [349]Contents ] [ [350]Section Contents ] [ [351]Next ]
2077 See also: The [353]comp.os.qnx newsgroup.
2079 Support for QNX 4.x was added in C-Kermit 5A(190). This is a
2080 full-function implementation, thoroughly tested on QNX 4.21 and later,
2081 and verified to work in both 16-bit and 32-bit versions. The 16-bit
2082 version was dropped in C-Kermit 7.0 since it can no longer be built
2083 successfully (after stripping most most features, I succeeded in
2084 getting it to compile and link without complaint, but the executable
2085 just beeps when you run it); for 16-bit QNX 4.2x, use C-Kermit 6.0 or
2086 earlier, or else [354]G-Kermit.
2088 The 32-bit version (and the 16-bit version prior to C-Kermit 7.0)
2089 supports most of C-Kermit's advanced features including TCP/IP, high
2090 serial speeds, hardware flow-control, modem-signal awareness, curses
2093 BUG: In C-Kermit 6.0 on QNX 4.22 and earlier, the fullscreen file
2094 transfer display worked fine the first time, but was fractured on
2095 subsequent file transfers. Cause and cure unknown. In C-Kermit 7.0 and
2096 QNX 4.25, this no longer occurs. It is not known if it would occur in
2097 C-Kermit 7.0 or later on earlier QNX versions.
2099 Dialout devices are normally /dev/ser1, /dev/ser2, ..., and can be
2100 opened explicitly with SET LINE. Reportedly, "/dev/ser" (no unit
2101 number) opens the first available /dev/sern device.
2103 Like all other Unix C-Kermit implementations, QNX C-Kermit does not
2104 provide any kind of terminal emulation. Terminal specific functions are
2105 provided by your terminal, terminal window (e.g. QNX Terminal or
2106 xterm), or emulator.
2108 QNX C-Kermit, as distributed, does not include support for UUCP
2109 line-locking; the QNX makefile entries (qnx32 and qnx16) include the
2110 -DNOUUCP switch. This is because QNX, as distributed, does not include
2111 UUCP, and its own communications software (e.g. qterm) does not use
2112 UUCP line locking. If you have a UUCP product installed on your QNX
2113 system, remove the -DNOUUCP switch from the makefile entry and rebuild.
2114 Then check to see that Kermit's UUCP lockfile conventions are the same
2115 as those of your UUCP package; if not, read the [355]UUCP lockfile
2116 section of the [356]Installation Instructions and make the necessary
2117 changes to the makefile entry (e.g. add -DHDBUUCP).
2119 QNX does, however, allow a program to get the device open count. This
2120 can not be a reliable form of locking unless all applications do it, so
2121 by default, Kermit uses this information only for printing a warning
2124 C-Kermit>set line /dev/ser1
2125 WARNING - "/dev/ser1" looks busy...
2127 However, if you want to use it as a lock, you can do so with:
2129 SET QNX-PORT-LOCK { ON, OFF }
2131 This is OFF by default; if you set in ON, C-Kermit will fail to open
2132 any dialout device when its open count indicates that another process
2133 has it open. SHOW COMM (in QNX only) displays the setting, and if you
2134 have a port open, it also shows the open count.
2136 As of C-Kermit 8.0, C-Kermit's "open-count" form of line locking works
2137 only in QNX4, not in QNX6 (this might change in a future C-Kermit
2140 3.6. C-KERMIT AND SCO
2142 [ [357]Top ] [ [358]Contents ] [ [359]Section Contents ] [ [360]Next ]
2147 3.6.1. [362]SCO XENIX
2148 3.6.2. [363]SCO UNIX and OSR5
2149 3.6.3. [364]Unixware
2150 3.6.4. [365]Open UNIX 8
2154 * The comp.unix.sco.* newsgroups.
2155 * [366]Section 3.10 below for Unixware.
2156 * The following FAQs:
2158 The comp.sco.misc FAQ:
2159 [367]http://aplawrence.com/SCOFAQ/
2161 Caldera (SCO) comp.unix.sco.programmer FAQ:
2162 [368]http://www.zenez.com/cgi-bin/scoprogfaq/faq.pl
2164 The UnixWare 7/OpenUNIX 8 FAQ:
2165 [369]http://www.zenez.com/cgi-bin/scouw7faq/faq.pl
2166 [370]http://zenez.pcunix.com/cgi-bin/scouw7faq/faq.pl
2168 High Speed Modems for SCO Unix:
2169 [371]http://pcunix.com/Unixart/modems.html
2172 [372]http://www.freebird.org/faq/
2174 The UnixWare 1.x and 2.0 Programmer FAQ
2175 [373]http://www.freebird.org/faq/developer.html
2177 Caldera Support Knowledge Base
2178 [374]http://support.caldera.com/caldera
2180 [375]http://stage.caldera.com/ta/
2181 Caldera (SCO) Technical Article Search Center
2183 [376]http://aplawrence.com/newtosco.html
2184 New to SCO (Tony Lawrence)
2186 The same comments regarding terminal emulation and key mapping apply to
2187 SCO operating systems as to all other Unixes. C-Kermit is not a
2188 terminal emulator, and you can't use it to map F-keys, Arrow keys, etc.
2189 The way to do this is with xmodmap (xterm) or loadkeys (console). For a
2190 brief explanation, see [377]Section 3.0.5. For a fuller explanation,
2193 Also see general comments on PC-based Unixes in [379]Section 3.0.
2197 [ [380]Top ] [ [381]Contents ] [ [382]Section Contents ] [ [383]Next ]
2199 Old Xenix versions... Did you know: Xenix 3.0 is *older* than Xenix
2202 In Xenix 2.3.4 and probably other Xenix versions, momentarily dropping
2203 DTR to hang up a modem does not work. DTR goes down but does not come
2204 up again. Workaround: Use SET MODEM HANGUP-METHOD MODEM-COMMAND.
2205 Anybody who would like to fix this is welcome to take a look at
2206 tthang() in [384]ckutio.c. Also: modem signals can not be read in
2207 Xenix, and the maximum serial speed is 38400.
2209 There is all sorts of confusion among SCO versions, particularly when
2210 third- party communications boards and drivers are installed, regarding
2211 lockfile naming conventions, as well as basic functionality. As far as
2212 lockfiles go, all bets are off if you are using a third-party multiport
2213 board. At least you have the source code. Hopefully you also have a C
2216 Xenix 2.3.0 and later claim to support RTSFLOW and CTSFLOW, but this is
2217 not modern bidirectional hardware flow control; rather it implements
2218 the original RS-232 meanings of these signals for unidirectional
2219 half-duplex line access: If both RTSFLOW and CTSFLOW bits are set,
2220 Xenix asserts RTS when it wants to send data and waits for CTS
2221 assertion before it actually starts sending data (also, reportedly,
2222 even this is broken in Xenix 2.3.0 and 2.3.1).
2224 3.6.2. SCO UNIX AND OSR5
2226 [ [385]Top ] [ [386]Contents ] [ [387]Section Contents ] [ [388]Next ]
2229 SCO systems tend to use different names (i.e. drivers) for the same
2230 device. Typically /dev/tty1a refers to a terminal device that has no
2231 modem control; open, read, write, and close operations do not depend on
2232 carrier. On the other hand, /dev/tty1A (same name, but with final
2233 letter upper case), is the same device with modem control, in which
2234 carrier is required (the SET LINE command does not complete until
2235 carrier appears, read/write operations fail if there is no carrier,
2238 SCO OpenServer 5.0.5 and earlier do not support the reading of modem
2239 signals. Thus "show comm" does not list modem signals, and C-Kermit
2240 does not automatically pop back to its prompt when the modem hangs up
2241 the connection (drops CD). The ioctl() call for this is simply not
2242 implmented, at least not in the standard drivers. OSR5.0.6 attempts to
2243 deal with modem signals but fails; however OSR5.0.6a appears to
2246 Dialing is likely not to work well in SCO OpenServer 5.0.x because many
2247 of the serial-port APIs simply do not operate when using the standard
2248 drivers. For example, if DTR is dropped by the recommended method
2249 (setting speed to 0 for half a seconds, then restoring the speed), DTR
2250 and RTS go down but never come back up. When in doubt SET MODEM
2251 HANGUP-METHOD MODEM-COMMAND or SET DIAL HANGUP OFF.
2253 On the other hand, certain functions that might not (do not) work right
2254 or at all when using SCO drivers (e.g. high serial speeds, hardware
2255 flow control, and/or reading of modem signals) might work right when
2256 using third-party drivers. (Example: hardware flow control works,
2257 reportedly, only on uppercase device like tty1A -- not tty1a -- and
2258 only when CLOCAL is clear when using the SCO sio driver, but there are
2259 no such restrictions in, e.g., [390]Digiboard drivers).
2261 One user reports that he can't transfer large files with C-Kermit under
2262 SCO OSR5.0.0 and 5.0.4 -- after the first 5K, everything falls apart.
2263 Same thing without Kermit -- e.g. with ftp over a PPP connection.
2264 Later, he said that replacing SCO's SIO driver with FAS, an alternative
2265 communications driver, made the problem go away:
2267 [391]ftp://ftp.fu-berlin.de/pub/unix/driver/fas
2269 With regard to bidirectional serial ports on OpenServer 5.0.4, the
2270 following advice appeared on an SCO-related newsgroup:
2272 No amount of configuration information is going to help you on 5.0.4
2273 unless it includes the kludge for the primary problem. With almost
2274 every modem, the 5.0.4 getty will barf messages and may or may not
2275 connect. There are 2 solutions and only one works on 5.0.4. Get the
2276 atdialer binary from a 5.0.0 system and substitute it for the native
2277 5.0.4 atdialer. The other solution is to upgrade to 5.0.5. And, most
2278 of all, on any OpenServer products, do NOT run the badly broken
2279 Modem Manager. Configure the modems in the time honored way that
2280 dates back to Xenix.
2282 Use SCO-provided utilities for switching the directionality of a modem
2283 line, such as "enable" and "disable" commands. For example, to dial out
2284 on tty1a, which is normally set up for logins:
2287 kermit -l /dev/tty1a
2290 If a tty device is listed as an ACU in /usr/lib/uucp/Devices and is
2291 enabled, getty resets the ownership and permissions to uucp.uucp and
2292 640 every time the device is released. If you want to use the device
2293 only for dialout, and you want to specify other owners or permissions,
2294 you should disable it in /usr/lib/uucp/Devices; this will prevent getty
2295 from doing things to it. You should also changes the device's file
2296 modes in /etc/conf/node.d/sio by changing fields 5-7 for the desired
2297 device(s); this determines how the devices are set if you relink the
2300 One SCO user of C-Kermit 5A(190) reported that only one copy of Kermit
2301 can run at a time when a Stallion Technologies multiport boards are
2302 installed. Cause, cure, and present status unknown (see [392]Section 14
2303 for more info regarding Stallion).
2305 Prior to SCO OpenServer 5.0.4, the highest serial port speed supported
2306 by SCO was 38400. However, in some SCO versions (e.g. OSR5) it is
2307 possible to map rarely-used lower speeds (like 600 and 1800) to higher
2308 ones like 57600 and 115200. To find out how, go to
2309 [393]http://www.sco.com/ and search for "115200". In OSR5.0.4, serial
2310 speeds up to 921600 are supported through the POSIX interface; C-Kermit
2311 6.1.193 or later, when built for OSR5.0.4 using /bin/cc (NOT the UDK,
2312 which hides the high-speed definitions from CPP), supports these
2313 speeds, but you might be able to run this binary on earlier releases to
2314 get the high serial speeds, depending on various factors, described by
2317 Serial speeds under SCO Unix / Open Desktop / OpenServer
2318 ========================================================
2319 Third party drivers (intelligent serial boards) may provide any speeds
2320 they desire; most support up to 115.2Kbps.
2322 SCO's "sio" driver, which is used to drive standard serial ports with
2323 8250/16450/16550 and similar UARTs, was limited to 38400bps in older
2324 releases. Support for rates through 115.2Kbps was added in the
2327 SCO OpenServer Release 5.0.0 (requires supplement "rs40b")
2328 SCO OpenServer Release 5.0.2 (requires supplement "rs40a" or "rs40b")
2329 SCO OpenServer Release 5.0.4 or later
2330 SCO Internet FastStart Release 1.0.0 or later
2332 SCO supplements are at [394]ftp://ftp.sco.com/; the "rs40" series are
2333 under directory /Supplements/internet
2335 Kermit includes the high serial speeds in all OSR5 builds, but that
2336 does not necessarily mean they work. For example, on our in-house 5.0.5
2337 system, SET SPEED 57600 or higher seems to succeed (no error occurs)
2338 but when we read the speed back the driver says it is 50. Similarly,
2339 76800 becomes 75, and 115200 becomes 110. Testing shows the resulting
2340 speed is indeed the low one we read back, not the high one we asked
2341 for. Moral: Use speeds higher than 38400 with caution on SCO OSR5.
2343 Reportedly, if you have a script that makes a TCP/IP SET HOST (e.g.
2344 Telnet) connection to SCO 3.2v4.2 with TCP/IP 1.2.1, and then does the
2350 this causes a pseudoterminal (pty) to be consumed on the SCO system; if
2351 you do it enough times, it will run out of ptys. An "exit" command is
2352 being sent to the SCO shell, and a HANGUP command is executed locally,
2353 so the chances are good that both sides are trying to close the
2354 connection at once, perhaps inducing a race condition in which the
2355 remote pty is not released. It was speculated that this would be fixed
2356 by applying SLS net382e, but it did not. Meanwhile, the workaround is
2357 to insert a "pause" between the SCRIPT and HANGUP commands. (The
2358 situation with later SCO releases is not known.)
2360 SCO UNIX and OpenServer allow their console and/or terminal drivers to
2361 be configured to translate character sets for you. DON'T DO THIS WHEN
2362 USING KERMIT! First of all, you don't need it -- Kermit itself already
2363 does this for you. And second, it will (a) probably ruin the formatting
2364 of your screens (depending on which emulation you are using); and (b)
2365 interfere with all sorts of other things -- legibility of non-ASCII
2366 text on the terminal screen, file transfer, etc. Use:
2370 to turn off this feature.
2372 Note that there is a multitude of SCO entries in the makefile, many of
2373 them exhibiting an unusually large number of compiler options. Some
2374 people actually understand all of this. Reportedly, things are settling
2375 down with SCO OpenServer 5.x and Unixware 7 (and Open UNIX 8 and who
2376 knows what the next one will be -- Linux probably) -- the SCO UDK
2377 compiler is said to generate binaries that will run on either platform,
2378 by default, automatically. When using gcc or egcs, on the other hand,
2379 differences persist, plus issues regarding the type of binary that is
2380 generated (COFF, ELF, etc), and where and how it can run. All of this
2381 could stand further clarification by SCO experts.
2385 [ [395]Top ] [ [396]Contents ] [ [397]Section Contents ] [ [398]Next ]
2388 Unixware changed hands several times before landing at SCO, and so has
2389 its [400]own section in this document. (Briefly: AT&T UNIX Systems
2390 Laboratories sold the rights to the UNIX name and to System V R4 (or
2391 R5?) to Novell; later Novell spun its UNIX division off into a new
2392 company called Univel, which eventually was bought by SCO, which later
2393 was bought by Caldera, which later sort of semi-spun-off SCO...)
2397 [ [401]Top ] [ [402]Contents ] [ [403]Section Contents ] [
2400 SCO was bought by Caldera in 2000 or 2001 and evolved Unixware 7.1 into
2401 Caldera Open UNIX 8.00. It's just like Unixware 7.1 as far as Kermit is
2402 concerned (the Unixware 7.1 makefile target works for Open UNIX 8.00,
2403 and in fact a Unixware 7.1 Kermit binary built on Unixware 7.1 runs
2404 under OU8; a separate OU8 makefile target exists simply to generate an
2405 appropriate program startup herald). Open Unix is now defunct;
2406 subsequent releases are called UnixWare again (e.g. UnixWare 7.1.3).
2408 3.7. C-KERMIT AND SOLARIS
2410 [ [405]Top ] [ [406]Contents ] [ [407]Section Contents ] [ [408]Next ]
2415 3.7.1. [410]Serial Port Configuration
2416 3.7.2. [411]Serial Port Problems
2417 3.7.3. [412]SunLink X.25
2418 3.7.4. [413]Sun Workstation Keyboard Mapping
2419 3.7.5. [414]Solaris 2.4 and Earlier
2423 * The [415]comp.unix.solaris newsgroup
2424 * [416]http://access1.sun.com/
2425 * [417]http://docs.sun.com/
2426 * [418]http://www.sunhelp.com/
2427 * [419]http://www.wins.uva.nl/pub/solaris/solaris2/
2428 * [420]http://www.wins.uva.nl/cgi-bin/sfaq.cgi
2429 * [421]ftp://ftp.wins.uva.nl/pub/solaris
2430 * [422]http://www.science.uva.nl/pub/solaris/solaris2.html
2432 And about serial communications in particular, see "Celeste's Tutorial
2433 on Solaris 2.x Modems and Terminals":
2435 [423]http://www.stokely.com/
2439 [424]http://www.stokely.com/unix.sysadm.resources/faqs.sun.html
2441 For PC-based Solaris, also see general comments on PC-based Unixes in
2442 [425]Section 3.0. Don't expect Solaris or any other kind of Unix to
2443 work right on a PC until you resolve all interrupt conflicts. Don't
2444 expect to be able to use COM3 or COM4 (or even COM2) until you have
2445 configured their addresses and interrupts.
2447 3.7.1. Serial Port Configuration
2449 [ [426]Top ] [ [427]Contents ] [ [428]Section Contents ] [ [429]Section
2450 Contents ] [ [430]Next ]
2452 Your serial port can't be used -- or at least won't work right -- until
2453 it is enabled in Solaris. For example, you get a message like "SERIAL:
2454 Operation would block" when attempting to dial. This probably indicates
2455 that the serial port has not been enabled for use with modems. You'll
2456 need to follow the instructions in your system setup or management
2457 manual, such as (e.g.) the Desktop SPARC Sun System & Network Manager's
2458 Guide, which should contain a section "Setting up Modem Software"; read
2459 it and follow the instructions. These might (or might not) include
2460 running a program called "eeprom", editing some system configuration
2461 file (such as, for example:
2463 /platform/i86pc/kernel/drv/asy.conf
2465 and then doing a configuration reboot, or running some other programs
2466 like drvconfig and devlinks. "man eeprom" for details.
2468 Also, on certain Sun models like IPC, the serial port hardware might
2469 need to have a jumper changed to make it an RS-232 port rather than
2472 eeprom applies only to real serial ports, not to "Spiff" devices
2473 (serial port expander), in which case setup with Solaris' admintool is
2476 Another command you might need to use is pmadm, e.g.:
2478 pmadm -d -p zsmon -s tty3
2479 pmadm -e -p zsmon -s tty3
2481 You can use the following command to check if a process has the device
2484 fuser -f /dev/term/3
2486 In some cases, however (according to Sun support, May 2001) "It is
2487 still possible that a zombie process has hold of the port EVEN IF there
2488 is no lock file and the fuser command comes up empty. In that case, the
2489 only way to resolve the problem is by rebooting."
2491 If you can't establish communication through a serial port to a device
2492 that is not asserting CD (Carrier Detect), try setting the environment
2493 variable "ttya-ignore-cd" to "true" (replace "ttya" with the port
2496 3.7.2. Serial Port Problems
2498 [ [431]Top ] [ [432]Contents ] [ [433]Section Contents ] [ [434]Next ]
2501 Current advice from Sun is to always the /dev/cua/x devices for dialing
2502 out, rather than the /dev/term/x. Nevertheless, if you have trouble
2503 dialing out with one, try the other.
2505 Reportedly, if you start C-Kermit and "set line" to a port that has a
2506 modem connected to it that is not turned on, and then "set flow
2507 rts/cts", there might be some (unspecified) difficulties closing the
2508 device because the CTS signal is not coming in from the modem.
2512 [ [436]Top ] [ [437]Contents ] [ [438]Section Contents ] [ [439]Next ]
2515 The built-in SunLink X.25 support for Solaris 2.3/2.4./25 and SunLink
2516 8.01 or 9.00 works OK provided the X.25 system has been installed and
2517 initialized properly. Packet sizes might need to be reduced to 256,
2518 maybe even less, depending on the configuration of the X.25
2519 installation. On one connection where C-Kermit 6.0 was tested, very
2520 large packets and window sizes could be used in one direction, but only
2521 very small ones would work in the other.
2523 In any case, according to Sun, C-Kermit's X.25 support is superfluous
2524 with SunLink 8.x / Solaris 2.3. Quoting an anonymous Sun engineer:
2526 ... there is now no need to include any X.25 code within kermit. As
2527 of X.25 8.0.1 we support the use of kermit, uucp and similar
2528 protocols over devices of type /dev/xty. This facility was there in
2529 8.0, and should also work on the 8.0 release if patch 101524 is
2530 applied, but I'm not 100% sure it will work in all cases, which is
2531 why we only claim support from 8.0.1 onwards.
2533 When configuring X.25, on the "Advanced Configuration->Parameters"
2534 screen of the x25tool you can select a number of XTY devices. If you
2535 set this to be > 1, press Apply, and reboot, you will get a number
2536 of /dev/xty entries created.
2538 Ignore /dev/xty0, it is a special case. All the others can be used
2539 exactly as if they were a serial line (e.g. /dev/tty) connected to a
2540 modem, except that instead of using Hayes-style commands, you use
2543 From kermit you can do a 'set line' command to, say, /dev/xty1, then
2544 set your dialing command to be "CALL 12345678", etc. All the usual
2545 PAD commands will work (SET, PAR, etc).
2547 I know of one customer in Australia who is successfully using this,
2548 with kermit scripts, to manage some X.25-connected switches. He used
2549 standard kermit, compiled for Solaris 2, with X.25 8.0 xty devices.
2551 3.7.4. Sun Workstation Keyboard Mapping
2553 [ [441]Top ] [ [442]Contents ] [ [443]Section Contents ] [ [444]Next ]
2556 Hints for using a Sun workstation keyboard for VT emulation when
2557 accessing VMS, from the [446]comp.os.vms newsgroup:
2559 From: Jerry Leichter <leichter@smarts.com>
2560 Newsgroups: comp.os.vms
2561 Subject: Re: VT100 keyboard mapping to Sun X server
2562 Date: Mon, 19 Aug 1996 12:44:21 -0400
2564 > I am stuck right now using a Sun keyboard (type 5) on systems
2566 > and Solaris. I would like to use EVE on an OpenVMS box with
2568 > the Sun. Does anyone know of a keyboard mapping (or some other
2570 > which will allow the Sun keyboard to approximate a VT100/VT220?
2572 You can't get it exactly - because the keypad has one fewer key -
2573 but you can come pretty close. Here's a set of keydefs I use:
2588 keycode 57=KP_Decimal
2591 keycode 30=KP_Separator
2593 keycode 78=KP_Subtract
2600 Put this in a file - I use "keydefs" in my home directory and feed
2603 xmodmap - <$HOME/keydefs
2605 This takes care of the arrow keys and the "calculator" key cluster.
2606 The "+" key will play the role of the DEC "," key. The Sun "-" key
2607 will be like the DEC "-" key, though it's in a physically different
2608 position - where the DEC PF4 key is. The PF4 key is ... damn, I'm
2609 not sure where "key 105" is. I *think* it may be on the leftmost key
2610 of the group of four just above the "calculator" key cluster.
2612 I also execute the following (this is all in my xinitrc file):
2614 xmodmap -e 'keysym KP_Decimal = KP_Decimal'
2615 xmodmap -e 'keysym BackSpace = Delete BackSpace' \
2616 -e 'keysym Delete = BackSpace Delete'
2617 xmodmap -e 'keysym KP_Decimal = Delete Delete KP_Decimal'
2618 xmodmap -e 'add mod1 = Meta_R'
2619 xmodmap -e 'add mod1 = Meta_L'
2621 Beware of one thing about xmodmap: Keymap changes are applied to the
2622 *whole workstation*, not just to individual windows. There is, in
2623 fact, no way I know of to apply them to individual windows. These
2624 definitions *may* confuse some Unix programs (and/or some Unix
2627 If you're using Motif, you may also need to apply bindings at the
2628 Motif level. If just using xmodmap doesn't work, I can try and dig
2629 that stuff up for you.
2631 3.7.5. Solaris PPP Connections
2633 [ [447]Top ] [ [448]Contents ] [ [449]Section Contents ] [ [450]Next ]
2636 The following is a report from a user of C-Kermit 8.0 on Solaris 8 and
2637 9, who had complained that while Kermit file transfers worked perfectly
2638 on direct (non-PPP) dialout connections, they failed miserably on PPP
2639 connections. We suggested that the PPP dialer probably was not setting
2640 the port and/or modem up in the same way that Kermit did:
2642 I want to get back on this and tell you what the resolution was. You
2643 pointed me in the direction of flow control, which turned out to be
2646 Some discussion on the comp.unix.solaris newsgroup led to some
2647 comments from Greg Andrews about the need to use the uucp driver to
2648 talk to the modem (/dev/cua/a). I had to remind Greg that no matter
2649 what the manpages for the zs and se drivers say, the ppp that Sun
2650 released with Solaris 8 7/01, and has in Solaris 9, is a setuid root
2651 program, and simply trying to make a pppd call from user space
2652 specifying /dev/cua/a would fail because of permissions. Greg
2653 finally put the question to the ppp people, who came back with
2654 information that is not laid out anywhere in the docs available for
2655 Solaris users. Namely, put /dev/cua/a in one of the priviledged
2656 options files in the /etc/ppp directory. That, plus resetting the
2657 OBP ttya-ignore-cd flag (this is Sun hardware) to false, seems to
2658 have solved the problems.
2660 While I note that I had installed Kermit suid to uucp to use
2661 /dev/cua/a on this particular box, it seems to run fine through
2662 /dev/term/a. Not so with pppd.
2664 With this change in place, I seem to be able to upload and download
2665 through telnet run on Kermit with the maximum length packets. I note
2666 that the window allocation display does show STREAMING, using
2667 telnet. Running ssh on Kermit, I see the standard 1 of 30 windows
2668 display, and note that there appears to be a buffer length limit
2669 between 1000 and 2000 bytes. Run with 1000, and it's tick-tock,
2670 solid as a rock. With 2000 I see timeout errors and RTS/CTS action
2673 Kermit's packet-length and other controls let you make adjustments like
2674 this to get around whatever obstacles might be thrown up -- in this
2675 case (running Kermit over ssh), the underling Solaris PTY driver.
2677 3.7.6. Solaris 2.4 and Earlier
2679 [ [452]Top ] [ [453]Contents ] [ [454]Section Contents ] [
2682 C-Kermit can't be compiled successfully under Solaris 2.3 using
2683 SUNWspro cc 2.0.1 unless at least some of the following patches are
2684 applied to cc (it is not known which one(s), if any, fix the problem):
2686 * 100935-01 SparcCompiler C 2.0.1: bad code generated when addresses
2687 of two double arguments are involved
2688 * 100961-05 SPARCcompilers C 2.0.1: conditional expression with
2689 function returning structure gives wrong value
2690 * 100974-01 SparcWorks 2.0.1: dbx jumbo patch
2691 * 101424-01 SPARCworks 2.0.1 maketool SEGV's instantly on Solaris 2.3
2693 With unpatched cc 2.0.1, the symptom is that certain modules generate
2694 truncated object files, resulting in many unresolved references at link
2697 The rest of the problems in this section have to do with
2698 bidirectional terminal ports and the Solaris Port Monitor. A bug in
2699 C-Kermit 5A ticked a bug in Solaris. The C-Kermit bug was fixed in
2700 version 6.0, and the Solaris bug was fixed in 2.4 (I think, or maybe
2703 Reportedly, "C-Kermit ... causes a SPARCstation running Solaris 2.3 to
2704 panic after the modem connects. I have tried compiling C-Kermit with
2705 Sun's unbundled C compiler, with GCC Versions 2.4.5 and 2.5.3, with
2706 make targets 'sunos51', 'sunos51tcp', 'sunos51gcc', and even 'sys5r4',
2707 and each time it compiles and starts up cleanly, but without fail, as
2708 soon as I dial the number and get a 'CONNECT' message from the modem, I
2713 kernel read fault at addr=0x45c, pme=0x0
2714 Sync Error Reg 80 <INVALID>
2720 The same modem works fine for UUCP/tip calling." Also (reportedly),
2721 this only happens if the dialout port is configured as in/out via
2722 admintool. If it is configured as out-only, no problem. This is the
2723 same dialing code that works on hundreds of other System-V based Unix
2724 OS's. Since it should be impossible for a user program to crash the
2725 operating system, this problem must be chalked up to a Solaris bug.
2726 Even if you SET CARRIER OFF, CONNECT, and dial manually by typing
2727 ATDTnnnnnnn, the system panics as soon as the modem issues its CONNECT
2728 message. (Clearly, when you are dialing manually, C-Kermit does not
2729 know a thing about the CONNECT message, and so the panic is almost
2730 certainly caused by the transition of the Carrier Detect (CD) line from
2731 off to on.) This problem was reported by many users, all of whom say
2732 that C-Kermit worked fine on Solaris 2.1 and 2.2. If the speculation
2733 about CD is true, then a possible workaround might be to configure the
2734 modem to leave CD on (or off) all the time. Perhaps by the time you
2735 read this, a patch will have been issued for Solaris 2.3.
2737 The following is from Karl S. Marsh, Systems & Networks Administrator,
2738 AMBIX Systems Corp, Rochester, NY:
2740 Environment: Solaris 2.3 Patch 101318-45 C-Kermit 5A(189) (and
2741 presumably this applies to 188 and 190 also). eeprom setting:
2743 ttya-rts-dtr-off=false
2744 ttya-ignore-cd=false
2745 ttya-mode=19200,8,n,8,-
2747 To use C-Kermit on a bidirectional port in this environment, do not
2748 use admintool to configure the port. Use admintool to delete any
2749 services running on the port and then quit admintool and issue the
2752 pmadm -a -p zsmon -s ttyb -i root -fu -v 1 -m "`ttyadm -b -d /dev/term/b \
2753 -l conttyH -m ldterm,ttcompat -s /usr/bin/login -S n`"
2755 [NOTE: This was copied from a blurry fax, so please check it
2760 -s = service tag (ttyb)
2761 -i = id to be associated with service tag (root)
2762 -fu = create utmp entry
2763 -v = version of ttyadm
2764 -m = port monitor-specific portion of the port monitor administrative file
2765 entry for the service
2766 -b = set up port for bidirectional use
2767 -d = full path name of device
2768 -l = which ttylabel in the /etc/ttydefs file to use
2769 -m = a list of pushable STREAMS modules
2770 -s = pathname of service to be invoked when connection request received
2771 -S = software carrier detect on or off (n = off)
2773 "This is exactly how I was able to get Kermit to work on a
2774 bi-directional port without crashing the system."
2776 On the Solaris problem, also see SunSolve Bug ID 1150457 ("Using
2777 C-Kermit, get Bad Trap on receiving prompt from remote system").
2778 Another user reported "So, I have communicated with the Sun tech
2779 support person that submitted this bug report [1150457]. Apparently,
2780 this bug was fixed under one of the jumbo kernel patches. It would seem
2781 that the fix did not live on into 101318-45, as this is EXACTLY the
2782 error that I see when I attempt to use kermit on my system."
2784 Later (Aug 94)... C-Kermit dialout successfully tested on a Sun4m with
2785 a heavily patched Solaris 2.3. The patches most likely to have been
2788 * 101318-50: SunOS 5.3: Jumbo patch for kernel (includes libc, lockd)
2789 * 101720-01: SunOS 5.3: ttymon - prompt not always visible on a modem
2791 * 101815-01: SunOS 5.3: Data fault in put() NULL queue passed from
2793 * 101328-01: SunOS 5.3: Automation script to properly setup tty ports
2794 prior to PCTS execution
2796 Still later (Nov 94): another user (Bo Kullmar in Sweden) reports that
2797 after using C-Kermit to dial out on a bidirectional port, the port
2798 might not answer subsequent incoming calls, and says "the problem is
2799 easy enough to fix with the Serial Port Manager; I just delete the
2800 service and install it again using the graphical interface, which
2801 underneath uses commands like sacadm and pmadm." Later Bo reports, "I
2802 have found that if I run Kermit with the following script then it
2803 works. This script is for /dev/cua/a, "-s a" is the last a in
2809 surun pmadm -e -p zsmon -s a
2811 3.8. C-KERMIT AND SUNOS
2813 [ [456]Top ] [ [457]Contents ] [ [458]Section Contents ] [ [459]Next ]
2816 For additional information, see "Celeste's Tutorial on SunOS 4.1.3+
2817 Modems and Terminals":
2819 [461]http://www.stokely.com/
2821 For FAQs, etc, from Sun, see:
2822 * [462]http://access1.sun.com/
2824 For history of Sun models and SunOS versions, see (should be all the
2826 * [463]http://www.ludd.luth.se/~bear/project/sun/sun.hardware.txt
2827 * [464]ftp://ftp.netcom.com/pub/ru/rubicon/sun.hdwr.ref
2828 * [465]ftp://ftp.intnet.net/pub/SUN/Sun-Hardware-Ref
2830 Sun SPARCstation users should read the section "Setting up Modem
2831 Software" in the Desktop SPARC Sun System & Network Manager's Guide. If
2832 you don't set up your serial ports correctly, Kermit (and other
2833 communications software) won't work right.
2835 Also, on certain Sun models like IPC, the serial port hardware might
2836 need to have a jumper changed to make it an RS-232 port rather than
2839 Reportedly, C-Kermit does not work correctly on a Sun SPARCstation in
2840 an Open Windows window with scrolling enabled. Disable scrolling, or
2841 else invoke Kermit in a terminal emulation window (xterm, crttool,
2842 vttool) under SunView (this might be fixed in later SunOS releases).
2844 On the Sun with Open Windows, an additional symptom has been reported:
2845 outbound SunLink X.25 connections "magically" translate CR typed at the
2846 keyboard into LF before transmission to the remote host. This doesn't
2847 happen under SunView.
2849 SET CARRIER ON, when used on the SunOS 4.1 version of C-Kermit
2850 (compiled in the BSD universe), causes the program to hang
2851 uninterruptibly when SET LINE is issued for a device that is not
2852 asserting carrier. When Kermit is built in the Sys V universe on the
2853 same computer, there is no problem (it can be interrupted with Ctrl-C).
2854 This is apparently a limitation of the BSD-style tty driver.
2856 SunOS 4.1 C-Kermit has been observed to dump core when running a
2857 complicated script program under cron. The dump invariably occurs in
2858 ttoc(), while trying to output a character to a TCP/IP TELNET
2859 connection. ttoc() contains a write() call, and when the system or the
2860 network is very busy, the write() call can get stuck for long periods
2861 of time. To break out of deadlocks caused by stuck write() calls, there
2862 is an alarm around the write(). It is possible that the core dump
2863 occurs when this alarm signal is caught. (This one has not been
2864 observed recently -- possibly fixed in edit 190.)
2866 On Sun computers with SunOS 4.0 or 4.1, SET FLOW RTS/CTS works only if
2867 the carrier signal is present from the communication device at the time
2868 when C-Kermit enters packet mode or CONNECT mode. If carrier is not
2869 sensed (e.g. when dialing), C-Kermit does not attempt to turn on
2870 RTS/CTS flow control. This is because the SunOS serial device driver
2871 does not allow characters to be output if RTS/CTS is set (CRTSCTS) but
2872 carrier (and DSR) are not present. Workaround (maybe): SET CARRIER OFF
2873 before giving the SET LINE command, establish the connection, then SET
2876 It has also been reported that RTS/CTS flow control under SunOS 4.1
2877 through 4.1.3 works only on INPUT, not on output, and that there is a
2878 patch from Sun to correct this problem: Patch-ID# T100513-04, 20 July
2879 1993 (this patch might apply only to SunOS 4.1.3). It might also be
2880 necessary to configure the eeprom parameters of the serial port; e.g.
2881 do the following as root at the shell prompt:
2883 eeprom ttya-ignore-cd=false
2884 eeprom ttya-rts-dtr-off=true
2886 There have been reports of file transfer failures on Sun-3 systems when
2887 using long packets and/or large window sizes. One user says that when
2888 this happens, the console issues many copies of this message:
2890 chaos vmunix: zs1: ring buffer overflow
2892 This means that SunOS is not scheduling Kermit frequently enough to
2893 service interrupts from the zs serial device (Zilog 8350 SCC serial
2894 communication port) before its input silo overflows. Workaround: use
2895 smaller packets and/or a smaller window size, or use "nice" to increase
2896 Kermit's priority. Use hardware flow control if available, or remove
2897 other active processes before running Kermit.
2899 SunLink X.25 support in C-Kermit 5A(190) was built and tested
2900 successfully under SunOS 4.1.3b and SunLink X.25 7.00.
2902 3.9. C-KERMIT AND ULTRIX
2904 [ [466]Top ] [ [467]Contents ] [ [468]Section Contents ] [ [469]Next ]
2907 See also: The [471]comp.unix.ultrix and [472]comp.sys.dec newsgroups.
2909 There is no hardware flow control in Ultrix. That's not a Kermit
2910 deficiency, but an Ultrix one.
2912 When sending files to C-Kermit on a Telnet connection to a remote
2913 Ultrix system, you must SET PREFIXING ALL (or at least prefix more
2914 control characters than are selected by SET PREFIXING CAUTIOUS).
2916 Reportedly, DEC ULTRIX 4.3 is immune to C-Kermit's disabling of
2917 SIGQUIT, which is the signal that is generated when the user types
2918 Ctrl-\, which kills the current process (i.e. C-Kermit) and dumps core.
2919 Diagnosis and cure unknown. Workaround: before starting C-Kermit -- or
2920 for that matter, when you first log in because this applies to all
2921 processes, not just Kermit -- give the following Unix command:
2925 Certain operations driven by RS-232 modem signal do not work on
2926 DECstations or other DEC platforms whose serial interfaces use MMP
2927 connectors (DEC version of RJ45 telephone jack with offset tab). These
2928 connectors convey only the DSR and DTR modem signals, but not carrier
2929 (CD), RTS, CTS, or RI. Use SET CARRIER OFF to enable communication, or
2930 "hotwire" DSR to CD.
2932 The maximum serial speed on the DECstation 5000 is normally 19200, but
2933 various tricks are available (outside Kermit) to enable higher rates.
2934 For example, on the 5000/200, 19200 can be remapped (somehow, something
2935 to do with "a bit in the SIR", whatever that is) to 38400, but in
2936 software you must still refer to this speed as 19200; you can't have
2937 19200 and 38400 available at the same time.
2939 19200, reportedly, is also the highest speed supported by Ultrix, but
2940 NetBSD reportedly supports speeds up to 57600 on the DECstation,
2941 although whether and how well this works is another question.
2943 In any case, given the lack of hardware flow control in Ultrix, high
2944 serial speeds are problematic at best.
2946 3.10. C-KERMIT AND UNIXWARE
2948 [ [473]Top ] [ [474]Contents ] [ [475]Section Contents ] [ [476]Next ]
2952 * The Freebird Project (Unixware software repository)
2953 [478]http://www.freebird.org/
2954 * The UnixWare FAQ: [479]http://www.freebird.org/faq/
2955 * The following newsgroups:
2956 + [480]comp.unix.unixware.misc
2957 + [481]comp.unix.sco.misc.
2959 Also see general comments on PC-based Unixes in [482]Section 3.0. By
2960 the way, this section is separate from the SCO (Caldera) section
2961 because at the time this section was started, Unixware was owned by a
2962 company called Univel. Later it was sold to Novell, and then to SCO.
2963 Still later, SCO was sold to Caldera.
2965 In Unixware 2.0 and later, the preferred serial device names (drivers)
2966 are /dev/term/00 (etc), rather than /dev/tty00 (etc). Note the
2967 following correspondence of device names and driver characteristics:
2969 New name Old name Description
2970 /dev/term/00 /dev/tty00 ???
2971 /dev/term/00h /dev/tty00h Modem signals and hardware flow control
2972 /dev/term/00m /dev/tty00m Modem signals(?)
2973 /dev/term/00s /dev/tty00s Modem signals and software flow control
2974 /dev/term/00t /dev/tty00t ???
2976 Lockfile names use device.major.minor numbers, e.g.:
2978 /var/spool/locks/LK.7679.003.005
2980 The minor number varies according to the device name suffix (none, h,
2981 m, s, or t). Only the device and major number are compared, and thus
2982 all of the different names for the same physical device (e.g. all of
2983 those shown in the table above) interlock effectively.
2985 Prior to UnixWare 7, serial speeds higher than 38400 are not supported.
2986 In UnixWare 7, we also support 57600 and 115200, plus some unexpected
2987 ones like 14400, 28800, and 76800, by virtue of a strange new
2988 interface, evidently peculiar to UnixWare 7, discovered while digging
2989 through the header files: tcsetspeed(). Access to this interface is
2990 allowed only in POSIX builds, and thus the UnixWare 7 version of
2991 C-Kermit is POSIX-based, unlike C-Kermit for Unixware 1.x and 2.x
2992 (since the earlier UnixWare versions did not support high serial
2995 HOWEVER, turning on POSIX features engages all of the "#if
2996 (!_POSIX_SOURCE)" clauses in the UnixWare header files, which in turn
2997 prevent us from having modem signals, access to the hardware flow
2998 control APIs, select(), etc -- in short, all the other things we need
2999 in communications software, especially when high speeds are used. Oh
3000 the irony. And so C-Kermit must be shamelessly butchered -- as it has
3001 been so many times before -- to allow us to have the needed features
3002 from the POSIX and non-POSIX worlds. See the UNIXWAREPOSIX sections of
3005 After the butchery, we wind up with Unixware 2.x having full
3006 modem-signal capability, but politically-correct Unixware 7.x lacking
3007 the ability to automatically detect a broken connection when carrier
3010 Meanwhile the Unixware tcsetspeed() function allows any number at all
3011 (any long, 0 or positive) as an argument and succeeds if the number is
3012 a legal bit rate for the serial device, and fails otherwise. There is
3013 no list anywhere of legal speeds. Thus the SET SPEED keyword table
3014 ("set speed ?" to see it) is hardwired based on trial and error with
3015 all known serial speeds, the maximum being 115200. However, to allow
3016 for the possibility that other speeds might be allowed in the future
3017 (or with different port drivers), the SET SPEED command for UnixWare 7
3018 only allows you to specify any number at all; a warning is printed if
3019 the number is not in the list, but the number is accepted anyway; the
3020 command succeeds if tcsetspeed() accepts the number, and fails
3023 In C-Kermit 8.0 testing, it was noticed that the POSIX method for
3024 hanging up the phone by dropping DTR (set speed 0, pause, restore
3025 speed) did not actually drop DTR. The APIs do not return any error
3026 indication, but nothing happens. I changed tthang() to skip the special
3027 case I had made for Unixware and instead follow the normal path: if
3028 TIOCSDTR is defined use that, otherwise blah blah... It turns out
3029 TIOCSDTR *is* defined, and it works.
3031 So in Unixware (at least in 2.1.3) we can read modem signals, hangup by
3032 toggling DTR, and so on, BUT... But once the remote hangs up and
3033 Carrier drops, the API for reading modem signals ceases to function;
3034 although the device is still open, the TIOCMGET ioctl always raises
3035 errno 6 = ENXIO, "No such device or address".
3039 Using C-Kermit 6.0 on the UnixWare 1.1 Application Server, one user
3040 reported a system panic when the following script program is executed:
3047 The panic does not happen if a PAUSE is inserted:
3055 This is using a Stallion EasyIO card installed as board 0 on IRQ 12 on
3056 a Gateway 386 with the Stallion-supplied driver. The problem was
3057 reported to Novell and Stallion and (reportedly) is now fixed.
3059 3.11. C-KERMIT AND APOLLO SR10
3061 [ [484]Top ] [ [485]Contents ] [ [486]Section Contents ] [ [487]Next ]
3064 Reportedly, version 5A(190), when built under Apollo SR10 using "make
3065 sr10-bsd", compiles, links, and executes OK, but leaves the terminal
3066 unusable after it exits -- the "cs7" or "cs8" (character size)
3067 parameter has become cs5. The terminal must be reset from another
3068 terminal. Cause and cure unknown. Suggested workaround: Wrap Kermit in
3069 a shell script something like:
3074 3.12. C-KERMIT AND TANDY XENIX 3.0
3076 [ [489]Top ] [ [490]Contents ] [ [491]Section Contents ] [ [492]Next ]
3079 C-Kermit 7.0 was too big to be built on Tandy Xenix, even in a minimum
3080 configuration; version 6.0 is the last one that fits.
3082 Reportedly, in C-Kermit 6.0, if you type lots of Ctrl-C's during
3083 execution of the initialization file, ghost Kermit processes will be
3084 created, and will compete for the keyboard. They can only be removed
3085 via "kill -9" from another terminal, or by rebooting. Diagnosis --
3086 something strange happening with the SIGINT handler while the process
3087 is reading the directory (it seems to occur during the SET PROMPT
3088 [\v(dir)] ... sequence). Cure: unknown. Workaround: don't interrupt
3089 C-Kermit while it is executing its init file on the Tandy 16/6000.
3091 3.13. C-KERMIT AND OSF/1 (DIGITAL UNIX) (TRU64 UNIX)
3093 [ [494]Top ] [ [495]Contents ] [ [496]Section Contents ] [ [497]Next ]
3096 While putting together and testing C-Kermit 8.0, it was discovered that
3097 binaries built for one version of Tru64 Unix (e.g. 4.0G) might exhibit
3098 very strange behavior if run on a different version of Tru64 Unix (e.g.
3099 5.1A). The typical symptom was that a section of the initialization
3100 file would be skipped, notably locating the dialing and/or network
3101 directory as well as finding and executing the customization file,
3102 ~/.mykermrc. This problem also is reported to occur on Tru64 Unix 5.0
3103 (Rev 732) even when running a C-Kermit binary that was built there.
3104 However, the Tru64 5.1A binary works correctly on 5.0. Go figure.
3106 When making Telnet connections to a Digital Unix or Tru64 system, and
3107 your Telnet client forwards your user name, the Telnet server evidently
3108 stuffs the username into login's standard input, and you see:
3113 This is clearly going to play havoc with scripts that look for
3114 "login:". Workaround (when Kermit is your Telnet client): SET LOGIN
3115 USER to nothing, to prevent Kermit from sending your user ID.
3117 Before you can use a serial port on a new Digital Unix system, you must
3118 run uucpsetup to enable or configure the port. Evidently the /dev/tty00
3119 and 01 devices that appear in the configuration are not usable;
3120 uucpsetup turns them into /dev/ttyd00 and 01, which are. Note that
3121 uucpsetup and other uucp-family programs are quite primitive -- they
3122 only know about speeds up to 9600 bps and their selection of modems
3123 dates from the early 1980s. None of this affects Kermit, though -- with
3124 C-Kermit, you can use speeds up to 115200 bps (at least in DU4.0 and
3125 later) and modern modems with hardware flow control and all the rest.
3127 Reportedly, if a modem is set for &S0 (assert DSR at all times), the
3128 system resets or drops DTR every 30 seconds; reportedly DEC says to set
3131 Digital Unix 3.2 evidently wants to believe your terminal is one line
3132 longer than you say it is, e.g. when a "more" or "man" command is
3133 given. This is has nothing to do with C-Kermit, but tends to annoy
3134 those who use Kermit or other terminal emulators to access Digital Unix
3135 systems. Workaround: tell Unix to "stty rows 23" (or whatever).
3137 Reportedly, there is some bizarre behavior when trying to use a version
3138 of C-Kermit built on one Digital Unix 4.0 system on another one,
3139 possibly due to differing OS or library revision levels; for example,
3140 the inability to connect to certain TCP/IP hosts. Solution: rebuild
3141 C-Kermit from source code on the system where you will be using it.
3143 Digital Unix tgetstr() causes a segmentation fault. C-Kermit 7.0 added
3144 #ifdefs to avoid calling this routine in Digital Unix. As a result, the
3145 SCREEN commands always send ANSI escape sequences -- even though curses
3146 knows your actual terminal type.
3148 Reportedy the Tru64 Unix 4.0E 1091 Telnet server does not tolerate
3149 streaming transfers into itself, at least not when the sending Kermit
3150 is on the same local network. Solution: tell one Kermit or the other
3151 (or both) to "set streaming off". This might or might be the case with
3152 earlier and/or later Tru64, Digital Unix, and OSF/1 releases.
3154 3.14. C-KERMIT AND SGI IRIX
3156 [ [499]Top ] [ [500]Contents ] [ [501]Section Contents ] [ [502]Next ]
3160 * The [504]comp.sys.sgi.misc and [505]comp.sys.sgi.admin newsgroups.
3161 [506]The SGI website
3163 + [507]http://www-viz.tamu.edu/~sgi-faq/
3164 + [508]ftp://viz.tamu.edu/pub/sgi/faq/
3166 About IRIX version numbers: "uname -a" tells the "two-digit" version
3167 number, such as "5.3" or "6.5". The three-digit form can be seen with
3168 "uname -R". (this information is unavailable at the simple API level).
3169 Supposedly all three-digit versions within the same two-digit version
3170 (e.g. 6.5.2, 6.5.3) are binary compatible; i.e. a binary built on any
3171 one of them should run on all others. The "m" suffix denotes just
3172 patches; the "f" suffix indicates that features were added.
3174 An IRIX binary built on lower MIPS model (Instruction Set Architecture,
3175 ISA) can run on higher models, but not vice versa:
3177 MIPS1 R3000 and below
3180 MIPS4 R5000 and above
3182 Furthermore, there are different Application Binary Inferfaces (ABIs):
3184 COFF 32 bits, IRIX 5.3, 5.2, 5.1, 4.x and below
3185 o32 ELF 32 bits, IRIX 5.3, 6.0 - 6.5
3186 N32 ELF 32 bits, IRIX 6.2 - 6.5
3187 N64 ELF 64 bits, IRIX 6.2 - 6.5
3189 Thus a prebuilt IRIX binary works on a particular machine only if (a)
3190 the machine's IRIX version (to one decimal place) is equal to or
3191 greater than the version under which the binary was built; (b) the
3192 machine's MIPS level is greater or equal to that of the binary; and (c)
3193 the machine supports the ABI of the binary. If all three conditions are
3194 not satisfied, of course, you can build a binary yourself from source
3195 code since, unlike some other Unix vendors, SGI does supply a C
3196 compiler and libraries.
3198 SGI did not supply an API for hardware flow control prior to IRIX 5.2.
3199 C-Kermit 6.1 and higher for IRIX 5.2 and higher supports hardware flow
3200 control in the normal way, via "set flow rts/cts".
3202 For hardware flow control on earlier IRIX and/or C-Kermit versions, use
3203 the ttyf* (modem control AND hardware flow control) devices and not the
3204 ttyd* (direct) or ttym* (modem control but no hardware flow control)
3205 ones, and obtain the proper "hardware handshaking" cable from SGI,
3206 which is incompatible with the ones for the Macintosh and NeXT even
3207 though they look the same ("man serial" for further info) and tell
3208 Kermit to "set flow keep" and "set modem flow rts/cts".
3210 Serial speeds higher than 38400 are available in IRIX 6.2 and later, on
3211 O-class machines (e.g. Origin, Octane) only, and are supported by
3212 C-Kermit 7.0 and later. Commands such as "set speed 115200" may be
3213 given on other models (e.g. Iris, Indy, Indigo) but will fail because
3214 the OS reports an invalid speed for the device.
3216 Experimentation with both IRIX 5.3 and 6.2 shows that when logged in to
3217 IRIX via Telnet, that remote-mode C-Kermit can't send files if the
3218 packet length is greater than 4096; the Telnet server evidently has
3219 this restriction (or bug), since there is no problem sending long
3220 packets on serial or rlogin connections. However, it can receive files
3221 with no problem if the packet length is greater than 4096. As a
3222 workaround, the FAST macro for IRIX includes "set send packet-length
3223 4000". IRIX 6.5.1 does not have this problem, so evidently it was fixed
3224 some time after IRIX 6.2. Tests show file-transfer speeds are better
3225 (not worse) with 8K packets than with 4K packets from IRIX 6.5.1.
3227 Reportedly some Indys have bad serial port hardware. IRIX 5.2, for
3228 example, needs patch 151 to work around this; or upgrade to a later
3229 release. Similarly, IRIX 5.2 has several problems with serial i/o, flow
3230 control, etc. Again, patch or upgrade.
3232 Reportedly on machines with IRIX 4.0, Kermit cannot be suspended by
3233 typing the suspend ("swtch") character if it was started from csh, even
3234 though other programs can be suspended this way, and even though the Z
3235 and SUSPEND commands still work correctly. This is evidently because
3236 IRIX's csh does not deliver the SIGTSTP signal to Kermit. The reason
3237 other programs can be suspended in the same environment is probably
3238 that they do not trap SIGTSTP themselves, so the shell is doing the
3239 suspending rather than the application.
3241 Also see notes about IRIX 3.x in the [509]C-Kermit for Unix
3242 Installation Instructions.
3244 If you have problems making TCP/IP connections in versions of IRIX
3245 built with GCC 2.95.2, see the bugs section of:
3247 [510]http://freeware.sgi.com/Installable/gcc-2.95.2.html.
3249 Reportedly, if you allow gcc to compile C-Kermit on Irix you should be
3250 aware that there might be problems with some of the network code. The
3252 [511]http://freeware.sgi.com/Installable/gcc-2.95.2.html; scroll down
3253 to the "known bugs" section at the end of the document.
3255 3.15. C-KERMIT AND THE BEBOX
3257 [ [512]Top ] [ [513]Contents ] [ [514]Section Contents ] [ [515]Next ]
3260 See also: The [517]comp.sys.be newsgroup.
3262 The BeBox has been discontinued and BeOS repositioned for PC platforms.
3263 The POSIX parts of BeOS are not finished, nor is the sockets library,
3264 therefore a fully functional version of C-Kermit is not possible. In
3265 version 6.0 of C-Kermit, written for BeOS DR7, it was possible to:
3267 * set line /dev/serial2 (and probably the other serial ports)
3268 * set speed 115200 (and at least some of the lower baud rates)
3270 * set modem type hayes (and likely others, too)
3272 * set send packet-length 2048 (other lengths for both send and
3274 * set receive packet length 2048
3275 * set file type binary (text mode works, too) (with remote kermit
3276 session in server mode)
3279 * get bedrop.jpg bedrop.jpg2
3282 The following do not work:
3283 * kermit does not detect modem hangup
3284 * !/RUN/PUSH [commandline command]
3285 * Running kermit in remote mode
3286 * Using other protocols (x/y/zmodem)
3287 * TCP networking interface (Be's TCP/IP API has a ways to go, still)
3289 C-Kermit does not work on BeOS DR8 because of changes in the underlying
3290 APIs. Unfortunately not enough changes were made to allow the regular
3291 POSIX-based C-Kermit to work either. Note: the lack of a fork() service
3292 requires the select()-based CONNECT module, but there is no select().
3293 There is a select() in DR8, but it doesn't work.
3295 C-Kermit 7.0 was built for BeOS 4.5 and works in remote mode. It does
3296 not include networking support since the APIs are still not there. It
3297 is not known if dialing out works, but probably not. Be experts are
3298 welcome to lend a hand.
3300 3.16. C-KERMIT AND DG/UX
3302 [ [518]Top ] [ [519]Contents ] [ [520]Section Contents ] [ [521]Next ]
3305 Somebody downloaded the C-Kermit 6.0 binary built under DG/UX 5.40 and
3306 ran it under DG/UX 5.4R3.10 -- it worked OK except that file dates for
3307 incoming files were all written as 1 Jan 1970. Cause and cure unknown.
3308 Workaround: SET ATTRIBUTE DATE OFF. Better: Use a version of C-Kermit
3309 built under and for DG/UX 5.4R3.10.
3311 3.17. C-KERMIT AND SEQUENT DYNIX
3313 [ [523]Top ] [ [524]Contents ] [ [525]Section Contents ] [ [526]Next ]
3316 Reportedly, when coming into a Sequent Unix (DYNIX) system through an
3317 X.25 connection, Kermit doesn't work right because the Sequent's
3318 FIONREAD ioctl returns incorrect data. To work around, use the
3319 1-character-at-a-time version of myread() in ckutio.c (i.e. undefine
3320 MYREAD in ckutio.c and rebuild the program). This is unsatisfying
3321 because two versions of the program would be needed -- one for use over
3322 X.25, and the other for serial and TCP/IP connections.
3324 3.18. C-KERMIT AND FREEBSD, OPENBSD, and NETBSD
3326 [ [528]Top ] [ [529]Contents ] [ [530]Section Contents ] [ [531]Next ]
3329 Some NebBSD users have reported difficulty escaping back from CONNECT
3330 mode, usually when running NetBSD on non-PC hardware. Probably a
3333 NetBSD users have also reported that C-Kermit doesn't pop back to the
3334 prompt if the modem drops carrier. This needs to be checked out & fixed
3337 (All the above seems to work properly in C-Kermit 7.0 and later.)
3339 3.19. C-KERMIT AND MAC OS X
3341 [ [533]Top ] [ [534]Contents ] [ [535]Section Contents ] [ [536]Next ]
3344 Mac OS X is Apple's 4.4BSD Unix variety, closely related to FreeBSD,
3345 but different. "uname -a" is singularly uninformative, as in Linux,
3346 giving only the Darwin kernel version number. The way to find out the
3347 actual Mac OS X version is with
3349 /usr/bin/sw_vers -productName
3350 /usr/bin/sw_vers -productVersion
3354 fgrep -A 1 'ProductVersion'
3355 /System/Library/CoreServices/SystemVersion.plist
3357 Here are some points to be aware of:
3359 * A big gotcha for Kermit users is that Mac OS X does not support
3360 serial ports and, as far as I can tell, doesn't support its
3361 built-in modem either, for anything other than making Internet
3362 connections. Macintoshes capable of running Mac OS X, such as the
3363 G5 and later, come without serial ports and without any APIs to
3364 support them, and also without the UUCP family of programs
3365 (including cu), nor any standard for serial-port lockfile
3367 * Early versions of Mac OS X came without Curses, Termlib, or
3368 Terminfo libraries. Later versions seem to have ncurses (it would
3369 seem that Mac OS X 10.3.9 was the first mature and complete version
3370 of Mac OS X). Kermit uses curses for its file-transfer display. See
3371 elsewhere about curses-vs-ncurses confusion.
3372 * In the HFS+ file system, filenames are case-folded. Thus "makefile"
3373 and "Makefile" are the same file. So, for example, suppose you are
3374 sending two distinct files, Foo and FOO, from (say) Linux to Mac OS
3375 X. This will produce a file collision that will be handled
3376 according to Mac OS X C-Kermit's FILE COLLISION setting, which by
3377 default is BACKUP, so the Mac will wind up with files called FOO
3379 * HSF+ files that are composed of a resource fork and a data fork...
3380 I doubt that C-Kermit does anything useful with them. There is no
3381 code in C-Kermit for traditional two-forked Macintosh files, but it
3382 could be added if there is any demand (code for this existed in
3383 [538]Mac Kermit, the old pre-Mac-OS-X Macintosh version of
3385 * In case you want to transfer a traditional Macintosh text file (or
3386 data fork of a file that is plain text), you can use these C-Kermit
3390 set file character-set apple-quickdraw
3393 * File or pathnames that include spaces must be enclosed in either
3394 doublequotes or curly braces in C-Kermit commands.
3395 * Mac OS X can use a third-party package manager called "fink".
3396 Various fink packages for C-Kermit are floating around that are not
3397 standard releases. For example, there's a C-Kermit 8.0.201 package
3398 in which C-Kermit was modifed (at least) to use a UUCP lockfile
3399 directory that does not exist on vanilla Mac OS X systems.
3401 Mac OS X and Serial Ports
3403 Apple is in the forefront of companies that believe serial ports have
3404 no use in the modern world and so has simply eliminated all traces of
3405 them from its machines and OS. But of course serial ports are still
3406 needed to connect not only to external modems, but also to the control
3407 ports of hubs, routers, terminal servers, PBXs, and similar devices,
3408 not to mention barcode readers, POS systems and components, speaking
3409 devices, hand calculators such as the HP48, automated factory-floor
3410 equipment, and scientific, medical, and lab equipment (to name a few).
3411 Among workers in these areas, there is a need to add serial ports back
3412 onto this platform, which is being filled by third-party products such
3413 as the [539]Keyspan High Speed USB Serial Adapter USA-19HS, which has a
3414 DB-9 male connector. To use the Keyspan device, you must install the
3415 accompanying device drivers, which winds up giving you serial ports
3416 with names like /dev/cu.USA19H3b1P1.1, /dev/cu.KeySerial1,
3417 /dev/tty.KeySerial1.
3419 C-Kermit 9.0 works "out of the box" with third-party serial ports on
3420 Mac OS X, because it is built by default ("make macosx") without the
3421 "UUCP lockfile" feature. If you have C-Kermit 9.0 on a personal
3422 Macintosh, you can skip the next section.
3424 Mac OS X Serial Ports with C-Kermit 8.0 and earlier
3426 In earlier versions of C-Kermit, you'll need to either build a special
3427 -DNOUUCP version, or deal with the UUCP port contention sytem in
3428 [540]all its glory (this is usually an exercise in futility because any
3429 other applications on your Mac that use the serial port will not
3430 necessarily follow the same conventions):
3433 chgrp xxxx /var/spool/lock
3434 chmod g+w /var/spool/lock
3435 chgrp xxxx /dev/cu.*
3436 (where xxxx is the name of the group for users to whom serial-port
3437 access is to be granted). Use "admin" or other existing group, or
3438 create a new group if desired. NB:
3440 In the absence of official guidance from Apple or anyone else, we
3441 choose /var/spool/lock as the lockfile directory because this
3442 directory (a) already exists on vanilla Mac OS X installations, and
3443 (b) it is the directory used for serial-port lockfiles on many other
3445 2. Put all users who need access to the serial port in the same group.
3446 3. Make sure the serial device files that are to be used by C-Kermit
3447 have group read-write permission and (if you care) lack world
3448 read-write permission, e.g.:
3450 chmod g+rw,o-rw /dev/cu.*
3452 If you do the above, then there's no need to become root to use Kermit,
3453 or to make Kermit suid or sgid. Just do this:
3456 mv wermit /usr/local/kermit
3458 (or whatever spot is more appropriate, e.g. /usr/bin/). For greater
3459 detail about installation, [541]CLICK HERE.
3461 Alternatively, to build a pre-9.0 version of C-Kermit without UUCP
3462 lockfile support, set the NOUUCP flag; e.g. (for Mac OS 10.4):
3464 make macosx10.4 KFLAGS=-DNOUUCP
3466 This circumvents the SET PORT failure "?Access to lockfile directory
3467 denied". But it also sacrifices Kermit's ability to ensure that only
3468 one copy of Kermit can have the device open at a time, since Mac OS X
3469 is the same as all other varieties of Unix in that exclusive access to
3470 serial ports is not enforced in any way. But if it's for your own
3471 desktop machine that nobody else uses, a -DNOUUCP version might be
3472 adequate and preferable to the alternatives.
3474 To build C-Kermit 9.0 with UUCP support, do:
3476 make macosx KFLAGS=-UNOUUCP
3478 (note: "-U", not "-D).
3480 RS-232 versus RS-422
3482 Meanwhile, back when Macs had serial ports, they were not RS-232 (the
3483 standard for connecting computers with nearby modems) but rather RS-422
3484 or -423 (a standard for connecting serial devices over longer
3485 distances). Macintosh serial ports do not support modems well because
3486 they do not have enough wires (or more properly in the case RS-422/423,
3487 wire pairs) to convey a useful subset of modem signals.
3489 Keyspan also sells a [542]USB Twin Serial Adapter that gives you two
3490 Mini-Din8 RS-422 ports, that are no better (or worse) for communicating
3491 with modems or serial devices than a real Mac Din-8 port was. In
3492 essense, you get Data In, Data Out, and two modem signals. It looks to
3493 me as if the signals chosen by Keyspan are RTS and CTS. This gives you
3494 hardware flow control, but at the expense of Carrier Detect. Thus to
3495 use C-Kermit with a Keyspan USB serial port, you must tell C-Kermit to:
3497 set modem type none ; (don't expect a modem)
3498 set carrier-watch off ; (ignore carrier signal)
3499 set port /dev/cu.USA19H3b1P1.1 ; (open the port)
3500 set flow rts/cts ; (this is the default)
3501 set speed 57600 ; (or whatever)
3502 connect ; (or DIAL or whatever)
3504 Use Ctrl-\C in the normal manner to escape back to the C-Kermit>
3505 prompt. Kermit can't pop back to its prompt automatically when Carrier
3506 drops because there is no Carrier signal in the physical interface.
3508 Here's a typical sequence for connecting to Cisco devices (using a
3509 mixture of command-line options and interactive commands at the
3512 $ ckermit -l /dev/cu.USA19H3b1P1.1 -b 9600
3513 C-Kermit> set carrier-watch off
3516 Instructions for the built-in modem (if any) remain to be written due
3517 to lack of knowledge. If you can contribute instructions, hints, or
3518 tips, please [543]send them in.
3520 3.20. C-KERMIT AND COHERENT
3522 [ [544]Top ] [ [545]Contents ] [ [546]Section Contents ] [
3527 [548]http://www.uni-giessen.de/faq/archiv/coherent-faq.general/msg000
3530 Mark Williams COHERENT was perhaps the first commercial Unix-based
3531 operating system for PCs, first appearing about 1983 or -84 for the
3532 PC/XT (?), and popular until about 1993, when Linux took over.
3533 C-Kermit, as of version 8.0, is still current for COHERENT 386 4.2
3534 (i.e. only for i386 and above). Curses is included, but lots of other
3535 features are omitted due to lack of the appropriate OS features, APIs,
3536 libraries, hardware, or just space: e.g. TCP/IP, floating-point
3537 arithmetic, learned scripts. Earlier versions of COHERENT ran on 8086
3538 and 80286, but these are to small to build or run C-Kermit, but
3539 G-Kermit should be OK (as might be ancient versions of C-Kermit).
3541 You can actually build a version with floating point support -- just
3542 take -DNOFLOAT out of CFLAGS and add -lm to LIBS; NOFLOAT is the
3543 default because COHERENT tends to run on old PCs that don't have
3544 floating-point hardware. You can also add "-f" to CFLAGS to have it
3545 link in the floating-point emulation library. Also I'm not sure why
3546 -DNOLEARN is included, since it depends on select(), which COHERENT
3549 4. GENERAL UNIX-SPECIFIC HINTS, LIMITATIONS, AND BUGS
3551 [ [549]Top ] [ [550]Contents ] [ [551]Next ] [ [552]Previous ]
3555 There seems to be an escalating demand for the ability to control "dumb
3556 serial devices" (such as "smartcard readers", barcode readers, etc) by
3557 explicitly manipulating modem signals, particularly RTS. This might
3558 have been easy to do in DOS, where there is no operating system
3559 standing between the application and the serial device, but it is
3560 problematic in Unix, where modem signals are controlled by the serial
3561 device driver. If the driver does not provide an API for doing this,
3562 then the application can't do it. If it does provide an API, expect it
3563 to be totally different on each Unix platform, since there is no
3568 Beginning with C-Kermit 6.0, the default C-Kermit prompt includes your
3569 current (working) directory; for example:
3571 [/usr/olga] C-Kermit>
3573 (In C-Kermit 7.0 the square braces were replaced by round parentheses
3574 to avoid conflicts with ISO 646 national character sets.)
3576 If that directory is on an NFS-mounted disk, and NFS stops working or
3577 the disk becomes unavailable, C-Kermit will hang waiting for NFS and/or
3578 the disk to come back. Whether you can interrupt C-Kermit when it is
3579 hung this way depends on the specific OS. Kermit has called the
3580 operating systems's getcwd() function, and is waiting for it to return.
3581 Some versions of Unix (e.g. HP-UX 9.x) allow this function to be
3582 interrupted with SIGINT (Ctrl-C), others (such as HP-UX 8.x) do not. To
3583 avoid this effect, you can always use SET PROMPT to change your prompt
3584 to something that does not involve calling getcwd(), but if NFS is not
3585 responding, C-Kermit will still hang any time you give a command that
3586 refers to an NFS-mounted directory. Also note that in some cases, the
3587 uninterruptibility of NFS-dependent system or library calls is
3588 considered a bug, and sometimes there are patches. For HP-UX, for
3592 HP-UX 10.20 libc PHCO_8764 PHCO_14891/PHCO_16723
3593 HP-UX 10.10 libc PHCO_8763 PHCO_14254/PHCO_16722
3594 HP-UX 9.x libc PHCO_7747 S700 PHCO_13095
3595 HP-UX 9.x libc PHCO_6779 S800 PHCO_11162
3597 4.3. C-Kermit as Login Shell
3599 You might have reason to make C-Kermit the login shell for a specific
3600 user, by entering the pathname of Kermit (possibly with command-line
3601 switches, such as -x to put it in server mode) into the shell field of
3602 the /etc/passwd file. This works pretty well. In some cases, for
3603 "ultimate security", you might want to use a version built with
3604 -DNOPUSH (see the [553]Configurations Options document for this, but
3605 even if you don't, then PUSHing or shelling out from C-Kermit just
3606 brings up a new copy of C-Kermit (but warning: this does not prevent
3607 the user from explicitly running a shell; e.g. "run /bin/sh"; use
3608 NOPUSH to prevent this).
3610 4.4. C-Kermit versus screen and splitvt
3612 C-Kermit file transfers will probably not work if attemped through the
3613 "splitvt" or GNU "screen" programs because the screen optimization (or
3614 at least, line wrapping, control-character absorption) done by this
3615 package interferes with Kermit's packets.
3617 The same can apply to any other environment in which the user's session
3618 is captured, monitored, recorded, or manipulated. Examples include the
3619 'script' program (for making a typescript of a session), the
3620 Computronics PEEK package and pksh (at least versions of it prior to
3623 You might try the following -- what we call "doomsday Kermit" --
3624 settings to push packets through even the densest and most obstructive
3625 connections, such as "screen" and "splitvt" (and certain kinds of 3270
3626 protocol emulators): Give these commands to BOTH Kermit programs:
3629 SET CONTROL PREFIX ALL
3630 SET RECEIVE PACKET-LENGTH 70
3631 SET RECEIVE START 62
3636 If it works, it will be slow.
3638 4.5. C-Kermit versus DOS Emulators
3640 On Unix workstations equipped with DOS emulators like SoftPC, watch out
3641 for what these emulators do to the serial port drivers. After using a
3642 DOS emulator, particularly if you use it to run DOS communications
3643 software, you might have to reconfigure the serial ports for use by
3646 4.6. C-Kermit versus Job Control
3648 Interruption by Ctrl-Z makes Unix C-Kermit try to suspend itself with
3649 kill(0,SIGTSTP), but only on platforms that support job control, as
3650 determined by whether the symbol SIGTSTP is defined (or on POSIX or
3651 SVR4 systems, if syconf(_SC_JOB_CONTROL) or _POSIX_JOB_CONTROL in
3652 addition to SIGTSTP). However, if Kermit is running under a login shell
3653 (such as the original Bourne shell) that does not support job control,
3654 the user's session hangs and must be logged out from another terminal,
3655 or hung up on. There is no way Kermit can defend itself against this.
3656 If you use a non-job control shell on a computer that supports job
3657 control, give a command like "stty susp undef" to fix it so the suspend
3658 signal is not attached to any particular key, or give the command SET
3659 SUSPEND OFF to C-Kermit, or build C-Kermit with -DNOJC.
3661 4.7. Dates and Times
3663 Unix time conversion functions typically apply locale rules to return
3664 local time in terms of any seasonal time zone change in effect for the
3665 given date. The diffdate function assumes that the same timezone rules
3666 are in effect for both dates, but a date with timezone information will
3667 be converted to the local time zone in effect at the given time, e.g.,
3668 a GMT specification will produce either a Standard Time or Daylight
3669 Savings Time, depending on which applies at the given time. An example
3670 using the 2001 seasonal change from EDT (-0400) to EST (-0500):
3672 C-Kermit> DATE 20011028 05:01:02 GMT ; EDT
3674 C-Kermit> DATE 20011028 06:01:02 GMT ; EST
3678 but the implicit change in timezone offset is not recognized:
3680 C-Kermit> echo \fdiffdate(20011028 05:01:02 GMT, 20011028 06:01:02 GMT)
3684 Date/time arithmetic, offsets, delta times, and timezone support are
3685 new to C-Kermit 8.0, and might be expected to evolve and improve in
3686 subsequent releases.
3688 On some platforms, files downloaded with HTTP receive the current
3689 timestamp, rather than the HTTP "Last Modified" time (this can be fixed
3690 by including utime.h, e.g. in SunOS and Tru64...).
3692 4.8. Pseudoterminals
3694 The SSH and PTY commands work by assigning a pseudoterminal and reading
3695 and writing from it. Performance varies according to the specific
3696 platform ranging from very fast to very flow.
3698 SSH and PTY commands can fail if (a) all pseudoterminals are in use; or
3699 (b) you do not have read/write access to the pseudoterminal that was
3700 assigned. An example of (b) was reported with the Zipslack Slackware
3701 Linux distribution, in which the pseudoterminals were created with
3702 crw-r--r-- permission, instead of crw-rw-rw-.
3706 * Reportedly, the Unix C-Kermit server, under some conditions, on
3707 certain particular systems, fails to log out its login session upon
3708 receipt of a BYE command. Before relying on the BYE command
3709 working, test it a few times to make sure it works on your system:
3710 there might be system configuration or security mechanisms to
3711 prevent an inferior process (like Kermit) from killing a superior
3712 one (like the login shell).
3713 * On AT&T 7300 (3B1) machines, you might have to "stty nl1" before
3714 starting C-Kermit. Do this if characters are lost during
3715 communications operations.
3716 * Under the bash shell (versions prior to 1.07 from CWRU), "pushing"
3717 to an inferior shell and then exiting back to Kermit leaves Kermit
3718 in the background such that it must be explicitly fg'd. This is
3719 reportedly fixed in version 1.07 of bash (and definitely in modern
3722 5. INITIALIZATION AND COMMAND FILES
3724 [ [554]Top ] [ [555]Contents ] [ [556]Next ] [ [557]Previous ]
3726 C-Kermit's initialization file for Unix is .kermrc (lowercase, starts
3727 with period) in your home directory, unless Kermit was built with the
3728 system-wide initialization-file option (see the [558]C-Kermit for Unix
3729 Installation Instructions).
3731 C-Kermit identifies your home directory based on the environment
3732 variable, HOME. Most Unix systems set this variable automatically when
3733 you log in. If C-Kermit can't find your initialization file, check your
3736 echo $HOME (at the Unix prompt)
3740 echo \$(HOME) (at the C-Kermit prompt)
3742 If HOME is not defined, or is defined incorrectly, add the appropriate
3743 definition to your Unix .profile or .login file, depending on your
3746 setenv HOME full-pathname-of-your-home-directory (C-Shell, .login file)
3750 HOME=full-pathname-of-your-home-directory (sh, ksh, .profile file)
3753 NOTE: Various other operations depend on the correct definition of
3754 HOME. These include the "tilde-expansion" feature, which allows you to
3755 refer to your home directory as "~" in filenames used in C-Kermit
3760 as well as the \v(home) variable.
3762 Prior to version 5A(190), C-Kermit would look for its initialization
3763 file in the current directory if it was not found in the home
3764 directory. This feature was removed from 5A(190) because it was a
3765 security risk. Some people, however, liked this behavior and had
3766 .kermrc files in all their directories that would set up things
3767 appropriately for the files therein. If you want this behavior, you can
3768 accomplish it in various ways, for example:
3770 * Create a shell alias, for example:
3771 alias kd="kermit -Y ./.kermrc"
3773 * Create a .kermrc file in your home directory, whose contents are:
3776 Suppose you need to pass a password from the Unix command line to a
3777 C-Kermit script program, in such a way that it does not show up in "ps"
3778 or "w" listings. Here is a method (not guaranteed to be 100% secure,
3779 but definitely more secure than the more obvious methods):
3781 echo mypassword | kermit myscript
3783 The "myscript" file contains all the commands that need to be executed
3784 during the Kermit session, up to and including EXIT, and also includes
3785 an ASK or ASKQ command to read the password from standard input, which
3786 has been piped in from the Unix 'echo' command, but it must not include
3787 a CONNECT command. Only "kermit myscript" shows up in the ps listing.
3789 6. COMMUNICATION SPEED SELECTION
3791 [ [559]Top ] [ [560]Contents ] [ [561]Next ] [ [562]Previous ]
3793 Version-7 based Unix implementations, including 4.3 BSD and earlier and
3794 Unix systems based upon BSD, use a 4-bit field to record a serial
3795 device's terminal speed. This leaves room for 16 speeds, of which the
3796 first 14 are normally:
3798 0, 50, 75, 110, 134.5, 150, 200, 300, 600, 1200, 1800, 2400, 4800,
3801 The remaining two are usually called EXTA and EXTB, and are defined by
3802 the particular Unix implementation. C-Kermit determines which speeds
3803 are available on your system based on whether symbols for them are
3804 defined in your terminal device header files. EXTA is generally assumed
3805 to be 19200 and EXTB 38400, but these assumptions might be wrong, or
3806 they might not apply to a particular device that does not support these
3807 speeds. Presumably, if you try to set a speed that is not legal on a
3808 particular device, the driver will return an error, but this can not be
3811 On these systems, it is usually not possible to select a speed of 14400
3812 bps for use with V.32bis modems. In that case, use 19200 or 38400 bps,
3813 configure your modem to lock its interface speed and to use RTS/CTS
3814 flow control, and tell C-Kermit to SET FLOW RTS/CTS and SET DIAL
3817 The situation is similar, but different, in System V. SVID Third
3818 Edition lists the same speeds, 0 through 38400.
3820 Some versions of Unix, and/or terminal device drivers that come with
3821 certain third-party add-in high-speed serial communication interfaces,
3822 use the low "baud rates" to stand for higher ones. For example, SET
3823 SPEED 50 gets you 57600 bps; SET SPEED 75 gets you 76800; SET SPEED 110
3826 SCO ODT 3.0 is an example where a "baud-rate-table patch" can be
3827 applied that can rotate the tty driver baud rate table such that
3828 600=57600 and 1800=115k baud. Similarly for Digiboard
3829 multiport/portservers, which have a "fastbaud" setting that does this.
3830 Linux has a "setserial" command that can do it, etc.
3832 More modern Unixes support POSIX-based speed setting, in which the
3833 selection of speeds is not limited by a 4-bit field. C-Kermit 6.1
3834 incorporates a new mechanism for finding out (at compile time) which
3835 serial speeds are supported by the operating system that does not
3836 involve editing of source code by hand; on systems like Solaris 5.1,
3837 IRIX 6.2, and SCO OSR5.0.4, "set speed ?" will list speeds up to 460800
3838 or 921600. In C-Kermit 7.0 and later:
3840 1. If a symbol for a particular speed (say B230400 for 230400 bps)
3841 appears in whatever header file defines acceptable serial speeds
3842 (e.g. <termbits.h> or <sys/termios.h> or <sys/ttydev.h>, etc), the
3843 corresponding speed will appear in C-Kermit's "set speed ?" list.
3844 2. The fact that a given speed is listed in the header files and
3845 appears in C-Kermit's list does not mean the driver will accept it.
3846 For example, a computer might have some standard serial ports plus
3847 some add-on ones with different drivers that accept a different
3848 repertoire of speeds.
3849 3. The fact that a given speed is accepted by the driver does not
3850 guarantee the underlying hardware can accept it.
3852 When Kermit is given a "set speed" command for a particular device, the
3853 underlying system service is called to set the speed; its return code
3854 is checked and the SET SPEED command fails if the return code indicates
3855 failure. Regardless of the system service return status, the device's
3856 speed is then read back and if it does not match the speed that was
3857 requested, an error message is printed and the command fails.
3859 Even when the command succeeds, this does not guarantee successful
3860 operation at a particular speed, especially a high one. That depends on
3861 electricity, information theory, etc. How long is the cable, what is
3862 its capacitance, how well is it shielded, etc, not to mention that
3863 every connection has two ends and its success depends on both of them.
3864 (With the obvious caveats about internal modems, is the cable really
3865 connected, interrupt conflicts, etc etc etc).
3867 Note, in particular, that there is a certain threshold above which
3868 modems can not "autobaud" -- i.e. detect the serial interface speed
3869 when you type AT (or whatever else the modem's recognition sequence
3870 might be). Such modems need to be engaged at a lower speed (say 2400 or
3871 9600 or even 115200 -- any speed below their autobaud threshold) and
3872 then must be given a modem-specific command (which can be found in the
3873 modem manual) to change their interface speed to the desired higher
3874 speed, and then the software must also be told to change to the new,
3877 For additional information, read [563]Section 9.5 of the Installation
3878 Instructions, plus any platform-specific notes in [564]Section 3 above.
3880 7. COMMUNICATIONS AND DIALING
3882 [ [565]Top ] [ [566]Contents ] [ [567]Next ] [ [568]Previous ]
3884 7.1. Serial Ports and Modems
3886 If you SET LINE to a serial port modem-control device that has nothing
3887 plugged in to it, or has a modem connected that is powered off, and you
3888 have not given a prior SET MODEM TYPE or SET CARRIER-WATCH OFF command,
3889 the SET LINE command is likely to hang. In most cases, you can Ctrl-C
3890 out. If not, you'll have to kill C-Kermit from another terminal.
3892 Similarly, if you give a SET MODEM TYPE HAYES (or USR, or any other
3893 modem type besides DIRECT, NONE, or UNKNOWN) and then SET LINE to an
3894 empty port, the subsequent close (implicit or explicit) is liable to
3895 hang or even crash (through no fault of Kermit's -- the hanging or
3896 crashing is inside a system call such as cfsetospeed() or close()).
3898 The SET CARRIER-WATCH command works as advertised only if the
3899 underlying operating system and device drivers support this feature; in
3900 particular only if a read() operation returns immediately with an error
3901 code if the carrier signal goes away or, failing that, if C-Kermit can
3902 obtain the modem signals from the device driver (you can tell by giving
3903 a "set line" command to a serial device, and then a "show
3904 communications" command -- if modem signals are not listed, C-Kermit
3905 won't be able to detect carrier loss, the WAIT command will not work,
3906 etc). Of course, the device itself (e.g. modem) must be configured
3907 appropriately and the cables convey the carrier and other needed
3910 If you dial out from Unix system, but then notice a lot of weird
3911 character strings being stuck into your session at random times
3912 (especially if they look like +++ATQ0H0 or login banners or prompts),
3913 that means that getty is also trying to control the same device. You'll
3914 need to dial out on a device that is not waiting for a login, or else
3915 disable getty on the device.
3917 As of version 7.0, C-Kermit makes explicit checks for the Carrier
3918 Detect signal, and so catches hung-up connections much better than 6.0
3919 and earlier. However, it still can not be guaranteed to catch every
3920 ever CD on-to-off transition. For example, when the HP-UX version of
3921 C-Kermit is in CONNECT mode on a dialed connection and CARRIER-WATCH ON
3922 or AUTO, and you turn off the modem, HP-UX is stuck in a read() that
3923 never returns. (C-Kermit does not pop back to its prompt automatically,
3924 but you can still escape back.)
3926 If, on the other hand, you log out from the remote system, and it hangs
3927 up, and CD drops on the local modem, C-Kermit detects this and pops
3928 back to the prompt as it should. (Evidently there can be a difference
3929 between CD and DSR turning off at the same time, versus CD turning off
3930 while DSR stays on; experimentation with &S0/&S1/&S2 on your modem
3931 might produce the desired results).
3933 When Unix C-Kermit exits, it closes (and must close) the communications
3934 device. If you were dialed out, this will most likely hang up the
3935 connection. If you want to get out of Kermit and still use Kermit's
3936 communication device, you have several choices:
3938 1. Shell out from Kermit or suspend Kermit, and refer to the device
3939 literally (as in "term -blah -blah < /dev/cua > /dev/cua").
3940 2. Shell out from Kermit and use the device's file descriptor which
3941 Kermit makes available to you in the \v(ttyfd) variable.
3942 3. Use C-Kermit's REDIRECT command.
3943 4. Use C-Kermit new EXEC /REDIRECT command.
3945 If you are having trouble dialing:
3947 1. Make sure the dialout line is configured correctly. More about this
3949 2. Make sure all necessary patches are installed for your operating
3951 3. If you can't dial on a "bidirectional" line, then configure it for
3952 outbound-only (remove the getty) and try again. (The mechanisms --
3953 if any -- for grabbing bidirectional lines for dialout vary wildly
3954 among Unix implementations and releases, and C-Kermit -- which runs
3955 on well over 300 different Unix variations -- makes no effort to
3956 keep up with them; the recommended method for coping with this
3957 situation is to wrap C-Kermit in a shell script that takes the
3958 appropriate actions.)
3959 4. Make sure C-Kermit's SET DIAL and SET MODEM parameters agree with
3960 the modem you are actually using -- pay particular attention to SET
3961 DIAL SPEED-MATCHING.
3962 5. If MODEM HANGUP-METHOD is set to RS232-SIGNAL, change it to
3963 MODEM-COMMAND. Or vice-versa.
3964 6. Try SET DIAL HANGUP OFF before the DIAL command. Also, SET DIAL
3965 DISPLAY ON to watch what's happening. See [569]Section 8 of the
3966 [570]Installation Instructions.
3967 7. Read pages 50-67 of [571]Using C-Kermit.
3968 8. As a last resort, don't use the DIAL command at all; SET CARRIER
3969 OFF and CONNECT to the modem and dial interactively, or write a
3970 script program to dial the modem.
3972 Make sure your dialout line is correctly configured for dialing out (as
3973 opposed to login). The method for doing this is different for each kind
3974 of Unix system. Consult your system documentation for configuring lines
3975 for dialing out (for example, Sun SparcStation IPC users should read
3976 the section "Setting up Modem Software" in the Desktop SPARC Sun System
3977 & Network Manager's Guide; HP-9000 workstation users should consult the
3978 manual Configuring HP-UX for Peripherals, etc).
3980 Symptom: DIAL works, but a subsequent CONNECT command does not.
3981 Diagnosis: the modem is not asserting Carrier Detect (CD) after the
3982 connection is made, or the cable does not convey the CD signal. Cure:
3983 Reconfigure the modem, replace the cable. Workaround: SET CARRIER OFF
3984 (at least in System-V based Unix versions).
3986 For Berkeley-Unix-based systems (4.3BSD and earlier), Kermit includes
3987 code to use LPASS8 mode when parity is none, which is supposed to allow
3988 8-bit data and Xon/Xoff flow control at the same time. However, as of
3989 edit 174, this code is entirely disabled because it is unreliable: even
3990 though the host operating system might (or might not) support LPASS8
3991 mode correctly, the host access protocols (terminal servers, telnet,
3992 rlogin, etc) generally have no way of finding out about it and
3993 therefore render it ineffective, causing file transfer failures. So as
3994 of edit 174, Kermit once again uses rawmode for 8-bit data, and so
3995 there is no Xon/Xoff flow control during file transfer or terminal
3996 emulation in the Berkeley-based versions (4.3 and earlier, not 4.4).
3998 Also on Berkeley-based systems (4.3 and earlier), there is apparently
3999 no way to configure a dialout line for proper carrier handling, i.e.
4000 ignore carrier during dialing, require carrier thereafter, get a fatal
4001 error on any attempt to read from the device after carrier drops (this
4002 is handled nicely in System V by manipulation of the CLOCAL flag). The
4003 symptom is that carrier loss does not make C-Kermit pop back to the
4004 prompt automatically. This is evident on the NeXT, for example, but not
4005 on SunOS, which supports the CLOCAL flag. This is not a Kermit problem,
4006 but a limitation of the underlying operating system. For example, the
4007 cu program on the NeXT doesn't notice carrier loss either, whereas cu
4010 On certain AT&T Unix systems equipped with AT&T modems, DIAL and HANGUP
4011 don't work right. Workarounds: (1) SET DIAL HANGUP OFF before
4012 attempting to dial; (2) If HANGUP doesn't work, SET LINE, and then SET
4013 LINE <device> to totally close and reopen the device. If all else
4014 fails, SET CARRIER OFF.
4016 C-Kermit does not contain any particular support for AT&T DataKit
4017 devices. You can use Kermit software to dial in to a DataKit line, but
4018 C-Kermit does not contain the specialized code required to dial out
4019 from a DataKit line. If the Unix system is connected to DataKit via
4020 serial ports, dialout should work normally (e.g. set line /dev/ttym1,
4021 set speed 19200, connect, and then see the DESTINATION: prompt, from
4022 which you can connect to another computer on the DataKit network or to
4023 an outgoing modem pool, etc). But if the Unix system is connected to
4024 the DataKit network through the special DataKit interface board, then
4025 SET LINE to a DataKit pseudodevice (such as /dev/dk031t) will not work
4026 (you must use the DataKit "dk" or "dkcu" program instead). In C-Kermit
4027 7.0 and later, you can make Kermit connections "though" dk or dkcu
4028 using "set line /pty".
4030 In some BSD-based Unix C-Kermit versions, SET LINE to a port that has
4031 nothing plugged in to it with SET CARRIER ON will hang the program (as
4032 it should), but it can't be interrupted with Ctrl-C. The interrupt trap
4033 is correctly armed, but apparently the Unix open() call cannot be
4034 interrupted in this case. When SET CARRIER is OFF or AUTO, the SET LINE
4035 will eventually return, but then the program hangs (uninterruptibly)
4036 when the EXIT or QUIT command (or, presumably, another SET LINE
4037 command) is given. The latter is probably because of the attempt to
4038 hang up the modem. (In edit 169, a timeout alarm was placed around this
4041 With SET DIAL HANGUP OFF in effect, the DIAL command might work only
4042 once, but not again on the same device. In that case, give a CLOSE
4043 command to close the device, and then another SET LINE command to
4044 re-open the same device. Or rebuild your version of Kermit with the
4045 -DCLSOPN compile-time switch.
4047 The DIAL command says "To cancel: Type your interrupt character
4048 (normally Ctrl-C)." This is just one example of where program messages
4049 and documentation assume your interrupt character is Ctrl-C. But it
4050 might be something else. In most (but not necessarily all) cases, the
4051 character referred to is the one that generates the SIGINT signal. If
4052 Ctrl-C doesn't act as an interrupt character for you, type the Unix
4053 command "stty -a" or "stty all" or "stty everything" to see what your
4054 interrupt character is. (Kermit could be made to find out what the
4055 interrupt character is, but this would require a lot of
4056 platform-dependent coding and #ifdefs, and a new routine and interface
4057 between the platform-dependent and platform-independent parts of the
4060 In general, the hangup operation on a serial communication device is
4061 prone to failure. C-Kermit tries to support many, many different kinds
4062 of computers, and there seems to be no portable method for hanging up a
4063 modem connection (i.e. turning off the RS-232 DTR signal and then
4064 turning it back on again). If HANGUP, DIAL, and/or Ctrl-\H do not work
4065 for you, and you are a programmer, look at the tthang() function in
4066 ckutio.c and see if you can add code to make it work correctly for your
4067 system, and send the code to the address above. (NOTE: This problem has
4068 been largely sidestepped as of edit 188, in which Kermit first attempts
4069 to hang up the modem by "escaping back" via +++ and then giving the
4070 modem's hangup command, e.g. ATH0, when DIAL MODEM-HANGUP is ON, which
4071 is the default setting.)
4073 Even when Kermit's modem-control software is configured correctly for
4074 your computer, it can only work right if your modem is also configured
4075 to assert the CD signal when it is connected to the remote modem and to
4076 hang up the connection when your computer drops the DTR signal. So
4077 before deciding Kermit doesn't work with your modem, check your modem
4078 configuration AND the cable (if any) connecting your modem to the
4079 computer -- it should be a straight-through [572]modem cable conducting
4080 the signals FG, SG, TD, RD, RTS, CTS, DSR, DTR, CD, and RI.
4082 Many Unix systems keep aliases for dialout devices; for example,
4083 /dev/acu might be an alias for /dev/tty00. But most of these Unix
4084 systems also use UUCP lockfile conventions that do not take this
4085 aliasing into account, so if one user assigns (e.g.) /dev/acu, then
4086 another user can still assign the same device by referring to its other
4087 name. This is not a Kermit problem -- Kermit must follow the lockfile
4088 conventions used by the vendor-supplied software (cu, tip, uucp).
4090 The SET FLOW-CONTROL KEEP option should be given *before* any
4091 communication (dialing, terminal emulation, file transfer,
4092 INPUT/OUTPUT/TRANSMIT, etc) is attempted, if you want C-Kermit to use
4093 all of the device's preexisting flow-control related settings. The
4094 default flow-control setting is XON/XOFF, and it will take effect when
4095 the first communication-related command is given, and a subsequent SET
4096 FLOW KEEP command will not necessarily know how to restore *all* of the
4097 device's original flow-control settings.
4099 7.2. Network Connections
4101 C-Kermit tries to use the 8th bit for data when parity is NONE, and
4102 this generally works on real Unix terminal (tty) devices, but it often
4103 does not work when the Unix system is accessed over a network via
4104 telnet or rlogin protocols, including (in many cases) through terminal
4105 servers. For example, an Encore computer with Annex terminal servers
4106 only gives a 7-bit path if the rlogin protocol is selected in the
4107 terminal server but it gives the full 8 bits if the proprietary RDP
4110 If file transfer does not work through a host to which you have
4111 rlogin'd, use "rlogin -8" rather than "rlogin". If that doesn't work,
4112 tell both Kermit programs to "set parity space".
4114 The Encore TELNET server does not allow long bursts of input. When you
4115 have a TELNET connection to an Encore, tell C-Kermit on the Encore to
4116 SET RECEIVE PACKET-LENGTH 200 or thereabouts.
4118 8. HARDWARE FLOW CONTROL
4120 [ [573]Top ] [ [574]Contents ] [ [575]Next ] [ [576]Previous ]
4122 SET FLOW RTS/CTS is available in Unix C-Kermit only when the underlying
4123 operating system provides an Application Program Interface (API) for
4124 turning this feature on and off under program control, which turns out
4125 to be a rather rare feature among Unix systems. To see if your Unix
4126 C-Kermit version supports hardware flow control, type "set flow ?" at
4127 the C-Kermit prompt, and look for "rts/cts" among the options. Other
4128 common situations include:
4130 1. The API is available, so "set flow rts/cts" appears as a valid
4131 C-Kermit command, but it doesn't do anything because the device
4132 driver (part of the operating system) was never coded to do
4133 hardware flow control. This is common among System V R4
4134 implementations (details below).
4135 2. The API is not available, so "set flow rts/cts" does NOT appear as
4136 a valid C-Kermit command, but you can still get RTS/CTS flow
4137 control by selecting a specially named device in your SET LINE
4139 + NeXTSTEP: /dev/cufa instead of /dev/cua, /dev/cufb instead of
4140 /dev/cub (68040 only; "man zs" for further info).
4141 + IRIX: /dev/ttyf2 instead of /dev/ttyd2 or /dev/ttym2 ("man 7
4143 3. The API is available, doesn't work, but a workaround as in (2) can
4145 4. The API is available, but Kermit doesn't know about it. In these
4146 cases, you can usually use an stty command to enable RTS/CTS on the
4147 device, e.g. "stty crtscts" or "stty ctsflow", "stty rtsflow",
4148 before starting Kermit, and then tell Kermit to SET FLOW KEEP.
4149 5. No API and no special device drivers. Hardware flow control is
4150 completely unavailable.
4152 System V R4 based Unixes are supposed to supply a <termiox.h> file,
4153 which gives Kermit the necessary interface to command the terminal
4154 driver to enable/disable hardware flow control. Unfortunately, but
4155 predictably, many implementations of SVR4 whimsically place this file
4156 in /usr/include/sys rather than /usr/include (where SVID clearly
4157 specifies it should be; see SVID, Third Edition, V1, termiox(BA_DEV).
4158 Thus if you build C-Kermit with any of the makefile entries that
4159 contain -DTERMIOX or -DSTERMIOX (the latter to select <sys/termiox.h>),
4160 C-Kermit will have "set flow rts/cts" and possibly other hardware
4161 flow-control related commands. BUT... That does not necessarily mean
4162 that they will work. In some cases, the underlying functions are simply
4163 not coded into the operating system.
4165 WARNING: When hardware flow control is available, and you enable in
4166 Kermit on a device that is not receiving the CTS signal, Kermit can
4167 hang waiting for CTS to come up. This is most easily seen when the
4168 local serial port has nothing plugged in to it, or is connected to an
4169 external modem that is powered off.
4171 9. TERMINAL CONNECTION AND KEY MAPPING
4173 [ [577]Top ] [ [578]Contents ] [ [579]Next ] [ [580]Previous ]
4175 C-Kermit is not a terminal emulator. Refer to page 147 of [581]Using
4176 C-Kermit, 2nd Edition: "Most versions of C-Kermit -- Unix, VMS, AOS/VS,
4177 VOS, etc -- provide terminal connection without emulation. These
4178 versions act as a 'semitransparent pipe' between the remote computer
4179 and your terminal, terminal emulator, console driver, or window, which
4180 in turn emulates (or is) a specific kind of terminal." The environment
4181 in which you run C-Kermit is up to you.
4183 If you are an X Windows user, you should be aware of an alternative to
4184 xterm that supports VT220 emulation, from Thomas E. Dickey:
4186 [582]http://dickey.his.com/xterm/xterm.html
4188 Unix C-Kermit's SET KEY command currently can not be used with keys
4189 that generate "wide" scan codes or multibyte sequences, such as
4190 workstation function or arrow keys, because Unix C-Kermit does not have
4191 direct access to the keyboard.
4193 However, many Unix workstations and/or console drivers provide their
4194 own key mapping feature. With xterm, for example, you can use 'xmodmap'
4195 ("man xmodmap" for details); here is an xterm mapping to map the Sun
4196 keyboard to DEC VT200 values for use with VT-terminal oriented
4197 applications like VMS EVE:
4212 keycode 57=KP_Decimal
4215 keycode 30=KP_Separator
4217 keycode 78=KP_Subtract
4224 Users of Linux consoles can use loadkeys ("man dumpkeys loadkeys
4225 keytables" for details. The format used by loadkeys is compatible with
4226 that used by Xmodmap, although it is not definitely certain that the
4227 keycodes are compatible for different keyboard types (e.g. Sun vs HP vs
4232 [ [583]Top ] [ [584]Contents ] [ [585]Next ] [ [586]Previous ]
4234 On most platforms, C-Kermit can not handle files longer than 2^31 or
4235 2^32 bytes long, because it uses the traditional file i/o APIs that use
4236 32-bit words to represent the file size. To accommodate longer files,
4237 we would have to switch to a new and different API. Unfortunately, each
4238 platform has a different one, a nightmare to handle in portable code.
4239 The C-Kermit file code was written in the days long before files longer
4240 than 2GB were supported or even contemplated in the operating systems
4243 If uploads (or downloads) fail immediately, give the CAUTIOUS command
4244 to Kermit and try again. If they still fail, then try SET PREFIXING
4245 ALL. If they still fail, try SET PARITY SPACE. If they still fail, try
4248 If reception (particularly of large files and/or binary files) begins
4249 successfully but then fail constently after a certain amount of bytes
4250 have been sent, check:
4252 * Your ulimit ("ulimit -a")
4253 * The amount of available space on the target disk ("df ." or "df -k
4255 * Your personal disk quota (platform- and site-dependent)
4256 * The maximum file size on the receiver's file system (e.g. 2GB in
4257 old verions the Linux VFS file system, and/or in applications that
4258 have not been recoded to use new "large file" APIs).
4259 * If it's an NFS-mounted disk (if so, try uploading to a local disk)
4260 * Is there an "idle limit" on the receiving end?
4262 If none of these seem to explain it, then the problem is not size
4263 related, but reflects some clash between the file contents and the
4264 characteristics of the connection, in which case follow the
4265 instructions in the first paragraph of this section.
4267 Suppose two copies of Kermit are receiving files into the same
4268 directory, and the files have the same name, e.g. "foo.bar". Whichever
4269 one starts first opens an output file called "foo.bar". The second one
4270 sees there is already a foo.bar file, and so renames the existing
4271 foo.bar to foo.bar.~1~ (or whatever). When the first file has been
4272 received completely, Kermit goes to change its modification time and
4273 permissions to those given by the file sender in the Attribute packet.
4274 But in Unix, the APIs for doing this take a filename, not a file
4275 descriptor. Since the first Kermit's file has been renamed, and the
4276 second Kermit is using the original name, the first Kermit changes the
4277 modtime and permissions of the second Kermit's file, not its own.
4278 Although there might be a way to work around this in the code, e.g.
4279 using inode numbers to keep track of which file is which, this would be
4280 tricky and most likely not very portable. It's better to set up your
4281 application to prevent such things from happening, which is easy enough
4282 using the script language, filename templates, etc.
4284 Suppose you start C-Kermit with a command-line argument to send or
4285 receive a file (e.g. "kermit -r") and then type Ctrl-\c immediately
4286 afterwards to escape back and initiate the other end of the transfer,
4287 BUT your local Kermit's escape character is not Ctrl-\. In this case,
4288 the local Kermit passes the Ctrl-\ to the remote system, and if this is
4289 Unix, Ctrl-\ is likely to be its SIGQUIT character, which causes the
4290 current program to halt and dump core. Well, just about the first thing
4291 C-Kermit does when it starts is to disable the SIGQUIT signal. However,
4292 it is still possible for SIGQUIT to cause Kermit to quit and dump core
4293 if it is delivered while Kermit is being loaded or started, before the
4294 signal can be disabled. There's nothing Kermit itself can do about
4295 this, but you can prevent it from happening by disabling SIGQUIT in
4296 your Unix session. The command is usually something like:
4300 Unix C-Kermit does not reject incoming files on the basis of size.
4301 There appears to be no good (reliable, portable) way to determine in
4302 advance how much disk space is available, either on the device, or
4303 (when quotas or other limits are involved) to the user.
4305 Unix C-Kermit discards all carriage returns from incoming files when in
4308 If C-Kermit has problems creating files in writable directories when it
4309 is installed setuid or setgid on BSD-based versions of Unix such as
4310 NeXTSTEP 3.0, it probably needs to be rebuilt with the -DSW_ACC_ID
4313 If you SET FILE DISPLAY FULLSCREEN, and C-Kermit complains "Sorry,
4314 terminal type not supported", it means that the terminal library
4315 (termcap or termlib) that C-Kermit was built with does not know about a
4316 terminal whose name is the current value of your TERM environment
4317 variable. If this happens, but you want to have the fullscreen file
4318 transfer display, EXIT from C-Kermit and set a Unix terminal type from
4319 among the supported values that is also supported by your terminal
4320 emulator, or else have an entry for your terminal type added to the
4321 system termcap and/or terminfo database.
4323 If you attempt to suspend C-Kermit during local-mode file transfer and
4324 then continue it in the background (via bg), it will block for "tty
4325 output" if you are using the FULLSCREEN file transfer display. This is
4326 apparently a problem with curses. Moving a local-mode file transfer
4327 back and forth between foreground and background works correctly,
4328 however, with the SERIAL, CRT, BRIEF, or NONE file transfer displays.
4330 If C-Kermit's command parser no longer echoes, or otherwise acts
4331 strangely, after returning from a file transfer with the fullscreen
4332 (curses) display, and the curses library for your version of Unix
4333 includes the newterm() function, then try rebuilding your version of
4334 C-Kermit with -DCK_NEWTERM. Similarly if it echoes doubly, which might
4335 even happen during a subsequent CONNECT session. If rebuilding with
4336 -DCK_NEWTERM doesn't fix it, then there is something very strange about
4337 your system's curses library, and you should probably not use it. Tell
4338 C-Kermit to SET FILE DISPLAY CRT, BRIEF, or anything else other than
4339 FULLSCREEN, and/or rebuild without -DCK_CURSES, and without linking
4340 with (termlib and) curses. Note: This problem seemed to have escalated
4341 in C-Kermit 7.0, and -DCK_NEWTERM had to be added to many builds that
4342 previously worked without it: Linux, AIX 4.1, DG/UX, etc. In the Linux
4343 case, it is obviously because of changes in the (n)curses library; the
4344 cause in the other cases is not known.
4346 C-Kermit creates backup-file names (such as "oofa.txt.~1~") based on
4347 its knowledge of the maximum filename length on the platform where it
4348 is running, which is learned at compile time, based on MAXNAMLEN or
4349 equivalent symbols from the system header files. But suppose C-Kermit
4350 is receiving files on a Unix platform that supports long filenames, but
4351 the incoming files are being stored on an NFS-mounted file system that
4352 supports only short names. NFS maps the external system to the local
4353 APIs, so C-Kermit has no way of knowing that long names will be
4354 truncated. Or that C-Kermit is running on a version of Unix that
4355 supports both long-name and short-name file systems simultaneously
4356 (such as HP-UX 7.00). This can cause unexpected behavior when creating
4357 backup files, or worse. For example, you are sending a group of files
4358 whose names are differentiated only by characters past the point at
4359 which they would be truncated, each file will overwrite the previous
4362 11. EXTERNAL FILE TRANSFER PROTOCOLS
4364 [ [587]Top ] [ [588]Contents ] [ [589]Next ] [ [590]Previous ]
4368 11.1. [591]C-Kermit as an External Protocol
4369 11.2. [592]Invoking External Protocols from C-Kermit
4371 Unix C-Kermit can be used in conjunction with other communications
4372 software in various ways. C-Kermit can be invoked from another
4373 communications program as an "external protocol", and C-Kermit can also
4374 invoke other communication software to perform external protocols.
4376 This sort of operation makes sense only when you are dialing out from
4377 your Unix system (or making a network connection from it). If the Unix
4378 system is the one you have dialed in to, you don't need any of these
4379 tricks. Just run the desired software on your Unix system instead of
4380 Kermit. When dialing out from a Unix system, the difficulty is getting
4381 two programs to share the same communication device in spite of the
4382 Unix UUCP lockfile mechanism, which would normally prevent any sharing,
4383 and preventing the external protocol from closing (and therefore
4384 hanging up) the device when it exits back to the program that invoked
4387 11.1. C-KERMIT AS AN EXTERNAL PROTOCOL
4389 [ [593]Top ] [ [594]Contents ] [ [595]Section Contents ] [ [596]Next ]
4391 (This section deleted; see [597]Using C-Kermit, 2nd Ed, Chapter 14.)
4393 "pcomm" is a general-purpose terminal program that provides file
4394 transfer capabilities itself (X- and YMODEM variations) and the ability
4395 to call on external programs to do file transfers (ZMODEM and Kermit,
4396 for example). You can tell pcomm the command to send or receive a file
4397 with an external protocol:
4399 ZMODEM sz filename rz
4400 Kermit kermit -s filename kermit -r
4402 pcomm runs external programs for file transfer by making stdin and
4403 stdout point to the modem port, and then exec-ing "/bin/sh -c xxx"
4404 (where xxx is the appropriate command). However, C-Kermit does not
4405 treat stdin and stdout as the communication device unless you instruct
4410 Kermit kermit -l 0 -s filename kermit -l 0 -r
4412 The "-l 0" option means to use file descriptor 0 for the communication
4415 In general, any program can pass any open file descriptor to C-Kermit
4416 for the communication device in the "-l" command-line option. When
4417 Kermit is given a number as the argument to the "-l" option, it simply
4418 uses it as a file descriptor, and it does not attempt to close it upon
4421 Here's another example, for Seyon (a Linux communication program).
4422 First try the technique above. If that works, fine; otherwise... If
4423 Seyon does not give you a way to access and pass along the file
4424 descriptor, but it starts up the Kermit program with its standard i/o
4425 redirected to its (Seyon's) communications file descriptor, you can
4426 also experiment with the following method, which worked here in brief
4427 tests on SunOS. Instead of having Seyon use "kermit -r" or "kermit -s
4428 filename" as its Kermit protocol commands, use something like this
4429 (examples assume C-Kermit 6.0):
4431 For serial connections:
4433 kermit -YqQl 0 -r <-- to receive
4434 kermit -YqQl 0 -s filename(s) <-- to send one or more files
4436 For Telnet connections:
4438 kermit -YqQF 0 -r <-- to receive
4439 kermit -YqQF 0 -s filename(s) <-- to send one or more files
4441 Command line options:
4443 Y - skip executing the init file
4444 Q - use fast file transfer settings (default in 8.0)
4445 l 0 - transfer files using file descriptor 0 for a serial connection
4446 F 0 - transfer files using file descriptor 0 for a Telnet connection
4447 q - quiet - no messages
4451 11.2. INVOKING EXTERNAL PROTOCOLS FROM C-KERMIT
4453 [ [598]Top ] [ [599]Contents ] [ [600]Section Contents ] [
4456 (This section is obsolete, but not totally useless. See Chapter 14
4457 of [602]Using C-Kermit, 2nd Edition).
4459 After you have opened a communication link with C-Kermit's SET LINE
4460 (SET PORT) or SET HOST (TELNET) command, C-Kermit makes its file
4461 descriptor available to you in the \v(ttyfd) variable so you can pass
4462 it along to other programs that you RUN from C-Kermit. Here, for
4463 example, C-Kermit runs itself as an external protocol:
4465 C-Kermit>set modem type hayes
4466 C-Kermit>set line /dev/acu
4467 C-Kermit>set speed 2400
4468 C-Kermit>dial 7654321
4470 C-Kermit>echo \v(ttyfd)
4472 C-Kermit>run kermit -l \v(ttyfd)
4474 Other programs that accept open file descriptors on the command line
4475 can be started in the same way.
4477 You can also use your shell's i/o redirection facilities to assign
4478 C-Kermit's open file descriptor (ttyfd) to stdin or stdout. For
4479 example, old versions of the Unix ZMODEM programs, sz and rz, when
4480 invoked as external protocols, expect to find the communication device
4481 assigned to stdin and stdout with no option for specifying any other
4482 file descriptor on the sz or rz command line. However, you can still
4483 invoke sz and rz as exterior protocols from C-Kermit if your current
4484 shell ($SHELL variable) is ksh (the Korn shell) or bash (the
4485 Bourne-Again shell), which allows assignment of arbitrary file
4486 descriptors to stdin and stdout:
4488 C-Kermit> run rz <&\v(ttyfd) >&\v(ttyfd)
4492 C-Kermit> run sz oofa.zip <&\v(ttyfd) >&\v(ttyfd)
4494 In version 5A(190) and later, you can use C-Kermit's REDIRECT command,
4495 if it is available in your version of C-Kermit, to accomplish the same
4496 thing without going through the shell:
4498 C-Kermit> redirect rz
4502 C-Kermit> redirect sz oofa.zip
4504 A complete set of rz,sz,rb,sb,rx,sx macros for Unix C-Kermit is defined
4505 in the file ckurzsz.ini. It automatically chooses the best redirection
4506 method (but is redundant since C-Kermit 6.0, which now has built-in
4507 support for external protocols via its SET PROTOCOL command).
4509 Note that external protocols can be used on C-Kermit SET LINE or SET
4510 HOST connections only if they operate through standard input and
4511 standard output. If they open their own connections, Kermit can't
4512 redirect them over its own connection.
4516 [ [603]Top ] [ [604]Contents ] [ [605]Next ] [ [606]Previous ]
4518 As of version 7.0, C-Kermit supports a wide range of security options
4519 for authentication and encryption: Kerberos 4, Kerberos 5 / GSSAPI,
4520 SSL/TLS, and SRP. See the separate [607]security document for details.
4522 13. MISCELLANEOUS USER REPORTS
4524 [ [608]Top ] [ [609]Contents ] [ [610]Next ] [ [611]Previous ]
4526 Date: Thu, 12 Mar 92 1:59:25 MEZ
4527 From: Walter Mecky <walter@rent-a-guru.de>
4528 Subject: Help.Unix.sw
4529 To: svr4@pcsbst.pcs.com, source@usl.com
4532 RELEASE: Dell SVR4 V2.1 (is USL V3.0)
4534 PATHNAME: /usr/lib/libc.so.1
4536 ABSTRACT: Function ttyname() does not close its file descriptor
4538 ttyname(3C) opens /dev but never closes it. So if it is called
4539 often enough the open(2) in ttyname() fails. Because the broken
4540 ttyname() is in the shared lib too all programs using it can
4541 fail if they call it often enough. One important program is
4542 uucico which calls ttyname for every file it transfers.
4545 Here is a little test program if your system has the bug:
4551 while (ttyname(0) != NULL)
4554 printf("i=%d\n", i);
4557 If this program runs longer than some seconds you don't have the bug.
4559 WORKAROUND: None FIX: Very easy if you have source code.
4561 Another user reports some more explicit symptoms and recoveries:
4563 > What happens is when invoking ckermit we get one of the following
4567 > No more processes.
4568 > One of the following three actions clears the peoblem:
4569 > shutdown -y -g0 -i6
4570 > kill -9 the ttymon with the highest PID
4571 > Invoke sysadm and disable then enable the line you want to use.
4572 > Turning off respawn of sac -t 300 and going to getty's and uugetty's
4575 > Also C-Kermit reports "?timed out closing /dev/ttyxx".
4576 > If this happens all is well.
4578 ------------------------------
4580 (Note: the following problem also occurs on SGI and probably many other
4583 From: James Spath <spath@jhunix.hcf.jhu.edu>
4584 To: Info-Kermit-Request@cunixf.cc.columbia.edu
4585 Date: Wed, 9 Sep 1992 20:20:28 -0400
4586 Subject: C-Kermit vs uugetty (or init) on Sperry 5000
4588 We have successfully compiled the above release on a Unisys/Sperry
4589 5000/95. We used the sys5r3 option, rather than sys5r2 since we have
4590 VR3 running on our system. In order to allow dialout access to
4591 non-superusers, we had to do "chmod 666 /dev/tty###, where it had been
4592 -rw--w--w- (owned by uucp), and to do "chmod +w /usr/spool/locks". We
4593 have done text and binary file transfers through local and remote
4596 The problem concerning uucp ownership and permissions is worse than I
4597 thought at first. Apparently init or uugetty changes the file
4598 permissions after each session. So I wrote the following C program to
4599 open a set of requested tty lines. I run this for any required outgoing
4600 line prior to a Kermit session.
4602 ------ cut here -------
4603 /* opentty.c -- force allow read on tty lines for modem i/o */
4604 /* idea from: restrict.c -- System 5 Admin book Thomas/Farrow p. 605 */
4605 /* /jes jim spath {spath@jhunix.hcj.jhu.edu } */
4606 /* 08-Sep-92 NO COPYRIGHT. */
4607 /* this must be suid to open other tty lines */
4610 #define TTY "/dev/tty"
4611 #define LOK "/usr/spool/locks/LCK..tty"
4614 /* allowable lines: */
4615 #define TOTAL_LINES 3
4616 static char allowable[TOTAL_LINES][4] = { "200", "201", "300" };
4617 static int total=TOTAL_LINES;
4626 int argc; char *argv[]; {
4631 fprintf(stderr, "usage: open 200 [...]\n");
4633 while (--argc > 0 && (*++argv) != NULL ) {
4635 fprintf(stderr, "TRYING: %s%s\n", TTY, *argv);
4637 sprintf(device, "%s%s", TTY, *argv);
4638 sprintf(lockdev, "%s%s", LOK, *argv);
4639 allow = TTY_UNDEF; i = 0;
4640 while (i <= total) { /* look at all defined lines */
4642 fprintf(stderr, "LOCKFILE? %s?\n", lockdev);
4644 if (access(lockdev, 00) == 0) {
4649 fprintf(stderr, "DOES:%s==%s?\n", allowable[i], *argv);
4651 if (strcmp(allowable[i], *argv) == 0)
4656 fprintf(stderr, "allow=%d\n", allow);
4660 fprintf (stderr, "open: not allowed on %s\n", *argv);
4663 fprintf (stderr, "open: device locked: %s\n", lockdev);
4666 /* attempt to change mode on device */
4667 if (chmod (device, 00666) < 0)
4668 fprintf (stderr, "open: cannot chmod on %s\n", device);
4671 fprintf (stderr, "open: FAULT\n");
4677 14. THIRD-PARTY DRIVERS
4679 [ [612]Top ] [ [613]Contents ] [ [614]Next ] [ [615]Previous ]
4681 Unix versions, especially those for PCs (SCO, Unixware, etc) might be
4682 augmented by third-party communication-board drivers from Digiboard,
4683 Stallion, etc. These can sometimes complicate matters for Kermit
4684 considerably since Kermit has no way of knowing that it is going
4685 through a possibly nonstandard driver. Various examples are listed in
4686 the earlier sections of this document; search for Stallion, Digiboard,
4689 * The Stallion Technologies EasyConnection serial board driver does
4690 not always report the state of DSR as low. From Stallion (October
4691 1997): "Unfortunately, this is a bug in our driver. We have
4692 implemented all of the other TIOMC functions, eg DTR, DCD, RTS and
4693 CTS, but not DSR. Our driver should report the actual state of DSR
4694 on those of our cards that have a DSR signal. That the driver
4695 always reports DSR as not asserted (0), is a bug in the driver. The
4696 driver should be either reporting the state of DSR correctly on
4697 those cards that support DSR or as always asserted (1) on those
4698 cards that do not have a DSR signal. This will be fixed in a future
4699 version of our drivers; at this time I cannot say when this will
4700 be." And later, "As far as I can tell, we don't support the
4701 termios/termiox ioctls that relate specifically to DSR and RI; all
4702 the rest are supported. This will, as I mentioned earlier, be fixed
4703 in the next release of our ATA software."
4704 - World Wide Escalation Support, Stallion Technologies, Toowong
4705 QLD, [616]support@stallion.oz.au.
4707 Later (December 1997, from the same source):
4709 * We have now released a new version of the ATA software, version
4710 5.4.0. This version fixes the problem with the states of the DSR
4711 and RI signals and how they were being reported by the driver. This
4712 is the problem that you reported in October. The DSR signal is
4713 reported correctly on those cards that support the DSR signal, such
4714 as the early revision of the EasyIO card and the EasyConnection 8D4
4715 panel, and as always asserted on those cards that do not support
4716 the DSR signal in the hardware. The new driver is available from
4717 our Web site, [617]www.stallion.com, in the /drivers/ata5/UnixWare
4720 [ [618]Top ] [ [619]Contents ] [ [620]C-Kermit Home ] [ [621]C-Kermit
4721 8.0 Overview ] [ [622]Kermit Home ]
4722 __________________________________________________________________
4724 C-Kermit 8.0 Unix Hints and Tips / [623]The Kermit Project /
4725 [624]Columbia University / [625]kermit@columbia.edu
4729 1. http://www.columbia.edu/
4730 2. mailto:kermit@columbia.edu
4731 3. http://www.columbia.edu/kermit/index.html
4732 4. http://www.columbia.edu/kermit/k95.html
4733 5. http://www.columbia.edu/kermit/ckermit.html
4734 6. http://www.columbia.edu/kermit/ckscripts.html
4735 7. http://www.columbia.edu/kermit/current.html
4736 8. http://www.columbia.edu/kermit/whatsnew.html
4737 9. http://www.columbia.edu/kermit/faq.html
4738 10. http://www.columbia.edu/kermit/support.html
4739 11. http://www.columbia.edu/kermit/
4740 12. http://www.columbia.edu/
4741 13. http://www.columbia.edu/kermit/ckubwr.html
4742 14. mailto:kermit-support@columbia.edu
4743 15. http://www.columbia.edu/kermit/ckermit.html
4744 16. http://www.columbia.edu/kermit/ckuins.html
4745 17. http://www.columbia.edu/kermit/ckututor.html
4746 18. http://www.columbia.edu/kermit/ckubwr.html#x1
4747 19. http://www.columbia.edu/kermit/ckubwr.html#x2
4748 20. http://www.columbia.edu/kermit/ckubwr.html#x3
4749 21. http://www.columbia.edu/kermit/ckubwr.html#x4
4750 22. http://www.columbia.edu/kermit/ckubwr.html#x5
4751 23. http://www.columbia.edu/kermit/ckubwr.html#x6
4752 24. http://www.columbia.edu/kermit/ckubwr.html#x7
4753 25. http://www.columbia.edu/kermit/ckubwr.html#x8
4754 26. http://www.columbia.edu/kermit/ckubwr.html#x9
4755 27. http://www.columbia.edu/kermit/ckubwr.html#x10
4756 28. http://www.columbia.edu/kermit/ckubwr.html#x11
4757 29. http://www.columbia.edu/kermit/ckubwr.html#x12
4758 30. http://www.columbia.edu/kermit/ckubwr.html#x13
4759 31. http://www.columbia.edu/kermit/ckubwr.html#x14
4760 32. http://www.columbia.edu/kermit/ckubwr.html#x3.3
4761 33. http://www.columbia.edu/kermit/ckubwr.html#x3.18
4762 34. http://www.columbia.edu/kermit/ckubwr.html#x3.19
4763 35. http://www.columbia.edu/kermit/ckubwr.html#x3.1
4764 36. http://www.columbia.edu/kermit/ckubwr.html#x3.2
4765 37. http://www.columbia.edu/kermit/ckubwr.html#x3.7
4766 38. http://www.columbia.edu/kermit/ckubwr.html#x3.6
4767 39. http://www.columbia.edu/kermit/ckubwr.html#x3.13
4768 40. http://www.columbia.edu/kermit/ckubwr.html#top
4769 41. http://www.columbia.edu/kermit/ckubwr.html#contents
4770 42. http://www.columbia.edu/kermit/ckubwr.html#x2
4771 43. http://www.columbia.edu/kermit/ckubwr.html#x1.1
4772 44. http://www.columbia.edu/kermit/ckubwr.html#x1.2
4773 45. http://www.columbia.edu/kermit/ckubwr.html#x1.3
4774 46. http://www.columbia.edu/kermit/ckubwr.html#x1.4
4775 47. http://www.columbia.edu/kermit/ckubwr.html#x3.3
4776 48. http://www.columbia.edu/kermit/ckubwr.html#x3.1
4777 49. http://www.columbia.edu/kermit/ckubwr.html#x3.2
4778 50. http://www.columbia.edu/kermit/ckubwr.html#x3.7
4779 51. http://www.columbia.edu/kermit/ckcbwr.html
4780 52. mailto:kermit-support@columbia.edu
4781 53. http://www.columbia.edu/kermit/ckubwr.html#top
4782 54. http://www.columbia.edu/kermit/ckubwr.html#contents
4783 55. http://www.columbia.edu/kermit/ckubwr.html#x1.2
4784 56. http://www.columbia.edu/kermit/ck60manual.html
4785 57. http://www.columbia.edu/kermit/ckermit70.html
4786 58. http://www.columbia.edu/kermit/ckermit80.html
4787 59. http://www.columbia.edu/kermit/ckermit90.html
4788 60. http://www.columbia.edu/kermit/ckubwr.html#top
4789 61. http://www.columbia.edu/kermit/ckubwr.html#contents
4790 62. http://www.columbia.edu/kermit/ckubwr.html#x1
4791 63. http://www.columbia.edu/kermit/ckubwr.html#x1.3
4792 64. http://www.columbia.edu/kermit/ckubwr.html#x1.1
4793 65. http://www.columbia.edu/kermit/support.html
4794 66. http://www.columbia.edu/kermit/ckubwr.html#top
4795 67. http://www.columbia.edu/kermit/ckubwr.html#contents
4796 68. http://www.columbia.edu/kermit/ckubwr.html#x1
4797 69. http://www.columbia.edu/kermit/ckubwr.html#x1.4
4798 70. http://www.columbia.edu/kermit/ckubwr.html#x1.2
4799 71. http://www.columbia.edu/kermit/ckubwr.html#top
4800 72. http://www.columbia.edu/kermit/ckubwr.html#contents
4801 73. http://www.columbia.edu/kermit/ckubwr.html#x1
4802 74. http://www.columbia.edu/kermit/ckubwr.html#x1.3
4803 75. http://www.columbia.edu/kermit/ckubwr.html#top
4804 76. http://www.columbia.edu/kermit/ckubwr.html#contents
4805 77. http://www.columbia.edu/kermit/ckubwr.html#x3
4806 78. http://www.columbia.edu/kermit/ckubwr.html#x1
4807 79. http://www.columbia.edu/kermit/ckubwr.html#top
4808 80. http://www.columbia.edu/kermit/ckubwr.html#contents
4809 81. http://www.columbia.edu/kermit/ckubwr.html#x4
4810 82. http://www.columbia.edu/kermit/ckubwr.html#x2
4811 83. http://www.columbia.edu/kermit/ckubwr.html#x3.0
4812 84. http://www.columbia.edu/kermit/ckubwr.html#x3.1
4813 85. http://www.columbia.edu/kermit/ckubwr.html#x3.2
4814 86. http://www.columbia.edu/kermit/ckubwr.html#x3.3
4815 87. http://www.columbia.edu/kermit/ckubwr.html#x3.4
4816 88. http://www.columbia.edu/kermit/ckubwr.html#x3.5
4817 89. http://www.columbia.edu/kermit/ckubwr.html#x3.6
4818 90. http://www.columbia.edu/kermit/ckubwr.html#x3.7
4819 91. http://www.columbia.edu/kermit/ckubwr.html#x3.8
4820 92. http://www.columbia.edu/kermit/ckubwr.html#x3.9
4821 93. http://www.columbia.edu/kermit/ckubwr.html#x3.10
4822 94. http://www.columbia.edu/kermit/ckubwr.html#x3.11
4823 95. http://www.columbia.edu/kermit/ckubwr.html#x3.12
4824 96. http://www.columbia.edu/kermit/ckubwr.html#x3.13
4825 97. http://www.columbia.edu/kermit/ckubwr.html#x3.14
4826 98. http://www.columbia.edu/kermit/ckubwr.html#x3.15
4827 99. http://www.columbia.edu/kermit/ckubwr.html#x3.16
4828 100. http://www.columbia.edu/kermit/ckubwr.html#x3.17
4829 101. http://www.columbia.edu/kermit/ckubwr.html#x3.18
4830 102. http://www.columbia.edu/kermit/ckubwr.html#x3.19
4831 103. http://www.columbia.edu/kermit/ckubwr.html#x3.20
4832 104. http://www.faqs.org/
4833 105. http://aplawrence.com/Unixart/newtounix.html
4834 106. http://www.columbia.edu/kermit/ckubwr.html#x3
4835 107. mailto:kermit-support@columbia.edu
4836 108. http://www.columbia.edu/kermit/support.html
4837 109. http://www.columbia.edu/kermit/ckubwr.html#top
4838 110. http://www.columbia.edu/kermit/ckubwr.html#contents
4839 111. http://www.columbia.edu/kermit/ckubwr.html#x3
4840 112. http://www.columbia.edu/kermit/ckubwr.html#x3.1
4841 113. http://www.pcunix.com/
4842 114. http://www.columbia.edu/kermit/ckubwr.html#x3.0.1
4843 115. http://www.columbia.edu/kermit/ckubwr.html#x3.0.2
4844 116. http://www.columbia.edu/kermit/ckubwr.html#x3.0.3
4845 117. http://www.columbia.edu/kermit/ckubwr.html#x3.0.4
4846 118. http://www.columbia.edu/kermit/ckubwr.html#x3.0.5
4847 119. http://www.columbia.edu/kermit/ckubwr.html#x3.0.6
4848 120. http://www.columbia.edu/kermit/ckubwr.html#top
4849 121. http://www.columbia.edu/kermit/ckubwr.html#contents
4850 122. http://www.columbia.edu/kermit/ckubwr.html#x3.0
4851 123. http://www.columbia.edu/kermit/ckubwr.html#x3.0.2
4852 124. http://www.columbia.edu/kermit/ckubwr.html#top
4853 125. http://www.columbia.edu/kermit/ckubwr.html#contents
4854 126. http://www.columbia.edu/kermit/ckubwr.html#x3.0
4855 127. http://www.columbia.edu/kermit/ckubwr.html#x3.0.3
4856 128. http://www.columbia.edu/kermit/ckubwr.html#x3.0.1
4857 129. http://www.linmodems.org/
4858 130. http://www.microsoft.com/hwdev/platform/PCdesign/LR/default.asp
4859 131. http://www.columbia.edu/kermit/ckubwr.html#top
4860 132. http://www.columbia.edu/kermit/ckubwr.html#contents
4861 133. http://www.columbia.edu/kermit/ckubwr.html#x3.0
4862 134. http://www.columbia.edu/kermit/ckubwr.html#x3.0.4
4863 135. http://www.columbia.edu/kermit/ckubwr.html#x3.0.2
4864 136. http://www.idir.net/~gromitkc/winmodem.html
4865 137. http://www.digi.com/
4866 138. http://www.columbia.edu/kermit/ckubwr.html#top
4867 139. http://www.columbia.edu/kermit/ckubwr.html#contents
4868 140. http://www.columbia.edu/kermit/ckubwr.html#x3.0
4869 141. http://www.columbia.edu/kermit/ckubwr.html#x3.0.5
4870 142. http://www.columbia.edu/kermit/ckubwr.html#x3.0.3
4871 143. http://www.columbia.edu/kermit/ckubwr.html#top
4872 144. http://www.columbia.edu/kermit/ckubwr.html#contents
4873 145. http://www.columbia.edu/kermit/ckubwr.html#x3.0
4874 146. http://www.columbia.edu/kermit/ckubwr.html#x3.0.6
4875 147. http://www.columbia.edu/kermit/ckubwr.html#x3.0.4
4876 148. http://www.columbia.edu/kermit/ckubwr.html#top
4877 149. http://www.columbia.edu/kermit/ckubwr.html#contents
4878 150. http://www.columbia.edu/kermit/ckubwr.html#x3.0
4879 151. http://www.columbia.edu/kermit/ckubwr.html#x3.0.5
4880 152. http://www.columbia.edu/kermit/ckubwr.html#top
4881 153. http://www.columbia.edu/kermit/ckubwr.html#contents
4882 154. http://www.columbia.edu/kermit/ckubwr.html#x3
4883 155. http://www.columbia.edu/kermit/ckubwr.html#x3.2
4884 156. http://www.columbia.edu/kermit/ckubwr.html#x3.0
4885 157. http://www.columbia.edu/kermit/ckubwr.html#x3.1.1
4886 158. http://www.columbia.edu/kermit/ckubwr.html#x3.1.2
4887 159. http://www.columbia.edu/kermit/ckubwr.html#x3.1.3
4888 160. http://www.columbia.edu/kermit/ckubwr.html#x3.1.4
4889 161. http://www.columbia.edu/kermit/ckubwr.html#x3.1.5
4890 162. http://www.emerson.emory.edu/services/aix-faq/
4891 163. http://www.faqs.org/faqs/by-newsgroup/comp/comp.unix.aix.html
4892 164. http://www.cis.ohio-state.edu/hypertext/faq/usenet/aix-faq/top.html
4893 165. http://aixpdslib.seas.ucla.edu/
4894 166. http://www.rootvg.net(AIXhistory)/
4895 167. ftp://rtfm.mit.edu/pub/usenet/news.answers/aix-faq/part1
4896 168. ftp://mirrors.aol.com/pub/rtfm/usenet-by-hierarchy/comp/unix/aix
4897 169. news:comp.unix.aix
4898 170. http://www.columbia.edu/kermit/ckubwr.html#top
4899 171. http://www.columbia.edu/kermit/ckubwr.html#contents
4900 172. http://www.columbia.edu/kermit/ckubwr.html#x3.1
4901 173. http://www.columbia.edu/kermit/ckubwr.html#x3.1.2
4902 174. http://www.columbia.edu/kermit/ckubwr.html#top
4903 175. http://www.columbia.edu/kermit/ckubwr.html#contents
4904 176. http://www.columbia.edu/kermit/ckubwr.html#x3.1
4905 177. http://www.columbia.edu/kermit/ckubwr.html#x3.1.3
4906 178. http://www.columbia.edu/kermit/ckubwr.html#x3.1.1
4907 179. http://www.columbia.edu/kermit/security.html#servers
4908 180. http://www.columbia.edu/kermit/ckubwr.html#top
4909 181. http://www.columbia.edu/kermit/ckubwr.html#contents
4910 182. http://www.columbia.edu/kermit/ckubwr.html#x3.1
4911 183. http://www.columbia.edu/kermit/ckubwr.html#x3.1.4
4912 184. http://www.columbia.edu/kermit/ckubwr.html#x3.1.2
4913 185. http://service.software.ibm.com/rs6000/
4914 186. http://www.columbia.edu/kermit/ckubwr.html#top
4915 187. http://www.columbia.edu/kermit/ckubwr.html#contents
4916 188. http://www.columbia.edu/kermit/ckubwr.html#x3.1
4917 189. http://www.columbia.edu/kermit/ckubwr.html#x3.1.5
4918 190. http://www.columbia.edu/kermit/ckubwr.html#x3.1.3
4919 191. http://www.columbia.edu/kermit/ckubwr.html#top
4920 192. http://www.columbia.edu/kermit/ckubwr.html#contents
4921 193. http://www.columbia.edu/kermit/ckubwr.html#x3.1
4922 194. http://www.columbia.edu/kermit/ckubwr.html#x3.1.4
4923 195. http://www.columbia.edu/kermit/ckubwr.html#top
4924 196. http://www.columbia.edu/kermit/ckubwr.html#contents
4925 197. http://www.columbia.edu/kermit/ckubwr.html#x3
4926 198. http://www.columbia.edu/kermit/ckubwr.html#x3.3
4927 199. http://www.columbia.edu/kermit/ckubwr.html#x3.1
4928 200. http://www.columbia.edu/kermit/ckubwr.html#x3.2.0
4929 201. http://www.columbia.edu/kermit/ckubwr.html#x3.2.1
4930 202. http://www.columbia.edu/kermit/ckubwr.html#x3.2.2
4931 203. http://www.columbia.edu/kermit/ckubwr.html#x3.2.3
4932 204. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4
4933 205. http://www.columbia.edu/kermit/ckubwr.html#x3.2.5
4934 206. news:comp.sys.hp.hpux
4935 207. http://www.columbia.edu/kermit/ckubwr.html#top
4936 208. http://www.columbia.edu/kermit/ckubwr.html#contents
4937 209. http://www.columbia.edu/kermit/ckubwr.html#x3.2
4938 210. http://www.columbia.edu/kermit/ckubwr.html#x3.2.1
4939 211. http://www.columbia.edu/kermit/ckubwr.html#top
4940 212. http://www.columbia.edu/kermit/ckubwr.html#contents
4941 213. http://www.columbia.edu/kermit/ckubwr.html#x3.2
4942 214. http://www.columbia.edu/kermit/ckubwr.html#x3.2.2
4943 215. http://www.columbia.edu/kermit/ckubwr.html#x3.2.0
4944 216. ftp://kermit.columbia.edu/kermit/f/makefile
4945 217. http://www.columbia.edu/kermit/ckubwr.html#top
4946 218. http://www.columbia.edu/kermit/ckubwr.html#contents
4947 219. http://www.columbia.edu/kermit/ckubwr.html#x3.2
4948 220. http://www.columbia.edu/kermit/ckubwr.html#x3.2.3
4949 221. http://www.columbia.edu/kermit/ckubwr.html#x3.2.1
4950 222. http://www.columbia.edu/kermit/ckubwr.html#top
4951 223. http://www.columbia.edu/kermit/ckubwr.html#contents
4952 224. http://www.columbia.edu/kermit/ckubwr.html#x3.2
4953 225. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4
4954 226. http://www.columbia.edu/kermit/ckubwr.html#x3.2.2
4955 227. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.1
4956 228. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.2
4957 229. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.3
4958 230. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.4
4959 231. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.5
4960 232. http://www.columbia.edu/kermit/ckubwr.html#top
4961 233. http://www.columbia.edu/kermit/ckubwr.html#contents
4962 234. http://www.columbia.edu/kermit/ckubwr.html#x3.2
4963 235. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.2
4964 236. http://www.columbia.edu/kermit/ckubwr.html#x3.2.2
4965 237. http://www.columbia.edu/kermit/ckubwr.html#top
4966 238. http://www.columbia.edu/kermit/ckubwr.html#contents
4967 239. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4
4968 240. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.3
4969 241. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.1
4970 242. http://www.columbia.edu/kermit/ckubwr.html#top
4971 243. http://www.columbia.edu/kermit/ckubwr.html#contents
4972 244. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4
4973 245. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.4
4974 246. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.2
4975 247. http://www.columbia.edu/kermit/ckubwr.html#top
4976 248. http://www.columbia.edu/kermit/ckubwr.html#contents
4977 249. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4
4978 250. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.5
4979 251. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.3
4980 252. http://www.columbia.edu/kermit/ckubwr.html#top
4981 253. http://www.columbia.edu/kermit/ckubwr.html#contents
4982 254. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4
4983 255. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4.4
4984 256. http://www.columbia.edu/kermit/ckubwr.html#top
4985 257. http://www.columbia.edu/kermit/ckubwr.html#contents
4986 258. http://www.columbia.edu/kermit/ckubwr.html#x3.2
4987 259. http://www.columbia.edu/kermit/ckubwr.html#x3.2.4
4988 260. http://www.columbia.edu/kermit/ckubwr.html#top
4989 261. http://www.columbia.edu/kermit/ckubwr.html#contents
4990 262. http://www.columbia.edu/kermit/ckubwr.html#x3
4991 263. http://www.columbia.edu/kermit/ckubwr.html#x3.4
4992 264. http://www.columbia.edu/kermit/ckubwr.html#x3.2
4993 265. http://www.columbia.edu/kermit/ckubwr.html#x3.3.1
4994 266. http://www.columbia.edu/kermit/ckubwr.html#x3.3.2
4995 267. http://www.columbia.edu/kermit/ckubwr.html#x3.3.3
4996 268. http://www.columbia.edu/kermit/ckubwr.html#x3.3.4
4997 269. http://www.columbia.edu/kermit/ckubwr.html#x3.3.5
4998 270. http://www.columbia.edu/kermit/ckubwr.html#x3.3.6
4999 271. http://en.wikipedia.org/wiki/Avahi_(software)
5000 272. news:comp.os.linux.misc
5001 273. news:comp.os.linux.answers
5002 274. http://www.tldp.org/
5003 275. http://www.tldp.org/FAQ/Linux-FAQ.html
5004 276. http://www.tldp.org/HOWTO/Serial-HOWTO.html
5005 277. http://tldp.org/HOWTO/Modem-HOWTO.html
5006 278. ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO
5007 279. ftp://tsx-11.mit.edu/pub/linux/docs/HOWTO
5008 280. http://www.tldp.org/HOWTO/
5009 281. http://www.tldp.org/hmirrors.html
5010 282. http://www.redhat.com/apps/support/
5011 283. http://www.debian.org/support
5012 284. http://www.slackware.com/support/
5013 285. http://www.caldera.com/support/
5014 286. http://www.novell.com/support/microsites/microsite.do
5015 287. http://www.mandrake.com/support/
5016 288. http://www.turbolinux.com/support/
5017 289. http://www.linmodems.org/
5018 290. http://www.columbia.edu/kermit/ckubwr.html#x3.0
5019 291. http://linux.dreamtime.org/decnet/
5020 292. mailto:kermit-support@columbia.edu
5021 293. http://www.linmodems.org/
5022 294. http://www.columbia.edu/kermit/ckubwr.html#x3.0.2
5023 295. http://www.columbia.edu/kermit/security.html#servers
5024 296. http://www.columbia.edu/kermit/sshclient.html
5025 297. http://www.columbia.edu/kermit/ckubwr.html#top
5026 298. http://www.columbia.edu/kermit/ckubwr.html#contents
5027 299. http://www.columbia.edu/kermit/ckubwr.html#x3
5028 300. http://www.columbia.edu/kermit/ckubwr.html#x3.3.2
5029 301. http://www.columbia.edu/kermit/ckubwr.html#top
5030 302. http://www.columbia.edu/kermit/ckubwr.html#contents
5031 303. http://www.columbia.edu/kermit/ckubwr.html#x3.3
5032 304. http://www.columbia.edu/kermit/ckubwr.html#x3.3.3
5033 305. http://www.columbia.edu/kermit/ckubwr.html#x3.3.1
5034 306. http://www.columbia.edu/kermit/ckubwr.html#x3.0
5035 307. http://www.columbia.edu/kermit/ckubwr.html#x6
5036 308. http://www.columbia.edu/kermit/ckubwr.html#x7
5037 309. http://www.columbia.edu/kermit/ckubwr.html#x8
5038 310. http://www.columbia.edu/kermit/ckuins.html#x10
5039 311. http://www.columbia.edu/kermit/ckuins.html#x11
5040 312. http://www.columbia.edu/kermit/ckuins.html
5041 313. http://www.columbia.edu/kermit/ckubwr.html#x3.0
5042 314. http://linuxwww.db.erau.edu/mail_archives/linux-kernel/Mar_98/1441.html
5043 315. http://www.columbia.edu/kermit/ckubwr.html#top
5044 316. http://www.columbia.edu/kermit/ckubwr.html#contents
5045 317. http://www.columbia.edu/kermit/ckubwr.html#x3.3
5046 318. http://www.columbia.edu/kermit/ckubwr.html#x3.3.4
5047 319. http://www.columbia.edu/kermit/ckubwr.html#x3.3.2
5048 320. http://www.columbia.edu/kermit/ckubwr.html#x3.0.5
5049 321. http://www.columbia.edu/kermit/ckfaq.html#term
5050 322. http://dickey.his.com/xterm/xterm.html
5051 323. http://dickey.his.com/xterm/xterm.html
5052 324. ftp://kermit.columbia.edu/kermit/f/xmodmap.txt
5053 325. http://www.columbia.edu/kermit/ckubwr.html#top
5054 326. http://www.columbia.edu/kermit/ckubwr.html#contents
5055 327. http://www.columbia.edu/kermit/ckubwr.html#x3.3
5056 328. http://www.columbia.edu/kermit/ckubwr.html#x3.3.5
5057 329. http://www.columbia.edu/kermit/ckubwr.html#x3.3.3
5058 330. http://www.columbia.edu/kermit/ckubwr.html#top
5059 331. http://www.columbia.edu/kermit/ckubwr.html#contents
5060 332. http://www.columbia.edu/kermit/ckubwr.html#x3.3
5061 333. http://www.columbia.edu/kermit/ckubwr.html#x3.3.6
5062 334. http://www.columbia.edu/kermit/ckubwr.html#x3.3.4
5063 335. http://www.columbia.edu/kermit/ckermit.html
5064 336. mailto:kermit-support@columbia.edu
5065 337. http://www.redhat.com/support/errata/RHBA-2001-153.html
5066 338. news:comp.protocols.kermit.misc
5067 339. http://www.columbia.edu/kermit/ckubwr.html#top
5068 340. http://www.columbia.edu/kermit/ckubwr.html#contents
5069 341. http://www.columbia.edu/kermit/ckubwr.html#x3.3
5070 342. http://www.columbia.edu/kermit/ckubwr.html#x3.3.5
5071 343. http://www.columbia.edu/kermit/ckubwr.html#top
5072 344. http://www.columbia.edu/kermit/ckubwr.html#contents
5073 345. http://www.columbia.edu/kermit/ckubwr.html#x3
5074 346. http://www.columbia.edu/kermit/ckubwr.html#x3.5
5075 347. http://www.columbia.edu/kermit/ckubwr.html#x3.3
5076 348. http://www.columbia.edu/kermit/ckubwr.html#top
5077 349. http://www.columbia.edu/kermit/ckubwr.html#contents
5078 350. http://www.columbia.edu/kermit/ckubwr.html#x3
5079 351. http://www.columbia.edu/kermit/ckubwr.html#x3.6
5080 352. http://www.columbia.edu/kermit/ckubwr.html#x3.4
5081 353. news:comp.os.qnx
5082 354. http://www.columbia.edu/kermit/gkermit.html
5083 355. http://www.columbia.edu/kermit/ckuins.html#x10
5084 356. http://www.columbia.edu/kermit/ckuins.html
5085 357. http://www.columbia.edu/kermit/ckubwr.html#top
5086 358. http://www.columbia.edu/kermit/ckubwr.html#contents
5087 359. http://www.columbia.edu/kermit/ckubwr.html#x3
5088 360. http://www.columbia.edu/kermit/ckubwr.html#x3.7
5089 361. http://www.columbia.edu/kermit/ckubwr.html#x3.5
5090 362. http://www.columbia.edu/kermit/ckubwr.html#x3.6.1
5091 363. http://www.columbia.edu/kermit/ckubwr.html#x3.6.2
5092 364. http://www.columbia.edu/kermit/ckubwr.html#x3.6.3
5093 365. http://www.columbia.edu/kermit/ckubwr.html#x3.6.4
5094 366. http://www.columbia.edu/kermit/ckubwr.html#x3.10
5095 367. http://aplawrence.com/SCOFAQ/
5096 368. http://www.zenez.com/cgi-bin/scoprogfaq/faq.pl
5097 369. http://www.zenez.com/cgi-bin/scouw7faq/faq.pl
5098 370. http://zenez.pcunix.com/cgi-bin/scouw7faq/faq.pl
5099 371. http://pcunix.com/Unixart/modems.html
5100 372. http://www.freebird.org/faq/
5101 373. http://www.freebird.org/faq/developer.html
5102 374. http://support.caldera.com/caldera
5103 375. http://stage.caldera.com/ta/
5104 376. http://aplawrence.com/newtosco.html
5105 377. http://www.columbia.edu/kermit/ckubwr.html#x3.0.5
5106 378. http://www.columbia.edu/kermit/ckfaq.html#term
5107 379. http://www.columbia.edu/kermit/ckubwr.html#x3.0
5108 380. http://www.columbia.edu/kermit/ckubwr.html#top
5109 381. http://www.columbia.edu/kermit/ckubwr.html#contents
5110 382. http://www.columbia.edu/kermit/ckubwr.html#x3.6
5111 383. http://www.columbia.edu/kermit/ckubwr.html#x3.6.1
5112 384. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
5113 385. http://www.columbia.edu/kermit/ckubwr.html#top
5114 386. http://www.columbia.edu/kermit/ckubwr.html#contents
5115 387. http://www.columbia.edu/kermit/ckubwr.html#x3.6
5116 388. http://www.columbia.edu/kermit/ckubwr.html#x3.6.3
5117 389. http://www.columbia.edu/kermit/ckubwr.html#x3.6.1
5118 390. http://www.digi.com/
5119 391. ftp://ftp.fu-berlin.de/pub/unix/driver/fas
5120 392. http://www.columbia.edu/kermit/ckubwr.html#x14
5121 393. http://www.sco.com/
5122 394. ftp://ftp.sco.com/
5123 395. http://www.columbia.edu/kermit/ckubwr.html#top
5124 396. http://www.columbia.edu/kermit/ckubwr.html#contents
5125 397. http://www.columbia.edu/kermit/ckubwr.html#x3.6
5126 398. http://www.columbia.edu/kermit/ckubwr.html#x3.6.4
5127 399. http://www.columbia.edu/kermit/ckubwr.html#x3.6.2
5128 400. http://www.columbia.edu/kermit/ckubwr.html#x3.10
5129 401. http://www.columbia.edu/kermit/ckubwr.html#top
5130 402. http://www.columbia.edu/kermit/ckubwr.html#contents
5131 403. http://www.columbia.edu/kermit/ckubwr.html#x3.6
5132 404. http://www.columbia.edu/kermit/ckubwr.html#x3.6.3
5133 405. http://www.columbia.edu/kermit/ckubwr.html#top
5134 406. http://www.columbia.edu/kermit/ckubwr.html#contents
5135 407. http://www.columbia.edu/kermit/ckubwr.html#x3
5136 408. http://www.columbia.edu/kermit/ckubwr.html#x3.8
5137 409. http://www.columbia.edu/kermit/ckubwr.html#x3.6
5138 410. http://www.columbia.edu/kermit/ckubwr.html#x3.7.1
5139 411. http://www.columbia.edu/kermit/ckubwr.html#x3.7.2
5140 412. http://www.columbia.edu/kermit/ckubwr.html#x3.7.3
5141 413. http://www.columbia.edu/kermit/ckubwr.html#x3.7.4
5142 414. http://www.columbia.edu/kermit/ckubwr.html#x3.7.5
5143 415. news:comp.unix.solaris
5144 416. http://access1.sun.com/
5145 417. http://docs.sun.com/
5146 418. http://www.sunhelp.com/
5147 419. http://www.wins.uva.nl/pub/solaris/solaris2/
5148 420. http://www.wins.uva.nl/cgi-bin/sfaq.cgi
5149 421. ftp://ftp.wins.uva.nl/pub/solaris
5150 422. http://www.science.uva.nl/pub/solaris/solaris2.html
5151 423. http://www.stokely.com/
5152 424. http://www.stokely.com/unix.sysadm.resources/faqs.sun.html
5153 425. http://www.columbia.edu/kermit/ckubwr.html#x3.0
5154 426. http://www.columbia.edu/kermit/ckubwr.html#top
5155 427. http://www.columbia.edu/kermit/ckubwr.html#contents
5156 428. http://www.columbia.edu/kermit/ckubwr.html#x3
5157 429. http://www.columbia.edu/kermit/ckubwr.html#x3.7
5158 430. http://www.columbia.edu/kermit/ckubwr.html#x3.7.2
5159 431. http://www.columbia.edu/kermit/ckubwr.html#top
5160 432. http://www.columbia.edu/kermit/ckubwr.html#contents
5161 433. http://www.columbia.edu/kermit/ckubwr.html#x3.7
5162 434. http://www.columbia.edu/kermit/ckubwr.html#x3.7.3
5163 435. http://www.columbia.edu/kermit/ckubwr.html#x3.7.1
5164 436. http://www.columbia.edu/kermit/ckubwr.html#top
5165 437. http://www.columbia.edu/kermit/ckubwr.html#contents
5166 438. http://www.columbia.edu/kermit/ckubwr.html#x3.7
5167 439. http://www.columbia.edu/kermit/ckubwr.html#x3.7.4
5168 440. http://www.columbia.edu/kermit/ckubwr.html#x3.7.2
5169 441. http://www.columbia.edu/kermit/ckubwr.html#top
5170 442. http://www.columbia.edu/kermit/ckubwr.html#contents
5171 443. http://www.columbia.edu/kermit/ckubwr.html#x3.7
5172 444. http://www.columbia.edu/kermit/ckubwr.html#x3.7.5
5173 445. http://www.columbia.edu/kermit/ckubwr.html#x3.7.3
5174 446. news:comp.os.vms
5175 447. http://www.columbia.edu/kermit/ckubwr.html#top
5176 448. http://www.columbia.edu/kermit/ckubwr.html#contents
5177 449. http://www.columbia.edu/kermit/ckubwr.html#x3.7
5178 450. http://www.columbia.edu/kermit/ckubwr.html#x3.7.6
5179 451. http://www.columbia.edu/kermit/ckubwr.html#x3.7.4
5180 452. http://www.columbia.edu/kermit/ckubwr.html#top
5181 453. http://www.columbia.edu/kermit/ckubwr.html#contents
5182 454. http://www.columbia.edu/kermit/ckubwr.html#x3.7
5183 455. http://www.columbia.edu/kermit/ckubwr.html#x3.7.5
5184 456. http://www.columbia.edu/kermit/ckubwr.html#top
5185 457. http://www.columbia.edu/kermit/ckubwr.html#contents
5186 458. http://www.columbia.edu/kermit/ckubwr.html#x3
5187 459. http://www.columbia.edu/kermit/ckubwr.html#x3.9
5188 460. http://www.columbia.edu/kermit/ckubwr.html#x3.7
5189 461. http://www.stokely.com/
5190 462. http://access1.sun.com/
5191 463. http://www.ludd.luth.se/~bear/project/sun/sun.hardware.txt
5192 464. ftp://ftp.netcom.com/pub/ru/rubicon/sun.hdwr.ref
5193 465. ftp://ftp.intnet.net/pub/SUN/Sun-Hardware-Ref
5194 466. http://www.columbia.edu/kermit/ckubwr.html#top
5195 467. http://www.columbia.edu/kermit/ckubwr.html#contents
5196 468. http://www.columbia.edu/kermit/ckubwr.html#x3
5197 469. http://www.columbia.edu/kermit/ckubwr.html#x3.10
5198 470. http://www.columbia.edu/kermit/ckubwr.html#x3.8
5199 471. news:comp.unix.ultrix
5200 472. news:comp.sys.dec
5201 473. http://www.columbia.edu/kermit/ckubwr.html#top
5202 474. http://www.columbia.edu/kermit/ckubwr.html#contents
5203 475. http://www.columbia.edu/kermit/ckubwr.html#x3
5204 476. http://www.columbia.edu/kermit/ckubwr.html#x3.11
5205 477. http://www.columbia.edu/kermit/ckubwr.html#x3.9
5206 478. http://www.freebird.org/
5207 479. http://www.freebird.org/faq/
5208 480. news:comp.unix.unixware.misc
5209 481. news:comp.unix.sco.misc
5210 482. http://www.columbia.edu/kermit/ckubwr.html#x3.0
5211 483. ftp://kermit.columbia.edu/kermit/f/ckutio.c
5212 484. http://www.columbia.edu/kermit/ckubwr.html#top
5213 485. http://www.columbia.edu/kermit/ckubwr.html#contents
5214 486. http://www.columbia.edu/kermit/ckubwr.html#x3
5215 487. http://www.columbia.edu/kermit/ckubwr.html#x3.12
5216 488. http://www.columbia.edu/kermit/ckubwr.html#x3.10
5217 489. http://www.columbia.edu/kermit/ckubwr.html#top
5218 490. http://www.columbia.edu/kermit/ckubwr.html#contents
5219 491. http://www.columbia.edu/kermit/ckubwr.html#x3
5220 492. http://www.columbia.edu/kermit/ckubwr.html#x3.13
5221 493. http://www.columbia.edu/kermit/ckubwr.html#x3.11
5222 494. http://www.columbia.edu/kermit/ckubwr.html#top
5223 495. http://www.columbia.edu/kermit/ckubwr.html#contents
5224 496. http://www.columbia.edu/kermit/ckubwr.html#x3
5225 497. http://www.columbia.edu/kermit/ckubwr.html#x3.14
5226 498. http://www.columbia.edu/kermit/ckubwr.html#x3.12
5227 499. http://www.columbia.edu/kermit/ckubwr.html#top
5228 500. http://www.columbia.edu/kermit/ckubwr.html#contents
5229 501. http://www.columbia.edu/kermit/ckubwr.html#x3
5230 502. http://www.columbia.edu/kermit/ckubwr.html#x3.15
5231 503. http://www.columbia.edu/kermit/ckubwr.html#x3.13
5232 504. news:comp.sys.sgi.misc
5233 505. news:comp.sys.sgi.admin
5234 506. http://www.sgi.com/
5235 507. http://www-viz.tamu.edu/~sgi-faq/
5236 508. ftp://viz.tamu.edu/pub/sgi/faq/
5237 509. http://www.columbia.edu/kermit/ckuins.html
5238 510. http://freeware.sgi.com/Installable/gcc-2.95.2.html
5239 511. http://freeware.sgi.com/Installable/gcc-2.95.2.html
5240 512. http://www.columbia.edu/kermit/ckubwr.html#top
5241 513. http://www.columbia.edu/kermit/ckubwr.html#contents
5242 514. http://www.columbia.edu/kermit/ckubwr.html#x3
5243 515. http://www.columbia.edu/kermit/ckubwr.html#x3.16
5244 516. http://www.columbia.edu/kermit/ckubwr.html#x3.14
5245 517. news:comp.sys.be
5246 518. http://www.columbia.edu/kermit/ckubwr.html#top
5247 519. http://www.columbia.edu/kermit/ckubwr.html#contents
5248 520. http://www.columbia.edu/kermit/ckubwr.html#x3
5249 521. http://www.columbia.edu/kermit/ckubwr.html#x3.17
5250 522. http://www.columbia.edu/kermit/ckubwr.html#x3.15
5251 523. http://www.columbia.edu/kermit/ckubwr.html#top
5252 524. http://www.columbia.edu/kermit/ckubwr.html#contents
5253 525. http://www.columbia.edu/kermit/ckubwr.html#x3
5254 526. http://www.columbia.edu/kermit/ckubwr.html#x3.18
5255 527. http://www.columbia.edu/kermit/ckubwr.html#x3.16
5256 528. http://www.columbia.edu/kermit/ckubwr.html#top
5257 529. http://www.columbia.edu/kermit/ckubwr.html#contents
5258 530. http://www.columbia.edu/kermit/ckubwr.html#x3
5259 531. http://www.columbia.edu/kermit/ckubwr.html#x3.19
5260 532. http://www.columbia.edu/kermit/ckubwr.html#x3.17
5261 533. http://www.columbia.edu/kermit/ckubwr.html#top
5262 534. http://www.columbia.edu/kermit/ckubwr.html#contents
5263 535. http://www.columbia.edu/kermit/ckubwr.html#x3
5264 536. http://www.columbia.edu/kermit/ckubwr.html#x3.20
5265 537. http://www.columbia.edu/kermit/ckubwr.html#x3.18
5266 538. http://www.columbia.edu/kermit/mac.html
5267 539. http://www.amazon.com/gp/product/B0000VYJRY?ie=UTF8&tag=aleidmoreldom-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=B0000VYJRY
5268 540. http://www.columbia.edu/kermit/ckuins.html#x10
5269 541. http://www.columbia.edu/kermit/ckuins.html
5270 542. http://www.amazon.com/gp/product/B000FX61MS?ie=UTF8&tag=aleidmoreldom-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=B000FX61MS
5271 543. mailto:kermit@columbia.edu
5272 544. http://www.columbia.edu/kermit/ckubwr.html#top
5273 545. http://www.columbia.edu/kermit/ckubwr.html#contents
5274 546. http://www.columbia.edu/kermit/ckubwr.html#x3
5275 547. http://www.columbia.edu/kermit/ckubwr.html#x3.19
5276 548. http://www.uni-giessen.de/faq/archiv/coherent-faq.general/msg00000.html
5277 549. http://www.columbia.edu/kermit/ckubwr.html#top
5278 550. http://www.columbia.edu/kermit/ckubwr.html#contents
5279 551. http://www.columbia.edu/kermit/ckubwr.html#x5
5280 552. http://www.columbia.edu/kermit/ckubwr.html#x3
5281 553. http://www.columbia.edu/kermit/ckccfg.html
5282 554. http://www.columbia.edu/kermit/ckubwr.html#top
5283 555. http://www.columbia.edu/kermit/ckubwr.html#contents
5284 556. http://www.columbia.edu/kermit/ckubwr.html#x6
5285 557. http://www.columbia.edu/kermit/ckubwr.html#x4
5286 558. http://www.columbia.edu/kermit/ckuins.html
5287 559. http://www.columbia.edu/kermit/ckubwr.html#top
5288 560. http://www.columbia.edu/kermit/ckubwr.html#contents
5289 561. http://www.columbia.edu/kermit/ckubwr.html#x7
5290 562. http://www.columbia.edu/kermit/ckubwr.html#x5
5291 563. http://www.columbia.edu/kermit/ckuins.html#9.5
5292 564. http://www.columbia.edu/kermit/ckubwr.html#x3
5293 565. http://www.columbia.edu/kermit/ckubwr.html#top
5294 566. http://www.columbia.edu/kermit/ckubwr.html#contents
5295 567. http://www.columbia.edu/kermit/ckubwr.html#x8
5296 568. http://www.columbia.edu/kermit/ckubwr.html#x6
5297 569. http://www.columbia.edu/kermit/ckuins.html#x8
5298 570. http://www.columbia.edu/kermit/ckuins.html
5299 571. http://www.columbia.edu/kermit/ck60manual.html
5300 572. http://www.columbia.edu/kermit/cable.html
5301 573. http://www.columbia.edu/kermit/ckubwr.html#top
5302 574. http://www.columbia.edu/kermit/ckubwr.html#contents
5303 575. http://www.columbia.edu/kermit/ckubwr.html#x9
5304 576. http://www.columbia.edu/kermit/ckubwr.html#x7
5305 577. http://www.columbia.edu/kermit/ckubwr.html#top
5306 578. http://www.columbia.edu/kermit/ckubwr.html#contents
5307 579. http://www.columbia.edu/kermit/ckubwr.html#x10
5308 580. http://www.columbia.edu/kermit/ckubwr.html#x8
5309 581. http://www.columbia.edu/kermit/ck60manual.html
5310 582. http://dickey.his.com/xterm/xterm.html
5311 583. http://www.columbia.edu/kermit/ckubwr.html#top
5312 584. http://www.columbia.edu/kermit/ckubwr.html#contents
5313 585. http://www.columbia.edu/kermit/ckubwr.html#x11
5314 586. http://www.columbia.edu/kermit/ckubwr.html#x9
5315 587. http://www.columbia.edu/kermit/ckubwr.html#top
5316 588. http://www.columbia.edu/kermit/ckubwr.html#contents
5317 589. http://www.columbia.edu/kermit/ckubwr.html#x12
5318 590. http://www.columbia.edu/kermit/ckubwr.html#x10
5319 591. http://www.columbia.edu/kermit/ckubwr.html#x11.1
5320 592. http://www.columbia.edu/kermit/ckubwr.html#x11.2
5321 593. http://www.columbia.edu/kermit/ckubwr.html#top
5322 594. http://www.columbia.edu/kermit/ckubwr.html#contents
5323 595. http://www.columbia.edu/kermit/ckubwr.html#x11
5324 596. http://www.columbia.edu/kermit/ckubwr.html#x11.2
5325 597. http://www.columbia.edu/kermit/ck60manual.html
5326 598. http://www.columbia.edu/kermit/ckubwr.html#top
5327 599. http://www.columbia.edu/kermit/ckubwr.html#contents
5328 600. http://www.columbia.edu/kermit/ckubwr.html#x11
5329 601. http://www.columbia.edu/kermit/ckubwr.html#x11.1
5330 602. http://www.columbia.edu/kermit/ck60manual.html
5331 603. http://www.columbia.edu/kermit/ckubwr.html#top
5332 604. http://www.columbia.edu/kermit/ckubwr.html#contents
5333 605. http://www.columbia.edu/kermit/ckubwr.html#x13
5334 606. http://www.columbia.edu/kermit/ckubwr.html#x11
5335 607. http://www.columbia.edu/kermit/security.html
5336 608. http://www.columbia.edu/kermit/ckubwr.html#top
5337 609. http://www.columbia.edu/kermit/ckubwr.html#contents
5338 610. http://www.columbia.edu/kermit/ckubwr.html#x14
5339 611. http://www.columbia.edu/kermit/ckubwr.html#x12
5340 612. http://www.columbia.edu/kermit/ckubwr.html#top
5341 613. http://www.columbia.edu/kermit/ckubwr.html#contents
5342 614. http://www.columbia.edu/kermit/ckubwr.html#x15
5343 615. http://www.columbia.edu/kermit/ckubwr.html#x14
5344 616. mailto:support@stallion.oz.au
5345 617. http://www.stallion.com/
5346 618. http://www.columbia.edu/kermit/ckubwr.html#top
5347 619. http://www.columbia.edu/kermit/ckubwr.html#contents
5348 620. http://www.columbia.edu/kermit/ckermit.html
5349 621. http://www.columbia.edu/kermit/ck80.html
5350 622. http://www.columbia.edu/kermit/index.html
5351 623. http://www.columbia.edu/kermit/index.html
5352 624. http://www.columbia.edu/
5353 625. mailto:kermit@columbia.edu