1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 1560 1561 1562 1563 1564 1565 1566 1567 1568 1569 1570 1571 1572 1573 1574 1575 1576 1577 1578 1579 1580 1581 1582 1583 1584 1585 1586 1587 1588 1589 1590 1591 1592 1593 1594 1595 1596 1597 1598 1599 1600 1601 1602 1603 1604 1605 1606 1607 1608 1609 1610 1611 1612 1613 1614 1615 1616 1617 1618 1619 1620 1621 1622 1623 1624 1625 1626 1627 1628 1629 1630 1631 1632 1633 1634 1635 1636 1637 1638 1639 1640 1641 1642 1643 1644 1645 1646 1647 1648 1649 1650 1651 1652 1653 1654 1655 1656 1657 1658 1659 1660 1661 1662 1663 1664 1665 1666 1667 1668 1669 1670 1671 1672 1673 1674 1675 1676 1677 1678 1679 1680 1681 1682 1683 1684 1685 1686 1687 1688 1689 1690 1691 1692 1693 1694 1695 1696 1697 1698 1699 1700 1701 1702 1703 1704 1705 1706 1707 1708 1709 1710 1711 1712 1713 1714 1715 1716 1717 1718 1719 1720 1721 1722 1723 1724 1725 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738 1739 1740 1741 1742 1743 1744 1745 1746 1747 1748 1749 1750 1751 1752 1753 1754 1755 1756 1757 1758 1759 1760 1761 1762 1763 1764 1765 1766 1767 1768 1769 1770 1771 1772 1773 1774 1775 1776 1777 1778 1779 1780 1781 1782 1783 1784 1785 1786 1787 1788 1789 1790 1791 1792 1793 1794 1795 1796 1797 1798 1799 1800 1801 1802 1803 1804 1805 1806 1807 1808 1809 1810 1811 1812 1813 1814 1815 1816 1817 1818 1819 1820 1821 1822 1823 1824 1825 1826 1827 1828 1829 1830 1831 1832 1833 1834 1835 1836 1837 1838 1839 1840 1841 1842 1843 1844 1845 1846 1847 1848 1849 1850 1851 1852 1853 1854 1855 1856 1857 1858 1859 1860 1861 1862 1863 1864 1865 1866 1867 1868 1869 1870 1871 1872 1873 1874 1875 1876 1877 1878 1879 1880 1881 1882 1883 1884 1885 1886 1887 1888 1889 1890 1891 1892 1893 1894 1895 1896 1897 1898 1899 1900 1901 1902 1903 1904 1905 1906 1907 1908 1909 1910 1911 1912 1913 1914 1915 1916 1917 1918 1919 1920 1921 1922 1923 1924 1925 1926 1927 1928 1929 1930 1931 1932 1933 1934 1935 1936 1937 1938 1939 1940 1941 1942 1943 1944 1945 1946 1947 1948 1949 1950 1951 1952 1953 1954 1955 1956 1957 1958 1959 1960 1961 1962 1963 1964 1965 1966 1967 1968 1969 1970 1971 1972 1973 1974 1975 1976 1977 1978 1979 1980 1981 1982 1983 1984 1985 1986 1987 1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030 2031 2032 2033 2034 2035 2036 2037 2038 2039 2040 2041 2042 2043 2044 2045 2046 2047 2048 2049 2050 2051 2052 2053 2054 2055 2056 2057 2058 2059 2060 2061 2062 2063 2064 2065 2066 2067 2068 2069 2070 2071 2072 2073 2074 2075 2076 2077 2078 2079 2080 2081 2082 2083 2084 2085 2086 2087 2088 2089 2090 2091 2092 2093 2094 2095 2096 2097 2098 2099 2100 2101 2102 2103 2104 2105 2106 2107 2108 2109 2110 2111 2112 2113 2114 2115 2116 2117 2118 2119 2120 2121 2122 2123 2124 2125 2126 2127 2128 2129 2130 2131 2132 2133 2134 2135 2136 2137 2138 2139 2140 2141 2142 2143 2144 2145 2146 2147 2148 2149 2150 2151 2152 2153 2154 2155 2156 2157 2158 2159 2160 2161 2162 2163 2164 2165 2166 2167 2168 2169 2170 2171 2172 2173 2174 2175 2176 2177 2178 2179 2180 2181 2182 2183 2184 2185 2186 2187 2188 2189 2190 2191 2192 2193 2194 2195 2196 2197 2198 2199 2200 2201 2202 2203 2204 2205 2206 2207 2208 2209 2210 2211 2212 2213 2214 2215 2216 2217 2218 2219 2220 2221 2222 2223 2224 2225 2226 2227 2228 2229 2230 2231 2232 2233 2234 2235 2236 2237 2238 2239 2240 2241 2242 2243 2244 2245 2246 2247 2248 2249 2250 2251 2252 2253 2254 2255 2256 2257 2258 2259 2260 2261 2262 2263 2264 2265 2266 2267 2268 2269 2270 2271 2272 2273 2274 2275 2276 2277 2278 2279 2280 2281 2282 2283 2284 2285 2286 2287 2288 2289 2290 2291 2292 2293 2294 2295 2296 2297 2298 2299 2300 2301 2302 2303 2304 2305 2306 2307 2308 2309 2310 2311 2312 2313 2314 2315 2316 2317 2318 2319 2320 2321 2322 2323 2324 2325 2326 2327 2328 2329 2330 2331 2332 2333 2334 2335 2336 2337 2338 2339 2340 2341 2342 2343 2344 2345 2346 2347 2348 2349 2350 2351 2352 2353 2354 2355 2356 2357 2358 2359 2360 2361 2362 2363 2364 2365 2366 2367 2368 2369 2370 2371 2372 2373 2374 2375 2376 2377 2378 2379 2380 2381 2382 2383 2384 2385 2386 2387 2388 2389 2390 2391 2392 2393 2394 2395 2396 2397 2398 2399 2400 2401 2402 2403 2404 2405 2406 2407 2408 2409 2410 2411 2412 2413 2414 2415 2416 2417 2418 2419 2420 2421 2422 2423 2424 2425 2426 2427 2428 2429 2430 2431 2432 2433 2434 2435 2436 2437 2438 2439 2440 2441 2442 2443 2444 2445 2446 2447 2448 2449 2450 2451 2452 2453 2454 2455 2456 2457 2458 2459 2460 2461 2462 2463 2464 2465 2466 2467 2468 2469 2470 2471 2472 2473 2474 2475 2476 2477 2478 2479 2480 2481 2482 2483 2484 2485 2486 2487 2488 2489 2490 2491 2492 2493 2494 2495 2496 2497 2498 2499 2500 2501 2502 2503 2504 2505 2506 2507 2508 2509 2510 2511 2512 2513 2514 2515 2516 2517 2518 2519 2520 2521 2522 2523 2524 2525 2526 2527 2528 2529 2530 2531 2532 2533 2534 2535 2536 2537 2538 2539 2540 2541 2542 2543 2544 2545 2546 2547 2548 2549 2550 2551 2552 2553 2554 2555 2556 2557 2558 2559 2560 2561 2562 2563 2564 2565 2566 2567 2568 2569 2570 2571 2572 2573 2574 2575 2576 2577 2578 2579 2580 2581 2582 2583 2584 2585 2586 2587 2588 2589 2590 2591 2592 2593 2594 2595 2596 2597 2598 2599 2600 2601 2602 2603 2604 2605 2606 2607 2608 2609 2610 2611 2612 2613 2614 2615 2616 2617 2618 2619 2620 2621 2622 2623 2624 2625 2626 2627 2628 2629 2630 2631 2632 2633 2634 2635 2636 2637 2638 2639 2640 2641 2642 2643 2644 2645 2646 2647 2648 2649 2650 2651 2652 2653 2654
|
CKUKER.BWR "Beware File" for C-Kermit Version 6.1 -*- text -*-
C-KERMIT FOR UNIX
As of C-Kermit version: 6.1.193 Beta.05
This file last updated: Thu May 7 11:15:44 1998Tue May 5 14:39:33 1998
Authors: Frank da Cruz and Christine M. Gianone, Columbia University.
Copyright (C) 1985, 1998, Trustees of Columbia University in the City of New
York. The C-Kermit software may not be, in whole or in part, licensed or
sold for profit as a software product itself, nor may it be included in or
distributed with commercial products or otherwise distributed by commercial
concerns to their clients or customers without written permission of the
Office of Kermit Development and Distribution, Columbia University. This
copyright notice must not be removed, altered, or obscured.
WHAT IS IN THIS FILE
This is the "beware file" for the UNIX version of C-Kermit. It contains hints
and tips, frequently asked questions (and answers), troubleshooting advice,
limitations and restrictions, known bugs, unresolved reports, etc, that apply
to all UNIX variations, as well as to specific ones like HP-UX, AIX, SunOS,
Solaris, Unixware, NeXTSTEP, etc etc.
This file should be read in conjunction with the system-independent C-Kermit
beware file, ckermit.bwr, which contains similar information, but applying to
all versions of C-Kermit (VMS, OS/2, AOS/VS, VOS, etc, as well as to UNIX).
CONTENTS
(0) DOCUMENTATION AND TECHNICAL SUPPORT
(0.1) THE C-KERMIT USER MANUAL
(0.2) TECHNICAL SUPPORT
(0.3) YEAR 2000
(1) IMPORTANT FILES
(2) BINARIES
(3) NOTES ON SPECIFIC UNIX VERSIONS
(3.0) C-KERMIT ON PC-BASED UNIXES
(3.1) C-KERMIT AND AIX
(3.2) C-KERMIT AND HP-UX
(3.3) C-KERMIT AND LINUX
3.3.1. Problems Building C-Kermit for Linux
3.3.2. Problems with Serial Devices in Linux
3.3.3. Terminal Emulation in Linux
3.3.4. Dates and Times
(3.4) C-KERMIT AND NEXTSTEP
(3.5) C-KERMIT AND QNX
(3.6) C-KERMIT AND SCO UNIX, XENIX, ODT, AND OPENSERVER
(3.7) C-KERMIT AND SOLARIS
(3.8) C-KERMIT AND SUNOS
(3.9) C-KERMIT AND ULTRIX
(3.10) C-KERMIT AND UNIXWARE
(3.11) C-KERMIT AND APOLLO SR10
(3.12) C-KERMIT AND TANDY XENIX 3.0
(3.13) C-KERMIT AND OSF/1 (DIGITAL UNIX)
(3.14) C-KERMIT AND SGI IRIX
(3.15) C-KERMIT AND THE BEBOX
(3.16) C-KERMIT AND DG/UX
(3.17) C-KERMIT AND SEQUENT DYNIX
(4) GENERAL UNIX-SPECIFIC LIMITATIONS AND BUGS
(5) INITIALIZATION AND COMMAND FILES
(6) COMMUNICATION SPEED SELECTION
(7) COMMUNICATIONS AND DIALING
(8) HARDWARE FLOW CONTROL
(9) TERMINAL CONNECTION AND KEY MAPPING
(10) FILE TRANSFER
(11) EXTERNAL FILE TRANSFER PROTOCOLS
(11.1) C-KERMIT AS AN EXTERNAL PROTOCOL
(11.2) INVOKING EXTERNAL PROTOCOLS FROM C-KERMIT
(11.3) USING C-KERMIT WITH TERM
(12) SECURITY
(13) MISCELLANEOUS USER REPORTS
(14) THIRD-PARTY DRIVERS
(0) DOCUMENTATION AND TECHNICAL SUPPORT
(0.1) THE C-KERMIT USER MANUAL
C-Kermit is documented in the book "Using C-Kermit" by Frank da Cruz and
Christine M. Gianone, Digital Press, Burlington, MA, USA, ISBN 1-55558-164-1.
Price: US $41.95. To order, call Columbia University, New York City, at +1
212 854-3703, or Digital Press / Butterworth-Heinemann at:
+1 800 366-2665 (Massachusetts office for USA & Canada)
+441 1993 414414 (Rushden, England office for Europe)
+61 2 372-5511 (Chatswood, NSW, office for Australia & New Zealand)
+65 220-3684 (Singapore office for Asia)
Or visit the Kermit website at http://www.columbia.edu/kermit/.
A German edition is available from Verlag Heinz Heise in Hannover, Germany,
Tel. +49 (05 11) 53 52-0, Fax. +49 (05 11) 53 52-1 29.
If you do not have the manual, please purchase it. It explains how to use
C-Kermit, from getting started through advanced use and scripting, and sales
of the manual are the primary source of funding for C-Kermit development and
support.
New features added since "Using C-Kermit", 2nd Ed, was published are
documented in the ckermit2.upd file.
(0.2) TECHNICAL SUPPORT
Please consult the manual, plus the ckermit.bwr file and this file itself,
before submitting questions, reporting problems, etc, to:
E-Mail: kermit-support@columbia.edu
News: comp.protocols.kermit.misc
Post: The Kermit Project
Columbia University
612 West 115th Street
New York NY 10025-7799
USA
Fax: +1 212 663-8202
or: +1 212 662-6442
Telephone support is also available:
USA Only: +1 900 555-5595, cost: $2.50 per minute
Anywhere: +1 212 854-5126, cost: $25.00 per call, payable via Visa or MC.
(0.3) YEAR 2000
The UNIX version of C-Kermit, release 6.0 and later, is "Year 2000 compliant",
but only if the underlying operating system is too. Contact your UNIX
operating system vendor to find out which operating system versions, patches,
hardware, and/or updates are required.
As of C-Kermit 6.0, post-millenium file dates are recognized, transmitted,
received, and reproduced correctly during the file transfer process in
C-Kermit's File Attribute packets. If post-millenium dates are not processed
correctly on the other end, file transfer will still take place, but the
modification or creation date of the received file might be incorrect. The
only exception would be if the "file collision update" feature is being used
to prevent unnecessary transfer of files that have not changed since the last
time a transfer took place; in this case, a file might be transferred
unnecessarily, or it might not be transferred when it should have been.
Correct operation of the update feature depends on both Kermit programs having
the correct date and time.
Of secondary importance are the time stamps in the transaction and/or debug
logs, and the date-related script programming constructs, such as \v(date),
\v(ndate), \v(day), \v(nday), and perhaps also the time-related ones, \v(time)
and \v(ntime), insofar as they might be affected by the date. The \v(ndate)
is a numeric-format date of the form yyyymmdd, suitable for comparison and
sorting: e.g. 19970208 or 20011231. If the underlying operating system
returns the correct date information, these variables will have the proper
values. If not, then scripts that make decisions based on these variables
might not operate correctly.
(1) IMPORTANT FILES
In addition to the published documentation, the following files are useful
in troubleshooting:
ckaaaa.hlp: Overview, file naming conventions, list of files, etc.
ckuins.doc: Installation instructions for UNIX C-Kermit.
ckccfg.doc: C-Kermit program configuration information.
ckermit.bwr: C-Kermit "beware file" for all platforms.
ckuker.bwr: C-Kermit "beware file" for UNIX (this file).
ckcplm.doc: C-Kermit program logic manual.
ckermit2.upd: User documentation for features added since 6.0.192.
ckcXXX.upd: Program edit history for edit XXX, e.g. ckc190.upd.
ckuker.mak: (or makefile) Makefile for UNIX C-Kermit.
ck[cuw]*.[chw]: Source code for UNIX C-Kermit.
(2) BINARIES
It is often dangerous to run a binary C-Kermit (or any other) program built
on a different computer. Particularly if that computer had a different C
compiler, libraries, operating system version, processor features, etc, and
especially if the program was built with shared libraries, because as soon as
you update the libraries on your system, they no longer match the ones
referenced in the binary, and the binary refuses to load when you run it,
in which case you'll see error messages similar to:
Could not load program kermit
Member shr4.o not found or file not an archive
Could not load library libcurses.a[shr4.o]
Error was: No such file or directory
(These samples are from AIX.) To avoid this problem, we try to build C-Kermit
with statically linked libraries whenever we can, but many of the binaries are
contributed from elsewhere (after all, we don't have several hundred different
machines in-house to build them on), and in any case some platforms do not
even offer the option of static linking.
It is often OK to run a binary built on an earlier OS version, but it is
rarely possible (or safe) to run a binary built on a later one, for example
to run a binary built under SunOS 4.1.2 on a SunOS 4.1.1 system. Sometimes
even the system-or-library patch/ECO level makes a difference.
When in doubt, build C-Kermit from the source code on the system where it is
to be run (if possible!). If not, ask us for a binary specific to your
configuration. We might have one, and if we don't, we might be able to find
somebody who will build one for you.
(3) NOTES ON SPECIFIC UNIX VERSIONS
The following sections apply to specific UNIX versions.
One thread that runs through many of them, and implicitly perhaps through all,
concerns the problems that occur when trying to dial out on a serial device
that is (also) enabled for dialing in. The "solutions" to this problem are
many, varied, diverse, and usually gross, involving configuring the device for
bidirectional use. This is done in a highly system-dependent and often
obscure manner, and the effects (good or evil) are also highly system-
dependent. Many examples are given in the system-specific sections below.
An important point to keep in mind is that C-Kermit is a CROSS-PLATFORM,
PORTABLE program. It was not designed specifically and only for your
particular UNIX version, or for that matter, for UNIX in particular, at all
(it also runs on VMS, AOS/VS, VOS, and many other non-UNIX platforms). All
the UNIX versions of C-Kermit share common i/o modules, with compile-time
#ifdef constructions used to account for the differences among the many UNIX
products and releases. If you think that C-Kermit is behaving badly, or
missing something, on your particular UNIX version, you might be right -- we
can't claim to be expert in 700+ different platforms. If you're a programmer,
take a look at the source code and send us your suggested fixes or changes.
Or else just send us a report about what seems to be wrong (see the TECHNICAL
SUPPORT section above for details).
(3.0) C-KERMIT ON PC-BASED UNIXES
PCs are not the best platform for a real operating systems like UNIX. The
architecture suffers from numerous deficiencies, not the least of which is the
stiflingly small number of hardware interrupts (either 7 or 15, most of which
are already taken). Thus adding devices, using multiple serial ports, etc, is
always a challenge and usually a nightmare. The free-for-all nature of the PC
market and the lack of standards combined with the diversity of UNIX OS
versions makes it difficult to find drivers for any particular device on any
particular version of UNIX.
This phenomenon is exacerbated by the fact that the PC platform is becoming
inexorably Windows-oriented. Increasing numbers of add-on devices are
"Windows only" -- meaning that they are incomplete and rely on Windows-based
drivers to do the jobs that you would expect the device itself to do. PCMCIA
or "Plug-n-Play" devices are rarely supported on PC-based UNIX versions such
as SCO; Winmodems, Winprinters, and the like are not supported at all on any
UNIX to our knowledge. The self-proclaimed Microsoft PC 97 standard will
probably only make matters worse since its only purpose to ensure that PCs are
"optimized to run Windows 95 and Windows NT 4.0 and future versions of these
operating systems".
Increasingly, vendors of PC devices are "optimizing" them for Windows to the
extent they need special software assistance (drivers), and are furnishing
these drivers only for Windows, since the Windows market dwarfs that of any
particular UNIX brand, and for that matter all UNIXes combined. If your
version of UNIX (SCO, Linux, BSDI, FreeBSD, etc) does not support a particular
device, then C-Kermit can't use it either. C-Kermit, like any UNIX
application, must access all devices through drivers and not directly.
So before you buy a new PC or add-on equipment, especially serial ports,
internal modems, or printers, make sure they are compatible with your version
of UNIX.
(3.1) C-KERMIT AND AIX
For additional information see the AIX FAQ:
http://www.emerson.emory.edu/services/aix-faq/
ftp://rtfm.mit.edu/pub/usenet/news.answers/aix-faq/part1
ftp://mirrors.aol.com/pub/rtfm/usenet-by-hierarchy/comp/unix/aix
and/or read the comp.unix.aix newsgroup.
IMPORTANT: Do NOT try to run AIX 3.x C-Kermit binaries on AIX 4.x (or vice
versa). Obtain -- or build -- the C-Kermit binary that is appropriate for
your AIX version. In general, it is always better to build from source code.
Several people have reported that C-Kermit (version unspecified) causes
AIX 4.2 (or later) to "freeze" or "hang" or "halt". No further details are
known at this time. However:
1. No user-mode application should ever be able to make AIX or any other
version of UNIX freeze, hang, or halt; if it does, this indicates a
serious bug in AIX, which should be reported immediately to IBM.
2. There various bugs in the original AIX 4.2 tty (serial i/o) support;
fixes for these and other AIX bugs are available from IBM at:
http://service.software.ibm.com/rs6000/
Downloads -> Software Fixes -> Download FixDist gets an application
for looking up known problems.
Other people have reported that after upgrading AIX from 4.1 to 4.2, the "ttys
hang" when they try to use Kermit. Again, so far no further details are
available. However, others report that C-Kermit 6.0 works fine on both AIX
4.2 and 4.3 if it is rebuilt from source code. Still others report that the
original C-Kermit 6.0 binaries, built under AIX 4.1, work perfectly in AIX
4.2 and 4.3.
C-Kermit 6.0.192 and earlier was built by default without "BIGBUFOK" defined
for AIX, and this limits the maximum size of macros, etc. It should be
defined, and it is in C-Kermit 6.1. In the meantime use:
make clean ; make aix??? KFLAGS=-DBIGBUFOK
Reportedly, telnet from AIX 4.1-point-something to non-Telnet ports does not
work unless the port number is in the /etc/services file; it's not clear from
the report whether this is a problem with AIX Telnet (in which case it would
not affect Kermit), or with the sockets library (in which case it would). The
purported fix is IBM APAR IX61523.
Many problems reported with bidirectional terminal lines on AIX 3.2.x on the
RS/6000. Workaround: don't use bidirectional terminal lines, or write some
kind of shell script that turns getty off on the line before starting Kermit,
or before Kermit attempts to do the SET LINE. (But note: These problems
MIGHT be fixed in C-Kermit 6.0 and later.)
Reportedly, all versions of IBM AIX use the same (undocumented) lockfile
conventions as RTAIX. If this is true, the "makes" for PS/2 AIX and AIX/370
will have to be changed to use the RTAIX convention (it may be sufficient to
simply add -DRTAIX to the make entry). Probably not an issue any more...
C-Kermit SET HOST or TELNET from AIX on an RS/6000 to another RS/6000 won't
work right unless you set your local terminal type to something other than
AIXTERM. When your terminal type is AIXTERM, AIX TELNET sends two escapes
whenever you type one, and the AIX telnet server swallows one of them.
This has something to do with the "hft" device. This behavior is reportedly
removed in AIX 3.2 and later.
Transfer of binary -- and maybe even text -- files can fail on AIX 3.x. The
problem was traced to a facility in AIX whereby a particular port can have
character-set translation done for it by the tty driver. The following
advice from a knowledgeable AIX user:
(begin quote...) [This feature] has to be checked (and set/cleared) with
a separate command, unfortunately stty doesn't handle this. To check:
$ setmaps
input map: none installed
output map: none installed
If it says anything other than "none installed" for either one, it is likely
to cause a problem with kermit. To get rid of installed maps:
$ setmaps -t NOMAP
However, I seem to recall that with some versions of AIX before 3.2.5, only
root could change the setting. I'm not sure what versions - it might have
only been under AIX 3.1 that this was true. At least with AIX 3.2.5 an
ordinary user can set or clear the maps. (...end quote) And this would
imply that Kermit itself cannot be coded to take care of this, because it
would have to run as root. On the same problem, another knowledgeable AIX
user says:
The way to get information on the NLS mapping under AIX (3.2.5 anyway) is
as follows. From the command line type:
lsattr -l tty# -a imap -a omap -E -H
Replace the tty number for the number sign above. This will give a human
readable output of the settings that looks like this;
# lsattr -l tty2 -a imap -a omap -E -H
attribute value description user_settable
imap none INPUT map file True
omap none OUTPUT map file True
If you change the -H to a -O, you get output that can easily be processed
by another program or a shell script, for example:
# lsattr -l tty2 -a imap -a omap -E -O
#imap:omap
none:none
To change the settings from the command line, the chdev command is used
with the following syntax.
chdev -l tty# -a imap='none' -a omap='none'
Again substituting the appropriate tty port number for the number sign,
"none" being the value we want for C-Kermit. Of course, the above can also
be changed by using the SMIT utility and selecting devices - tty.
(...end quote)
About AIX versions and hardware platforms (from the AIX FAQ):
If you are using IBM's xlc (cc) compiler, the default is to use the common
instruction set, so the same binary will run on both RS/6000 and PowerPC.
The option -mcpu=common makes GCC use the common instruction set. Please
note that (unlike xlc) this is *not* the default with GCC on AIX.
A couple of other gotcha's:
Use shared libraries. The C runtime can and does change as IBM introduces
patches. Also this avoids "Netscape syndrome." They bound AIX 3 libraries
into their browser. Although AIX 3 binaries will run on AIX 4, the AIX 3
libraries aren't totally compatible.
AIX 4.2 changed the C runtime radically. AIX 4.2 binaries won't run on AIX
4.1 or 3.anything. AIX 3 binaries run on AIX 4.1 and AIX 4.2.
Of course, the moment you take any of this as gospel, you'll get into big
trouble, but my own experience has pretty much jibed with the above.
(end quote)
"Is AIX Year 2000 Compliant?" According to a comp.unix.aix newsgroup posting
from IBM Austin, version 4.2 is; earlier versions such as 4.1.x and 3.2.5
require PTFs (which, as of Jan 1997, have not yet been issued).
Here is a sample configuration for setting up an xterm keyboard for VT220 or
higher terminal emulation on AIX, courtesy of Bruce Momjian, Drexel Hill, PA.
Xterm can be started like this:
xterm $XTERMFLAGS +rw +sb +ls $@ -tm 'erase ^? intr ^c' -name vt220 \
-title vt220 -tn xterm-220 "$@" &
---------------------------------------------------------------------------
XTerm*VT100.Translations: #override \n\
<Key>Home: string(0x1b) string("[3~") \n \
<Key>End: string(0x1b) string("[4~") \n
vt220*VT100.Translations: #override \n\
Shift <Key>F1: string("[23~") \n \
Shift <Key>F2: string("[24~") \n \
Shift <Key>F3: string("[25~") \n \
Shift <Key>F4: string("[26~") \n \
Shift <Key>F5: string("[K~") \n \
Shift <Key>F6: string("[31~") \n \
Shift <Key>F7: string("[31~") \n \
Shift <Key>F8: string("[32~") \n \
Shift <Key>F9: string("[33~") \n \
Shift <Key>F10: string("[34~") \n \
Shift <Key>F11: string("[28~") \n \
Shift <Key>F12: string("[29~") \n \
<Key>Print: string(0x1b) string("[32~") \n\
<Key>Cancel: string(0x1b) string("[33~") \n\
<Key>Pause: string(0x1b) string("[34~") \n\
<Key>Insert: string(0x1b) string("[2~") \n\
<Key>Delete: string(0x1b) string("[3~") \n\
<Key>Home: string(0x1b) string("[1~") \n\
<Key>End: string(0x1b) string("[4~") \n\
<Key>Prior: string(0x1b) string("[5~") \n\
<Key>Next: string(0x1b) string("[6~") \n\
<Key>BackSpace: string(0x7f) \n\
<Key>Num_Lock: string(0x1b) string("OP") \n\
<Key>KP_Divide: string(0x1b) string("Ol") \n\
<Key>KP_Multiply: string(0x1b) string("Om") \n\
<Key>KP_Subtract: string(0x1b) string("OS") \n\
<Key>KP_Add: string(0x1b) string("OM") \n\
<Key>KP_Enter: string(0x1b) string("OM") \n\
<Key>KP_Decimal: string(0x1b) string("On") \n\
<Key>KP_0: string(0x1b) string("Op") \n\
<Key>KP_1: string(0x1b) string("Oq") \n\
<Key>KP_2: string(0x1b) string("Or") \n\
<Key>KP_3: string(0x1b) string("Os") \n\
<Key>KP_4: string(0x1b) string("Ot") \n\
<Key>KP_5: string(0x1b) string("Ou") \n\
<Key>KP_6: string(0x1b) string("Ov") \n\
<Key>KP_7: string(0x1b) string("Ow") \n\
<Key>KP_8: string(0x1b) string("Ox") \n\
<Key>KP_9: string(0x1b) string("Oy") \n
! <Key>Up: string(0x1b) string("[A") \n\
! <Key>Down: string(0x1b) string("[B") \n\
! <Key>Right: string(0x1b) string("[C") \n\
! <Key>Left: string(0x1b) string("[D") \n\
*visualBell: true
*saveLines: 1000
*cursesemul: true
*scrollKey: true
*scrollBar: true
(3.2) C-KERMIT AND HP-UX
For further information, read the comp.sys.hp.hpux newsgroup.
During the C-Kermit 6.0 Beta cycle, something happened to ckcpro.w (or, more
precisely, the ckcpro.c file that is generated from it) which causes HP
optimizing compilers under HP-UX versions 7.0 and 8.0 (apparently on all
platforms) as well as under HP-UX 9.0 on Motorola platforms only, to blow up.
In version 6.1, the problem has spread to other modules.
The symptoms vary from the system grinding to a halt, to the compiler
crashing, to the compilation of the ckcpro.c module taking very long periods
of time, like 9 hours. This problem is handled by compiling the modules
that tickle it without optimization; the C-Kermit 6.1 makefile takes care of
this, and shows how to do it in case the same thing begins happening with
other modules.
On HP-UX 9.0, a kernel parameter, maxdsiz (maximum process data segment size),
seems to be important. On Motorola systems, it is 16MB by default, whereas on
RISC systems the default is much bigger. Increasing maxdsiz to about 80MB
seems to make the problem go away, but only if the system also has a lot of
physical memory -- otherwise it swaps itself to death.
The optimizing compiler might complain about "some optimizations skipped" on
certain modules, due to lack of space available to the optimizer. You can
increase the space (the incantation depends on the particular compiler version
-- see the makefile), but doing so tends to make the compilations take a much
longer time. For example, the "hpux100o+" makefile entry adds the "+Onolimit"
compiler flag, and about an hour to the compile time on an HP-9000/730. But
it *does* produce an executable that is about 10K smaller :-)
(3.2.0) Performance
An unexpected slowness has been noted when transferring files over local
Ethernet connections when an HP-UX system (9.0 or later, perhaps also earlier
versions) is on the remote end. The following experiment was conducted to
determine the cause. C-Kermit 6.0 was used (C-Kermit 6.1 is much faster).
The systems were HP-UX 10.00 (on 715/33) and SunOS 4.1.3 (on Sparc-20), both
on the same local 10Mbps Ethernet. Window size 20, packet length 4096, parity
none, control prefixing "cautious", using only local disks on each machine --
no NFS. The file was a 1.08MB binary file (wermit), transferred in binary
mode. Conditions were relatively poor: the Sun and the local net heavily
loaded; the HP system is slow and memory-constrained.
Client Server Send Receive
Sun HP 36 18 <-- K cps
HP HP 25 15
HP Sun 77 83
Sun Sun 60 60
So whenever HP is the server we have bad performance. Why?
. Changing file display to CRT has no effect (so it's not the curses
library on the client side).
. Changing TCP RECV-BUFFER or SEND-BUFFER has very little effect.
. Telling the client to make a binary-mode connection (SET TELNET BINARY
REQUESTED, which successfully negotiates a binary connection) has no effect.
BUT... If I start C-Kermit as a TCP server:
set host * 3000
server
and then from the client "set host blah 3000", I get:
Client Server Send Receive
HP HP 50 50
Sun HP 77 67
HP Sun 57 85
Sun Sun 57 50
Therefore the HP-UX telnet server or pty driver seems to be adding more
overhead than the SunOS one, and most others. When going through this type of
connection (a remote telnet server) there is little Kermit can do improve
matters, since the telnet server and pty driver are between the two Kermits,
and neither Kermit can have any influence over them (except putting the Telnet
connection in binary mode, but that doesn't help).
(3.2.1) Dialing Out and UUCP Lockfiles in HP-UX
Before you can use serial ports on the HP-9000, you must configure them as
either "terminals" or "modems" with SAM ("peripheral devices"..."terminals and
modems"), as described in the HP manual, "Configuring HP-UX for Peripherals:
HP 9000". If you attempt to use a serial device before it has been configured
this way, it will not work properly; typical symptoms are (a) no communication
at all; (b) nonfunctional modem signals; and/or (c) massive amounts of
character loss in both directions.
In HP-UX 9.0, serial device names began to change. The older names looked
like "/dev/cua00", "/dev/tty01", etc (sometimes with only one digit).
The newer names have two digits with the letter "p" in between. HP-UX 8.xx
and earlier have the older form, HP-UX 10.00 and later have the newer form.
HP-UX 9.xx has the newer form on Series 800 machines, and the older form on
other hardware models. The situation is summarized in the following table:
Converged HP-UX Serial I/O Filenames : TTY Mux Naming
---------------------------------------------------------------------
General meaning Old Form S800 9.0 Convio 10.0
---------------------------------------------------------------------
tty* hardwired ports tty<YY> tty<X>p<Y> tty<D>p<p>
diag:mux<X> diag:mux<D>
---------------------------------------------------------------------
ttyd* dial-in modems ttyd<YY> ttyd<X>p<Y> ttyd<D>p<p>
diag:ttyd<X>p<Y> diag:ttyd<D>p<p>
---------------------------------------------------------------------
cua* auto-dial out cua<YY> cua<X>p<Y> cua<D>p<p>
diag:cua<X>p<Y>
---------------------------------------------------------------------
cul* dial-out cul<YY> cul<X>p<Y> cul<D>p<p>
diag:cul<X>p<Y>
---------------------------------------------------------------------
<X>= LU (Logical Unit) <D>= Devspec (decimal card instance)
<Y> or <YY> = Port <p>= Port
For dialing out, you should use the cua or cul devices. When C-Kermit's
CARRIER setting is AUTO or ON, C-Kermit should pop back to its prompt
automatically if the carrier signal drops, e.g. when you log out from the
remote computer or service. If you use the tty<D>p<d> (e.g. tty0p0) device,
the carrier signal should be ignored. The tty<D>p<d> device should be used
for direct connections where the carrier signal does not follow RS-232
conventions (use the cul device for hardwired connections through a true null
modem). Do not use the ttyd<D>p<d> device for dialing out.
Kermit's access to serial devices is controlled by "UUCP lockfiles", which are
intended to prevent different users using different software programs (Kermit,
cu, etc, and UUCP itself) from accessing the same serial device at the same
time. When a device is in use by a particular user, a file with a special
name is created in:
/var/spool/locks (HP-UX 10.00 and later)
/usr/spool/uucp (HP-UX 9.xx and earlier)
The file's name indicates the device that is in use, and its contents
indicates the process ID (pid) of the process that is using the device. Since
serial devices and the locks directory are not both publicly readable and
writable, Kermit and other communication software must be installed setuid to
the owner (bin) of the serial device and setgid to the group (daemon) of the
/var/spool/locks directory. Kermit's setuid and setgid privileges are enabled
only when opening the device and accessing the lockfiles.
Let's say "unit" means a string of decimal digits (the interface instance
number) followed (in HP-UX 10.00 and later) by the letter "p" (lowercase),
followed by another string of decimal digits (the port number on the
interface), e.g.:
"0p0", "0p1", "1p0", etc (HP-UX 10.00 and later)
"0p0", "0p1", "1p0", etc (HP-UX 9.xx on Series 800)
"00", "01", "10", "0", etc (HP-UX 9.xx not on Series 800)
"00", "01", "10", "0", etc (HP-UX 8.xx and earlier)
Then a normal serial device (driver) name consists of a prefix ("tty", "ttyd",
"cua", "cul", or possibly "cuad" or "culd") followed by a unit, e.g. "cua0p0".
Kermit's treatment of UUCP lockfiles is as close as possible to that of the
HP-UX "cu" program. Here is a table of the lockfiles that Kermit creates for
unit 0p0:
Selection Lockfile 1 Lockfile 2
------------ ------------ ------------
/dev/tty0p0 LCK..tty0p0 (none)
* /dev/ttyd0p0 LCK..ttyd0p0 (none)
/dev/cua0p0 LCK..cua0p0 LCK..ttyd0p0
/dev/cul0p0 LCK..cul0p0 LCK..ttyd0p0
/dev/cuad0p0 LCK..cuad0p0 LCK..ttyd0p0
/dev/culd0p0 LCK..culd0p0 LCK..ttyd0p0
<other> LCK..<other> (none)
(* = Dialin device, should not be used.)
In other words, if the device name begins with "cu", a second lockfile for
the "ttyd" device, same unit, is created, which should prevent dialin access
on that device.
The <other> case allows for symbolic links, etc, but of course it is not
foolproof since we have no way of telling which device is really being used.
When C-Kermit tries to open a dialout device whose name ends with a "unit", it
searches the lockfile directory for all possible names for the same unit. For
example, if user selects /dev/cul2p3, Kermit looks for lockfiles named:
LCK..tty2p3
LCK..ttyd2p3
LCK..cua2p3
LCK..cul2p3
LCK..cuad2p3
LCK..culd2p3
If any of these files are found, Kermit opens them to find out the ID (pid) of
the process that created them; if the pid is still valid, the process is still
active, and so the SET LINE command fails and the user is informed of the pid
so s/he can use "ps" to find out who is using the device.
If the pid is not valid, the file is deleted. If all such files (i.e. with
same "unit" designation) are successfully removed, then the SET LINE command
succeeds; up to six messages are printed telling the user which "stale
lockfiles" are being removed.
When the "set line" command succeeds in HP-UX 10.00 and later, C-Kermit also
creates a UNIX System V R4 "advisory lock" as a further precaution (but not
guarantee) against any other process obtaining access to the device while
you are using it.
If the selected device was in use by "cu", Kermit can't open it, because "cu"
has changed its ownership, so we never get as far as looking at the lockfiles.
In the normal case, we can't even look at the device to see who the owner is
because it is visible only to its (present) owner. In this case, Kermit says
(for example):
/dev/cua0p0: Permission denied
When Kermit releases a device it has successfully opened, it removes all the
lockfiles that it created. This also happens whenever Kermit exits "under its
own power".
If Kermit is killed with a device open, the lockfile(s) are left behind. The
next Kermit program that tries to assign the device, under any of its various
names, will automatically clean up the stale lockfiles because the pids
they contain are invalid. The behavior of cu and communication programs under
these conditions should be the same.
(3.2.2) HP-UX 5.21
Reportedly, "[there is] a bug in C-Kermit using HP-UX version 5.21 on the
HP-9000 series 500 computers. It only occurs when the controlling terminal
is using an HP-27140 six-port modem mux. The problem is not present if the
controlling terminal is logged into an HP-27130 eight-port mux. The symptom
is that just after dialing successfully and connecting Kermit locks up and
the port is unusable until both forks of Kermit and the login shell are
killed."
(3.2.3) HP-UX 8.05
To make C-Kermit work on HP-UX 8.05 on a model 720, obtain and install HP-UX
patch PHNE_0899. This patch deals with a lot of driver issues, particularly
related to communication at higher speeds.
(3.2.4) HP-UX 9.00 AND LATER
HP-UX 9.00 and 9.01 need patch PHNE_10572 (note: this replaces PHNE_3641)
for hptt0.o, asio0.o, and ttycomn.o in libhp-ux.a. Contact Hewlett Packard
if you need this patch. Without it, the dialout device (tty) will be hung
after first use; subsequent attempts to use will return an error like "device
busy". (There are also equivalent patches for s700 9.03 9.05 9.07
(PHNE_10573) and s800 9.00 9.04 (PHNE_10416).
When C-Kermit is in server mode, it might have trouble executing REMOTE HOST
commands. This problem happens under HP-UX 9.00 (Motorola) and HP-UX 9.01
(RISC) IF the C-Shell is the login shell AND with the C-Shell Revision 70.15.
Best thing is to install HP's Patch PHCO_4919 for Series 300/400 and PHCO_5015
for the Series 700/800. PHCO_5015 is called "s700_800 9.X cumulative csh(1)
patch with memory leak fix" which works for HP-UX 9.00, 9.01, 9.03, 9.04, 9.05
and 9.07. At least you need C-Shell Revision 72.12!
C-Kermit works fine -- including its curses-based file-transfer display -- on
the console terminal, in a remote session (e.g. when logged in to the HP 9000
on a terminal port or when telnetted or rlogin'd), and in an HP-VUE hpterm
window or an xterm window.
(3.2.5) HP-UX 10.10 AND LATER
C-Kermit is included as part of the HP-UX operating system by contract between
Hewlett Packard and Columbia University for all HP-UX releases 10.00 and
later. Each level of HP-UX includes a freshly built C-Kermit binary in
/bin/kermit, which should work correctly. However, if you are building your
own or downloading from Columbia, you should be aware that you can only use a
binary that was built under the same OS level as you are running. As of
C-Kermit version 6.0, HP-UX 10.xx / 11.xx binaries announce, in the startup
herald and the VERSION command, the explicit HP-UX version they were built
for: HP-UX 10.00, 10.01, 10.10, 10.20, 10.30, or 11.00. If there is a version
mismatch, HP-UX (not Kermit) is very likely to do something like "Invalid
version for shared lib /usr/lib/libc.1, IOT trap (core dumped)" during program
load.
Beginning in 10.10, libcurses is linked to libxcurses, the new UNIX95 (X/Open)
version of curses, which has some serious bugs; some routines, when called,
would hang and never return, some would dump core. Evidently libxcurses
contains a select() routine, and whenever C-Kermit calls what it thinks is the
regular (sockets) select(), it gets the curses one, causing a segmentation
fault. There is a patch for this from HP, PHCO_8086, "s700_800 10.10
libcurses patch", "shared lib curses program hangs on 10.10", "10.10 enhanced
X/Open curses core dumps due to using wrong select call", 96/08/02 (you can
tell if the patch is installed with "what /usr/lib/libxcurses.1"; the unpatched
version is 76.20, the patched one is 76.20.1.2). It has been verified that
C-Kermit works OK with the patched library, but results are not definite for
HP-UX 10.20 or higher.
To ensure that C-Kermit works even on non-patched HP-UX 10.10 systems,
separate makefile entries are provided for HP-UX 10.00/10.01, 10.10, 10.20,
etc, in which the entries for 10.10 and above link with libHcurses, which is
"HP curses", the one that was used in 10.00/10.01.
(3.2.6) HP-UX and X.25
Although C-Kermit presently does not include built-in support for HP-UX X.25
(as it does for the Sun and IBM X.25 products), it can still be used to make
X.25 connections as follows: start Kermit and then telnet to localhost. After
logging back in, start padem as you would normally do to connect over X.25.
Padem acts as a pipe between Kermit and X.25. In C-Kermit 6.1, you might also
be able to avoid the "telnet localhost" step by using:
C-Kermit> pipe padem <address>
This will work if padem uses standard i/o (see Section 2.7 of ckermit2.upd).
(3.3) C-KERMIT AND LINUX
For further information, read the comp.os.linux.misc, comp.os.linux.answers,
and other Linux-oriented newsgroups, and:
The Linux Document Project (LDP):
. http://sunsite.unc.edu/LDP/
The Linux FAQ:
. http://sunsite.unc.edu/LDP/FAQ/Linux-FAQ.html
The Linux HOWTOs (especially the Serial HOWTO):
. ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO
. ftp://tsx-11.mit.edu/pub/linux/docs/HOWTO
. http://sunsite.unc.edu/LDP/HOWTO/
. http://sunsite.unc.edu/LDP/hmirrors.html
3.3.1. Problems Building C-Kermit for Linux
Be sure to read the comments in the "linux:" makefile entry. There are all
sorts of confusing issues caused by the many and varied Linux distributions.
Some of the worst involve the curses library and header files: where are they,
what are they called, which ones are they really?
Linux C-Kermit, like all other UNIX C-Kermit versions, was built with curses.h
and the curses library. However, this library was evidently so buggy (users
reported that, after doing a file transfer using the fullscreen display,
"screen scrolling locks up" and the cursor "is stuck on the bottom of the
screen", etc), that a new curses library, called ncurses, was developed to
replace it. C-Kermit, as of version 6.1, uses ncurses rather than curses.
But ncurses is dynamically linked, rather than linked into the executable.
This means a certain relationship must obtain between the version number
referenced in the executable and the version number of the library. But there
are evidently several different numbering systems for libncurses.so --
e.g. 1.9.9e is another "name" for 3.0 -- but the program loader doesn't know
that and so won't run the program. Solution: rebuild C-Kermit yourself from
source code, and if you have additional trouble, come back and read the rest
of this section.
Different UUCP lockfile conventions are used by Linux, depending on your Linux
version and/or distribution. In C-Kermit 6.0, "make linux" uses
/var/lock/LCK..name, decimal ASCII 10-byte PID string with leading spaces
because -DLINUXFSSTND ("Linux File System Standard") is included in the
compilation CFLAGS. If you remove this definition, C-Kermit will use the
earlier arrangement of integer PID, /usr/spool/uucp/LCK..name. The leading
spaces are required by FSSTND 1.2, but FSSTND 1.0 required leading zeros; to
get the leading zeros, also include -DFSSTND10. Use whichever option agrees
with your uucp, cu, tip, etc, programs.
One user reported problems building C-Kermit under Linux 2.0.30/Slackware 96,
errors like:
/usr/include/linux/socket.h:77: warning: `PF_AAL5' redefined
/usr/local/include/socketbits.h:68: warning: this is the location of the
previous definition
ckutio.c:4679: `TIOCGSERIAL' undeclared (first use this function)
ckutio.c:4685: `TIOCSSERIAL' undeclared (first use this function)
ckutio.c:6092: warning: passing arg 3 of `select' from incompatible
pointer type
etc etc. Diagnosis: These were caused by installing some other package, which
created files in /usr/local/include. Cure: rm -rf /usr/local/include, and
start over.
Reportedly, building C-Kermit 6.0 on Linux 1.1.33 and 1.1.34 gets fatal
compilation errors due to inconsistencies in the Linux header files. Linux
kernel versions prior to 1.1.33 and later than 1.1.34 should be OK. (Also,
C-Kermit 6.1 should be OK since it no longer includes kernel header files.)
Reportedly there is a bug in gcc 2.5.8 with signed to unsigned compares
that can wreak havoc when Kermit (or most any other program) is compiled with
this version of gcc; reportedly this can be worked around, at least in part,
by adding "-fno-unroll-loops" to the gcc compilation options. (This problem
is evidently fixed in more recent gcc releases.)
Reportedly, if you have the iBCS2 (Intel Binary Compatibility Standard 2)
module installed, you can also run SCO Xenix and UNIX binaries under Linux,
including the SCO C-Kermit binaries, shareable libraries and all.
(iCBS2 is available via anonymous ftp from tsx-11.mit.edu, along with an
SCO libc_s compatibility module for Linux).
3.3.2. Problems with Serial Devices in Linux
"set line /dev/modem" or "set line /dev/ttyS2", etc, results in an error,
"/dev/modem is not a tty". Cause unknown, but obviously a driver issue, not a
Kermit one (Kermit uses "isatty()" to check that the device is a tty, so it
knows it will be able to issue all the tty-related ioctl's on it, like setting
the speed & flow control). Try a different name (i.e. driver) for the same
port, e.g. "set line /dev/cua2" or whatever.
"set modem type xxx" (where xxx is the name of a modem) followed by
"set line /dev/modem" or "set line /dev/ttyS2", etc, hangs (but can be
interrupted with Ctrl-C). Experimentation shows that if the modem is
configured to always assert carrier (&C0) the same command does not hang.
Again, a driver issue. Use /dev/cua2 (or whatever) instead.
"set line /dev/cua0" reports "Device is busy", but "set line /dev/ttyS0"
works OK.
In short: If the cua device doesn't work, try the corresponding ttyS device.
If the ttyS device doesn't work, try the corresponding cua device.
From /usr/doc/faq/howto/Serial-HOWTO:
12.4. What's The Real Difference Between The /dev/cuaN And /dev/ttySN
Devices?
The only difference is the way that the devices are opened. The
dialin devices /dev/ttySN are opened in blocking mode, until CD is
asserted (ie someone connects). So, when someone wants to use the
/dev/cuaN device, there is no conflict with a program watching the
/dev/ttySN device (unless someone is connected of course).
The multiple /dev entries, allow operation of the same physical device
with different operating characteristics. It also allows standard
getty programs to coexist with any other serial program, without the
getty being retrofitted with locking of some sort. It's especially
useful since standard Unix kernel file locking, and UUCP locking are
both advisory and not mandatory.
It was discovered during development of C-Kermit 6.1 that rebuilding C-Kermit
with -DNOCOTFMC (No Close/Open To Force Mode Change) made the aforementioned
problem with /dev/ttyS0 go away. It is not yet clear, however, what its
affect might be on the /dev/cua* devices. As of this writing (19 March 1998),
this option has been added to the CFLAGS in the makefile entry for Linux
("make linux").
Note that the cua device is now "deprecated", and new editions of Linux will
phase it out in favor of the ttyS device. See:
http://linuxwww.db.erau.edu/mail_archives/linux-kernel/Mar_98/1441.html
3.3.3. Terminal Emulation in Linux
Run C-Kermit in the regular console screen, which provides Linux Console
"emulation" via the "console" termcap entry, or under X-Windows in an xterm
window, which gives VTxxx emulation. An xterm that includes color ANSI and
VT220 emulation is available with Xfree86:
http://www.clark.net/pub/dickey/xterm/xterm.faq.html
Before starting C-Kermit in an xterm window, you might need to tell the xterm
window's shell to "stty sane".
To set up your PC console keyboard to send VT220 key sequences when using
C-Kermit as your communications program in an X terminal window, create a file
somewhere (e.g. in /root/) called .xmodmaprc, containing something like the
following:
keycode 77 = KP_F1 ! Num Lock => DEC Gold (PF1)
keycode 112 = KP_F2 ! Keypad / => DEC PF1
keycode 63 = KP_F3 ! Keypad * => DEC PF3
keycode 82 = KP_F4 ! Keypad - => DEC PF4
keycode 111 = Help ! Print Screen => DEC Help
keycode 78 = F16 ! Scroll Lock => DEC Do
keycode 110 = F16 ! Pause => DEC Do
keycode 106 = Find ! Insert => DEC Find
keycode 97 = Insert ! Home => DEC Insert
keycode 99 = 0x1000ff00 ! Page Up => DEC Remove
keycode 107 = Select ! Delete => DEC Select
keycode 103 = Page_Up ! End => DEC Prev Screen
keycode 22 = Delete ! Backspace sends Delete (127)
Then put "xmodmap <filename>" in your .xinitrc file (in your login
directory), e.g.
xmodmap /root/.xmodmaprc
Of course you can move things around. Use the xev program to find out key
codes.
3.3.4. Dates and Times
If C-Kermit's date-time (e.g. as shown by its DATE command) differs from
the system's date and time:
a. Make sure the libc to which Kermit is linked is set to GMT or is not
set to any time zone. Watch out for mixed libc5/libc6 systems; each
must be set indpendently.
b. If you have changed your TZ environment variable, make sure it is
exported. This is normally done in /etc/profile or /etc/TZ.
(3.4) C-KERMIT AND NEXTSTEP
Run C-Kermit in a Terminal, Stuart, or xterm window, or when logged in
remotely through a serial port or TELNET connection. C-Kermit does not work
correctly when invoked directly from the NeXTSTEP File Viewer or Dock. This
is because the terminal-oriented gtty, stty, & ioctl calls don't work on the
little window that NeXTSTEP pops up for non-NeXTSTEP applications like Kermit.
CBREAK and No-ECHO settings do not take effect in the command parser --
commands are parsed strictly line at a time. "set line /dev/cua" works.
During CONNECT mode, the console stays in cooked mode, so characters are not
transmitted until carriage return or linefeed is typed, and you can't escape
back. If you want to run Kermit directly from the File Viewer, then launch it
from a shell script that puts it in the desired kind of window, something like
this (for "Terminal"):
Terminal -Lines 24 -Columns 80 -WinLocX 100 -WinLocY 100 $FONT $FONTSIZE \
-SourceDotLogin -Shell /usr/local/bin/kermit &
C-Kermit does not work correctly on a NeXT with NeXTSTEP 3.0 to which you have
established an rlogin connection, due to a bug in NeXTSTEP 3.0, which has been
reported to NeXT.
The SET CARRIER command has no effect on the NeXT -- this is a limitation of
the tty device drivers.
Hardware flow control on the NeXT is selected not by "set flow rts/cts" in
Kermit (since NeXTSTEP offers no API for this), but rather, by using a
specially-named driver for the serial device: /dev/cufa instead /dev/cua;
/dev/cufb instead of /dev/cub. This is available only on 68040-based NeXT
models (the situation for Intel NeXTSTEP implementations is unknown).
NeXT-built 68030 and 68040 models have different kinds of serial interfaces;
the 68030 has a Macintosh-like RS-422 interface, which lacks RTS and CTS
signals; the 68040 has an RS-423 (RS-232 compatible) interface, which
supports the commonly-used modem signals. WARNING: the connectors look
exactly the same, but the pins are used in completely DIFFERENT ways --
different cables are required for the two kinds of interfaces.
IF YOU GET LOTS OF RETRANSMISSIONS during file transfer, even when
using a /dev/cuf* device and the modem is correctly configured for
RTS/CTS flow control, YOU PROBABLY HAVE THE WRONG KIND OF CABLE.
On the NeXT, Kermit reportedly (by TimeMon) causes the kernel to use a lot of
CPU time when using a "set line" connection. That's because there is no DMA
channel for the NeXT serial port, so the port must interrupt the kernel for
each character in or out.
One user reported trouble running C-Kermit on a NeXT from within NeXT's
Subprocess class under NeXTstep 3.0, and/or when rlogin'd from one NeXT to
another: Error opening /dev/tty:, congm: No such device or address.
Diagnosis: Bug in NeXTSTEP 3.0, cure unknown.
(3.5) C-KERMIT AND QNX
See also: The comp.os.qnx newsgroup.
Support for QNX 4.x was added in C-Kermit 5A(190). This is a full-function
implementation, thoroughly tested on QNX 4.21, and verified to work in both
16-bit and 32-bit versions. Most advanced features are supported including
TCP/IP, high serial speeds, hardware flow-control, modem-signal awareness,
curses support, etc.
Dialout devices are normally /dev/ser1, /dev/ser2, ..., and can be opened
explicitly with SET LINE. Reportedly, "/dev/ser" (no unit number) opens the
first available /dev/ser<n> device.
Like all other UNIX C-Kermit implementations, QNX C-Kermit does not provide
any kind of terminal emulation. Terminal specific functions are provided by
your terminal, terminal window (e.g. QNX Terminal or xterm), or emulator.
QNX C-Kermit, as distributed, does not include support for UUCP line-locking;
the QNX makefile entries (qnx32 and qnx16) include the -DNOUUCP switch. This
is because QNX, as distributed, does not include UUCP, and its own
communications software (e.g. qterm) does not use UUCP line locking. If you
have a UUCP product installed on your QNX system, remove the -DNOUUCP switch
from the makefile entry and rebuild. Then check to see that Kermit's UUCP
lockfile conventions are the same as those of your UUCP package; if not, read
the UUCP lockfile section ckuins.doc and make the necessary changes to the
makefile entry (e.g. add -DHDBUUCP).
BUG: The fullscreen file transfer display works fine the first time, but it is
fractured on subsequent file transfers. Cause and cure unknown.
(3.6) C-KERMIT AND SCO UNIX, XENIX, ODT, AND OPENSERVER
See also:
. The comp.unix.sco.* newsgroups.
. http://www.sco.com/Support/ssl.html
There is an FAQ, but I'm not sure where to find it. It is posted to the
newsgroups from time to time.
Old Xenix versions... Did you know: Xenix 3.0 is *older* than Xenix 2.0?
There is all sorts of confusion among SCO versions, particularly when third-
party communications boards and drivers are installed, regarding lockfile
naming conventions, as well as basic functionality. As far as lockfiles go,
all bets are off if you are using a third-party multiport board. At least you
have the source code. Hopefully you also have a C compiler :-)
On the other hand, certain functions that might not (do not) work right or
at all when using SCO drivers (e.g. high serial speeds, hardware flow control,
and/or reading of modem signals) might work right when using third-party
drivers. (Example: hardware flow control works, reportedly, only on uppercase
device like tty1A -- not tty1a -- and only when CLOCAL is clear when using the
SCO sio driver, but there are no such restrictions in, e.g., Digiboard
drivers).
One user reports that he can't transfer large files with C-Kermit under SCO
OSR5.0.0 and 5.0.4 -- after the first 5K, everything falls apart. Same thing
without Kermit -- e.g. with ftp over a PPP connection. Later, he said that
replacing SCO's SIO driver with FAS, an alternative communications driver,
made the problem go away:
ftp://ftp.fu-berlin.de/pub/unix/driver/fas
Hardware flow control is available in C-Kermit when the underlying SCO version
supports it. Note that Xenix 2.3.0 and later claims to support RTSFLOW and
CTSFLOW, but this is not modern bidirectional hardware flow control, but
rather it implements the original RS-232 meanings of these signals for
unidirectional half-duplex line access: If both RTSFLOW and CTSFLOW bits are
set, Xenix asserts RTS when it wants to send data and waits for CTS assertion
before it actually starts sending data (also, reportedly, even this is broken
in Xenix 2.3.0 and 2.3.1).
Use SCO-provided utilities for switching the directionality of a modem line,
such as "enable" and "disable" commands. For example, to dial out on tty1a,
which is normally set up for logins:
disable tty1a
kermit -l /dev/tty1a
enable tty1a
If a tty device is listed as an ACU in /usr/lib/uucp/Devices and is enabled,
getty resets the ownership and permissions to uucp.uucp 640 every time the
device is released. If you want to use the device only for dialout, and you
want to specify other owners or permissions, you should disable it in
/usr/lib/uucp/Devices; this will prevent getty from doing things to it. You
should also changes the device's file modes in /etc/conf/node.d/sio by
changing fields 5-7 for the desired device(s); this determines how the devices
are set if you relink the kernel.
SCO systems tend to use different names (i.e. drivers) for the same device.
In Xenix, /dev/tty1a refers to a terminal device that has no modem control;
open, read, write, and close operations do not depend on carrier. On the
other hand, /dev/tty1A (same name, but with final letter upper case), is the
same device with modem control, in which carrier is required (the SET LINE
command does not complete until carrier appears, read/write operations fail if
there is no carrier, etc). In the SCO case, C-Kermit always uses the
lowercase name when creating the UUCP lockfile (this is, according to SCO
experts, the proper behavior, but reportedly not all other communications
applications found on SCO systems follow this rule).
In SCO Xenix, you must use SET CARRIER ON *and* use the upper-case tty device
name in order to have carrier detection. SET CARRIER OFF should work with
either upper or lowercase tty devices. SET CARRIER AUTO is the same as OFF.
One SCO user of C-Kermit 5A(190) reported that only one copy of Kermit can run
at a time when a Stallion Technologies multiport boards are installed. Cause,
cure, and present status unknown (see Section 14 of this file for more info
regarding Stallion).
Prior to SCO OpenServer 5.0.4, the highest serial port speed supported by SCO
was 38400. However, in some SCO versions (e.g. OSR5) it is possible to map
rarely-used lower speeds (like 600 and 1800) to higher ones like 57600 and
115200. To find out how, go to http://www.sco.com/ and search for "115200".
In OSR5.0.4, serial speeds up to 921600 are supported through the POSIX
interface; C-Kermit 6.1.193 or later, when built for OSR5.0.4, supports these
speeds, but you might be able to run this binary on earlier releases to get
the high serial speeds, depending on various factors, described by Bela Lubkin
of SCO:
Serial speeds under SCO Unix / Open Desktop / OpenServer
========================================================
Third party drivers (intelligent serial boards) may provide any speeds
they desire; most support up to 115.2Kbps.
SCO's "sio" driver, which is used to drive standard serial ports with
8250/16450/16550 and similar UARTs, was limited to 38400bps in older
releases. Support for rates through 115.2Kbps was added in the
following releases:
SCO OpenServer Release 5.0.0 (requires supplement "rs40b")
SCO OpenServer Release 5.0.2 (requires supplement "rs40a" or "rs40b")
SCO OpenServer Release 5.0.4 or later
SCO Internet FastStart Release 1.0.0 or later
SCO supplements are at ftp://ftp.sco.com/; the "rs40" series are
under directory /Supplements/internet
(end quote)
Reportedly, if you have a script that makes a TCP/IP SET HOST (e.g. Telnet)
connection to SCO 3.2v4.2 with TCP/IP 1.2.1, and then does the following:
script $ exit
hangup
this causes a pseudoterminal (pty) to be consumed on the SCO system; if you do
it enough times, it will run out of ptys. An "exit" command is being sent to
the SCO shell, and a HANGUP command is executed locally, so the chances are
good that both sides are trying to close the connection at once, perhaps
inducing a race condition in which the remote pty is not released. It was
speculated that this would be fixed by applying SLS net382e, but it did not.
Meanwhile, the workaround is to insert a "pause" between the SCRIPT and HANGUP
commands. (The situation with later SCO releases is not known.)
SCO UNIX and OpenServer allow their console and/or terminal drivers to be
configured to translate character sets for you. DON'T DO THIS WHEN USING
KERMIT! First of all, you don't need it -- Kermit itself already does this
for you. And second, it will (a) probably ruin the formatting of your screens
(depending on which emulation you are using); and (b) interfere with all sorts
of other things -- legibility of non-ASCII text on the terminal screen, file
transfer, etc. Use:
mapchan -n
to turn off this feature.
(3.7) C-KERMIT AND SOLARIS
See also: The comp.unix.solaris newsgroup.
Your serial port can't be used -- or at least won't work right -- until it is
configured in Solaris. For example, you get a message like "SERIAL: Operation
would block" when attempting to dial. This probably indicates that the serial
port has not been properly set up for use with modems. You'll need to follow
the instructions in your system setup or management manual, such as (e.g.) the
Desktop SPARC Sun System & Network Manager's Guide, which should contain a
section "Setting up Modem Software"; read it and follow the instructions.
These might (or might not) include running a program called "eeprom", editing
some system configuration file (such as, for example:
/platform/i86pc/kernel/drv/asy.conf
and then doing a configuration reboot, or running some other programs like
drvconfig and devlinks. "man eeprom" for details.
Some users report difficulties dialing out with C-Kermit on serial port when
using the /dev/cua/a name -- session seems to become stuck, can't escape back,
etc -- but when using the /dev/term/a name for the *same* device, everything
works fine. Explanation: unknown, but probably due to improper configuration
of the port; again, see the materials referenced above.
Reportedly, if you start C-Kermit and "set line" to a port that has a modem
connected to it that is not turned on, and then "set flow rts/cts", there
might be some (unspecified) difficulties closing the device (Solaris version
not specified).
The built-in SunLink X.25 support for Solaris 2.3/2.4./25 and SunLink 8.01 or
9.00 works OK provided the X.25 system has been installed and initialized
properly. Packet sizes might need to be reduced to 256, maybe even less,
depending on the configuration of the X.25 installation. On one connection
where C-Kermit 6.0 was tested, very large packets and window sizes could be
used in one direction, but only very small ones would work in the other.
In any case, according to Sun, C-Kermit's X.25 support is superfluous with
SunLink 8.x / Solaris 2.3. Quoting an anonymous Sun engineer:
... there is now no need to include any X.25 code within kermit. As of
X.25 8.0.1 we support the use of kermit, uucp and similar protocols over
devices of type /dev/xty. This facility was there in 8.0, and should
also work on the 8.0 release if patch 101524 is applied, but I'm not 100%
sure it will work in all cases, which is why we only claim support from
8.0.1 onwards.
When configuring X.25, on the "Advanced Configuration->Parameters" screen
of the x25tool you can select a number of XTY devices. If you set this
to be > 1, press Apply, and reboot, you will get a number of /dev/xty
entries created.
Ignore /dev/xty0, it is a special case. All the others can be used exactly
as if they were a serial line (e.g. /dev/tty) connected to a modem, except
that instead of using Hayes-style commands, you use PAD commands.
From kermit you can do a 'set line' command to, say, /dev/xty1, then set
your dialing command to be "CALL 12345678", etc. All the usual PAD
commands will work (SET, PAR, etc).
I know of one customer in Australia who is successfully using this, with
kermit scripts, to manage some X.25-connected switches. He used standard
kermit, compiled for Solaris 2, with X.25 8.0 xty devices.
C-Kermit can't be compiled successfully under Solaris 2.3 using SUNWspro cc
2.0.1 unless at least some of the following patches are applied to cc (it is
not known which one(s), if any, fix the problem):
100935-01 SparcCompiler C 2.0.1: bad code generated when addresses
of two double arguments are involved
100961-05 SPARCcompilers C 2.0.1: conditional expression with
function returning structure gives wrong value
100974-01 SparcWorks 2.0.1: dbx jumbo patch
101424-01 SPARCworks 2.0.1 maketool SEGV's instantly on Solaris 2.3
With unpatched cc 2.0.1, the symptom is that certain modules generate
truncated object files, resulting in many unresolved references at link time.
Using a Sun workstation keyboard for VT emulation when accessing VMS:
From: Jerry Leichter <leichter@smarts.com>
Newsgroups: comp.os.vms
Subject: Re: VT100 keyboard mapping to Sun X server
Date: Mon, 19 Aug 1996 12:44:21 -0400
> I am stuck right now using a Sun keyboard (type 5) on systems running SunOS
> and Solaris. I would like to use EVE on an OpenVMS box with display back to
> the Sun. Does anyone know of a keyboard mapping (or some other procedure)
> which will allow the Sun keyboard to approximate a VT100/VT220?
You can't get it exactly - because the keypad has one fewer key - but
you can come pretty close. Here's a set of keydefs I use:
keycode 101=KP_0
keycode 119=KP_1
keycode 120=KP_2
keycode 121=KP_3
keycode 98=KP_4
keycode 99=KP_5
keycode 100=KP_6
keycode 75=KP_7
keycode 76=KP_8
keycode 77=KP_9
keycode 52=KP_F1
keycode 53=KP_F2
keycode 54=KP_F3
keycode 57=KP_Decimal
keycode 28=Left
keycode 29=Right
keycode 30=KP_Separator
keycode 105=KP_F4
keycode 78=KP_Subtract
keycode 8=Left
keycode 10=Right
keycode 32=Up
keycode 33=Down
keycode 97=KP_Enter
Put this in a file - I use "keydefs" in my home directory and feed it
into xmodmap:
xmodmap - <$HOME/keydefs
This takes care of the arrow keys and the "calculator" key cluster. The
"+" key will play the role of the DEC "," key. The Sun "-" key will be
like the DEC "-" key, though it's in a physically different position -
where the DEC PF4 key is. The PF4 key is ... damn, I'm not sure where
"key 105" is. I *think* it may be on the leftmost key of the group of
four just above the "calculator" key cluster.
I also execute the following (this is all in my xinitrc file):
xmodmap -e 'keysym KP_Decimal = KP_Decimal'
xmodmap -e 'keysym BackSpace = Delete BackSpace' \
-e 'keysym Delete = BackSpace Delete'
xmodmap -e 'keysym KP_Decimal = Delete Delete KP_Decimal'
xmodmap -e 'add mod1 = Meta_R'
xmodmap -e 'add mod1 = Meta_L'
Beware of one thing about xmodmap: Keymap changes are applied to the
*whole workstation*, not just to individual windows. There is, in fact,
no way I know of to apply them to individual windows. These definitions
*may* confuse some Unix programs (and/or some Unix users).
If you're using Motif, you may also need to apply bindings at the Motif
level. If just using xmodmap doesn't work, I can try and dig that stuff
up for you.
(end quote)
NOTE: The rest of the problems in this section have to do with bidirectional
tty lines and the Solaris Port Monitor. Hopefully these were all fixed in
C-Kermit 6.0.
Reportedly, "C-Kermit ... causes a SPARCstation running Solaris 2.3
to panic after the modem connects. I have tried compiling C-Kermit with Sun's
unbundled C compiler, with GCC Versions 2.4.5 and 2.5.3, with make targets
'sunos51', 'sunos51tcp', 'sunos51gcc', and even 'sys5r4', and each time it
compiles and starts up cleanly, but without fail, as soon as I dial the number
and get a 'CONNECT' message from the modem, I get:
BAD TRAP
kermit: Data fault
kernel read fault at addr=0x45c, pme=0x0
Sync Error Reg 80 <INVALID>
...
panic: Data Fault.
...
Rebooting...
The same modem works fine for UUCP/tip calling." Also (reportedly), this only
happens if the dialout port is configured as in/out via admintool. If it is
configured as out-only, no problem. This is the same dialing code that works
on hundreds of other System-V based UNIX OS's. Since it should be impossible
for a user program to crash the operating system, this problem must be chalked
up to a Solaris bug. Even if you SET CARRIER OFF, CONNECT, and dial manually
by typing ATDTnnnnnnn, the system panics as soon as the modem issues its
CONNECT message. (Clearly, when you are dialing manually, C-Kermit does not
know a thing about the CONNECT message, and so the panic is almost certainly
caused by the transition of the Carrier Detect (CD) line from off to on.)
This problem was reported by many users, all of whom say that C-Kermit worked
fine on Solaris 2.1 and 2.2. If the speculation about CD is true, then a
possible workaround might be to configure the modem to leave CD on (or off)
all the time. Perhaps by the time you read this, a patch will have been
issued for Solaris 2.3.
The following is from Karl S. Marsh, Systems & Networks Administrator,
AMBIX Systems Corp, Rochester, NY (begin quote):
"Environment:
Solaris 2.3 Patch 101318-45
C-Kermit 5A(189) (and presumably this applies to 188 and 190 also)
eeprom setting:
ttya-rts-dtr-off=false
ttya-ignore-cd=false
ttya-mode=19200,8,n,8,-
"To use C-Kermit on a bidirectional port in this environment, do not use
admintool to configure the port. Use admintool to delete any services running
on the port and then quit admintool and issue the following command:
pmadm -a -p zsmon -s ttyb -i root -fu -v 1 -m "`ttyadm -b -d /dev/term/b \
-l conttyH -m ldterm,ttcompat -s /usr/bin/login -S n`"
[NOTE: This was copied from a fax, so please check it carefully] where:
-a = Add service
-p = pmtag (zsmon)
-s = service tag (ttyb)
-i = id to be associated with service tag (root)
-fu = create utmp entry
-v = version of ttyadm
-m = port monitor-specific portion of the port monitor administrative file
entry for the service
-b = set up port for bidirectional use
-d = full path name of device
-l = which ttylabel in the /etc/ttydefs file to use
-m = a list of pushable STREAMS modules
-s = pathname of service to be invoked when connection request received
-S = software carrier detect on or off (n = off)
"This is exactly how I was able to get Kermit to work on a bi-directional
port without crashing the system." (End quote)
On the Solaris problem, also see SunSolve Bug ID 1150457 ("Using C-Kermit, get
Bad Trap on receiving prompt from remote system"). Another user reported "So,
I have communicated with the Sun tech support person that submitted this bug
report [1150457]. Apparently, this bug was fixed under one of the jumbo
kernel patches. It would seem that the fix did not live on into 101318-45, as
this is EXACTLY the error that I see when I attempt to use kermit on my
system."
Later (Aug 94)... C-Kermit dialout successfully tested on a Sun4m with a
heavily patched Solaris 2.3. The patches most likely to have been relevant:
101318-50: SunOS 5.3: Jumbo patch for kernel (includes libc, lockd)
101720-01: SunOS 5.3: ttymon - prompt not always visible on a modem connection
101815-01: SunOS 5.3: Data fault in put() NULL queue passed from
ttycommon_qfull()
101328-01: SunOS 5.3: Automation script to properly setup tty ports prior to
PCTS execution
Still later (Nov 94): another user (Bo Kullmar in Sweden) reports that after
using C-Kermit to dial out on a bidirectional port, the port might not answer
subsequent incoming calls, and says "the problem is easy enough to fix with
the Serial Port Manager; I just delete the service and install it again using
the graphical interface, which underneath uses commands like sacadm and
pmadm." Later Bo reports, "I have found that if I run Kermit with the
following script then it works. This script is for /dev/cua/a, -s a is the
last a in /dev/cua/a
#! /bin/sh
kermit
sleep 2
surun pmadm -e -p zsmon -s a
(end quote)
(3.8) C-KERMIT AND SUNOS
Sun SPARCstation users should read the section "Setting up Modem Software" in
the Desktop SPARC Sun System & Network Manager's Guide. If you don't set up
your serial ports correctly, Kermit (and other communications software) won't
work right.
Reportedly, C-Kermit does not work correctly on a Sun SPARCstation in an Open
Windows window with scrolling enabled. Disable scrolling, or else invoke
Kermit in a terminal emulation window (xterm, crttool, vttool) under SunView
(this might be fixed in later SunOS releases).
On the Sun with Open Windows, an additional symptom has been reported:
outbound SunLink X.25 connections "magically" translate CR typed at the
keyboard into LF before transmission to the remote host. This doesn't happen
under SunView.
SET CARRIER ON, when used on the SunOS 4.1 version of C-Kermit (compiled in
the BSD universe), causes the program to hang uninterruptibly when SET LINE
is issued for a device that is not asserting carrier. When Kermit is built
in the Sys V universe on the same computer, there is no problem (it can be
interrupted with Ctrl-C). This is apparently a limitation of the BSD-style
tty driver.
SunOS 4.1 C-Kermit has been observed to dump core when running a complicated
script program under cron. The dump invariably occurs in ttoc(), while trying
to output a character to a TCP/IP TELNET connection. ttoc() contains a
write() call, and when the system or the network is very busy, the write()
call can get stuck for long periods of time. To break out of deadlocks caused
by stuck write() calls, there is an alarm around the write(). It is possible
that the core dump occurs when this alarm signal is caught. (This one has
not been observed recently -- possibly fixed in edit 190.)
On Sun computers with SunOS 4.0 or 4.1, SET FLOW RTS/CTS works only if the
carrier signal is present from the communication device at the time when
C-Kermit enters packet mode or CONNECT mode. If carrier is not sensed (e.g.
when dialing), C-Kermit does not attempt to turn on RTS/CTS flow control.
This is because the SunOS serial device driver does not allow characters to
be output if RTS/CTS is set (CRTSCTS) but carrier (and DSR) are not present.
Workaround (maybe): SET CARRIER OFF before giving the SET LINE command,
establish the connection, then SET FLOW RTS/CTS
It has also been reported that RTS/CTS flow control under SunOS 4.1 through
4.1.3 works only on INPUT, not on output, and that there is a patch from Sun
to correct this problem: Patch-ID# T100513-04, 20 July 1993 (this patch might
apply only to SunOS 4.1.3). It might also be necessary to configure the
eeprom parameters of the serial port; e.g. do the following as root at the
shell prompt:
eeprom ttya-ignore-cd=false
eeprom ttya-rts-dtr-off=true
There have been reports of file transfer failures on Sun-3 systems when using
long packets and/or large window sizes. One user says that when this happens,
the console issues many copies of this message:
chaos vmunix: zs1: ring buffer overflow
This means that SunOS is not scheduling Kermit frequently enough to service
interrupts from the zs serial device (Zilog 8350 SCC serial communication
port) before its input silo overflows. Workaround: use smaller packets
and/or a smaller window size, or use "nice" to increase Kermit's priority.
Use hardware flow control if available, or remove other active processes
before running Kermit.
SunLink X.25 support in C-Kermit 5A(190) has been built and tested
successfully under SunOS 4.1.3b and SunLink X.25 7.00.
(3.9) C-KERMIT AND ULTRIX
See also: The comp.unix.ultrix and comp.sys.dec newsgroups.
There is no hardware flow control in Ultrix. That's not a Kermit deficiency,
but an Ultrix one.
Reportedly, DEC ULTRIX 4.3 is immune to C-Kermit's disabling of SIGQUIT,
which is the signal that is generated when the user types Ctrl-\, which kills
the current process (i.e. C-Kermit) and dumps core. Diagnosis and cure
unknown. Workaround: before starting C-Kermit -- or for that matter, when you
first log in because this applies to all processes, not just Kermit -- give
the following UNIX command:
stty quit undef
Certain operations driven by RS-232 modem signal do not work on DECstations or
other DEC platforms whose serial interfaces use MMP connectors (DEC version of
RJ45 telephone jack with offset tab). These connectors convey only the DSR
and DTR modem signals, but not carrier (CD), RTS, CTS, or RI. Use SET CARRIER
OFF to enable communication, or "hotwire" DSR to CD.
The maximum serial speed on the DECstation 5000 is normally 19200, but various
tricks are available (outside Kermit) to enable higher rates. For example, on
the 5000/200, 19200 can be remapped (somehow, something to do with "a bit in
the SIR", whatever that is) to 38400, but in software you must still refer to
this speed as 19200; you can't have 19200 and 38400 available at the same time.
19200, reportedly, is also the highest speed supported by Ultrix, but NetBSD
reportedly supports speeds up to 57600 on the DECstation, although whether and
how well this works is another question.
In any case, given the lack of hardware flow control in Ultrix, high serial
speeds are problematic at best.
(3.10) C-KERMIT AND UNIXWARE
See also: The comp.unix.ultrix newsgroup.
Using the UnixWare 1.1 Application Server, one user reports a system panic
when the following script program is executed:
set line /dev/tty4
set speed 9600
output \13
connect
The panic does not happen if a PAUSE is inserted:
set line /dev/tty4
set speed 9600
pause 1
output \13
connect
This is using a Stallion EasyIO card installed as board 0 on IRQ 12 on
a Gateway 386 with the Stallion-supplied driver. The problem was reported
to Novell and Stallion, resolution pending. (Reportedly, this problem
is now fixed.)
(3.11) C-KERMIT AND APOLLO SR10
Reportedly, version 5A(190), when built under Apollo SR10 using "make
sr10-bsd", compiles, links, and executes OK, but leaves the terminal unusable
after it exits -- the "cs7" or "cs8" (character size) parameter has become
cs5. The terminal must be reset from another terminal. Cause and cure
unknown. Suggested workaround: Wrap Kermit in a shell script something like:
kermit @*
stty sane
(3.12) C-KERMIT AND TANDY XENIX 3.0
Reportedly, if you type lots of Ctrl-C's during execution of the
initialization file, ghost Kermit processes will be created, and will compete
for the keyboard. They can only be removed via "kill -9" from another
terminal, or by rebooting. Diagnosis -- something strange happening with
the SIGINT handler while the process is reading the directory (it seems to
occur during the SET PROMPT [\v(dir)] ... sequence). Cure: unknown.
Workaround: don't interrupt C-Kermit while it is executing its init file on
the Tandy 16/6000.
(3.13) C-KERMIT AND OSF/1 (DIGITAL UNIX)
Reportedly, if a modem is set for &S0 (assert DSR at all times), the system
resets or drops DTR every 30 seconds; reportedly DEC says to set &S1.
Digital UNIX 3.2 evidently wants to believe your terminal is one line longer
than you say it is, e.g. when a "more" or "man" command is given. This is has
nothing to do with C-Kermit, but tends to annoy those who use Kermit or other
terminal emulators to access Digital UNIX systems. Workaround: tell UNIX
to "stty rows 23" (or whatever).
Reportedly, there is some bizarre behavior when trying to use a version of
C-Kermit built on Digital Unix 4.0 on another, possibly due to differing
OS or library revision levels; for example, the inability to connect to
certain TCP/IP hosts. Solution: rebuild C-Kermit from source code on the
system where you will be using it.
(3.14) C-KERMIT AND SGI IRIX
See also: The comp.sys.sgi.misc newsgroup.
SGI did not supply an API for hardware flow control prior to IRIX 5.2.
C-Kermit 6.1 for IRIX 5.2 and higher supports hardware flow control in the
normal way, via "set flow rts/cts".
For hardware flow control on earlier IRIX and/or C-Kermit versions, use the
ttyf* (modem control AND hardware flow control) devices and not the ttyd*
(direct) or ttym* (modem control but no hardware flow control) ones, and
obtain the proper "hardware handshaking" cable from SGI, which is incompatible
with the ones for the Macintosh and NeXT even though they look the same. "man
serial" for further info.
Serial speeds higher than 38400 are available in IRIX 6.2 and later, on
O-class machines only, and are supported by C-Kermit 6.1 and later.
Experimentation with both IRIX 5.3 and 6.2 shows that when logged in to IRIX
via Telnet, that remote-mode C-Kermit can't send files if the packet length is
greater than 4096; the Telnet server evidently has this restriction (or bug),
since there is no problem sending long packets on serial or rlogin connections.
However, it can receive files with no problem if the packet length is greater
than 4096. As a workaround, the FAST macro for IRIX includes "set send
packet-length 4000".
Reportedly some Indys have bad serial port hardware. IRIX 5.2, for example,
needs patch 151 to work around this; or upgrade to a later release.
Similarly, IRIX 5.2 has several problems with serial i/o, flow control, etc.
Again, patch or upgrade.
Reportedly on Silicon Graphics (SGI) machines with IRIX 4.0, Kermit cannot be
suspended by typing the suspend ("swtch") character if it was started from
csh, even though other programs can be suspended this way, and even though the
Z and SUSPEND commands still work correctly. This is evidently because IRIX's
csh does not deliver the SIGTSTP signal to Kermit. The reason other programs
can be suspended in the same environment is probably that they do not trap
SIGTSTP themselves, so the shell is doing the suspending rather than the
application.
(3.15) C-KERMIT AND THE BEBOX
See also: The comp.sys.be newsgroup.
The BeBox isn't a real product yet, and BeOS -- particularly the POSIX pieces
of it -- aren't finished. As the POSIX bits are fleshed out, a lot of the
Be-specific code can Be removed. C-Kermit 6.0 works only in BeOS DR7. The
workarounds in this version are for DR7, contributed by an anonymous donor,
sufficient to:
- set line /dev/serial2 (and probably the other serial ports)
- set speed 115200 (and at least some of the lower baud rates)
- connect
- set modem type hayes (and likely others, too)
- dial [phone number]
- set send packet length 2048 (other lengths for both send and receive)
- set receive packet length 2048
- set file type binary (text mode works, too)
(with remote kermit session in server mode)
- put bedrop.jpg
- get bedrop.jpg
- get bedrop.jpg bedrop.jpg2
- finish, bye
The following do not work:
- kermit does not detect modem hangup
- !/RUN/PUSH [commandline command]
- running kermit in remote mode
- using other protocols (x/y/zmodem)
- TCP networking interface (Be's TCP/IP API has a ways to go, still)
C-Kermit does not work on BeOS DR8 because of changes in the underlying APIs.
Unfortunately not enough changes were made to allow the regular POSIX-based
C-Kermit to work either, in particular the lack of the fork() call needed for
CONNECT mode; thus an entirely new thread-based CONNECT module would need to
be written.
Later... C-Kermit *almost* works on DR8. The required new CONNECT module has
been written (ckucns.c). Unfortunately, it is based on select(), which also
does not work in DR8.
Stay tuned.
(3.16) C-KERMIT AND DG/UX
Somebody downloaded the C-Kermit 6.0 binary built under DG/UX 5.40 and ran it
under DG/UX 5.4R3.10 -- it worked OK except that file dates for incoming files
were all written as 1 Jan 1970. Cause and cure unknown.
(3.17) C-KERMIT AND SEQUENT DYNIX
Reportedly, when coming into a Sequent UNIX (DYNIX) system through an X.25
connection, Kermit doesn't work right because the Sequent's FIONREAD ioctl
returns incorrect data. To work around, use the 1-character-at-a-time version
of myread() in ckutio.c (i.e. undefine MYREAD in ckutio.c and rebuild the
program).
(4) GENERAL UNIX-SPECIFIC HINTS, LIMITATIONS, AND BUGS
In version 6.0, the default C-Kermit prompt includes your current (working)
directory; for example:
[/usr/olga] C-Kermit>
If that directory is on an NFS-mounted disk, and NFS stops working or the
disk becomes unavailable, C-Kermit will hang waiting for NFS and/or the disk
to come back. Whether you can interrupt C-Kermit when it is hung this way
depends on the specific OS. Kermit has called the operating systems's
getcwd() function, and is waiting for it to return. Some versions of UNIX
(e.g. HP-UX 9.x) allow this function to be interrupted with SIGINT (Ctrl-C),
others (such as HP-UX 8.x) do not. To avoid this effect, you can always
use SET PROMPT change your prompt to something that does not involve calling
getcwd(), but if NFS is not responding, C-Kermit will still hang any time you
give a command that refers to the current directory. Also note that in some
cases, the uninterruptibility of NFS-dependent system or library calls is
considered a bug, and sometimes there are patches. For HP-UX, for example:
HP-UX 10.20 libc PHCO_8764 PHCO_14891
HP-UX 10.10 libc PHCO_8763 PHCO_14254
HP-UX 9.x libc PHCO_7747 S700 PHCO_13095
HP-UX 9.x libc PHCO_6779 S800 PHCO_11162
You might have reason to make C-Kermit the login shell for a specific user,
by entering the pathname of Kermit (possibly with command-line switches, such
as -x to put it in server mode) into the shell field of the /etc/passwd file.
This works pretty well. In some cases, for "ultimate security", you might
want to use a version built with -DNOPUSH (see ckccfg.doc) for this, but even
if you don't, then PUSHing or shelling out from C-Kermit just brings up a
new copy of C-Kermit (but warning: this does not prevent the user from
explicitly running a shell; e.g. "run /bin/sh"; use NOPUSH to prevent this).
C-Kermit will not work as expected on a remote UNIX system, when used through
the "splitvt" or GNU "screen" programs. In this case, terminal connections to
the remote UNIX system work, but attempts to transfer files fail because the
screen optimization (or at least, line wrapping, control-character absorption)
done by this package interferes with Kermit's packets.
You might try the following -- what we call "doomsday Kermit" settings to
push packets through even the densest and most obstructive connections, such
as "screen" and "splitvt" (and certain kinds of 3270 protocol emulators):
Give these commands to BOTH Kermit programs:
SET FLOW NONE
SET CONTROL PREFIX ALL
SET RECEIVE PACKET-LENGTH 70
SET RECEIVE START 62
SET SEND START 62
SET SEND PAUSE 100
SET BLOCK B
If it works, it will be slow.
On UNIX workstations equipped with DOS emulators like SoftPC, watch out for
what these emulators do to the serial port drivers. After using a DOS
emulator, particularly if you use it to run DOS communications software, you
might have to reconfigure the serial ports for use by UNIX.
On AT&T 7300 (3B1) machines, you might have to "stty nl1" before starting
C-Kermit. Do this if characters are lost during communications operations.
Under the bash shell (versions prior to 1.07 from CWRU), "pushing" to an
inferior shell and then exiting back to Kermit leaves Kermit in the background
such that it must be explicitly fg'd. This is reportedly fixed in version
1.07 of bash.
Interruption by Ctrl-Z makes UNIX C-Kermit try to suspend itself with
kill(0,SIGSTOP), but only on systems that support job control, as determined
by whether the symbol SIGTSTP is defined (or on POSIX or SVR4 systems, if
syconf(_SC_JOB_CONTROL) or _POSIX_JOB_CONTROL in addition to SIGTSTP).
However, if Kermit is running under a login shell (such as the original Bourne
shell) that does not support job control, the user's session hangs and must be
logged out from another terminal, or hung up on. There is no way Kermit can
defend itself against this. If you use a non-job control shell on a computer
that supports job control, give a command like "stty susp undef" to fix it so
the suspend signal is not attached to any particular key, or give the command
SET SUSPEND OFF to C-Kermit, or build C-Kermit with -DNOJC.
Reportedly, the UNIX C-Kermit server, under some conditions, on certain
particular systems, fails to log out its login session upon receipt of a
BYE command. Before relying on the BYE command working, test it a few times
to make sure it works on your system: there might be system configuration or
security mechanisms to prevent an inferior process (like Kermit) from
killing a superior one (like the login shell).
(5) INITIALIZATION AND COMMAND FILES
C-Kermit's initialization file for UNIX is .kermrc (lowercase, starts with
period) in your home directory, unless Kermit was built with the system-wide
initialization-file option (see ckuins.doc).
C-Kermit identifies your home directory based on the environment variable,
HOME. Most UNIX systems set this variable automatically when you log in. If
C-Kermit can't find your initialization file, check your HOME variable:
echo $HOME (at the UNIX prompt)
or:
echo \$(HOME) (at the C-Kermit prompt)
If HOME is not defined, or is defined incorrectly, add the appropriate
definition to your UNIX .profile or .login file, depending on your shell:
setenv HOME full-pathname-of-your-home-directory (C-Shell, .login file)
or:
HOME=full-pathname-of-your-home-directory (sh, ksh, .profile file)
export HOME
NOTE: Various other operations depend on the correct definition of HOME.
These include the "tilde-expansion" feature, which allows you to refer to
your home directory as "~" in filenames used in C-Kermit commands, e.g.
send ~/.kermrc
as well as the \v(home) variable.
Prior to version 5A(190), C-Kermit would look for its initialization file in
the current directory if it was not found in the home directory. This feature
was removed from 5A(190) because it was a security risk. Some people, however,
liked this behavior and had .kermrc files in all their directories that would
set up things appropriately for the files therein. If you want this behavior,
you can accomplish it in various ways, for example:
. Create a shell alias, for example:
alias kd="kermit -Y ./.kermrc"
. Create a .kermrc file in your home directory, whose contents are:
take ./.kermrc
The TAKE command does not search your UNIX PATH for command files. If a
command file is not in the current directory, you must give a full path
specification for it. This poses a problem for TAKE commands that are
themselves in TAKE files. See the trick used in CKETEST.INI...
Suppose you need to pass a password from the UNIX command line to a C-Kermit
script program, in such a way that it does not show up in "ps" or "w" listings.
Here is a method (not guaranteed to be 100% secure, but definitely more secure
than the more obvious methods):
echo mypassword | kermit myscript
The "myscript" file contains all the commands that need to be executed during
the Kermit session, up to and including EXIT, and also includes an ASK or ASKQ
command to read the password from standard input, which has been piped in from
the UNIX 'echo' command, but it must not include a CONNECT command. Only
"kermit myscript" shows up in the ps listing.
(6) COMMUNICATION SPEED SELECTION
Version-7 based UNIX implementations, including 4.3 BSD and earlier and
UNIX systems based upon BSD, use a 4-bit field to record a serial device's
terminal speed. This leaves room for 16 speeds, which are normally:
0, 50, 75, 110, 134.5, 150, 200, 300, 600, 1200, 1800, 2400, 4800, and 9600
The remaining two are usually called EXTA and EXTB, and are defined by the
particular UNIX implementation. C-Kermit determines which speeds are
available on your system based on whether symbols for them are defined in your
terminal device header files. EXTA is generally assumed to be 19200 and EXTB
38400, but these assumptions might be wrong, or they might not apply to a
particular device that does not support these speeds. Presumably, if you try
to set a speed that is not legal on a particular device, the driver will
return an error, but this can not be guaranteed.
On these systems, it is usually not possible to select a speed of 14400 bps
for use with V.32bis modems. In that case, use 19200 or 38400 bps, configure
your modem to lock its interface speed and to use RTS/CTS flow control, and
tell C-Kermit to SET FLOW RTS/CTS and SET DIAL SPEED-MATCHING OFF.
Some versions of UNIX, and/or terminal device drivers that come with
certain third-party add-in high-speed serial communication interfaces, use the
low "baud rates" to stand for higher ones. For example, SET SPEED 50 gets you
57600 bps; SET SPEED 75 gets you 76800; SET SPEED 110 gets 115200.
SCO ODT 3.0 is an example where a "baud-rate-table patch" can be applied that
can rotate the tty driver baud rate table such that 600=57600 and 1800=115k
baud. Similarly for Digiboard multiport/portservers, which have a
"fastbaud" setting that does this.
The situation is similar, but different, in System V. SVID Third Edition
lists the same speeds, 0 through 38400.
More modern UNIXes support POSIX-based speed setting, in which the selection
of speeds is not limited by a 4-bit field. C-Kermit 6.1 incorporates a new
mechanism for finding out (at compile time) which serial speeds are supported
by the operating system that does not involve editing of source code by hand;
on systems like Solaris 5.1, IRIX 6.2, and SCO OSR5.0.4, "set speed ?" will
list speeds up to 460800 or 921600.
For further details, read the section TERMINAL SPEEDS in ckuins.doc.
(7) COMMUNICATIONS AND DIALING
The SET CARRIER-WATCH command works as advertised only if the underlying
operating system and device drivers support this feature; in particular only
if a read() operation returns immediately with an error code if the carrier
signal goes away. And, of course, if the devices themselves (e.g. modems) are
configured appropriately and the cables convey the carrier signal, etc.
In version 6.1, C-Kermit makes a lot of explicit checks for the Carrier Detect
signal, and so catches hung-up connections much better than 6.0 and earlier.
However, it still can not be guaranteed to catch every ever CD on-to-off
transition. For example, when the HP-UX version of C-Kermit is in CONNECT
mode on a dialed connection and CARRIER-WATCH ON or AUTO, and you turn off
the modem, HP-UX is stuck in a read() that never returns. (C-Kermit does not
pop back to its prompt automatically, but you can still escape back.)
If, on the other hand, you log out from the remote system, and it hangs up,
and CD drops on the local modem, C-Kermit detects this and pops back to the
prompt as it should. (Evidently there is a difference between CD and DSR
turning off at the same time, versus CD turning off while DSR stays on...)
When UNIX C-Kermit exits, it closes (and must close) the communications
device. If you were dialed out, this will most likely hang up the connection.
If you want to get out of Kermit and still use Kermit's communication device,
you have several choices:
1. Shell out from Kermit or suspend Kermit, and refer to the device literally
(as in "term -blah -blah < /dev/cua > /dev/cua").
2. Shell out from Kermit and use the device's file descriptor which Kermit
makes available to you in the \v(ttyfd) variable.
3. Use C-Kermit's REDIRECT command. See the ckermit2.upd file about this.
If you are having trouble dialing:
1. Make sure the dialout line is configured correctly. More
about this below.
2. Make sure all necessary patches are installed for your operating
system.
3. If you can't dial on a "bidirectional" line, then configure it for
outbound-only (remove the getty) and try again. (The mechanisms -- if
any -- for grabbing bidirectional lines for dialout vary wildly
among UNIX implementations and releases, and C-Kermit -- which runs on
well over 300 different UNIX variations -- makes no effort to keep up
with them; the recommended method for coping with this situation is to
wrap C-Kermit in a shell script that takes the appropriate actions.)
4. Make sure C-Kermit's SET DIAL and SET MODEM parameters agree with the
modem you are actually using -- pay particular attention to SET DIAL
SPEED-MATCHING.
5. Try SET DIAL HANGUP OFF before the DIAL command. Also, SET DIAL DISPLAY
ON to watch what's happening. See section 8 of ckuins.doc.
6. Read pages 50-67 of "Using C-Kermit".
7. As a last resort, don't use the DIAL command at all; SET CARRIER OFF and
CONNECT to the modem and dial interactively, or write a script program to
dial the modem.
Make sure your dialout line is correctly configured for dialing out (as
opposed to login). The method for doing this is different for each kind of
UNIX system. Consult your system documentation for configuring lines for
dialing out (for example, SUN SparcStation IPC users should read the section
"Setting up Modem Software" in the Desktop SPARC Sun System & Network
Manager's Guide; HP-9000 workstation users should consult the manual
"Configuring HP-UX for Peripherals", etc).
Symptom: DIAL works, but a subsequent CONNECT command does not. Diagnosis:
the modem is not asserting Carrier Detect (CD) after the connection is made,
or the cable does not convey the CD signal. Cure: Reconfigure the modem,
replace the cable. Workaround: SET CARRIER OFF (at least in System-V based
UNIX versions).
C-Kermit tries to use the 8th bit for data when parity is NONE, and this
generally works on real UNIX terminal (tty) devices, but it often does not
work when the UNIX system is accessed over a network via telnet or rlogin
protocols, including (in many cases) through terminal servers. For example,
an Encore computer with Annex terminal servers only gives a 7-bit path if
the rlogin protocol is selected in the terminal server but it gives the full
8 bits if the proprietary RDP protocol is used.
If file transfer does not work through a host to which you have rlogin'd,
use "rlogin -8" rather than "rlogin". If that doesn't work, tell both Kermit
programs to "set parity space".
The Encore TELNET server does not allow long bursts of input. When you have
a TELNET connection to an Encore, tell C-Kermit on the Encore to SET RECEIVE
PACKET-LENGTH 200 or thereabouts.
For Berkeley-UNIX-based systems (4.3BSD and earlier), Kermit includes code to
use LPASS8 mode when parity is none, which is supposed to allow 8-bit data and
Xon/Xoff flow control at the same time. However, as of edit 174, this code is
entirely disabled because it is unreliable: even though the host operating
system might (or might not) support LPASS8 mode correctly, the host access
protocols (terminal servers, telnet, rlogin, etc) generally have no way of
finding out about it and therefore render it ineffective, causing file
transfer failures. So as of edit 174, Kermit once again uses rawmode for
8-bit data, and so there is no Xon/Xoff flow control during file transfer or
terminal emulation in the Berkeley-based versions (4.3 and earlier, not 4.4).
Also on Berkeley-based systems (4.3 and earlier), there is apparently no way
to configure a dialout line for proper carrier handling, i.e. ignore carrier
during dialing, require carrier thereafter, get a fatal error on any attempt
to read from the device after carrier drops (this is handled nicely in System
V by manipulation of the CLOCAL flag). The symptom is that carrier loss does
not make C-Kermit pop back to the prompt automatically. This is evident on
the NeXT, for example, but not on SunOS, which supports the CLOCAL flag. This
is not a Kermit problem, but a limitation of the underlying operating system.
For example, the cu program on the NeXT doesn't notice carrier loss either,
whereas cu on the Sun does.
On certain AT&T UNIX systems equipped with AT&T modems, DIAL and HANGUP don't
work right. Workarounds: (1) SET DIAL HANGUP OFF before attempting to dial;
(2) If HANGUP doesn't work, SET LINE, and then SET LINE <device> to totally
close and reopen the device. If all else fails, SET CARRIER OFF.
C-Kermit does not contain any particular support for AT&T DataKit devices.
You can use Kermit software to dial in to a DataKit line, but C-Kermit does
not contain the specialized code required to dial out from a DataKit line. If
the UNIX system is connected to DataKit via serial ports, dialout should work
normally (e.g. set line /dev/ttym1, set speed 19200, connect, and then see the
DESTINATION: prompt, from which you can connect to another computer on the
DataKit network or to an outgoing modem pool, etc). But if the UNIX system
is connected to the DataKit network through the special DataKit interface
board, then SET LINE to a DataKit pseudodevice (such as /dev/dk031t) will not
work (you must use the DataKit "dk" or "dkcu" program instead).
In some BSD-based UNIX C-Kermit versions, SET LINE to a port that has nothing
plugged in to it with SET CARRIER ON will hang the program (as it should), but
it can't be interrupted with Ctrl-C. The interrupt trap is correctly armed,
but apparently the UNIX open() call cannot be interrupted in this case. When
SET CARRIER is OFF or AUTO, the SET LINE will eventually return, but then the
program hangs (uninterruptibly) when the EXIT or QUIT command (or, presumably,
another SET LINE command) is given. The latter is probably because of the
attempt to hang up the modem. (In edit 169, a timeout alarm was placed around
this operation.)
With SET DIAL HANGUP OFF in effect, the DIAL command might work only once,
but not again on the same device. In that case, give a SET LINE command
with no arguments to close the device, and then another SET LINE command for
the desired device. Or rebuild your version of Kermit with the -DCLSOPN
compile-time switch (see ckuins.doc).
The DIAL command says "To cancel: Type your interrupt character (normally
Ctrl-C)." This is just one example of where program messages and
documentation assume your interrupt character is Ctrl-C. But it might be
something else. In most (but not necessarily all) cases, the character
referred to is the one that generates the SIGINT signal. If Ctrl-C doesn't
act as an interrupt character for you, type the Unix command "stty -a" or
"stty all" or "stty everything" to see what your interrupt character is.
(Kermit could be made to find out what the interrupt character is, but this
would require a lot of system-dependent coding and #ifdefs, and a new routine
and interface between the system-dependent and system-independent parts of the
program.)
In general, the hangup operation on a serial communication device is prone
to failure. C-Kermit tries to support many, many different kinds of
computers, and there seems to be no portable method for hanging up a modem
connection (i.e. turning off the RS-232 DTR signal and then turning it back on
again). If HANGUP, DIAL, and/or Ctrl-\H do not work for you, and you are a
programmer, look at the tthang() function in ckutio.c and see if you can add
code to make it work correctly for your system, and send the code to the
address above. (NOTE: This problem has been largely sidestepped as of edit
188, in which Kermit first attempts to hang up the modem by "escaping back"
via +++ and then giving the modem's hangup command, e.g. ATH0, when DIAL
MODEM-HANGUP is ON, which is the default setting.)
Even when Kermit's modem-control software is configured correctly for your
computer, it can only work right if your modem is also configured to assert
the CD signal when it is connected to the remote modem and to hang up the
connection when your computer drops the DTR signal. So before deciding Kermit
doesn't work with your modem, check your modem configuration AND the cable (if
any) connecting your modem to the computer -- it should be a straight-through
modem cable conducting the signals FG, SG, TD, RD, RTS, CTS, DSR, DTR, CD,
and RI.
Many UNIX systems keep aliases for dialout devices; for example, /dev/acu
might be an alias for /dev/tty00. But most of these UNIX systems also use
UUCP lockfile conventions that do not take this aliasing into account, so if
one user assigns (e.g.) /dev/acu, then another user can still assign the same
device by referring to its other name. This is not a Kermit problem --
Kermit must follow the lockfile conventions used by the vendor-supplied
software (cu, tip, uucp).
The SET FLOW-CONTROL KEEP option should be given *before* any communication
(dialing, terminal emulation, file transfer, INPUT/OUTPUT/TRANSMIT, etc) is
attempted, if you want C-Kermit to use all of the device's preexisting
flow-control related settings. The default flow-control setting is XON/XOFF,
and it will take effect when the first communication-related command is given,
and a subsequent SET FLOW KEEP command will not necessarily know how to
restore *all* of the device's original flow-control settings.
(8) HARDWARE FLOW CONTROL
SET FLOW RTS/CTS is available in UNIX C-Kermit only when the underlying
operating system provides an Application Program Interface (API) for turning
this feature on and off under program control, which turns out to be a rather
rare feature among UNIX systems. To see if your UNIX C-Kermit version
supports hardware flow control, type "set flow ?" at the C-Kermit prompt, and
look for "rts/cts" among the options. Other common situations include:
1. The API is available, so "set flow rts/cts" appears as a valid C-Kermit
command, but it doesn't do anything because the device driver (part of
the operating system) was never coded to do hardware flow control. This
is common among System V R4 implementations (details below).
2. The API is not available, so "set flow rts/cts" does NOT appear as a valid
C-Kermit command, but you can still get RTS/CTS flow control by selecting
a specially named device in your SET LINE command. Examples:
NeXTSTEP: /dev/cufa instead of /dev/cua, /dev/cufb instead of /dev/cub
(68040 only; "man zs" for further info).
IRIX: /dev/ttyf2 instead of /dev/ttyd2 or /dev/ttym2 ("man 7 serial").
3. The API is available, doesn't work, but a workaround as in (2) can be used.
4. The API is available, but Kermit doesn't know about it. In these cases,
you can usually use an stty command to enable RTS/CTS on the device, e.g.
"stty crtscts" or "stty ctsflow", "stty rtsflow", before starting Kermit,
and then tell Kermit to SET FLOW KEEP.
5. No API and no special device drivers. Hardware flow control is completely
unavailable.
System V R4 based UNIXes are supposed to supply a <termiox.h> file, which
gives Kermit the necessary interface to command the terminal driver to
enable/disable hardware flow control. Unfortunately, but predictably, many
implementations of SVR4 whimsically place this file in /usr/include/sys rather
than /usr/include (where SVID clearly specifies it should be; see SVID, Third
Edition, V1, termiox(BA_DEV). Thus if you build C-Kermit with any of the
makefile entries that contain -DTERMIOX or -DSTERMIOX (the latter to select
<sys/termiox.h>), C-Kermit will have "set flow rts/cts" and possibly other
hardware flow-control related commands. BUT... That does not necessarily
mean that they will work. In some cases, the underlying functions are simply
not coded into the operating system.
(9) TERMINAL CONNECTION AND KEY MAPPING
UNIX C-Kermit is not a terminal emulator. Refer to page 147 of "Using
C-Kermit", 2nd Edition: "Most versions of C-Kermit -- UNIX, VMS, AOS/VS, VOS,
etc -- provide terminal connection without emulation. These versions act as a
'semitransparent pipe' between the remote computer and your terminal, terminal
emulator, console driver, or window, which in turn emulates (or is) a specific
kind of terminal." The environment in which you run C-Kermit is up to you.
If you are an X Windows user, you should be aware of an alternative to xterm
that supports VT220 emulation, from Thomas E. Dickey:
http://www.clark.net/pub/dickey/xterm/xterm.faq.html
UNIX C-Kermit's SET KEY command currently can not be used with keys that
generate "wide" scan codes or multibyte sequences, such as workstation
function or arrow keys, because UNIX C-Kermit does not have direct access to
the keyboard.
However, many UNIX workstations and/or console drivers provide their own key
mapping feature. With xterm, for example, you can use 'xmodmap' ("man
xmodmap" for details); here is an xterm mapping to map the Sun keyboard to DEC
VT200 values for use with VT-terminal oriented applications like VMS EVE:
keycode 101=KP_0
keycode 119=KP_1
keycode 120=KP_2
keycode 121=KP_3
keycode 98=KP_4
keycode 99=KP_5
keycode 100=KP_6
keycode 75=KP_7
keycode 76=KP_8
keycode 77=KP_9
keycode 52=KP_F1
keycode 53=KP_F2
keycode 54=KP_F3
keycode 57=KP_Decimal
keycode 28=Left
keycode 29=Right
keycode 30=KP_Separator
keycode 105=KP_F4
keycode 78=KP_Subtract
keycode 8=Left
keycode 10=Right
keycode 32=Up
keycode 33=Down
keycode 97=KP_Enter
Users of Linux consoles can use loadkeys ("man dumpkeys loadkeys keytables"
for details. The format used by loadkeys is compatible with that used by
Xmodmap, although it is not definitely certain that the keycodes are
compatible for different keyboard types (e.g. Sun vs HP vs PC, etc).
(10) FILE TRANSFER
UNIX C-Kermit does not reject incoming files on the basis of size. There
appears to be no good (reliable, portable) way to determine in advance how
much disk space is available, either on the device, or (when quotas or other
limits are involved) to the user.
File transfer might fail if the incoming file is bigger than your "ulimit".
Use the UNIX ulimit command to examine or change your ulimit (the number is
in 512-byte blocks, i.e. 0.5K). The exact effect of the ulimit depends on
the particular UNIX version, and to some extent probably also on the shell.
"man ulimit" for details, or read the man page for the shell you are using.
UNIX C-Kermit discards all carriage returns from incoming files when in text
mode.
If C-Kermit has problems creating files in writable directories when it is
installed setuid or setgid on BSD-based versions of UNIX such as NeXTSTEP 3.0,
it probably needs to be rebuilt with the -DSW_ACC_ID compilation switch (see
ckuins.doc).
If C-Kermit is receiving a file on a dialup connection and the connection
hangs up, the SIGHUP signal is delivered to the top-level shell, which kills
all processes (including Kermit and any of its subforks) and closes all open
files, including the file that was being received. Even if you have told
Kermit to SET FILE INCOMPLETE DISCARD, the partially received file is kept.
See comments in ckutio.c (search for SIGHUP) for details.
If you SET FILE DISPLAY FULLSCREEN, and C-Kermit complains "Sorry, terminal
type not supported", it means that the terminal library (termcap or termlib)
that C-Kermit was built with does not know about a terminal whose name is the
current value of your TERM environment variable. If this happens, but you
want to have the fullscreen file transfer display, EXIT from C-Kermit and set
a UNIX terminal type from among the supported values that is also supported by
your terminal emulator, or else have an entry for your terminal type added to
the system termcap and/or terminfo database.
If you attempt to suspend C-Kermit during local-mode file transfer and then
continue it in the background (via bg), it will block for "tty output" if
you are using the FULLSCREEN file transfer display. This is apparently
a problem with curses. Moving a local-mode file transfer back and forth
between foreground and background works correctly, however, with the SERIAL,
CRT, BRIEF, or NONE file transfer displays.
If C-Kermit's command parser no longer echoes, or otherwise acts strangely,
after returning from a file transfer with the fullscreen (curses) display,
and your version of UNIX is based on AT&T System V, then try rebuilding your
version of C-Kermit with -DCK_NEWTERM. Similarly if it echoes doubly, which
might even happen during a subsequent CONNECT session. If rebuilding with
-DCK_NEWTERM doesn't fix it, then there is something very strange about your
system's curses library, and you should probably not use it. Tell C-Kermit
to SET FILE DISPLAY CRT or anything else other than FULLSCREEN, and/or rebuild
without -DCK_CURSES, and without linking with (termlib and) curses.
It has been observed on a couple platforms -- e.g. BSDI and QNX -- that the
curses display works properly only once. The second and subsequent times, the
display is a mess. The reason is unknown, the cure is unknown. See the
comments in screenc() in ckuusx.c. In one other case (one of the Linux
distributions), this problem was cured by linking to a different curses
library (ncurses rather than curses).
Reportedly, when using "MSEND *" from a 14-character filename UNIX system to
another system (e.g. BSD) that allows longer names, with SET FILE NAMES
LITERAL, any files with 14-character names will have a space added to the end
of the name on the receiving machine (this *should* be fixed in 6.0).
Optimum file transfer performance is a matter of tuning parameters like packet
length, window size, control-character unprefixing, and on serial connections,
ensuring there is an effective flow control method, preferably hardware (such
as RTS/CTS).
However, a fully-configured C-Kermit program can be slower than a minimally
configured one simply because of its size. A command-line-only version that
is stripped of every conceivable feature not affecting file transfer (such as
"sunos41m" for the Sun or "dellsys5r4m" for Dell) can move files faster than a
full-featured one. Thus, it might make sense to keep a minimal version
available as well as a full-featured one. See the files ckuins.doc and
ckccfg.doc as well as the makefile for how to do this.
A fairly substantial reduction in size and a noticeable improvement in speed
can be obtained simply by rebuilding C-Kermit without the debugging feature:
make <entryname> KFLAGS=-DNODEBUG
See ckccfg.doc for more detailed information about configuration.
(11) EXTERNAL FILE TRANSFER PROTOCOLS
UNIX C-Kermit can be used in conjunction with other communications software
in various ways. C-Kermit can be invoked from another communications program
as an "external protocol", and C-Kermit can also invoke other communication
software to perform external protocols.
This sort of operation makes sense only when you are dialing out from your
UNIX system. If the UNIX system is the one you have dialed in to, you don't
need any of these tricks. Just run the desired software on your UNIX system
instead of Kermit. When dialing out from a UNIX system, the difficulty is
getting two programs to share the same communication device in spite of the
UNIX UUCP lockfile mechanism, which would normally prevent any sharing, and
preventing the external protocol from closing (and therefore hanging up) the
device when it exits back to the program that invoked it.
(This section deleted; see "Using C-Kermit", 2nd Ed, Chapter 14.)
"pcomm" is a general-purpose terminal program that provides file transfer
capabilities itself (X- and YMODEM variations) and the ability to call on
external programs to do file transfers (ZMODEM and Kermit, for example). You
can tell pcomm the command to send or receive a file with an external
protocol:
send receive
ZMODEM sz <filename> rz
Kermit kermit -s <filename> kermit -r
pcomm runs external programs for file transfer by making stdin and stdout
point to the modem port, and then exec-ing "/bin/sh -c xxx" (where xxx is the
appropriate command). However, C-Kermit does not treat stdin and stdout as
the communication device unless you instruct it:
send receive
Kermit kermit -l 0 -s <filename> kermit -l 0 -r
The "-l 0" option means to use file descriptor 0 for the communication device.
In general, any program can pass any open file descriptor to C-Kermit for the
communication device in the "-l" command-line option. When Kermit is given
a number as the argument to the "-l" option, it simply uses it as a file
descriptor, and it does not attempt to close it upon exit.
Here's another example, for Seyon (a Linux communication program). First try
the technique above. If that works, fine; otherwise... If Seyon does not
give you a way to access and pass along the file descriptor, but it starts up
the Kermit program with its standard i/o redirected to its (Seyon's)
communications file descriptor, you can also experiment with the following
method, which worked here in brief tests on SunOS. Instead of having Seyon
use "kermit -r" or "kermit -s filename" as its Kermit protocol commands, use
something like this (examples assume C-Kermit 6.0):
For serial connections:
kermit -YqQl 0 -r <-- to receive
kermit -YqQl 0 -s filename(s) <-- to send one or more files
For Telnet connections:
kermit -YqQF 0 -r <-- to receive
kermit -YqQF 0 -s filename(s) <-- to send one or more files
Command line options:
Y - skip executing the init file
Q - use fast file transfer settings
l 0 - transfer files using file descriptor 0 for a serial connection
F 0 - transfer files using file descriptor 0 for a Telnet connection
q - quiet - no messages
r - receive
s - send
(11.2) INVOKING EXTERNAL PROTOCOLS FROM C-KERMIT
(This section is obsolete, but not totally useless.
See Chapter 14 of "Using C-Kermit", 2nd Edition).
After you have opened a communication link with C-Kermit's SET LINE (SET PORT)
or SET HOST (TELNET) command, C-Kermit makes its file descriptor available to
you in the \v(ttyfd) variable so you can make it available to other programs
that you RUN from C-Kermit. Here, for example, C-Kermit runs itself as an
external protocol:
C-Kermit>set modem type hayes
C-Kermit>set line /dev/acu
C-Kermit>set speed 2400
C-Kermit>dial 7654321
Call complete.
C-Kermit>echo \v(ttyfd)
3
C-Kermit>run kermit -l \v(ttyfd)
Other programs that accept open file descriptors on the command line can be
started in the same way.
You can also use your shell's i/o redirection facilities to assign C-Kermit's
open file descriptor (ttyfd) to stdin or stdout. For example, old versions of
the UNIX ZMODEM programs, sz and rz, when invoked as external protocols,
expect to find the communication device assigned to stdin and stdout with no
option for specifying any other file descriptor on the sz or rz command line.
However, you can still invoke sz and rz as exterior protocols from C-Kermit if
your current shell ($SHELL variable) is ksh (the Korn shell) or bash (the
Bourne-Again shell), which allows assignment of arbitrary file descriptors to
stdin and stdout:
C-Kermit> run rz <&\v(ttyfd) >&\v(ttyfd)
or:
C-Kermit> run sz oofa.zip <&\v(ttyfd) >&\v(ttyfd)
In version 5A(190) and later, you can use C-Kermit's REDIRECT command, if it
is available in your version of C-Kermit, to accomplish the same thing without
going through the shell:
C-Kermit> redirect rz
or:
C-Kermit> redirect sz oofa.zip
A complete set of rz,sz,rb,sb,rx,sx macros for UNIX C-Kermit is defined in
the file ckurzsz.ini. It automatically chooses the best redirection method.
(11.3) USING C-KERMIT WITH TERM
Note: the following section dates from circa 1994. Since then,
evidently, "slirp" has supplanted "term", and reportedly, unlike
term, slirp can be used transparently to the application:
http://blitzen.canberra.edu.au/resources
The "term" program provides an error-corrected, multiplexed connection
between two UNIX systems, allowing you to run multiple applications over a
single connection, for example several terminal windows and a file transfer
simultaneously. Term depends on a communications application (such as
C-Kermit) to make the connection and then redirect it to term's standard i/o.
The advantages of using C-Kermit rather than other communication programs for
this include:
. C-Kermit's script language lets you automate the entire process.
. With C-Kermit's REDIRECT command, term sessions are not limited to serial
connections, but can work over network connections (TCP/IP, X.25) too.
Here is an example showing how to set up a term session between two UNIX
systems with C-Kermit (assuming the connection has already been made by
C-Kermit, e.g. by dialing up):
C-Kermit> connect
login: xxx
Password: xxx
$ exec term -r -s 38400 -A
^\c (escape back)
C-Kermit>redirect term -s 38400 -A &
C-Kermit>push ; or "suspend"
$
Now you can run term clients such as trsh and tupload at the local shell
prompt.
(12) SECURITY
We receive constant requests for versions of C-Kermit that use all sorts of
security mechanisms: SOCKS, SSL, SSH, SSLeay, TSL, PCT, SRP, etc etc. Well...
(a) C-Kermit can be linked with a SOCKS library if you have one; see
ckccfg.doc, section 8.1.1.
(b) Most of the others require export or import licenses, carry source-code
restrictions, and/or are patented.
HOWEVER...
(c) C-Kermit 6.1 includes support for Kerberos; see kerberos.txt for details.
(d) It also has a new feature to let it be used "over" secure clients like
SSL Telnet, SRP Telnet, etc. See ckermit2.upd Section 2.7 for details.
(13) MISCELLANEOUS USER REPORTS
Date: Thu, 12 Mar 92 1:59:25 MEZ
From: Walter Mecky <walter@rent-a-guru.de>
Subject: Help.Unix.sw
To: svr4@pcsbst.pcs.com, source@usl.com
PRODUCT: Unix
RELEASE: Dell SVR4 V2.1 (is USL V3.0)
MACHINE: AT-386
PATHNAME: /usr/lib/libc.so.1
/usr/ccs/lib/libc.a
ABSTRACT: Function ttyname() does not close its file descriptor
DESCRIPTION:
ttyname(3C) opens /dev but never closes it. So if it is called
often enough the open(2) in ttyname() fails. Because the broken
ttyname() is in the shared lib too all programs using it can
fail if they call it often enough. One important program is
uucico which calls ttyname for every file it transfers.
Here is a little test program if your system has the bug:
#include <stdlib.h>
#include <stdio.h>
main() {
int i = 0;
while (ttyname(0) != NULL)
i++;
perror("ttyname");
printf("i=%d\n", i);
}
If this program runs longer than some seconds you don't have the bug.
WORKAROUND:
None
FIX:
Very easy if you have source code.
Another user reports some more explicit symptoms and recoveries:
> What happens is when invoking ckermit we get one of the following
> error messages:
> You must set line
> Not a tty
> No more processes.
> One of the following three actions clears the peoblem:
> shutdown -y -g0 -i6
> kill -9 the ttymon with the highest PID
> Invoke sysadm and disable then enable the line you want to use.
> Turning off respawn of sac -t 300 and going to getty's and uugetty's
> does not help.
>
> Also C-Kermit reports "?timed out closing /dev/ttyxx".
> If this happens all is well.
------------------------------
(Note: the following problem also occurs on SGI and probably many other
UNIX systems):
From: James Spath <spath@jhunix.hcf.jhu.edu>
To: Info-Kermit-Request@cunixf.cc.columbia.edu
Date: Wed, 9 Sep 1992 20:20:28 -0400
Subject: C-Kermit vs uugetty (or init) on Sperry 5000
We have successfully compiled the above release on a Unisys/Sperry 5000/95. We
used the sys5r3 option, rather than sys5r2 since we have VR3 running on our
system. In order to allow dialout access to non-superusers, we had to do
"chmod 666 /dev/tty###", where it had been -rw--w--w- (owned by uucp), and to
do "chmod +w /usr/spool/locks". We have done text and binary file transfers
through local and remote connections.
The problem concerning uucp ownership and permissions is worse than I thought
at first. Apparently init or uugetty changes the file permissions after each
session. So I wrote the following C program to open a set of requested tty
lines. I run this for any required outgoing line prior to a Kermit session.
------ cut here -------
/* opentty.c -- force allow read on tty lines for modem i/o */
/* idea from: restrict.c -- System 5 Admin book Thomas/Farrow p. 605 */
/* /jes jim spath {spath@jhunix.hcj.jhu.edu } */
/* 08-Sep-92 NO COPYRIGHT. */
/* this must be suid to open other tty lines */
/* #define DEBUG */
#define TTY "/dev/tty"
#define LOK "/usr/spool/locks/LCK..tty"
#include <stdio.h>
/* allowable lines: */
#define TOTAL_LINES 3
static char allowable[TOTAL_LINES][4] = { "200", "201", "300" };
static int total=TOTAL_LINES;
int allow;
/* states: */
#define TTY_UNDEF 0
#define TTY_LOCK 1
#define TTY_OKAY 2
main(argc, argv)
int argc; char *argv[]; {
char device[512];
char lockdev[512];
int i;
if (argc == 1) {
fprintf(stderr, "usage: open 200 [...]\n");
}
while (--argc > 0 && (*++argv) != NULL ) {
#ifdef DEBUG
fprintf(stderr, "TRYING: %s%s\n", TTY, *argv);
#endif
sprintf(device, "%s%s", TTY, *argv);
sprintf(lockdev, "%s%s", LOK, *argv);
allow = TTY_UNDEF; i = 0;
while (i <= total) { /* look at all defined lines */
#ifdef DEBUG
fprintf(stderr, "LOCKFILE? %s?\n", lockdev);
#endif
if (access(lockdev, 00) == 0) {
allow=TTY_LOCK;
break;
}
#ifdef DEBUG
fprintf(stderr, "DOES:%s==%s?\n", allowable[i], *argv);
#endif
if (strcmp(allowable[i], *argv) == 0)
allow=TTY_OKAY;
i++;
}
#ifdef DEBUG
fprintf(stderr, "allow=%d\n", allow);
#endif
switch (allow) {
case TTY_UNDEF:
fprintf (stderr, "open: not allowed on %s\n", *argv);
break;
case TTY_LOCK:
fprintf (stderr, "open: device locked: %s\n", lockdev);
break;
case TTY_OKAY:
/* attempt to change mode on device */
if (chmod (device, 00666) < 0)
fprintf (stderr, "open: cannot chmod on %s\n", device);
break;
default:
fprintf (stderr, "open: FAULT\n");
}
}
exit (0);
}
------------------------------
(14) THIRD-PARTY DRIVERS
UNIX versions, especially those for PCs (SCO, Unixware, etc) might be
augmented by third-party communication-board drivers from Digiboard, Stallion,
etc. These can sometimes complicate matters for Kermit considerably since
Kermit has no way of knowing that it is going through a possibly nonstandard
driver. Various examples are listed in the earlier sections of this file;
search for Stallion, Digiboard, etc. Additionally:
. The Stallion Technologies EasyConnection serial board driver does not
always report the state of DSR as low. From Stallion (October 1997):
"Unfortunately, this is a bug in our driver. We have implemented all of the
other TIOMC functions, eg DTR, DCD, RTS and CTS, but not DSR. Our driver
should report the actual state of DSR on those of our cards that have a DSR
signal. That the driver always reports DSR as not asserted (0), is a bug in
the driver. The driver should be either reporting the state of DSR
correctly on those cards that support DSR or as always asserted (1) on
those cards that do not have a DSR signal. This will be fixed in a future
version of our drivers; at this time I cannot say when this will be." And
later, "As far as I can tell, we don't support the termios/termiox ioctls
that relate specifically to DSR and RI; all the rest are supported. This
will, as I mentioned earlier, be fixed in the next release of our ATA
software." - World Wide Escalation Support, Stallion Technologies,
Toowong QLD, support@stallion.oz.au.
Later (December 1997, from the same source):
. We have now released a new version of the ATA software, version 5.4.0.
This version fixes the problem with the states of the DSR and RI
signals and how they were being reported by the driver. This is the
problem that you reported in October. The DSR signal is reported
correctly on those cards that support the DSR signal, such as the early
revision of the EasyIO card and the EasyConnection 8D4 panel, and as
always asserted on those cards that do not support the DSR signal in
the hardware. The new driver is available from our Web site,
www.stallion.com, in the /drivers/ata5/UnixWare directory.
(End of CKUKER.BWR)
|