![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to ckuker.bwr CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [Research Unix] / researchv10dc / lbin / kermit|
Return to ckuker.bwr CVS log | Up to [Research Unix] / researchv10dc / lbin / kermit |
1.1 root 1: C-Kermit Version 4E(070):
2: Status, Bugs, and Problems
3: As of: 4:23pm Wednesday, 23 March 1988
4:
5: See ckuker.upd for a list of changes since the last release. 4E(066) was a
6: beta test release. It was tested at Columbia on various VAXes running Ultrix
7: 1.2 and 2.0 (4.2 and 4.3 BSD equivalents, more or less), a Pro-380 running
8: 2.9BSD, and an AT&T 3B20 running Sys V R2. The Unix versions need testing,
9: especially in local (dialout) mode on SUNs, PC's with Xenix, etc. During the
10: beta test, users reported that it worked on the Macintosh, on VAX/VMS (once a
11: the definition of syscleanup() was supplied in CKVTIO.C), on Xenix systems
12: once some extra #includes of "file.h" were removed, on the Pyramid once a
13: minor change was made to ckutio.c, and various other systems. 4E(067) just
14: applies these fixes, so that it can replace 4D(061) as the standard
15: distributed version. 4E(068) adds the ability to suspend Kermit on systems
16: with job control, plus support for the ATT 7300 internal modem, and
17: improvements to the C-Kermit server's handling of the 'remote cwd' command.
18: See ckuker.upd for details.
19:
20:
21: -- SUPPORT FOR DIFFERENT SYSTEMS: --
22:
23: 4.2BSD: "make bsd" works. Should work on VAX, SUN, Pyramid, Convex, & others.
24:
25: 4.3BSD: "make bsd" works.
26:
27: 4.1BSD: "make bsd" should work for this too (did not in C-Kermit v4.2).
28:
29: 2.9BSD: "make bsd29" works, at least on Pro-380. Should be the same for 2.8.
30:
31: Version 7: works ok on the systems tested so far using "make v7", but some
32: fiddling with the make file is necessary for proc table definitions; see
33: the makefile and also ckuv7.hlp for details.
34:
35: PC/IX: should work ok with "make pcix".
36:
37: ATT 3Bx systems: should work ok with "make att3bx".
38:
39: Xenix: This word no longer means anything specific. Is it an old Xenix that
40: looks like V6 or V7 Unix? Is it a System-V-like Xenix? Is it IBM's, or SCO's,
41: or somebody else's, and which Xenix version is it, and which compiler version?
42: Look at your system's documentation to see what's really hiding under the name
43: Xenix and use the appropriate make option. Usually 'make xenix' or 'make sys3'
44: work, so long as you're using the most up-to-date version of C-Kermit, 4D(061)
45: or later.
46:
47: HP Integral PC -- "make sys3", but either remove code that sets up lock files,
48: or have the lock files put in a directory that is guaranteed to be there,
49: like /tmp. Some problems reported when running under csh.
50:
51: AT&T System V R3 has redefined the type of the signal() function. Use
52: "make sys5r3". If that doesn't work (as reportedly it does not on certain
53: recent Xenix systems), "make sys3" or "make xenix".
54:
55: AT&T 7300 has its own make option, "make att7300" as of 4E(068), to allow
56: operation with its internal modem and system support thereof.
57:
58: Most other System V or System III based systems can build a working Kermit with
59: "make sys3" or "make sys3nid" or "make att3bx" or (for Sys 5 R3) "make sys5r3".
60:
61: PDP-11's running a System III or V based Unix and which have no I & D space
62: should use "make sys3nid".
63:
64: DEC Pro-350 or -380 with Pro/Venix V2 (not V1) -- uses the regular "make sys3"
65: or "make sys3nid", but the file ckcfio.c might have to be edited first to
66: reduce the value of MAXWLD and/or SSPACE. See below under HINTS for details.
67:
68: Valid Scaldstar CAD system -- There's a "make valid" in the makefile, but
69: reportedly one thing is still lacking: ckutio.c needs to #include<sys/file.h>.
70:
71: For other Unix systems, see the makefile, and for further notes, consult the
72: messages appended chronologically below.
73:
74: VAX/VMS: support added by Stew Rubenstein at Harvard and Martin Minow at DEC.
75: Has to be built with CKV*.COM, needs development to handle all the VMS/RMS
76: features and to improve performance. See CKV*.*. VMS-specific bugs in
77: CKVKER.BWR. Somebody is working on upgrading the VMS support.
78:
79: Macintosh: Support originally added at Columbia for SUMACC C cross
80: compiler. Has own makefile, etc. Adapted by Jim Noble of PRC to
81: compile under Megamax C directly on the Mac. See CKM*.*. SUMACC no longer
82: supported, only Megamax. In fact, the current code should not be used as
83: the basis of any development, because a very different new version is about
84: to be released, written in MPW C.
85:
86: Commodore Amiga: Support added by Davide Cervone, U of Rochester, later
87: replaced (with Davide's consent) by new code from Phil Julian & Jack Rouse
88: of SAS Institute. See CKI*.*.
89:
90: -- HINTS --
91:
92: - If the program dies with a message like "malloc fails in splitpath()"
93: whenever it tries to parse a filename (as in the "send" command), then
94: the amount of space allocated for filename expansion in the module
95: ckufio.c must be reduced. This can be done by changing the #defines
96: for MAXWLD (the maximum number of filenames) and SSPACE (the size of
97: static string space) to make the numbers smaller.
98:
99: - When modifying or writing Kermit code, do NOT pass to a function
100: (e.g., "signal") the address of a static function. Doing so may
101: break VENIX code mapping. If you must pass the address of the
102: function, make it global and pick a "non-generic" name for it that
103: will hopefully be unique and yet informative.
104:
105:
106: -- BUG LIST --
107:
108: First, a disclaimer must be made. C-Kermit attempts to support all post-V6
109: Unix variations on all machines. This is a tall order, and requires careful
110: attention to certain details. As changes are made (and C-Kermit is still in
111: stage of fairly rapid development), there is always the chance that a change
112: -- made to introduce a new feature or fix a bug -- will not work as intended
113: on some systems, even though it was tested successfully on others. The main
114: area to watch out for is not system differences (which are handled fairly well
115: in the system-dependent ck?[ft]io modules), but in compiler differences,
116: especially int/char confusion. Characters should be stored in variables of
117: type char, not int, and char/int conversion should be avoided because of
118: problems introduced by sign extension. And i/o should not be used to read
119: characters into int variables, because the way in which the system stores the
120: character in an int varies from system to system (e.g. 68000s put them on the
121: left, the VAX on the right).
122:
123: If you have received a C-Kermit release that does not work correctly (except
124: for the bugs & restrictions noted below), it is not because the release was
125: not thoroughly tested -- it was -- but because it was not tested on your system
126: since the last time changes were made, because of a lack of such a system to
127: test it on. If this happens to you, please try to track down the problem and
128: report as specifically as possible back to Columbia.
129:
130:
131: General problems:
132:
133: - The program is too big, with too many features; source is too large to fit on
134: some disks. Needs to be reorganized so that a minimal Kermit can be built
135: for any system, and then frills can be added on if desired -- interactive
136: command parser, help strings, dial command, script command, etc.
137:
138: - There's not a full enough set of features available from command line
139: invocation. Commands like "bye" are missing. This is mainly to keep the
140: "kermit -h" help message small enough to fit on one screen.
141:
142: - Conditionalizations are not done clearly. In some cases it might be
143: better to have compile-time flags for features, rather than systems, or
144: generic system names, rather than specific vendor/machine names, to
145: avoid excessive nesting or repitition of compile-time variables.
146: Constructions like "#ifdef FOO | BAR" are avoided because many compilers
147: don't understand them; the alternative is to repeat code under different
148: conditionals (to accomplish an OR) or to include it within nested
149: conditionals (AND), sometimes applying De Morgan's law to achieve the
150: desired result...
151:
152: - Program's return code might be wrong in some cases (in 4.0, it was always
153: zero; in 4C some attempt is made to return correct codes for failure and
154: success). Actually, no attempt has been made to correlate return codes
155: with success or failure of file transfer -- a bad return code only reflects
156: a fatal error.
157:
158: - On some systems (e.g. TRS-80 Model 16 with Xenix V7, or HP-9000 HP-UX)
159: C-Kermit reportedly runs VERY SLOWLY. The program could certainly do with
160: some tuning -- but not at the expense of modularity and transportability! --
161: but in the meantime, it can probably be sped up a lot by removing the
162: -DDEBUG from the makefile, eliminating hundreds of function calls, many of
163: them in critical code (one user reports a 1250% improvement doing this on
164: the TRS-80 Model 16!). Another speedup could come from allowing more
165: systems to take advantage of "myread()" -- the nonblocking version of
166: read(); see below. (4E fixes this to a great extent with rewritten ttinl(),
167: elimination of inlin(), etc.)
168:
169: - In reality, TANDEM flow control (XON/XOFF) is not really done on most
170: systems, because Kermit opens the communication line in rawmode, which
171: has the side effect of disabling flow control. Rawmode is used in order
172: to allow 8-bit data. Using cooked mode & CRMOD would be possible for
173: text files, but 8th-bit prefixing would be required for 8-bit binary
174: files. But at least this would allow in-band flow control to take place.
175: Allegedly, 4.3BSD and Sys 5 R3 allow XON/XOFF and rawmode to coexist,
176: but this hasn't been verified. It doesn't seem to happen on Ultrix 2.0.
177:
178: - Need 'set' command for server timeout.
179:
180: - The timeout interval is not automatically adjusted according to the
181: packet length.
182:
183: - The program could be a little bit less cavalier in its treatment of files.
184: For instance, when receiving a file (with "warning" turned off) it will
185: overwrite any existing file of the same name. That's ok, but what if the
186: user types ^F or ^B to interrupt the transfer? This does not save the
187: existing file -- it's already been destroyed by the open() of the new copy,
188: which in turn is discarded as a result of the interruption. Maybe Kermit
189: should always make a temporary, unique name for incoming files, and then
190: rename them to their real names only after the transfer is complete. But
191: that's no good on systems (like the Macintosh) that don't have disk space
192: to burn.
193:
194: - Local versus remote mode is not, and probably can not, be determined
195: automatically upon startup. For instance, if you build Kermit with
196: "make sys3" on a 3B20 and a 3B2, the program has no way of knowing whether
197: it's running on a timesharing system (the 3B20, where it should be remote
198: by default) or a workstation (the 3B2, where it should be local by default).
199: If you find that Kermit comes up on your system in the wrong mode, you can
200: put the appropriate "set line" command in your .kermrc file -- "set line
201: /dev/tty" SHOULD always put you in remote mode. (Actually, problems have
202: been reported for this on some systems that support incoming X.25 connections
203: on pseudoterminals.)
204:
205: - If the program crashes or is halted (killed) from outside while it has the
206: terminal in a not-normal mode during command parsing or file transfer, the
207: terminal mode is not restored, and lock files are not cleaned up. There can
208: be no fix for this within C-Kermit itself. Subsequent Kermit runs may still
209: fail because the device is already opened by "another process" (you have
210: to log out & log in again to clear this one up).
211:
212: - The shell's interrupt, delete, and kill characters may interfere or
213: conflict with those used by the Kermit command parser. In any case, there
214: is no way to change Kermit's editing characters to conform to user's taste.
215:
216: - "!" command requires a space after, contrary to the Unix user's normal
217: expectation.
218:
219: - Many people have asked for a system-wide startup file similar to
220: the user's .kermrc file, perhaps with a conditional way to escape from
221: it if the user has her own .kermrc file. This notion might be extended
222: to include the entire hierarchy system -- home -- current directory.
223:
224: - Some users report that it would be more desirable to have an error during
225: execution of a take file return directly to command level, rather than
226: pop to the invoking take file, in case the error in question is of such
227: severity that it would cause all subsequent commands in the stack of TAKE
228: files to fail. Best to have a SET command to control this behavior.
229: (This desired behavior does occur -- or at least should occur -- when the
230: program is in the background.)
231:
232: - Some users report that the program should make no internal distinction
233: between running in foreground or background, so that program exit codes
234: are consistent, making it easier to debug shell scripts that invoke Kermit.
235:
236: - Speaking of background, not all systems seem to define it the same way.
237: If your prompt disappears, you probably have one of those systems. See
238: function conint() in ckutio.c, and try to figure out what's amiss.
239:
240: - Speaking of conint(), it has been reported that there may be something
241: wrong with the way Unix Kermit responds to hangups. Although it traps
242: the SIGHUP signal and cleans up and exits when a phone connection drops,
243: some users report that the line is unusable after that.
244:
245: - Since Kermit opens and closes the communication line with each command line
246: invocation, it is not convenient to use it in scripts in which it is
247: repeatedly invoked (e.g. a print spooler).
248:
249: - Opening & closing a comm line selected with 'set line' involves the use
250: of UUCP "lock files", whose use is inconsistent from one Unix variation to
251: another, and from site to site and system to system. The lack of a
252: consistent, reliable way to get guaranteed exclusive access to a
253: communication is one of Unix's biggest shortcomings.
254:
255: - There very little provision in the program (as yet) for running setuid.
256: Nor for dealing with bidirectional terminal lines. Nor with system-provided
257: dialer programs. Every system does these things differently.
258:
259: - Variable names are sometimes confusing, especially the send/receive parameter
260: pairs (spsiz/rpsize, mystch/stchr, npad/mypadn, rtimo/timint, etc). This
261: is mostly history... they tend to agree with the names used in other Kermit
262: programs. Still, they should probably be changed. Ditto for some of the
263: procedure names.
264:
265: - Some C compilers do not support variable names longer than 6, nor function
266: names longer than 5, and some are not case sensitive (one DEC-20 C compiler
267: has all these restrictions, and the V6 Unix C compiler has some of them).
268: To ensure the widest possible portability, all identifiers should comply
269: with these restrictions -- currently many do not.
270:
271: - When the C-Kermit server is given a host command (or even some generic
272: commands like 'space'), it might have to think for a long time before
273: returning output. In this case, it should set a timer while waiting for
274: input from the fork and whenever the timer goes off, it should send a null
275: data packet to prevent the other Kermit from timing out.
276:
277: - When connecting back to C-Kermit after a transaction, or after finishing
278: the server, it may be necessary to type a ^Q to clear up an XOFF deadlock.
279: There's not much the Kermit program can do about this...
280:
281: - When interrupting a send with ^F or ^B, an appropriate message does not
282: seem to make it into the transaction log.
283:
284: - The transaction log should record file type (text or binary).
285:
286: - There should be a nonverbose transaction log, in the Unix tradition,
287: which can be read by another program. For instance, if Kermit is
288: used to 'send *', but only certain of the files make across successfully,
289: another program could read the list of those files and do something to
290: them (like (re)move them).
291:
292: ckucmd.c:
293:
294: - Interactive Kermit commands that come in from a pipe (as in
295: "cat foo | kermit") are echoed. Some people think they should not be.
296: The fix can be made (at some expense) in getwd() by adding a line to
297: the first if () {} block, "if (!isatty(0)) echof = 1;".
298: (Not sure if this is still true...)
299:
300: ckufio.c:
301:
302: - ckufio currently goes to a lot of trouble to traverse the directory in
303: order to expand "*" and "?" in wildcards. Maybe it should just fork the
304: user's customary shell and have it do the expansion. This would allow
305: fancier filespecs to be given, like "~/ck*.[cwh]". But it would slow down
306: features like filename completion and menus in the interactive command
307: parser. (Find out how Unix FTP does it...)
308:
309: ckutio.c:
310:
311: - Myread() should be expanded to include systems that can't do nonblocking
312: reads, but can find out how many characters are in the input buffer -- this
313: would eliminate calling read() in a loop for each character during packet
314: transmission (e.g. Pro/Venix V1 could use "ioctl(x,TIOCQCNT,&y)", V7 could
315: use its buffer-queue-peeking trick, etc). (Myread() was eliminated from
316: BSD, and the same technique is used as in ckucon.c -- do a single-char
317: blocking read, then check how many more chars are in the buffer, then read
318: that many -- it's faster.)
319:
320: - There should be a timed option for ttoc() for use during connect so you
321: can escape from XOFF'd or other stuck conditions.
322:
323: - There's no good way to select baud rates higher than 9600. Most Unix systems
324: don't supply symbols for them (unless you use EXTA, EXTB), and even when they
325: do, the program has no way of knowing whether a specific port serial
326: controller supports those rates.
327:
328: - Use of RAW|TANDEM in 4.1 BSD gives only unidirectional, not bidirectional,
329: flow control -- xoff's from the terminal are treated as data rather than
330: control signals. Symptom: possible loss of characters during CONNECT.
331:
332: - On some systems, there is an undesired interaction between the various
333: open() modes, fnctl(), and ioctl() invocations when modem-control lines
334: are involved. Some of this due to bugs in some Unix implementations or to
335: inconsistencies between them (e.g. as to the behavior of TIOCEXCL, etc).
336: In particular, the whole business about opening modem-controlled lines
337: with O_NDELAY before dialing and then switching modes after causes no end of
338: confusion and trouble.
339:
340: ckudia.c:
341:
342: - Some systems do not allow users to manipulate dialers directly.
343: - Should support a "phone book" (this would actually go in ckuus*.c).
344: - Pro/Venix V2 (and some other Sys V-based systems) are having DTR-dropping
345: problems when dialing. With Pro/Venix V2, a workaround is to get the system
346: to ignore the modem control signals and treat the line as a direct line by
347: issuing a "setline -d xxx" command, where "xxx" is the device node (e.g.
348: com1), rather than "setline -m xxx".
349: - Should do "demon dialing" (keep trying till there's a connection).
350:
351: ckuus*.c:
352:
353: - When an alternate filename is given for an incoming file name, and the
354: alternate name is uppercase, the name is lowercased. Alternate names
355: should be taken literally.
356:
357: - Baud rate selection currently requires user to type a number, which is
358: then verified against a system-dependent table. Better to have a baud rate
359: keyword (cmkey) table defined in the system-dependent module, so user
360: can abbreviate (e.g. '9' for '9600'). Also, it's a pain having parallel
361: tables in ckuus3.c, ckutio.c, etc. Should consolidate this.
362:
363: - No way to put trailing comments on commands.
364:
365: - ckuus2.c reportedly makes the C optimizer run out of space under PC/IX and
366: some other systems.
367:
368: Protocol (ckcpro.w, ckcfn*.c):
369:
370: - No way to interrupt a protocol transaction until after it starts
371: successfully. For instance, no way to interrupt the timeouts and
372: retransmissions of the initial packet when the other side is not
373: responding, except for killing the whole program. Cure: check for
374: keyboard "interrupts" during the send-init process, set c[xz]seen.
375: But doing this will make the state table a lot more complicated...
376: Maybe change ^C trap to get back to command mode rather than exit
377: the program.
378:
379: ckucon.c:
380:
381: - Doesn't do any particular kind of terminal emulation. It wasn't meant to.
382: Filters can be used for this. Or a replacement module can be written
383: (as has been done for the Macintosh).
384:
385: - When sending BREAK, should clear output buffer first (this is done in BSD,
386: should be added for other systems to ttsndb() in ckutio.c).
387:
388: - Performance is poor on systems that can't check the input buffer or
389: do nonblocking read() calls. See the horrendous code that was added for V7
390: to get around this (peeking into tty buffers in kernel memory).
391:
392: - As structured, connect mode can't include commands to toggle logging on
393: and off or to change settings, because the fork that reads keyboard input
394: doesn't share variables with the fork that does port i/o.
395:
396: - Reportedly, a control-S typed at the keyboard doesn't always seem to "take"
397: when doing terminal emulation under Pro/Venix V2 (DEC micros, terminals,
398: devices, systems are notorious for their insistence on doing XON/XOFF and
399: attendant problems. Remember the VT180?)
400:
401: - Should have a shell escape ("push").
402:
403: ------------------------------
404:
405: Undigested:
406:
407: Date: Sun, 24 Nov 85 04:16:02 CST
408: From: Stan Barber <[email protected]>
409: Subject: more notes on C-kermit 4C(057)
410: Organization: Neurophysiology, Baylor College of Medicine, Houston, Tx
411:
412: One more suggestion:
413:
414: I would provide some mechanism to allow SYSIII compatible sites to
415: configure what signal that might like to use to allow the child and
416: parent to notify each other of problems. At my site, SIGUSR1 can not
417: be used by kermit, so I modify ckucon.c by replacing SIGUSR1 with
418: SIGUSR2. That fixes everything just fine.
419:
420: At least a warning should be noted somewhere (in the .bwr file, I guess)
421: so that people will know to change it.
422:
423: Alternatively, I would suggest a unique name (SIGKERMIT) that the
424: installer can define in the makefile (e.g. -DSIGKERMIT=SIGUSR2) to
425: keep people from mucking in the source file.
426:
427: ------------------------------
428:
429: Date: 9 Apr 1986 1105-EST (Wednesday)
430: From: Vic Abell <[email protected]>
431: Subject: Kermit and 4.xBSD rlogin
432:
433: There is an undocumented option on the 4.xBSD rlogin call that must be used
434: when C Kermit is at the end of a TCP/IP rlogin connection. The option is "-8"
435: and should be used in the following fashion:
436:
437: % rlogin hostname -8
438: % kermit
439:
440: Vic Abell, Purdue University Computing Center
441: [email protected], ...!pur-ee!pucc-j!abe
442:
443: ------------------------------
444:
445: Date: Fri 5 Sep 86 13:59:44-EDT
446: From: Fred Wang <[email protected]>
447: Subject: problem compiling kermit on the 3b2/310
448:
449: If Mr. Ray's 3b2/310 is running the new C compiler (CFP+) he
450: will run into problems when he issues the 'make att3bx' command. CFP+
451: uses the 'fpcc' rather than the conventional 'cc' to compile C
452: programs.
453:
454: My suggestion to Mr. Ray's problem (if indeed he has CFP+) is
455: to substitute fpcc for cc in the variables CC and CC2 in the makefile
456: text. This worked fine for my 3b2/310 running Unix System V 2.0.4 with
457: CFP+ C compiler.
458:
459: ------------------------------
460:
461: Date: Fri, 12-SEP-1986 18:54 EDT
462: From: Kuryan Thomas <THOMASK@VTVAX5>
463: Subject: C-Kermit
464: To: fdccu@cuvmb
465:
466: This is Kuryan Thomas at Virginia Tech again. I talked to you about the
467: modem problem I was having with my 6300plus. I think I found the problem --
468: tthang() does an ioctl() call to clear the CBAUD field, which ought to
469: cause a hangup. On my system, ioctl() doesn't like to be called with a
470: zero baud, and returns -1, which causes tthang() to return an error.
471: I think this may be why I always get a "Warning, problem hanging up the
472: phone" whenever I exit Kermit (regardless of the "set modem" setting).
473:
474: I don't know how to cure this, but I'm not going to try. I think I prefer
475: the "aberrant" behavior. This way, I can start a session on a remote
476: Kermit, start its server, come back down to my shell, and start a long
477: file-transfer in the background. This wouldn't work if Kermit could
478: hang up the phone, because I'd have to use Kermit interactively. I often
479: transfer quite large files, and it's actually an advantage instead of a bug
480: that C-Kermit can't hang up my phone!
481:
482: Amazing how problems can be turned to your advantage, isn't it?
483:
484: Thanks for replying to my earlier message.
485:
486: ------------------------------
487:
488: Date: Mon, 15 Sep 86 21:35:48 CST
489: From: [email protected] (Stan Barber)
490: To: [email protected]
491: Subject: NEWUUCP conditional in C-KERMIT
492:
493: You do need to define the NEWUUCP conditional to get the 4.3 acucntrl support.
494: Also, lock files are now kept in a seperate globally writable LCK directory
495: so unpriviledged programs can LCK lines without have write permission on
496: /usr/spool/uucp. This will keep uucp from stomping on kermit.
497:
498: Stan
499:
500: (NEWUUCP is currently not defined anywhere, so this code never gets used)
501:
502: ------------------------------
503:
504: Date: Fri, 17 Oct 86 15:17:14 EDT
505: From: Chris Maio <[email protected]>
506: To: [email protected]
507: Subject: telnetd "fix"
508:
509: [Ed. - The following fix allows C-Kermit to work with 4.3BSD systems which are
510: accessed via TCP/IP-based terminal servers. The fix is to TELNET, not Kermit.
511: Thanks to Chris Maio of the Columbia University Computer Science Department for
512: tracking down the problem and providing a workaround.]
513:
514: This fix for /etc/telnetd in 4.3 BSD is really only a workaround, designed
515: to allow kermit, uucp, emacs, and other programs to receive carriage-return
516: chararacters over a "netascii mode" telnet connection where the client is
517: mapping carriage return to CRLFs (what I suspect to be the most common
518: case for terminal servers and non-UNIX telnet implementations). The real
519: solution is to use telnet binary mode connections, but not all telnet clients
520: allow the user to negotiate this.
521:
522: In /usr/src/etc/telnetd.c, routine telrcv(), line 640, replace
523:
524: c = '\n';
525: with
526: c = '\r';
527:
528: This fix is inappropriate if you have telnet clients which map CR into CR NUL,
529: and LF into CR LF, since those clients will then be unable to generate send the
530: linefeed character through to the application when CRMOD is turned off. See
531: RFC 854 for more details.
532:
533: The basic problem is that any program that manipulates the terminal will
534: generally only work right if the telnet connection is "binary mode" (remember
535: those odd commands you have to give to a TAC?). Many telnet user interfaces,
536: including the terminal concentrators we use, don't provide a way for the user
537: to specify binary mode instead of netascii mode. TOPS-20 is a lot smarter
538: about this kind of thing, e.g. it negotiates telnet binary mode when a program
539: running on a TVT specifies binary input from its controlling terminal, but
540: I'm sure there are still bugs in TOPS-20's implementation.
541:
542: Chris
543:
544: ------------------------------
545:
546: Date: Wed, 7 Jan 87 00:55:42 EST
547: From: [email protected] (Gary Nelson)
548: Subject: Xenix on IBM-PC/AT & SCO Xenix V
549: Keywords: Xenix, C-Kermit, SCO Xenix
550:
551: In response to request for users of C-Kermit 4D(061) on SCO Xenix:
552:
553: My configuration: IBM-PC/AT
554: SCO Xenix Release 2.1.3 (Update E & F)
555:
556: The dial command did not work after updating to the release of SCO
557: Xenix V. The following diff file corrects problem in ckutio.c that broke
558: the dial command. Note, if you are on SCO Release 2.1.0 - DO NOT include
559: this fix, leave the 4D061 version as released alone - it works fine. The
560: nap() mod is not neccessary - just saw it and changed it to use an available
561: facility.
562:
563: ********** start of diff file **********
564:
565: 14a15,27
566: > /* Modification history:
567: >
568: > 23-NOV-86 Gary B. Nelson, Nelson Associates, Manassas, VA
569: > As a consequence of my new release of SCO Xenix V2.1.3
570: > breaking kermit:
571: > Mods to msleep to use nap(), note -> add "-lx" to
572: > LNKFLAGS in the makefile.
573: > Mods to tthang to make it work again, with this new release
574: > of XENIX (symptom was that the dial command
575: > stopped working, a problem that was incorrectly
576: > diagnosed by ?? as seen on the usenet a few days ago).
577: > */
578: >
579: 527d539
580: < #ifndef XENIX /* xenix cannot do close/open when carrier drops */
581: 532d543
582: < #endif
583: 1416,1418c1427
584: < #ifdef XENIX
585: < #define CLOCK_TICK 50 /* millisecs per clock tick */
586: < #else
587: > #ifndef XENIX
588: 1420d1428
589: < #endif
590: 1431a1440,1446
591: > #endif
592: > #endif
593: >
594: > #ifdef UXIII
595: > #ifdef XENIX
596: > nap( (long) m );
597: > #endif
598:
599: ********** end of diff file **********
600:
601: ------------------------------
602:
603: Date: Sat, 29 Aug 87 15:37 EST
604: From: <[email protected]> (Rick Pim)
605: Subject: C-Kermit 4E Amiga .BOO File
606: Keywords: C-Kermit, Amiga
607:
608: The Aug 7 info-kermit digest mentioned a new release of C-Kermit
609: for, amongst other things, the Amiga. According to the directory I looked
610: at of cki* *, the BOO file is new. The digest requested comments/etc, so I
611: ordered the BOO file and decoded it today. According to the header once
612: it's running, the version is 4D. It has at least one of the same bugs as 4D
613: (parity does not work).
614:
615: [Ed. - Right, we don't have an Amiga .BOO file based on the new version yet.
616: We were hoping somebody would make one. See next message.]
617:
618: ------------------------------
619:
620: Date: Wed, 12 Aug 87 10:25:42 pdt
621: From: [email protected] (Steve Walton)
622: Subject: C-Kermit 4E(066) on Amiga
623: Keywords: C-Kermit, Amiga
624:
625: Well, I grabbed C-Kermit 4E(066) from CU20B, and have been able to compile and
626: link a running version on my Amiga using Manx Aztec C V3.40b. In the process,
627: I added the appropriate include files and the DOSFH and FILENO macros for Manx
628: C to ckiutl.c and ckitio.c; diffs will follow shortly. (One thing which was
629: easy: parity can be ignored in ttinl(), since the Amiga's serial.device
630: handles it itself, and passes characters to Kermit with the parity bit already
631: stripped.)
632:
633: Stephen Walton, [email protected]
634: Ametek Computer Research Div.
635: 610 N. Santa Anita Ave.
636: Arcadia, CA 91006 USA
637: 818-445-6811
638:
639: ------------------------------
640:
641: Date: Thu, 3 Sep 87 08:26:14 EDT
642: From: [email protected]
643: Subject: C-Kermit 4E Problems on Tandy 16A/6000 and Arete 1200
644: Keywords: C-Kermit, Tandy 16A/6000, Arete 1200
645:
646: I've tried out the new 4E(066) release on a Tandy 16A/6000 and Arete 1200 under
647: System V.2. One problem I've noticed is that if you try to get the status
648: of the transfer, as soon as you type Cntrl A, the transmission begins to
649: send %T's, and eventually times out. This was during file transmissions
650: between the Arete and MTS Kermit. It was also reproducible between the
651: Arete and Tandy machines.
652:
653: [Ed. - This sounds like something pretty specific to your machine; Ctrl-A
654: status reports work ok on the machines we've tested. I hope you can track it
655: down.]
656:
657: The program compiled cleanly on both machines, except that on the Tandy end
658: (running under Xenix 3.1.2), I had to include <sys/types.h> for one of the
659: files in which void is used.
660:
661: ------------------------------
662:
663: From: [email protected] (Stan Barber)
664: Subject: C-Kermit Lock Files
665: Date: 20 Aug 87 21:26:17 GMT
666: Keywords: C-Kermit, Unix Lock Files
667:
668: I should point out that C-Kermit(041) does handle lock files correctly under
669: BSD4.3 with the 4.3UUCP locking structure. This creates a lock directory
670: (/usr/spool/uucp/LCK) that is publically writable and each program (except
671: kermit) using the locking protocol is smart enough to test for dead locks
672: (coming from programs that aborted and did not remove its lock).
673:
674: Stan
675:
676: [Ed. - Presumably, this is also true for 4E?]
677:
678: ------------------------------
679:
680: Date: 13 Sep 87 17:22:26 GMT
681: From: [email protected] (Warren Burstein)
682: Subject: patches to ckermit
683: Organization: Industrial Automation Systems - New York, NY
684:
685: These patches add to ckermit a "set phone" command. Aliases
686: are recognized in the "dial" command. My .kermrc is now full of
687: set phone commands.
688:
689: The new command looks like
690: set phone pacx 280-8050
691: After this command, I can say
692: dial pacx
693:
694: I don't know how to make a "patch" file so here is a shar
695: of all the diffs.
696:
697: I am leaving the net in two days, I hope to be back on in
698: a while and pick up my mail from this machine.
699:
700: I didn't use any fancy methods to store phone numbers, it didn't
701: seem worth the effort.
702:
703: ---------------
704: # This is a shell archive. Remove anything before this line, then
705: # unpack it by saving it in a file and typing "sh file". (Files
706: # unpacked will be owned by you and have default permissions.)
707: #
708: # This archive contains:
709: # ckudia.diff ckuus3.diff ckuusr.diff ckuusrh.diff
710:
711: echo x - ckudia.diff
712: cat > "ckudia.diff" << '//E*O*F ckudia.diff//'
713: 73,75d72
714: < *
715: < * 6-May-87 Support for phone aliases
716: < * -- Warren Burstein
717: 126d122
718: < char *malloc(), *strcpy();
719: 422,431d417
720: <
721: < /*
722: < * Array of phone aliases, unsorted
723: < */
724: <
725: < #define MAXPHONES 100
726: < struct phones {
727: < char *name, *number;
728: < } phones[MAXPHONES];
729: <
730: 528d513
731: < struct phones *lookup_phone(), *p;
732: 530,537d514
733: < if ( !isdigit(*telnbr))
734: < if (p = lookup_phone(telnbr))
735: < telnbr = p->number;
736: < else {
737: < printf("I don't recognize that system\n");
738: < return -2;
739: < }
740: <
741: 866,927d842
742: < }
743: <
744: < /*
745: < * Following code added by WB for phone aliases.
746: < */
747: <
748: < /*
749: < * Add a phone alias.
750: < */
751: <
752: < add_phone(name, number)
753: < char *name, *number;
754: < {
755: < struct phones *p;
756: <
757: < /*
758: < * If name is in use, redefine its number.
759: < */
760: < if (p = lookup_phone(name)) {
761: < free(p->number);
762: < p->number = malloc(strlen(number) + 1);
763: < (void) strcpy(p->number, number);
764: < return;
765: < }
766: <
767: < /*
768: < * Find a vacancy in the table.
769: < */
770: < for (p = phones; p < &phones[MAXPHONES]; p++)
771: < if ( !p->name) {
772: < p->name = malloc(strlen(name) + 1);
773: < (void) strcpy(p->name, name);
774: < p->number = malloc(strlen(number) + 1);
775: < (void) strcpy(p->number, number);
776: < return;
777: < }
778: <
779: < printf("There are too many phone aliases.\n");
780: < }
781: <
782: < /*
783: < * Returns phone number to use, or NULL if phone number could not be found.
784: < */
785: <
786: < struct phones *lookup_phone(name)
787: < char *name;
788: < {
789: < struct phones *p;
790: <
791: < for (p = phones; p < &phones[MAXPHONES]; p++)
792: < if (p->name && !strcmp(p->name, name))
793: < return p;
794: <
795: < return (struct phones *) 0;
796: < }
797: <
798: < shphones() {
799: < struct phones *p;
800: <
801: < for (p = phones; p < &phones[MAXPHONES]; p++)
802: < if (p->name)
803: < printf("%s %s\n", p->name, p->number);
804: //E*O*F ckudia.diff//
805:
806: echo x - ckuus3.diff
807: cat > "ckuus3.diff" << '//E*O*F ckuus3.diff//'
808: 268,280d267
809: < case XYPHONE:
810: < {
811: < char name[30], number[30];
812: <
813: < if ( (x = cmfld("name of phone alias", "", &s)) < 0) return x;
814: < (void) strcpy(name, s);
815: < if ( (x = cmfld("phone number", "", &s)) < 0) return x;
816: < (void) strcpy(number, s);
817: <
818: < add_phone(name, number);
819: < }
820: < break;
821: <
822: //E*O*F ckuus3.diff//
823:
824: echo x - ckuusr.diff
825: cat > "ckuusr.diff" << '//E*O*F ckuusr.diff//'
826: 436d435
827: < "phone-number", XYPHONE, 0,
828: 473,474c472
829: < #define SHPHONE 2 /* phone numbers */
830: <
831: ---
832: >
833: 477d474
834: < "phone-aliases", SHPHONE, 0,
835: 1085,1089c1082
836: <
837: < case SHPHONE:
838: < shphones();
839: < break;
840: <
841: ---
842: >
843: //E*O*F ckuusr.diff//
844:
845: echo x - ckuusrh.diff
846: cat > "ckuusrh.diff" << '//E*O*F ckuusrh.diff//'
847: 104c104
848: < #define XYPHONE 33 /* set phone alias - WB */
849: ---
850: >
851: //E*O*F ckuusrh.diff//
852:
853: exit 0
854: --
855: /|/~\~~\ The entire world Warren Burstein
856: |__/__/_/ is a very strange carrot.
857: | But the farmer philabs!tg!pluto!warren
858: / is not afraid at all. Why doesn't life come with subtitles?
859:
860: ------------------------------
861:
862: Date: Mon, 21 Sep 87 09:54:28 PDT
863: From: [email protected] (Kevin 0'Gorman)
864: Subject: C-kermit 067 / UNIX PC
865:
866: The comments in the makefile about AT&T 3bx machines DO NOT APPLY
867: to the 3b1. This machine uses the standard lock files. However, when using
868: the "shared libraries" (highly recommended) available on the UNIX PC, there
869: is a name conflict which makes it useful to add something like
870: -Dopeni=UPCOI -Ddial=UPCDIAL
871: to the cc command line. I accordingly create a new version, like the sys3
872: entry except for this addition. I call it unixpc, though upc would also be
873: familiar to UNIX PC hackers.
874:
875: ------------------------------
876:
877: Date: Wed, 23 Sep 87 08:43:02 EDT
878: From: [email protected]
879: Subject: C-Kermit on Tandy 6000
880:
881: Regarding your question about the Tandy 6000:
882: I am currently running 4D(061) kermit on such a machine with no
883: problems. My machine has 512K memory and a 15 Meg hard drive. It
884: runs at 6Mhz. I have not experienced any problems with "slowness",
885: as other's have often described. As a matter of fact, my machine is
886: in reality on old Model II that was upgraded to essentially a Model 16a,
887: which is my case is equivalent to a Model 6000 now. Anyway, the Xenix
888: that Tandy current supports is Xenix 3.1.2, which is pretty much like
889: system III. Note that all the versions of kermit I have compiled on my
890: machine have been done under Xenix 3.xx. The earlier version of Xenix that
891: Tandy put out for the first Model 16's was done from a version 7 Unix base.
892: I have had no expericence with the older Xenix. However, if you are using that
893: version, you really should pay the $99.00 to Tandy and upgrade to version
894: 3.xx. (At least it was $99.00 about a year and a half ago).
895: Anyhow, to compile c-kermit on a 6000 under Xenix 3.xx, you need to do
896: two things:
897: 1). Look in the source files for the use of identifier "void". If you
898: find that identifier in a file, make sure you put the include
899: line "#include <sys/types.h>" at the top of that file with the
900: other include statements.
901: 2). Say make sys3, and wait awhile. If your system is fully loaded,
902: ie, about 90% full on the hard drive, and little memory, you may
903: not be able to compile the program. Make space on your hard drive
904: (down to around 75% free), and try again. It may take as long as
905: a half hour to compile.
906:
907: Note that I recently compiled the experimental c-kermit (the "new release")
908: on a 6000 under Xenix 3.1.2 with no problems, save for the "void" identifier.
909: Also note that I am the only user of my machine, ie, I don't have other
910: users running out of tty ports. I can't tell you what running kermit
911: is like on a 6000 with 2-3 other users.
912:
913: I hope this information is of help to Tandy 6000 owners trying to get kermit
914: up and running.
915:
916: ------------------------------
917:
918: To: [email protected]
919: Subject: minor bug in c-kermit
920: Date: Thu, 01 Oct 87 23:52:57 EDT
921: From: [email protected]
922:
923: In C-Kermit 4E(067) 14 Sep 87, 4.2 BSD:
924: When compiling under Ultrix 2.0, using the vcc C compiler (which is slightly
925: better than pcc), C-Kermit doesn't compile cleanly, due the the existence
926: of several #ifdef vax11c lines in some of the .h files. These have been used
927: to denote VAX/VMS specific code. The vcc compiler pre-defines the symbol
928: vax11c on Ultrix just as it does on VMS. C-Kermit can be made to compile
929: cleanly on both Ultrix and VMS if these lines are changed to #ifdef vms.
930:
931: Keith Moore
932: UT Computer Science Dept. Internet: [email protected]
933: 107 Ayres Hall, UT Campus CSnet: moore@tennessee
934: Knoxville Tennessee BITNET: moore@utkcs1
935:
936: ------------------------------
937:
938: Date: Wed, 21 Oct 87 22:20:18 EDT
939: From: [email protected] (Paul Sutcliffe Jr.)
940: Subject: Diffs for C-Kermit 4D(061) and Tandy 6000
941: Keywords: C-Kermit 4D(061), Tandy Kermit
942:
943: In Info-Kermit Digest V6 #23, I said I'd send the diffs along to compile
944: C-Kermit on a Tandy 6000. Here they are. Note that they assume that one is
945: running Tandy Xenix 3.0 or greater.
946:
947: Install these diffs in the "stock" 4D(061) C-Kermit distribution, and then
948: type "make trs16" to compile. In reality, you only need to make the
949: modification to the makefile (ckuker.mak); the other diffs just make the
950: startup banner agree with the operating system version -- I didn't like
951: kermit saying "Xenix/286" on my 68000!
952:
953: - paul
954:
955: =========== CUT HERE ===========
956:
957: *** .orig/ckuker.mak Fri Nov 21 16:04:08 1986
958: --- ckuker.mak Sun Jan 18 13:29:07 1987
959: ***************
960: *** 226,231
961: "LNKFLAGS = -F 3000 -i"
962:
963:
964: #PC/IX, Interactive Corp System III for IBM PC/XT
965: pcix:
966: make wermit \
967:
968: --- 226,237 -----
969: "LNKFLAGS = -F 3000 -i"
970:
971:
972: + #Tandy 16/6000 with Xenix 3.0
973: + trs16:
974: + make wermit "CFLAGS= -DTRS16 -DXENIX -DUXIII -DDEBUG -DTLOG -DM_VOID -Dvoid=int -F 3000 -n" \
975: + "LNKFLAGS = -F 3000 -n"
976: +
977: +
978: #PC/IX, Interactive Corp System III for IBM PC/XT
979: pcix:
980: make wermit \
981:
982: *** .orig/ckufio.c Fri Nov 21 16:04:08 1986
983: --- ckufio.c Sat Jan 17 20:43:16 1987
984: ***************
985: *** 63,68
986: /* Sys III/V, Xenix, PC/IX,... support by Herm Fischer, Litton Data Systems */
987: #ifdef UXIII
988: #ifdef XENIX
989: char *ckzsys = " Xenix/286";
990: #else
991: #ifdef PCIX
992:
993: --- 63,71 -----
994: /* Sys III/V, Xenix, PC/IX,... support by Herm Fischer, Litton Data Systems */
995: #ifdef UXIII
996: #ifdef XENIX
997: + #ifdef TRS16
998: + char *ckzsys = " Xenix/68000";
999: + #else
1000: char *ckzsys = " Xenix/286";
1001: #else
1002: #ifdef PCIX
1003: ***************
1004: *** 71,76
1005: #ifdef ISIII
1006: char *ckzsys = " Interactive Systems Corp, System III";
1007: #else
1008: char *ckzsys = " AT&T System III/System V";
1009: #endif
1010: #endif
1011:
1012: --- 74,80 -----
1013: #ifdef ISIII
1014: char *ckzsys = " Interactive Systems Corp, System III";
1015: #else
1016: + #ifndef TRS16
1017: char *ckzsys = " AT&T System III/System V";
1018: #endif
1019: #endif
1020: ***************
1021: *** 72,77
1022: char *ckzsys = " Interactive Systems Corp, System III";
1023: #else
1024: char *ckzsys = " AT&T System III/System V";
1025: #endif
1026: #endif
1027: #endif
1028:
1029: --- 76,83 -----
1030: #else
1031: #ifndef TRS16
1032: char *ckzsys = " AT&T System III/System V";
1033: + #endif
1034: + #endif
1035: #endif
1036: #endif
1037: #endif
1038:
1039: *** .orig/ckutio.c Fri Nov 21 16:04:09 1986
1040: --- ckutio.c Sat Jan 17 20:44:47 1987
1041: ***************
1042: *** 96,101
1043: /* Sys III/V, Xenix, PC/IX support by Herm Fischer, Encino, CA */
1044: #ifdef UXIII
1045: #ifdef XENIX
1046: char *ckxsys = " Xenix/286";
1047: #else
1048: #ifdef PCIX
1049:
1050: --- 96,104 -----
1051: /* Sys III/V, Xenix, PC/IX support by Herm Fischer, Encino, CA */
1052: #ifdef UXIII
1053: #ifdef XENIX
1054: + #ifdef TRS16
1055: + char *ckxsys = " Xenix/68000";
1056: + #else
1057: char *ckxsys = " Xenix/286";
1058: #else
1059: #ifdef PCIX
1060: ***************
1061: *** 104,109
1062: #ifdef ISIII
1063: char *ckxsys = " Interactive Systems Corp System III";
1064: #else
1065: char *ckxsys = " AT&T System III/System V";
1066: #endif
1067: #endif
1068:
1069: --- 107,113 -----
1070: #ifdef ISIII
1071: char *ckxsys = " Interactive Systems Corp System III";
1072: #else
1073: + #ifndef TRS16
1074: char *ckxsys = " AT&T System III/System V";
1075: #endif
1076: #endif
1077: ***************
1078: *** 105,110
1079: char *ckxsys = " Interactive Systems Corp System III";
1080: #else
1081: char *ckxsys = " AT&T System III/System V";
1082: #endif
1083: #endif
1084: #endif
1085:
1086: --- 109,116 -----
1087: #else
1088: #ifndef TRS16
1089: char *ckxsys = " AT&T System III/System V";
1090: + #endif
1091: + #endif
1092: #endif
1093: #endif
1094: #endif
1095:
1096: =========== CUT HERE ===========
1097:
1098: Paul Sutcliffe, Jr.
1099:
1100: UUCP (smart): [email protected]
1101: UUCP (dumb): ...{rutgers,ihnp4,cbosgd}!bpa!vu-vlsi!devon!paul
1102:
1103: ------------------------------
1104:
1105: Date: Tue, 3 Nov 87 08:20:38 CST
1106: From: [email protected]
1107: (Richard Sharpe--Apprentice Sorcerer)
1108: Subject: CKermit under Unix ...
1109:
1110: We are having problems with ckermit on an Ultrix system (approx 4.3BSD).
1111:
1112: We have kermit installed setuid and setgid to uucp to allow access to the UUCP
1113: spool directory (to write the lock files). However, whenever kermit tries to
1114: write files in the user's directories (perhaps because the user is running
1115: kermit on the VAX in server mode and doing a send from a pc--mskermit), it
1116: fails saying that it cannot open the file. If the user sets their directory to
1117: world write, then ckermit onm the VAX is happy.
1118:
1119: Now, this seems to be an interaction between the way we have kermit installed
1120: and what it is trying to do, but I cannot see any other way to set up kermit
1121: so that it can reliably access the UUCP spool directory.
1122:
1123: So, I checked out the code, and found that zopeno in ckufio.c just does an
1124: open of the file that it is opening for output and then does a chown to the
1125: real user and real group. I added the following code, and all seems to work:
1126:
1127: 1. First pick up the real and effective UIDs.
1128:
1129: 2. Then, just before the file open, set effective UID to back to our real
1130: UID.
1131:
1132: 3. Then, just after the file open, set our effective UID back to what it
1133: was just before we changed it.
1134:
1135: Here is the code fragment that does it (lines with a * in col 1 are mine):
1136:
1137: zopeno(n,name) int n; char *name; {
1138: * int uid, euid;
1139: debug(F111," zopeno",name,n);
1140: if (chkfn(n) != 0) return(0);
1141: if ((n == ZCTERM) || (n == ZSTDIO)) { /* Terminal or standard output */
1142: fp[ZOFILE] = stdout;
1143: debug(F101," fp[]=stdout", "", (int) fp[n]);
1144: return(1);
1145: }
1146: * uid = getuid(); euid = geteuid();
1147: * seteuid(uid); /* Set us back to who is running kermit */
1148: fp[n] = fopen(name,"w"); /* A real file, try to open */
1149: * seteuid(euid); /* And set things back to our SUID value */
1150: if (fp[n] == NULL) {
1151: perror("zopeno can't open");
1152: } else {
1153: chown(name, getuid(), getgid()); /* In case set[gu]id */
1154: if (n == ZDFILE) setbuf(fp[n],NULL); /* Debugging file unbuffered */
1155: }
1156: debug(F101, " fp[n]", "", (int) fp[n]);
1157: return((fp[n] != NULL) ? 1 : 0);
1158: }
1159: ------------------------------------
1160:
1161: Now, as I say, this works, but I wonder if there is not a simpler way to get
1162: this done, like only have kermit setgid to uucp. Would that be sufficient?
1163:
1164: BTW, this fragment came from version 4c(029) of ckufio.c. I also have
1165: another version (ckcmai 4d(061) 8-Sep-86 and ckufio 4c(033) 8-Sep-86) but
1166: there seems to be no changes in routine zopeno.
1167:
1168: Hope you can help me here.
1169:
1170: Regards
1171: Richard Sharpe
1172: rsharpe%[email protected]
1173:
1174: ------------------------------
1175:
1176: Date: Wed, 4 Nov 87 09:54:09 CST
1177: From: [email protected]
1178: (Richard Sharpe--Apprentice Sorcerer)
1179: Subject: CKermit under Unix ...
1180:
1181: I have found problems with my solution that are to do with the differences
1182: between sysV and 4.2 (I read about this setuid stuff in Bach's book), so I am
1183: going to fix it up properly for SysV and 4.2/Ultrix. I also have access to a
1184: MicroPort 2.2 system, so I will try to get it working on that system as well.
1185: Finally, across the road is an NCR Tower, so I will try to get it running on
1186: that.
1187:
1188: When I do, I will ship you a copy of the changes. I may also try to fix the
1189: problem where you wipe out the existing file if a send is aborted. However,
1190: let me know if someone has already fixed this.
1191:
1192: Regards
1193: Richard
1194:
1195: ------------------------------
1196:
1197: Date: Wed 4 Nov 87 09:40:00-EST
1198: From: Frank da Cruz <[email protected]>
1199: Subject: Re: CKermit under Unix ...
1200: To: [email protected]
1201:
1202: Sounds good. And no, nobody has sent in a fix for wiping out an existing
1203: file when the transfer is aborted, and "warning" is off. Of course, if
1204: people care about this, they should set warning on. But to be super nice
1205: to them, I suppose Kermit could behave as though warning was on all the time,
1206: i.e. give a new, unique name to an incoming file if another file by the
1207: desired name already exists. Then, if the transfer finishes successfully,
1208: delete the old file and rename the new one to the desired name. Otherwise,
1209: delete the new file and keep the old one. - Frank
1210:
1211: ------------------------------
1212:
1213: Date: Sun, 6 Dec 87 16:02 MST
1214: From: <JRD%[email protected]> (Joe Doupnik)
1215: Subject: CKermit bug in MAXL field w/Long pkts.
1216:
1217: A small problem in CKermit 4E(067) 14 Sept 1987: when using Long
1218: Packets the MAXL field in the initialization packet is incorrect. For example,
1219: when the received packet size is set to 1000 bytes (Set Rec Pack 1000) then
1220: MAXL is transmitted as a Control-H (8) and when the size is set to 997 bytes
1221: then MAXL is Control-E (5). This indicates that somewhere the parameter rpsiz
1222: is referring to the Long packet length rather than the desired size of regular
1223: packets and tochar(rpsiz) is, of course, extracting the 8 bit remainder of
1224: rpsiz + 32d. Curiously, manually overriding the startup length yields a correct
1225: field for the initial S packet interchange with the server but an incorrect
1226: value for the S packet interchange for a particular file.
1227: In practice this has little effect because Long packet lengths are
1228: used from their separate information and when they are not used the MAXL
1229: field is correct.
1230: Regards,
1231: Joe D.
1232:
1233: ------------------------------
1234:
1235: A user at NBS complained that the makefile does not work for building
1236: C-Kermit from source on a PC/AT under Microsoft Xenix version 3.4B.
1237: It compiled all the source files into object files, but did not link them
1238: together into "wermit". After much experimentation, he found that he
1239: could link the program manually:
1240:
1241: cc -F3000 -i -o wermit <list of object files>
1242:
1243: ------------------------------
1244:
1245: Date: 27 Jan 88 10:59 EST
1246: From: [email protected] (John Junod)
1247: Subject: C-Kermit Timeout Problem Fix
1248: Keywords: C-Kermit 4E(068)
1249:
1250: The following code was developed about a year and a half ago by Mark A.
1251: Thomas here at David Taylor Research Center to solve the time-out problem as
1252: mentioned in the Info-Kermit Digest, V7 #3.
1253:
1254: Hope this helps....
1255:
1256: L. John Junod
1257: junod@dtrc
1258:
1259: /* The following fix was made in kermit to prevent the local machine from
1260: timing out the terminal line. The local machine uses the last access time
1261: of /dev/ttyXX to check for an inactive terminal. Fancy kermit i/o doesn't
1262: update /dev/ttyXX while packets are sent/received. Since a packet doesn't
1263: update the access time of the tty line, The local machine thinks the line is
1264: inactive and times it out after 5-10 minutes. A call to the routine
1265: check_time() is made in spack() and rpack(), and after 50 packets the tty
1266: time is updated. 60 packets at 300 baud take about 5 minutes to send, so 50
1267: packets is safe. */
1268:
1269: /* included to fix local timeout problem */
1270:
1271: #include "signal.h"
1272: #include "sys/types.h"
1273: #include "sys/timeb.h"
1274: #define NULL 0x0
1275:
1276: /* C H E C K _ T I M E -- Fix timeout during packet sending and
1277: receiving. Since packets don't update the
1278: tty access and modify times, we do it. */
1279:
1280: check_time()
1281: {
1282: static char *tty_name = (char *) NULL;
1283: static int i = 0;
1284: char *ttyname(),*calloc();
1285: struct timeb tbp;
1286: time_t t[2];
1287: if (tty_name == NULL)
1288: {
1289: tty_name = calloc(32,sizeof(char));
1290: strcpy(tty_name,ttyname(0)); /* allocate and get tty name of stdin */
1291: }
1292: i++;
1293: if (i > 50)
1294: {
1295: i = 0;
1296: ftime(&tbp); /* get system time */
1297: t[0] = tbp.time;
1298: t[1] = tbp.time;
1299: utime(tty_name,t); /* update tty time */
1300: }
1301: }
1302:
1303: [Ed. - This would probably do the trick for BSD, but all the time stuff is
1304: system dependent. BSD, Sys V, Xenix, Venix, V7, etc, have different ways of
1305: getting the time. Meanwhile, this message has been added to the C-Kermit
1306: "beware file".]
1307:
1308: ------------------------------
1309:
1310: Date: Mon, 1 Feb 88 15:23:59 EST
1311: From: Gary P Standorf <[email protected]>
1312: Subject: Ifdef problem with ckuus3.c.2
1313:
1314: When I tried compiling C-Kermit 4E(070) on an Intel-310 running
1315: SCO Xenix 3.4 it blew up in the ckuus3.c module. It doesn't like the
1316: #include <termio.h> line which follows the #ifdef UXIII in ckuus3.c.
1317: I added an #ifndef XENIX before the include for termio.h and then it
1318: compiled ok. I am including a context diff for your convenience.
1319:
1320: PS. I hope that doing an #ifndef was the proper thing to do, since I'm not
1321: sure what other versions of XENIX need.
1322:
1323: Thanks,
1324:
1325: Gary Standorf
1326: <[email protected]>
1327:
1328: ---------------------------------------------------------------------------
1329: *** ckuus3.c Mon Feb 1 14:58:01 1988
1330: --- ckuus3.c.new Mon Feb 1 14:55:46 1988
1331: ***************
1332: *** 20,25
1333: #include "ckucmd.h"
1334: #include "ckuusr.h"
1335: #ifdef UXIII
1336: #include <termio.h>
1337: #endif
1338:
1339:
1340: --- 20,26 -----
1341: #include "ckucmd.h"
1342: #include "ckuusr.h"
1343: #ifdef UXIII
1344: + #ifndef XENIX
1345: #include <termio.h>
1346: #endif
1347: #endif
1348: ***************
1349: *** 21,26
1350: #include "ckuusr.h"
1351: #ifdef UXIII
1352: #include <termio.h>
1353: #endif
1354:
1355: #ifdef datageneral
1356:
1357: --- 22,28 -----
1358: #ifdef UXIII
1359: #ifndef XENIX
1360: #include <termio.h>
1361: + #endif
1362: #endif
1363:
1364: #ifdef datageneral
1365:
1366: -------
1367:
1368: Date: Tue, 2 Feb 88 02:39:45 CST
1369: From: Donn Baumgartner <[email protected]>
1370: Subject: bug/problem
1371:
1372: version: 4e(70) [I think]
1373: system: pc/ix
1374: problem
1375: description: compilation fails during link phase with unresolved reference
1376: to _getcwd (and _end, but that doesn't count)
1377:
1378: The problem is in ckufio.c, in routine zgtdir(); the #ifdef's there are
1379: not correct for pc/ix (there, grouped with UXIII).
1380:
1381: I have two fixes:
1382: (1) just have the call return the (un-ifdef'ed) default, a pseudo
1383: error message (it's something like "(undefined..."); not a
1384: very elegant solution, but functional.
1385: (2) I have programmed the berkeley-like call 'getwd' along with
1386: supporting directory routines opendir, closedir, etc.; I did
1387: these some time ago - they're well tested. You're welcome to
1388: this source, if you like.
1389:
1390: I have integrated the (2) solution into my copy; it's not clear whether
1391: either solution is 'better', as I didn't notice how important that routine
1392: was in the whole scheme of things...
1393: cheers,
1394: Donn Baumgartner
1395: [email protected]
1396: -------
1397:
1398: Date: Wed, 10 Feb 88 22:29:13 EST
1399: From: rochester!ames!ucbcad!ucbvax.Berkeley.EDU!-
1400: [email protected] (Rahul Dhesi)
1401: Subject: Re: Unix Kermit Idle Line Problem
1402:
1403: This is an answer to a query from [email protected] (Michael Galassi)
1404: dated 28 Dec 87 00:42:59 GMT, in which he said that users using
1405: "C-Kermit, 4C(057) 31 Jul 85, 4.2 BSD" are timed out for being idle
1406: even though they are doing Kermit file transfers. Here is my
1407: work-around as it was posted in a local newsgroup.
1408:
1409: "By popular demand, here again is the technique for avoiding inactivity
1410: timeouts when doing a long file transfer via Kermit.
1411:
1412: Step 1. At the system prompt, give the command "tty". This command
1413: will print your terminal name. It will be of the form /dev/tty15
1414: where instead of 15 you will see the number of your terminal.
1415: Remember it.
1416:
1417: Step 2. Invoke Kermit interactively with the command "kermit" given
1418: without parameters. (Actually you can give parameters too, so long
1419: as they don't cause Kermit to begin data transfer immediately.)
1420: When Kermit starts up and prints the prompt "C-Kermit", you go to:
1421:
1422: Step 3. To Kermit, give the command "set line /dev/tty15". In place
1423: of the 15, use whatever terminal number you obtained in Step 1.
1424:
1425: Step 4. Now give Kermit the commands necessary to begin your file
1426: transfer. You will not get an inactivity timeout.
1427:
1428: Users who want to win fame on this system and the gratitude of others
1429: can change Kermit so that the above sequence will not be necessary.
1430: Currently Kermit uses the standard device /dev/tty which is synonymous
1431: with your actual terminal. However, the operating system treats it
1432: like a distinct device from your actual terminal. So, even though a
1433: file transfer is going on using /dev/tty, the actual terminal, say
1434: /dev/tty15, seems to be idle to the system, so you can get logged out.
1435: This can be fixed by (a) finding the place where Kermit opens /dev/tty
1436: and (b) replacing that with an open of the actual terminal name, which
1437: can be obtained from the system call ttyname()."
1438:
1439: Rahul Dhesi UUCP: {ihnp4,seismo}!{iuvax,pur-ee}!bsu-cs!dhesi
1440:
1441: [Ed. - We'll consider this for the next release. Meanwhile, this message
1442: has been added to the C-Kermit "beware file", CKUKER.BWR.]
1443:
1444: ------------------------------
1445:
1446: Date: 10 Feb 88 23:09:57 EST (Wed)
1447: From: [email protected] (Len Rose)
1448: Subject: C-Kermit 4E(070)
1449: Keywords: C-Kermit 4E(070)
1450:
1451: One little note to people setting up this on an ATT 3B2 running under
1452: SYSVR3... They have two options in the makefile that sort of clash when you
1453: are bringing up this software.. You either have to choose:
1454:
1455: make att3bx or make sys5r3
1456:
1457: If you don't choose att3bx,the code does not look for the LCK..ttyxx in
1458: /usr/spool/locks ... However if you choose att3bx,it does not handle signals
1459: correctly... All I did to defeat this was just put a #define in ckutio.c for
1460: att3bx...
1461:
1462: Just thought I'd pass this on, no big deal with it...
1463:
1464: Len
1465:
1466: [Ed. - Sigh, lock files again. There must be some better approach. Are
1467: there any Unix experts out there who can suggest a better way to deal with
1468: this problem, than requiring Kermit itself know the directory name, the
1469: filename, the permissions, and the contents of the lock file on every version
1470: of every Unix variant? Perhaps a separate program that runs Kermit in a
1471: lower fork, or a program that Kermit runs in a lower fork. Of course,
1472: separate programs have a way of getting lost...]
1473:
1474: ------------------------------
1475:
1476: Date: Fri, 12 Feb 88 12:34:08 EST
1477: From: David Herron E-Mail Hack <[email protected]>
1478: To: [email protected]
1479: Subject: Bug Report for C-Kermit 4E(070) on Unix PC (3b1)
1480:
1481: I've gotten a copy of C-Kermit and am trying it out on various machines.
1482: Mainly my Unix-PC since it's advertised to support the UnixPC.
1483:
1484: First off, it wouldn't even compile right. In ckudai.c there is a "static
1485: MDMINF ATT7300" which simply CANNOT be right. The problem is that you're also
1486: using "ATT7300" as the pre-processor symbol to select UnixPC features, and it
1487: has a null value, and the statement ends up looking like:
1488: "struct mdminf = { ... };" which is a syntax error.
1489:
1490: My workaround for the moment is to make all references to that symbol to be
1491: "att7300" and make sure it's "static". The preprocessor on UnixPC's is of the
1492: style that doesn't allow:
1493:
1494: #define ATT7300 ATT7300
1495:
1496: because it complains about macro recursion. (Oh, BTW, I'm running SYSV r3.51,
1497: the latest version for Unix PC's).
1498:
1499: Next, the makefile stuff for supporting the shared libraries is wrong. When
1500: doing an ld to use the shared libraries, at least on Unix PC's, you pretty
1501: much have to use ld directly like:
1502:
1503: ld {some options} /lib/shlib.ifile {object files}
1504: {more options} /lib/shlib
1505:
1506: I may be off in a detail or two, but the point is that the way it was written
1507: in the makefile was very wrong, as evidenced by all the multiply defined
1508: symbols. Further, if I undo the stuff for the shared libraries I get
1509: "tgetent" and a couple of other termcap functions as being undefined. And I
1510: can't find those functions in any of the libraries on the system. What I
1511: ended up doing was using a "cc" front end which handles loading the shared
1512: libraries properly and has support for programs which use curses. It was
1513: posted recently in unix-pc.sources and I could forward it to y'all if you
1514: want. (It's the one named "ccc", there's at least one other of these
1515: scripts).
1516:
1517: Using "ccc" I got it pretty close, but there's a routine in /lib/shlib named
1518: "openi" and there was a conflict between it and the one y'all had in ckcfns.c
1519: -- the workaround here is to declare YOUR openi() to be static (which works
1520: because it's not used in any other of your files), and don't forget to put a
1521: "static openi();" at the beginning of the file as well. There's even a
1522: section reserved up there for local variables.
1523:
1524: Now I've got a program that compiles and loads without errors. In testing
1525: some functionality:
1526:
1527: I started with the remote kermit in server mode and transferred /bin/cat to
1528: the remote (a 4.3bsd vax running kermit 4C(057)) and then got it back ("get
1529: cat"). The result is a cat that is one byte shorter, but is otherwise exactly
1530: the same. Now, this is a real neat trick too, 'cause it starts and ends with
1531: the EXACT same bytes (I looked using od)! This shouldn't work out like this.
1532: The new copy should be missing a byte at the end, but we've got the same byte
1533: at the end. There isn't a byte missing in the middle 'cause "cmp" doesn't
1534: find it, and if I "diff" the "od -c" output from each file, the ONLY
1535: difference is the byte count at the very end.
1536:
1537: I'm more than a little confused about that one ...
1538:
1539: While the remote is in server, the local kermit acts rather strangely.
1540: Possibly when doing ANY command, but definitely when doing send, get, and "!"
1541: commands, to get back to command level from the command I have to type ^R ...
1542: the only other character I've tried is <CR> which didn't get me back to
1543: command level. Further, I once hit an empty line then started to do a shell
1544: escape and it dumped me OUT of kermit and said something about an invalid
1545: shell command. (an asice: There's times when I hate command processors which
1546: read what I'm typing and complain before I get a chance to fix typing errors
1547: ...)
1548:
1549: FINALLY:
1550:
1551: In order to successfully connect to the modem and make a phone call I have to
1552: enter this non-intuitive sequence of commands:
1553:
1554: ! rm /usr/spool/uucp/LCK..ph0
1555: set line /dev/ph0
1556: set modem att7300
1557: set speed 1200
1558: dial <phone number>
1559: ! phtoggle
1560: dial <phone number>
1561:
1562: If I don't remove the lock file first, the set line command of course will
1563: complain about the lock file being there. But if I go ahead and phtoggle then
1564: set line, the open in set line never returns and I hang. Then, there's some
1565: other state where if I phtoggle the getty process that get started starts
1566: looping -- that is, getty exits immediately causing init to start a new one
1567: which exits immediately, and so on. Anyway -- I haven't tried it without a
1568: dial command before the phtoggle yet.
1569:
1570: I've got a kermit around here which'll let you do:
1571:
1572: ! phtoggle
1573: set line /dev/ph0
1574: set modem att7300
1575: set speed 1200
1576: dial <phone number>
1577:
1578: just like you'd expect ... but it's an old copy that someone here made work
1579: and then never told you guys about the changes. (ARGH!) Anyway, between the
1580: two versions I should be able to get something working.
1581:
1582: Oh, another problem when I exitted kermit ... I said "quit" and it waited a
1583: little while and said "Problem with hanging up modem".
1584:
1585: [Ed. - Unfortunately, we don't have any Unix PCs, or for that matter any
1586: System III or V systems to test C-Kermit on, so we rely on people like
1587: you to tell us what to do, or what we should have done. You're apparently
1588: the first person who tried the new ATT7300 stuff, so thanks for the feedback
1589: on that. But I haven't heard complaints from others about multiply defined
1590: symbols, shared libraries, etc, and a lot of people are running this version
1591: on System V, so I can only assume the problem there must be UnixPC-specific.
1592:
1593: If you can send me a makefile entry that you have actually used with the
1594: UnixPC, I'll be glad to replace the current one with yours, and add a hint
1595: that if people have trouble w/other ATT Sys III/V based systems, they might
1596: look at the ATT7300 entry for a model. If this is new stuff, then we have
1597: a slight problem, because up till now (or at least up to Sys V R3), all
1598: Sys III and Sys V C-Kermits could be compiled the same way.
1599:
1600: Termcap??? There's nothing in Kermit that uses termcap or curses...
1601: The other stuff will have to be looked in to. Thanks for the report. For
1602: now, it's been added to the "beware file", CKUKER.BWR.]
1603:
1604: ------------------------------
1605:
1606: Date: Wed, 2 Mar 88 17:23:47 EST
1607: From: [email protected] (Arthur David Olson)
1608: Subject: MORE/bsd 4.3 (10/5/87) kermit does CR strips, not CR-LF->NL maps--w/fix
1609:
1610: (This may be fixed in versions of C-Kermit later than version 4C(057), which
1611: we're running.)
1612:
1613: Description:
1614: The kermit command strips all carriage returns, rather than
1615: mapping CR-LF sequences to NL. This causes problems when transferring
1616: (to the VAX) the output of programs that do underlining by outputing
1617: a line of characters, doing a return, then outputing underlines in
1618: the desired places.
1619:
1620: Fix:
1621: Note that even with this fix in place, if a file has a CR as its very
1622: last character the CR will be (inappropriately) stripped. Then again,
1623: we're not kermit gurus around here.
1624:
1625: *** 1.1/ckcfns.c Wed Mar 2 17:17:32 1988
1626: --- 1.3/ckcfns.c Wed Mar 2 17:17:43 1988
1627: ***************
1628: *** 131,136 ****
1629: --- 131,140 ----
1630: /* Call with string to be decoded and an output function. */
1631: /* Returns 0 on success, -1 on failure (e.g. disk full). */
1632:
1633: + #ifdef NLCHAR
1634: + static int sawcr;
1635: + #endif /* defined NLCHAR */
1636: +
1637: decode(buf,fn) char *buf; int (*fn)(); {
1638: unsigned int a, a7, b8; /* Low order 7 bits, and the 8th bit */
1639:
1640: ***************
1641: *** 158,172 ****
1642: }
1643: a |= b8; /* OR in the 8th bit */
1644: if (rpt == 0) rpt = 1; /* If no repeats, then one */
1645: - #ifdef NLCHAR
1646: - if (!binary) { /* If in text mode, */
1647: - if (a == CR) continue; /* discard carriage returns, */
1648: - if (a == LF) a = NLCHAR; /* convert LF to system's newline. */
1649: - }
1650: - #endif
1651: for (; rpt > 0; rpt--) { /* Output the char RPT times */
1652: ! ffc++, tfc++; /* Count the character */
1653: if ((*fn)(a) < 0) return(-1); /* Send it to the output function. */
1654: }
1655: }
1656: return(0);
1657: --- 162,189 ----
1658: }
1659: a |= b8; /* OR in the 8th bit */
1660: if (rpt == 0) rpt = 1; /* If no repeats, then one */
1661: for (; rpt > 0; rpt--) { /* Output the char RPT times */
1662: ! ffc++; /* Count the character */
1663: ! #ifdef NLCHAR
1664: ! if (!binary) {
1665: ! if (a == CR) {
1666: ! if (sawcr == 0) {
1667: ! sawcr = 1;
1668: ! continue;
1669: ! }
1670: ! } else {
1671: ! if (sawcr)
1672: ! if (a == LF)
1673: ! a = NLCHAR;
1674: ! else if ((*fn)(CR) < 0)
1675: ! return -1;
1676: ! else ++tfc;
1677: ! sawcr = 0;
1678: ! }
1679: ! }
1680: ! #endif /* defined NLCHAR */
1681: if ((*fn)(a) < 0) return(-1); /* Send it to the output function. */
1682: + ++tfc;
1683: }
1684: }
1685: return(0);
1686: ***************
1687: *** 424,429 ****
1688: --- 441,449 ----
1689: rcvfil() {
1690: int x;
1691: ffc = flci = flco = 0; /* Init per-file counters */
1692: + #ifdef NLCHAR
1693: + sawcr = 0;
1694: + #endif /* defined NLCHAR */
1695: srvptr = srvcmd; /* Decode file name from packet. */
1696: decode(data,putsrv);
1697: if (*srvcmd == '\0') /* Watch out for null F packet. */
1698: --
1699: [email protected] ADO, VAX, and NIH are Ampex and DEC trademarks
1700:
1701: ------------------------------
1702:
1703: Date: Sun, 28 Feb 88 02:47:21 EST
1704: From: [email protected] (Charles Hedrick)
1705: Subject: Results of Porting C-Kermit 4E and Fixes
1706: Keywords: C-Kermit 4E
1707:
1708: I just finished porting Kermit 4E to my Microport System V/AT. As usual,
1709: simply typing "make sys3nid" (which is the setting for vanilla System V,
1710: oddly enough) works correctly. It works correctly in the sense of building
1711: a kermit that works the same as it works on other systems. Unfortunately,
1712: the major new feature in 4E turns out not to work on any of the systems I
1713: have access to. This is the long packet size feature. The two kermits
1714: exchange information about what options they support. Unfortunately, the
1715: code used for generating the byte that contains the capabilities appears to
1716: be wrong. It results in having the systems say that they don't support long
1717: packets. The expression is a long one involving several ? : constructs. My
1718: C documentation does not make clear what the relative precedence of ? and |
1719: should be. However both the Sun 3 and System V 286 compilers take the
1720: opposite view from the authors of C Kermit. By adding a few ()'s, we avoid
1721: the ambiguity. There was also a problem that the packet size sent for the
1722: benefit of old systems that don't support long packets was miscalculated.
1723: THey simply took the low-order byte of the full packet size. What they
1724: wanted was MIN (packetsize, 94), 94 being the maximum size allowed by old
1725: implementations.
1726:
1727: The fixes are shown below.
1728:
1729: This message is being sent to be info-kermit and the Microport newsgroup.
1730: For the benefit of Microport users, let me note that Microport supplies a
1731: fairly recent version of kermit with the system, version 4D. The version
1732: being discussed here adds only the long packet support. (You might still
1733: find it useful to get the files, since Microport doesn't seem to supply
1734: documentation.) Kermit is available via anonymous FTP from
1735: CU20B.COLUMBIA.EDU. The files you need are roughly ker:ckc*.*, ker:cku*,
1736: and ker:ckw*, but ker:ckaaaa.hlp will give me information. Kermit is also
1737: available at Simtel20. The index I have claims it is pd2:<unix.kermit>,
1738: although today I was unable to get to those files to check them.
1739:
1740: *** ckcfns.c.ORIG Sat Feb 27 19:25:03 1988
1741: --- ckcfns.c Sun Feb 28 02:05:44 1988
1742: ***************
1743: *** 607,613
1744:
1745: CHAR *
1746: rpar() {
1747: ! data[1] = tochar(rpsiz); /* Biggest packet I can receive */
1748: data[2] = tochar(rtimo); /* When I want to be timed out */
1749: data[3] = tochar(mypadn); /* How much padding I need (none) */
1750: data[4] = ctl(mypadc); /* Padding character I want */
1751:
1752: --- 607,616 -----
1753:
1754: CHAR *
1755: rpar() {
1756: ! if (rpsiz > 94)
1757: ! data[1] = tochar(94);
1758: ! else
1759: ! data[1] = tochar(rpsiz); /* Biggest packet I can receive */
1760: data[2] = tochar(rtimo); /* When I want to be timed out */
1761: data[3] = tochar(mypadn); /* How much padding I need (none) */
1762: data[4] = ctl(mypadc); /* Padding character I want */
1763: ***************
1764: *** 626,632
1765: else
1766: data[9] = '~';
1767:
1768: ! data[10] = tochar(atcapr?atcapb:0 | lpcapr?lpcapb:0 | swcapr?swcapb:0);
1769: data[capas+1] = tochar(swcapr ? wsize : 0); /* Window size */
1770:
1771: rpsiz = urpsiz; /* Long packets ... */
1772:
1773: --- 629,635 -----
1774: else
1775: data[9] = '~';
1776:
1777: ! data[10] = tochar((atcapr?atcapb:0) | (lpcapr?lpcapb:0) | (swcapr?swcapb:0));
1778: data[capas+1] = tochar(swcapr ? wsize : 0); /* Window size */
1779:
1780: rpsiz = urpsiz; /* Long packets ... */
1781:
1782: ------------------------------
1783:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.