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