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