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