home *** CD-ROM | disk | FTP | other *** search
/ kermit.columbia.edu / kermit.columbia.edu.tar / kermit.columbia.edu / bin / mstibm.zip / NETWORKS / SETUP.DOC < prev    next >
Text File  |  1995-06-08  |  66KB  |  1,469 lines

  1. File NETWORKS\SETUP.DOC                           January 1995
  2.  
  3. SETTING UP YOUR PC FOR MS-DOS KERMIT NETWORKING
  4.  
  5. Applies to:  MS-DOS Kermit 3.14
  6. Authors:     Joe R. Doupnik, Utah State University
  7.          Frank da Cruz, Columbia University
  8.  
  9. Last updated: Wed May 31 09:45:25 1995
  10.  
  11. ABSTRACT
  12.  
  13. Applying mainly to TCP/IP, but with some discussion of STARLAN, etc, this file
  14. concentrates on the low-level network configuration of your PC, network board
  15. interface standards, drivers and shims, Windows, memory management, TCP/IP
  16. configuration, and how to get MS-DOS Kermit working on your network.
  17.  
  18. CHAPTER 0. GENERAL PRINCIPLES
  19.  
  20. Specific Network Boards:
  21.  
  22.   Kermit does not support specific network boards.  It speaks to network
  23.   boards only through interpreters known as drivers, and only those drivers
  24.   that present certain standard interfaces to the application (Kermit).
  25.  
  26. The Zeroth Law of Kermodynamics (pay attention):
  27.  
  28.   ONLY ONE PROTOCOL STACK OF A GIVEN KIND PER NETWORK BOARD.
  29.  
  30. Corollary:
  31.  
  32.   Only one TCP/IP-based application can use a LAN adapter at a time.
  33.  
  34. Some applications of this principle:
  35.  
  36.   You can't run Kermit's TCP/IP stack at the same time as (for example):
  37.   . LAN Workplace for DOS (LWP) (but Kermit can run over it)
  38.   . PC/TCP            (but Kermit can run over it)
  39.   . PC NFS
  40.   . Trumpet Winsock
  41.   . etc etc etc
  42.  
  43. Brief explanation: The board driver has little slots for each "protocol", such
  44. as IP, ARP, IPX, LAT, etc, one slot for each.  Each slot identifies the
  45. application that is using the given protocol on the board.  Now, the network
  46. packets also contain protocol types.  So if (say) an IP packet comes in, the
  47. driver looks up IP in its protocol slots, sees who owns it, and gives the
  48. packet to that application.  There is only one slot per protocol.
  49.  
  50. This is good because it allows multiple protocols to be active at once,
  51. for example IPX and TCP/IP (this is why Kermit can, say, transfer a file from
  52. a NetWare disk to a UNIX computer via TCP/IP, when the NetWare server and the
  53. UNIX system are both being accessed by Kermit at the same time through the
  54. same Ethernet board).
  55.  
  56. But... if you need to run multiple TCP/IP applications, i.e. different
  57. applications that use the *same* protocol, you'll have to unload one before
  58. you can start the other.  For example, you can't make a TCP/IP connection
  59. with Kermit to transfer a file from an NFS-mounted disk.
  60.  
  61. If you need to run them simultaneously, then you have the following choices:
  62.  
  63.  . Install a second network board (recommended) (really, they're cheap).
  64.  . Tell one, if possible, to use the other's TCP/IP stack for transport.
  65.    More about this later on.
  66.  . Look into something called PKTMUX, but please don't ask us about it.
  67.    We don't support it or recommend it.     But if it works for you, fine.
  68.    (We don't denigrate it either -- it is a heroic attempt at dealing
  69.    with the limitations of the PC platform, but it is very complicated,
  70.    and a short glance at the warnings and disclaimers at the beginning
  71.    of the manual will scare away all but the most courageous.)
  72.  
  73. Note, by the way, that TCP, UDP, and ICMP are not "protocols" at this level.
  74. The network driver software never sees them because they are encapsulated
  75. inside IP packets.
  76.  
  77. CHAPTER 1.  NETWORK DRIVERS USABLE BY KERMIT
  78.  
  79. MS-DOS Kermit 3.11 and later contains an extremely compact and fast built-in
  80. TCP/IP protocol implementation, including TELNET protocol, designed to run
  81. over any of the following types of network board drivers:
  82.  
  83.  1. A packet driver of the ETHERNET (1) or SLIP (6) class.
  84.  2. An ODI driver.
  85.  3. The Novell SLIP_PPP driver.
  86.  4. The Telebit PPP driver.
  87.  
  88. (1.1) PACKET DRIVERS
  89.  
  90. These provide a somewhat uniform interface between a wide variety of network
  91. boards and the application.  However, the application still must be aware of
  92. which kind of network technology is being used -- Ethernet, Token Ring,
  93. Arcnet, SLIP, etc.  Kermit knows about Ethernet and SLIP.  In order to use
  94. Kermit with a packet driver over some other kind of network board, such as
  95. Token Ring or Arcnet, you need an "Ethernet simulation" packet driver -- i.e.
  96. one that converts between its own networking method and Ethernet, tricking
  97. Kermit into thinking it has an Ethernet board.
  98.  
  99. The packet driver should be loaded in conventional memory from AUTOEXEC.BAT,
  100. or by hand when you need to use it.
  101.  
  102. The packet driver works as an extension of the application program, since they
  103. share the same memory.    To send a packet, the application puts it in a buffer,
  104. tells the packet driver where the buffer is, and tells it to send it.  The
  105. packet driver returns some kind of completion code.  When packets arrive from
  106. the outside, the packet driver gets an interrupt from the device, takes over
  107. the CPU, asks the application for a buffer, and copies the incoming data from
  108. the device to the buffer, and then taps the application on the shoulder to 
  109. let it know that the packet has arrived.  There are several incompatible
  110. "classes" of packet drivers: 1 (Ethernet), 2 (ProNet), 3 (Token Ring), ...,
  111. 5 (Appletalk), 6 (Serial Line), etc.  Kermit supports classes 1 and 6.
  112.  
  113. Packet drivers are usually provided with each network board by the vendor.
  114. There are also some free packet drivers (Cyrnwr Collection being the best
  115. known), including the one supplied on the Kermit disk for SLIP. 
  116.  
  117. This discussion has neglected what happens under Microsoft Windows, which is
  118. postponed until later.    If you need to use Kermit to make TCP/IP connections
  119. from within Windows, don't forget to read CHAPTER 3: WINDOWS.
  120.  
  121. (1.2) ODI DRIVERS
  122.  
  123. ODI is Novell's Open Datalink Inteface, providing a uniform way for the
  124. application to talk to the network board, independent of which networking
  125. method it uses: Ethernet, Token Ring, etc.  MS-DOS Kermit supports this method
  126. directly.  That is, it talks directly to the ODI driver.
  127.  
  128. Direct use of ODI drivers permits Kermit's TCP/IP to run with several kinds of
  129. Ethernet frames: DIX/Blue-Book/Ethernet_II, Token Ring, Arcnet, and PCLan
  130. broadband.  No extra protocol "shim" is needed, but you must have ODI drivers
  131. from Novell or your network board vendor.
  132.  
  133. The mechanics are roughly the same as for packet drivers.  The driver
  134. configuration, however, is done differently.  Rather than feeding command-line
  135. parameters to the driver, a file called NET.CFG is created to give certain
  136. information not only to the driver, but also to the applications that use it.
  137.  
  138. ODI drivers generally come on a diskette packaged with your network board.
  139. Novell supplied drivers and ODI components are available from Compuserve
  140. and across the Internet from ftp.novell.com and its official mirror sites:
  141.  
  142.   BNUG FTP server, bnug.proteon.com [128.185.17.201]
  143.   University of Groningen, ftp.rug.nl [129.125.4.15]
  144.   University of Salford, ftp.salford.ac.uk [146.87.0.201]
  145.   Utah State University, netlab2.usu.edu [129.123.1.44],
  146.    netlab1.usu.edu [129.123.1.43]
  147.   Lincoln University, tui.lincoln.ac.nz [138.75.80.3]
  148.   National Research Council (Canada), novell.nrc.ca [132.246.160.4]
  149.  
  150. Example Ethernet NET.CFG file, using VLMs in this case
  151.  
  152. ; File NET.CFG for NW 4.0 and for VLMs
  153. ; Don't forget to say  lastdrive=z  in config.sys!
  154.  
  155. Netware dos requester
  156.     PB buffers=6
  157.     true commit=off        ; off=let server buffer writes
  158.     network printers=1    ; shrinks print.vlm, won't load it
  159.     average name length=24    ; shrinks connection table
  160.     load low conn=ON
  161.     load low ipxncp=ON
  162.     signature level=0    ; 0=don't load security.vlm
  163.     read only compatibility=on
  164.     first network drive=n
  165.     preferred server=edu-usu-netlab2
  166.     preferred tree=USU-TREE
  167.     name context="O=USU"
  168. ; VLM selection, order sensitive.
  169. ; For Bindery include bind and netx, omit nds.
  170. ;   Also preferred server is read for Bindery only.
  171. ; For Directory Services include nds, omit bind and netx.
  172. ;   Also preferred tree and name context are read for DS only.
  173.     use defaults=off    ; off=use explict list of vlms which follow
  174.     vlm=conn.vlm        ; Connection tables
  175.     vlm=ipxncp.vlm        ; NCP over IPX
  176.     vlm=tran.vlm        ; Transport services worker
  177.     vlm=security.vlm    ; Security, optional
  178. ;     vlm=nds.vlm        ; DS, NCP Directory Services
  179.     vlm=bind.vlm        ; Bindery, NCP
  180.     vlm=nwp.vlm        ; Transport services worker
  181.     vlm=fio.vlm        ; File i/o
  182.     vlm=general.vlm        ; General support routines
  183.     vlm=redir.vlm        ; Redirector
  184.     vlm=print.vlm        ; Print services, optional
  185.     vlm=netx.vlm        ; Bindery, shell compatibility
  186. ;    vlm=rsa.vlm        ; DS, RSA encryption, optional
  187. ;    vlm=auto.vlm        ; DS, autoreconnect/retry, optional
  188. ;    vlm=nmr.vlm        ; Managment responder, optional
  189.  
  190. Netx
  191.     show dots=on
  192.  
  193. ;# Below this line material is the same as for NetWare 3.x and for NETX
  194.  
  195. protocol KERMIT
  196.     bind ne2000
  197.  
  198. Link Support
  199.     Buffers    6 1600
  200.     MemPool    2048
  201.  
  202. Link Driver NE2000
  203.     INT 5
  204.     PORT 360
  205.     FRAME    Ethernet_II
  206.     Protocol IPX    8137    Ethernet_II
  207.     Protocol IP    0800    Ethernet_II
  208.     Protocol ARP    0806    Ethernet_II
  209.     Protocol RARP    8035    Ethernet_II
  210.  
  211. Please notice several things about this file. Items must be spelled as shown,
  212. indented items must be indented (with a tab for SMC drivers), and flush left
  213. items must be flush left. There is no, none, zero, creativity permitted in
  214. this material, and that applies especially to the indented protocol lines.
  215. IP is not IPX, so don't get them mixed up.  Please type carefully.
  216.  
  217. Ethernet clients must use Ethernet_II frames for TCP/IP work (IP, ARP, and
  218. RARP).    Token Ring clients will use TOKEN-RING_SNAP for the frame kind with
  219. IP, ARP, and RARP.  The protocol ident values are the same as above.
  220.  
  221. LINK DRIVER TOKEN
  222.      INT 3
  223.      FRAME TOKEN-RING
  224.      FRAME TOKEN-RING_SNAP
  225.      PROTOCOL IPX  E0    TOKEN-RING
  226.      Protocol IP   0800 TOKEN-RING_SNAP
  227.      Protocol ARP  0806 TOKEN-RING_SNAP
  228.      Protocol RARP 8035 TOKEN-RING_SNAP
  229.  
  230. Arcnet clients will use NOVELL_RX-NET for the frame kind, and the protocol
  231. ident values will be D4 for IP, D5 for ARP, and D6 for RARP, rather than 0800
  232. etc, as per RFC-1201.
  233.  
  234. LINK DRIVER SMCARCWS
  235.      INT 3
  236.      PORT 300
  237.      MEM D0000
  238.      Frame NOVELL_RX-NET
  239.      Protocol IPX  FA NOVELL_RX-NET
  240.      Protocol IP   D4 NOVELL_RX-NET
  241.      Protocol ARP  D5 NOVELL_RX-NET
  242.      Protocol RARP D6 NOVELL_RX-NET
  243.  
  244. Which board will Kermit (or IPX or other application) use if two or more boards
  245. are available? Although one would think the board could be selected by placing
  246. the Protocol IP, etc, lines under the desired Link Driver section, such is not
  247. the case; those lines tell LSL the frame kind to associate with the protocol
  248. (say IP) but not the board.  The frame lines are associated with particular
  249. boards, however.  By default, the application chooses "the first board"
  250. offering a suitable frame, regardless of whether or not the Protocol IP, etc,
  251. lines are present for that board. "First" refers not to the contents of NET.CFG
  252. but to the order in which board drivers are loaded at DOS level.  So the
  253. indented protocol lines tell ODI which frame a protocol needs, and a TYPE to
  254. use for recognizing packets, but the lines do not identify a particular board.
  255.  
  256. To target a particular board, a separate main section is used in NET.CFG.  The
  257. section starts with the word Protocol against the left margin and has Bind
  258. indented beneath it, like this -
  259.  
  260.     Protocol Kermit            Identifies Kermit section of NET.CFG
  261.         bind SMCPLUS        Bind to SMCPLUS board driver
  262.  
  263. When a board name is used more than once then the alternative form is to use
  264. a board number in place of the name:
  265.  
  266.     Protocol Kermit
  267.         bind #2            bind to the board loaded second
  268.  
  269. Kermit considers the text in these sections to be case-insensitive.  The
  270. #<digit> construction must not have a separation between the number sign (#)
  271. and the digit. The #<digit> case is normally used when two or more boards share
  272. the same driver and thus are not distinguishable by name alone.     Note that
  273. IPXODI now can use only the #number form.
  274.  
  275. A sample STARTNET.BAT file might look like this:
  276.  
  277. @echo off            run quietly
  278. c:\lsl >nul            LSL is always loaded before boards
  279. c:\smcplus.com >nul        SMC/WD8003E board, the first
  280. c:\exos.com >nul        EXOS-205T board, the second
  281. rem c:\odinsup            Odinsup can coexist with Kermit
  282. rem c:\odipkt 0 96        Odipkt can coexist with Kermit
  283. c:\ipxodi >nul            IPX is always loaded after boards
  284. rem echo Starting network...    may be needed to help some drivers
  285. c:\bnetx ps=my-preferred-server > nul
  286. rem (Packet Burst mode)    NETX loads after IPX
  287. @echo on
  288.  
  289. If both EXOS and SMCPLUS boards offer frame Ethernet_II Kermit will choose the
  290. first loaded board, SMCPLUS, in the absence of a "bind" command.  Putting the
  291. section "Protocol Kermit, bind <board name or number>" anywhere in NET.CFG
  292. selects a particular board for Kermit.
  293.  
  294. (1.3) THE NOVELL SLIP_PPP DRIVER
  295.  
  296. Novell provides a combined SLIP/PPP async ODI board driver and separate dialer.
  297. The ODI configuration file NET.CFG needs sections as shown below to support
  298. Kermit and SLIP_PPP.
  299.  
  300. Protocol KERMIT
  301.     Bind SLIP_PPP
  302.  
  303. Link Driver SLIP_PPP
  304.     DIRECT    YES
  305.     BAUD     9600
  306.     OPEN    ACTIVE
  307. ;;    TCPIPCOMP    VJ        <<< Optional Van Jacobson compression
  308.     PCOMP    YES
  309.     ACCOMP    YES
  310.     PORT    2F8            << serial port details, COM2 here
  311.     INT    3
  312.     FRAME    SLIP            << choose SLIP or PPP, not both
  313. ;;    FRAME    PPP
  314.     Protocol IP    0800    SLIP    << required for Kermit
  315. ;;    Protocol PPP    0800    PPP    << alternative, with PPP
  316.  
  317. Dialing the phone is separate from loading the ODI components.  Once those
  318. components are loaded the phone may be dialed with Novell's Dialer program (see
  319. Netwire archives for LWP/DOS updates; archives include Compuserve,
  320. ftp.novell.com, and official mirrors such as netlab2.usu.edu).  Kermit itself
  321. can be used to dial the phone, and in many cases it can do so after SLIP_PPP is
  322. loaded (but you will need to tell Kermit the port details via "SET COM1 port
  323. irq" because SLIP_PPP will try to hide them for safety).  The remote host may
  324. say or your notes will be needed to find out the current IP number.
  325.  
  326. Further details are given in the documentation for Lan WorkPlace for DOS and in
  327. the NetWare 3.12 and 4.02 operating systems.  The latter pair are available
  328. across the net from the sites mentioned above, directory EPUB.
  329.  
  330. (1.4) THE TELEBIT PPP DRIVER
  331.  
  332. Telebit provides an ODI compatible PPP driver with their NetBlazer modem pool
  333. product.  That driver needs a section of ODI configuration file NET.CFG as
  334. shown below in the ODIPPP section.  The driver has a feature of reporting back
  335. the IP number to be used in a PPP session and writing it into an application
  336. part of NET.CFG.  Kermit's part is shown below, and the MYIP line is ready to
  337. receive the IP number.  The IPCP line tells the PPP driver the syntax to be
  338. used when locating Kermit's MYIP line, and the constuction must be as shown
  339. below in the IPCP line.
  340.  
  341. Kermit can be told to look at the MYIP line for its IP address by command SET
  342. TCP ADDRESS Telebit-PPP.  Notice also that the driver name to bind to is
  343. "telebit", not ODIPPP unfortunately (a Telebit design "feature").
  344.  
  345. Protocol KERMIT
  346.     Bind telebit
  347.     MYIP                <<< ODIPPP fills in IP number here
  348.  
  349. Link Driver ODIPPP
  350.     Frame PPP
  351.     Protocol IP    0800 PPP
  352.     Protocol IPX    0000 PPP
  353.     Protocol ARP    0806 PPP
  354.     Protocol RARP    8035 PPP
  355.     IPCP DYNAMIC "PROTOCOL KERMIT: MYIP:"
  356.  
  357. An example batch file to startup this combination is shown below.
  358.  
  359. @echo off
  360. set nwlanguage=ENGLISH
  361. comppp pppmar94.jrd    << pppmar94.jrd is a personalized Telebit config file
  362. lsl.com            << serial part is going, now start ODI material
  363. odippp            << ODI MLID (board driver), Telebit's PPP here
  364. ipxodi /d        << /d omits diagnostic part, to save memory
  365. vlm /mX            << /mX loads VLMs into extended (raw) memory
  366. @echo on
  367.  
  368. The COMPPP driver reads configuration file PPPMAR94.JRD (or your file name) and
  369. makes a telephone connection before exiting back to the .BAT file to load the
  370. ODI components.
  371.  
  372. CHAPTER 2.  SHIMS.
  373.  
  374. Some interface standards are not supported directly by Kermit.  In such cases,
  375. we insert what is known as a "shim" (a term familiar to carpenters) between the
  376. board driver and Kermit, which fools Kermit into thinking it is one of the
  377. driver types that it knows about.
  378.  
  379. An example is NDIS (Network Driver Interface Specification) from Microsoft and
  380. 3COM.  You probably have NDIS drivers installed if you are using Banyan Vines,
  381. LAN Manager, DEC PATHWORKS, AT&T STARGROUP, some cases of Windows for
  382. Workgroups, etc.  Like ODI, NDIS gives a uniform interface to the application,
  383. independent of the networking method, but a different one from ODI.
  384.  
  385. To use Kermit over NDIS, we insert the shim called DIS_PKT9.  It talks NDIS on
  386. one side and packet-driver on the other.  Expect Packet Driver applications to
  387. work properly with this shim only if the board is Ethernet; there is no
  388. general frame-conversion facility.
  389.  
  390. Here is a section of NDIS configuration file PROTOCOL.INI.  Several important
  391. points about this need to be noticed:
  392.  
  393.  . Spelling must be correct.
  394.  . The names in [square brackets] must be those specified by the various
  395.    vendors, including the [pktdrv] one for DIS_PKT9.
  396.  . The right side of the "DRIVERNAME=" clause must be as given by the vendor
  397.    (pktdrv$ for dis_pkt9); it is not a filename.  The drivername string is
  398.    written into the code of the driver; no user choices. 
  399.  . The right side of the "BINDINGS=" clause is a name which appears elsewhere
  400.    in square brackets, and for DIS_PKT9 it is the square bracket name for a
  401.    board driver.
  402.  
  403. ; Packet Driver protocol users tie in here, dis_pkt9 section
  404. [pktdrv]
  405.     drivername = pktdrv$
  406.     bindings = wd8003
  407.     intvec = 0x60
  408. ;    chainvec = 0x66        ; chaining to another Packet Driver is unused
  409.  
  410. ; AT&T StarGROUP protocol stack ties in here via name ATTISO$
  411. [attiso]
  412.     drivername = ATTISO$
  413.     bindings = wd8003
  414.     nsess = 5
  415.     ncmds = 14
  416.     use_emm = n
  417.  
  418. ;Western Digital EtherCard PLUS Family Adapter, WD8003E in this case
  419. [wd8003]
  420.     drivername = MACWD$
  421.     irq = 7
  422.     ramaddress = 0xCA00
  423.     iobase = 0x280
  424.     receivebufsize = 1536
  425.  
  426. Lengthier examples are presented in text file DIS_PKT9.DOC.
  427.  
  428. Similarly, there is a shim called ODIPKT, which makes an ODI driver look like a
  429. packet driver.    This is not normally needed by Kermit except when running in
  430. Windows (explained in Chapter 3).
  431.  
  432. Please note that the introduction of Windows For Workgroups (WFW) 3.11 has
  433. changed the way networking drivers are loaded and which kind of drivers, NDIS
  434. v2 real mode or NDIS v3 protected mode.     This is explained more fully in 
  435. Chapter 8, below.
  436.  
  437. CHAPTER 3.  WINDOWS.
  438.  
  439. Windows complicates matters for us by moving Kermit around in memory and/or
  440. swapping it in and out, and also by disguising the address of its network
  441. buffers (in technical terms, providing a virtual address space when the the
  442. packet driver must be given actual physical addresses).  The latter case occurs
  443. under Windows in Enhanced Mode, when Windows loads Kermit in "high memory".
  444.  
  445. If you paid attention to Chapter 1, you can see why this might be a problem.
  446. The board driver has been given a buffer address to use for incoming packets,
  447. but Kermit's buffer isn't really there -- Kermit has been moved, or it is in
  448. high memory, or it is swapped out.  When the driver writes the data to the
  449. address, it is writing it over something else -- another application, a disk
  450. buffer, it could be almost anything, with results ranging from bad to worse.
  451.  
  452. There are two ways around this.  First, you can tell Windows to "Lock
  453. Application Memory" for Kermit -- that is, once having loaded Kermit into
  454. memory, leave it there and don't move it or swap it out.  This is a .PIF file
  455. option, good for Kermit but bad for your other applications, which have less
  456. memory available to them (not only because Kermit is hanging on to its own
  457. piece, but because the remaining memory might therefore be fragmented).
  458.  
  459. The second method is to put the shim WINPKT on top of the Packet Driver.
  460. WINPKT knows about Windows, traps the packet delivery, asks Windows to activate
  461. our application (putting it back where it was at buffer handout time), and then
  462. copies the packet safely to the application's buffer.  WINPKT is sort of a way
  463. to "lock in memory but only when needed."
  464.  
  465. The setup of a packet driver depends on the particular driver, but in general
  466. one feeds it parameters on the command line:
  467.  
  468.   c:\wd8003e 0x60 7 0x280 0xd000
  469.   c:\winpkt 0x60
  470.  
  471. The first line loads a Packet Driver for a WD8003E Ethernet board, using
  472. software interrupt 60 hexadecimal, with the board using hardware IRQ 7, port
  473. 280 hex, and shared memory starting at segment D000 hex.  The second line loads
  474. WINPKT, telling it to form a new Packet Driver interface at the same interrupt,
  475. hiding the real packet driver from the application (see NETWORKS\WINPKT.DOC for
  476. details).  Now you see why we call it a shim.
  477.  
  478. WINPKT only works over packet drivers, not ODI drivers or NDIS drivers.     Thus,
  479. if you have an ODI or NDIS driver, you must run the appropriate packet-driver
  480. simulation shim over it, and then run WINPKT over that.
  481.  
  482. Please note that there are two WINPKT programs: the two-argument one (included
  483. on the Kermit diskette as WINPKT9.COM) and the one-argument one described
  484. above (WINPKT.COM).  The one-arg WINPKT is newer, and works with Winsock (in
  485. fact, it comes from the Winsock distribution) but, reportedly, is less stable.
  486. If you have trouble with it when using Kermit, try the two-arg version:
  487.  
  488.   c:\wd8003e 0x61 7 0x280 0xd000
  489.   c:\winpkt 0x60 0x61
  490.  
  491. Also note that the introduction of Windows For Workgroups (WFW) 3.11 has
  492. changed the way networking drivers are loaded and which kind of drivers, NDIS
  493. v2 real mode or NDIS v3 protected mode.     See Chapter 8.
  494.  
  495. CHAPTER 4.  SETTING UP KERMIT'S TCP/IP CONFIGURATION
  496.  
  497. This chapter discusses TCP/IP setup *after* you have successfully coped with
  498. the driver issues, and assumes some knowledge of TCP/IP.  See "Using MS-DOS
  499. Kermit", Chapter 16, for additional explanatory material, or Douglas Comer's
  500. book(s) "Internetworking with TCP/IP" (Prentice-Hall), or show this material to
  501. your network manager.  Also consult the networks section of MSKERM.BWR
  502. (KERMIT.BWR) for additional detail.
  503.  
  504. Before Kermit can use the TCP/IP network, you must use SET TCP/IP commands to
  505. supply Kermit with the necessary details about it.  Check with your network
  506. manager to find out the correct values for these commands, and then put them
  507. in your MSCUSTOM.INI file.  Don't make them up!     Automatic downloading of your
  508. TCP/IP network configuration via BOOTP is recommended.
  509.  
  510. You can view your TCP/IP settings with the SHOW COMMUNICATIONS command.
  511.  
  512. Here are the commands for configuring Kermit for TCP/IP connections:
  513.  
  514. SET TCP/IP ADDRESS {<IP-address>, BOOTP, RARP, TELEBIT-PPP}
  515.   Tell Kermit your PC's IP address (required).    If your local network has a
  516.   BOOTP or RARP server, you can SET TCP/IP ADDRESS BOOTP or RARP to have the
  517.   server download your IP address automatically.  Examples:
  518.     SET TCP/IP ADDRESS 128.59.77.23 ; My IP address, fully specified
  519.     SET TCP/IP ADDRESS BOOTP        ; Get my address from a BOOTP server
  520.     SET TCP/IP ADDRESS RARP        ; Get my address from a RARP server
  521.  
  522. SET TCP/IP SUBNETMASK <IP-address-mask>
  523.   Tell Kermit which portion of an IP address corresponds to your physical
  524.   network.  The default is 255.255.255.0.  A correct value is essential; it is
  525.   used by Kermit to tell whether an IP address is on your physical network
  526.   or must be accessed through a gateway.  Incorrect values prevent successful
  527.   communication.  The subnetmask can be downloaded by BOOTP.
  528.  
  529. SET TCP/IP BROADCAST <IP-broadcast-address>
  530.   Tell Kermit the IP address to use when sending IP broadcast messages, for
  531.   example to the BOOTP server, and to recognize incoming ones.    The default is
  532.   255.255.255.255, meaning "my own physical network".  Change this parameter
  533.   if your BOOTP server is on a different subnet of your local network, or if
  534.   your local network uses the old 4.2 Berkeley UNIX convention of 0's rather
  535.   than 1's for IP broadcast addresses.    An incorrect value can prevent
  536.   successful communication, or worse.  This parameter can NOT be downloaded
  537.   from a BOOTP server -- you can't reach the BOOTP server in the first place
  538.   unless you already have the correct broadcast address.
  539.  
  540. SET TCP/IP PRIMARY-NAMESERVER <IP-address>
  541.   The IP address of your network's primary nameserver, which translates
  542.   hostnames into IP addresses.    Required if you want to use host names rather
  543.   than numeric IP addresses in your SET PORT TCP/IP commands.  Example:
  544.     SET TCP/IP PRIMARY-NAMESERVER 128.59.77.1
  545.   Can also be downloaded automatically by BOOTP.
  546.  
  547. SET TCP/IP SECONDARY-NAMESERVER <IP-address>
  548.   The IP address of your network's secondary nameserver, used by Kermit if the
  549.   primary nameserver is unavailable.  If no nameserver is reachable, use IP
  550.   host numbers rather than names in your SET PORT TCP/IP commands.  Nameserver
  551.   addresses can also be downloaded automatically by BOOTP.
  552.  
  553. SET TCP/IP GATEWAY <IP-address>
  554.   The IP address of the gateway between your local area network and the rest of
  555.   the Internet.     Required if you want to communicate outside of your immediate
  556.   local network.  Can also be downloaded automatically by BOOTP.
  557.  
  558. SET TCP/IP HOST {<IP-address>, <IP-hostname>}
  559.   The default host for SET PORT TCP/IP commands.  SET PORT TCP/IP <host> sets
  560.   this too, so the next SET PORT TCP/IP command remembers it if you omit the
  561.   host.     This allows you to switch back and forth between serial and TCP/IP
  562.   connections.
  563.  
  564. SET TCP/IP DOMAIN <domain-name>
  565.   IP domain name for your organization or department, for example columbia.edu
  566.   for Columbia University, cc.columbia.edu for the Computer Center at Columbia
  567.   University.  This lets you refer to hosts on your local network with
  568.   nicknames, for example watsun rather than watsun.cc.columbia.edu.  When a
  569.   hostname given in your SET PORT TCP/IP command can't be found, Kermit appends
  570.   the domain and tries again.  If it still can't be found, Kermit trims the
  571.   leftmost field from the domain and tries again, and so on until the host is
  572.   found or the domain name is used up:
  573.     SET TCP/IP DOMAIN cc.columbia.edu
  574.     SET PORT TCP/IP oofa.cs
  575.   Kermit tries (in this order): oofa.cs, oofa.cs.cc.columbia.edu,
  576.   oofa.cs.columbia.edu, oofa.cs.edu.  Version 3.13 of MS-DOS Kermit can get
  577.   the domain name from a BOOTP server that has been upgraded to RFC1395 level.
  578.  
  579. SET TCP/IP PACKET-DRIVER-INTERRUPT {<number>, ODI}
  580.   MS-DOS Kermit normally searches for the packet driver beginning at interrupt
  581.   \x60 and going up the \x80.  You can use this command to disable MS-DOS
  582.   Kermit's automatic search and specify a particular interrupt number, for
  583.   example, SET TCP PACKET-DRIVER \x63.    If you specify "ODI" instead of an
  584.   interrupt number, Kermit uses ODI rather than packet-driver conventions for
  585.   communicating with the network board driver.
  586.  
  587. SET TCP/IP MSS <number> (version 3.14)
  588.    Maximum TCP Segment Size, to override built-in defaults of 1046 bytes 
  589.    local and 536 bytes if routed (plus 40 bytes TCP and IP headers).  This
  590.    may be considered MTU (maximum transmission unit) but smarter because
  591.    TCP informs the other side.    Maximum size is 1460 bytes (1500 byte pkt).
  592.  
  593. SET TELNET TERM-TYPE <name>
  594.   Normally MS-DOS Kermit sends the name of terminal it is currently emulating,
  595.   for example, "VT320", in response to a terminal-type request from the remote
  596.   TELNET server.  Use this command to supply any terminal-type name you want.
  597.  
  598. SET TELNET NEWLINE-MODE {OFF, ON}
  599.   During terminal emulation on a TCP/IP connection, MS-DOS Kermit follows the
  600.   TELNET specification and transmits carriage and line feed (CRLF) whenever
  601.   you type carriage return (the Enter key).  If the remote TELNET server is
  602.   confused by this (i.e. it does not follow the TELNET specification), use SET
  603.   TCP/IP NEWLINE-MODE OFF to make Kermit omit the line feed.
  604.  
  605. SET TELNET MODE {NVT-ASCII, BINARY}
  606.   NVT-ASCII is the normal TELNET mode; you may also select BINARY if needed.
  607.   Mode selection is effective only when starting a connection.
  608.  
  609. SET TELNET DEBUG-OPTIONS {ON, OFF} 
  610.   Whether to display TELNET options negotiation on the screen.    Default is
  611.   OFF, don't display them.  When ON, you can view the negotiations on the
  612.   screen, and you can capture them in screen dump or session log files, or
  613.   print them, just like any other CONNECT-mode screen text.
  614.  
  615. Sample TCP-related commands for MSCUSTOM.INI (substitute your own correct
  616. values for the ones shown here!):
  617.  
  618.   SET TCP/IP ADDRESS 128.59.77.23           ; Your PC's IP address
  619.   SET TCP/IP SUBNETMASK 255.255.255.0           ; Your local net's subnet mask
  620.   SET TCP/IP GATEWAY 128.59.77.1           ; The gateway on your local net
  621.   SET TCP/IP PRIMARY-NAMESERVER 128.59.77.19   ; Nameserver on your local net
  622.   SET TCP/IP SECONDARY-NAMESERVER 128.59.78.12 ; Fallback nameserver
  623.   SET TCP/IP DOMAIN bar.baz.edu               ; Your local IP domain name
  624.  
  625. Then, to make a TCP/IP connection:
  626.  
  627.   SET PORT TCP/IP foo                   ; Connect to foo.bar.baz.edu
  628.   CONNECT
  629.  
  630. The TCP/IP connection is not actually established until the CONNECT (or INPUT,
  631. OUTPUT, PAUSE, or similar) command is given, at which time some progress
  632. messages are displayed on your screen.    If connection is immediate, you won't
  633. see these messages, but if the connection fails, they will remain visible so
  634. you'll know why it failed.
  635.  
  636. Logging out from the remote host will normally terminate your session and
  637. pop you back to the MS-Kermit> prompt.    The HANGUP command, or Ctrl-]H during
  638. terminal emulation, should do the same thing.
  639.  
  640. If your network has a BOOTP server, Kermit can learn its own IP address, as
  641. well as the nameserver addresses, gateway address, subnet mask, and other
  642. information from the server if the BOOTP server's database has an entry for
  643. your PC that contains these items.  The BOOTP server knows it's your PC making
  644. the request because it has your network interface board's hardware address in
  645. its database, and BOOTP requests contain the network board's hardware address.
  646. To enter your PC in the BOOTP database, use the PKTADDR program (supplied on
  647. your Kermit diskette) to find out the hardware address, for example:
  648.  
  649.   C:\KERMIT\NETWORKS\PKTADDR 0x60
  650.   My Ethernet address is 00:00:1E:0C:AA:1F
  651.  
  652. Give this address to your network administrator, along with the adapter type
  653. (Ethernet, Token Ring, etc), your PC's IP host name and address (if you know
  654. it, or ask your network administrator to assign these to you -- DON'T MAKE THEM
  655. UP!).  Then, the only commands you need to set up your TCP connection are:
  656.  
  657.   SET TCP/IP SUBNETMASK 255.255.254.0 ; Only needed if different from default
  658.   SET TCP/IP BROADCAST 0.0.0.0          ; Only needed if different from default
  659.   SET TCP/IP DOMAIN bar.baz.edu          ; (3.12 and earlier, or pre-RFC1395)
  660.   SET TCP/IP ADDRESS BOOTP          ; Get my TCP/IP configuration from BOOTP 
  661.   SET PORT TCP/IP <name-or-number>    ; Establish a connection
  662.   CONNECT
  663.  
  664. Notes:
  665.  
  666.  . The SET TCP/IP BROADCAST command is not needed unless you have a nonstandard
  667.    network that uses all-zeroes for IP broadcasts, rather than all ones.
  668.  
  669.  . The SET TCP/IP SUBNETMASK command is necessary only if your subnetwork uses
  670.    a different mask than Kermit's default, which is 255.255.255.0.  These
  671.    commands should go in your MSCUSTOM.INI file.
  672.  
  673.  . The SET TCP/IP DOMAIN command is not needed if you have MS-DOS Kermit 3.13,
  674.    the BOOTP server is at RFC1395 level (January 1993), and its BOOTP database
  675.    contains your PC's domain name.
  676.  
  677. Thus, in many cases, your TCP/IP setup can be as simple as this:
  678.  
  679.   SET TCP/IP ADDRESS BOOTP
  680.  
  681. Kermit sends an IP broadcast message to find the BOOTP server. If you also have
  682. given SET TCP/IP ADDRESS, SUBNETMASK, PRIMARY-NAMESERVER, SECONDARY-NAMESERVER,
  683. and GATEWAY commands, their values will be superseded by any values sent by the
  684. BOOTP server.
  685.  
  686. BOOTP service has the great advantage that PC network configurations need be
  687. maintained in only one central file, rather than on many individual PCs.  If
  688. the BOOTP server is unavailable, users can still enter the required information
  689. with SET TCP/IP commands.
  690.  
  691. If your network has a RARP server, Kermit can learn its own IP address from the
  692. server, if the RARP server's database contains an entry for your PC.  The RARP
  693. server can't tell you the subnetmask, nameserver addresses, or gateway address,
  694. so you will still need these items in your MSCUSTOM.INI file.  However,
  695. everybody on the same physical network can use the same TCP/IP network
  696. parameters in their MSCUSTOM.INI files because the SET TCP/IP parameters other
  697. than ADDRESS are all the same.
  698.  
  699. HINT: To avoid typing long SET PORT TCP/IP commands, define a macro for each
  700. host you commonly connect to:
  701.  
  702.   DEFINE OOFA SET PORT TCP/IP OOFA.XYZ.COM, PAUSE 0, IF SUCCESS CONNECT
  703.  
  704. Put these definitions in your MSCUSTOM.INI file.  Then just type "OOFA" to
  705. connect to TCP/IP host OOFA.XYZ.COM.  The standard sample MSCUSTOM.INI file
  706. already defines a TELNET macro for you:
  707.  
  708. ; TELNET macro, and macros for telnetting to particular hosts
  709. ; using appropriate terminal type.
  710. ;   \%1 = IP host name or address
  711. ;   \%2 = TCP port (optional, default is 23)
  712. ;   \%3 = terminal type (optional)
  713. ;
  714. define telnet -
  715.   set port tcp \%1 \%2,-
  716.   set flow none,-
  717.   if def \%3 set term type \%3,-
  718.   pause 0, if fail end 1, connect
  719.  
  720. You can use this to easily make a connection to a particular host:
  721.  
  722.   TELNET FOO
  723.  
  724. and you can optionally specify a nonstandard (i.e. other than 23) TCP port:
  725.  
  726.   TELNET FOO 2000
  727.  
  728. and you can also (optionally) specify a terminal type to use:
  729.  
  730.   TELNET FOO 23 HEATH-19
  731.  
  732. For information about multiple sessions, see KERMIT.UPD.
  733.  
  734. MAKING SLIP CONNECTIONS
  735.  
  736. To make a SLIP (Serial Line IP) connection, follow these steps:
  737.  
  738. 1. SET PORT 1
  739.    (or whichever serial port you will be using for the SLIP connection).
  740.  
  741. 2. SET SPEED 19200
  742.    (or whatever speed you will be using)
  743.  
  744. 3. SET FLOW RTS/CTS (or NONE)
  745.    Don't use Xon/Xoff flow control on a SLIP connection!  SLIP and Xon/Xoff
  746.    are incompatible with each other.
  747.  
  748. 4. Establish a connection to the terminal server or other device that will be
  749.    providing SLIP service.  Determine the IP address and other information
  750.    (e.g. gateway address) that it has assigned to you.    Normally, these are
  751.    displayed on your screen before the terminal server enters SLIP mode.
  752.  
  753. 5. Escape back to the MS-Kermit prompt and EXIT from MS-DOS Kermit.  The
  754.    connection is left open.
  755.  
  756. 6. Start the SLIP8250 driver, telling it to use the same port (hex address and
  757.    IRQ number must be supplied) and speed (decimal) used in (1) and (2) above,
  758.    and to use hardware flow control (-h), for example:
  759.  
  760.       slip8250 0x60 -h slip 4 0x3f8 19200
  761.  
  762. 7. Start MS-DOS Kermit again.  Do NOT give it a SET PORT command for the
  763.    serial port where SLIP is running.  Instead, give the SET TCP ADDRESS,
  764.    SET TCP GATEWAY, and other necessary SET TCP commands.  Then, to make
  765.    a connection, use SET PORT TCP <address>, where <address> is the IP
  766.    hostname or address of the IP host you want to connect to.
  767.  
  768. Note: Even though you might think it's silly to exit from Kermit and then start
  769. it again, when you could simply start the SLIP driver from the Kermit prompt,
  770. there is a reason: starting a driver from inside an application results in
  771. memory fragmentation.
  772.  
  773. Note 2: In version 3.13 and later, it is also possible to obtain BOOTP service
  774. on a SLIP connection if your SLIP server is configured to provide it (for
  775. example, Cisco terminal servers can do this).  Also, MS-DOS Kermit's SHOW
  776. COMMUNICATIONS command will display the IP address of the BOOTP server.
  777.  
  778. CHAPTER 5.  ACCESSING EXTERNAL TCP/IP PROTOCOL STACKS
  779.  
  780. MS-DOS Kermit can also work with TCP/IP protocol stacks from other vendors, but
  781. it cannot be built with support for stacks which require a proprietary library.
  782. Kermit is a DOS program, Windows-aware, but not a pure Windows program.     Thus
  783. it cannot use the various Winsock Windows TCP/IP implementations.
  784.  
  785. (4.1) FTP Software Inc. PC/TCP. 
  786.  
  787. Use the FTP Telnet interface TNGLASS and run Kermit from it.
  788.  
  789.   tnglass host.domain <optional port> -c0 -e kermit.exe
  790.  
  791. This example uses communication port 1 (-c0) so tell Kermit SET PORT BIOS1,
  792. for example:
  793.  
  794.   tnglass host.domain <optional port> -c0 -e kermit.exe set port bios1, stay
  795.  
  796. The TNGLASS interface causes the Enter key to send <CR><LF> pairs, as
  797. specified in the Telnet protocol specification.  This may cause some problems
  798. in connecting to UNIX machines.  Using "stty igncr" might help, along with
  799. "set key \284 \10" to re-map the Enter key to send a newline.
  800.  
  801. (4.2) Novell Lan WorkPlace for DOS with TELAPI
  802.  
  803. start LWP/DOS and run the TCPIP.EXE program, and also run TELAPI.EXE:
  804.  
  805.   kermit
  806.   set port telapi host.domain <optional port>
  807.   connect
  808.  
  809. This uses Kermit macro named "telapi" which is defined as:
  810.  
  811.   def telapi run tsu -o \%1 -p \%2 k1,run tsu -a k1 1,set port novell
  812.  
  813. TSU is a LWP/DOS transitor helper program doing resolution of IP names to IP
  814. numbers, -o is open to host in first Kermit argument \%1, -p using port in
  815. second Kermit argument \%2 (defaults to 23, Telnet), and assign TSU label k1 to
  816. the connection.     Then run TSU again to -a attach connection k1 to serial port
  817. simulator for Bios com1 (1).  Finally tell Kermit to use fast transmission
  818. method SET PORT NOVELL.     Other choices are SET PORT 3COM and SET PORT BIOS1
  819. (slowest).  If other serial ports are used then tell Kermit SET PORT BIOSn.
  820.     
  821. Kermit needs ODIPKT only if running in Windows enhanced mode, and it needs
  822. WINPKT then too.  Otherwise it runs fastest straight over ODI (force use of ODI
  823. over an available Packet Driver by SET TCP PACKET ODI).     If Kermit is run over
  824. LWP then it can do so in Windows too.
  825.  
  826. If you want to use Kermit's built-in TCP/IP stack instead of Telapi, you can
  827. also unload the LWP/DOS TCP/IP stack and then run Kermit.  It unloads smoothly
  828. and can be reloaded as smoothly.
  829.  
  830. (4.3) Beame and Whiteside TCP/IP
  831.  
  832. Kermit uses the loaded B&W TCP/IP drivers to communicate. The command SET PORT
  833. BWTCP Host Port defines the connection. Host is an IP number, not a name, and
  834. port is an optional TCP port number (defaults to 23, Telnet). Here is a section
  835. of config.sys which loads the B&W resident drivers
  836.  
  837.   DEVICE=C:\BWTCP\ETHDEV.SYS
  838.   DEVICE=C:\QEMM\LOADHI.SYS C:\BWTCP\TCPIP.SYS 1514
  839.  
  840. CHAPTER 6.  OTHER NETWORKS
  841.  
  842. (5.1) Meridian Technology SuperLAT
  843.  
  844. Load the SuperLAT driver according to the Meridian instruction manual.    Kermit
  845. can talk to the driver directly via command SET PORT SUPERLAT host.  Host is
  846. the name of a LAT host, or "*" to see a list of available hosts.  An Interrupt
  847. 14h simulator is also available from Meridian, which Kermit can use via SET
  848. PORT BIOS1.
  849.  
  850. When using SuperLAT over ODI drivers please add the following indented Protocol
  851. LAT line to your NET.CFG file, as shown in the example below.  The frame kind
  852. should be Ethernet_II.
  853.  
  854. Protocol LATDRVR
  855.     bind #1            << use these two lines only if multiple boards
  856.  
  857. Link Driver NE2000
  858.     INT 5
  859.     PORT 360
  860.     FRAME    Ethernet_II
  861.     Protocol IPX    8137    Ethernet_II
  862.     Protocol LAT    6004    Ethernet_II
  863.  
  864. (5.2) Novell NASI/NACS
  865.  
  866. Load the NASI.EXE file (or equivalent) on the client PC, then run Kermit.
  867. Command SET PORT NOVELL(NASI) chooses the comms channel. You should see a
  868. connection menu from the NASI.EXE file when you begin Connect mode; that is a
  869. session manager external to Kermit.  Kermit supports NASI/NACS v2, but in many
  870. cases it also works fine with v3.
  871.  
  872. (5.3) DIGITAL PATHWORKS
  873.  
  874. Kermit can use either LAT or CTERM connection facilities of Pathworks. It tries
  875. a LAT connection first (LAT is not routeable so only local nodes are reachable
  876. this way) and then CTERM (regular DECnet). If only LAT or CTERM support modules
  877. are loaded with Pathworks, then that limits Kermit's choices. The command SET
  878. PORT DECNET host (or * to see list of LAT hosts) chooses the communications
  879. channel.
  880.  
  881. LAT tables in clients are frequently too small to hold all host names
  882. advertized on the net, so please review the PATHWORKS documentation and enlarge
  883. the table to match your site.
  884.  
  885. The PATHWORKS LAT module has distinct trouble if too many bytes are sent by the
  886. PC in too short a time, and there's no feedback about what is "too many" at any
  887. given time.  To avoid the link dropping we recommend using medium-small file
  888. transfer packets, say 256 bytes, and only two window slots.
  889.  
  890. LAT comes in at least two much different flavors in PATHWORKS, depending on
  891. version number of PATHWORKS.  Kermit tries to discover which is which and act
  892. properly, but there might still be nuances which lead to trouble.  MS-DOS
  893. Kermit 3.14 is tested with PATHWORKS v4.2, the latest available to us.
  894.  
  895. (5.4) TES, by Interconnections, Inc.
  896.  
  897. Kermit works with older and the latest TES client programs.  It accommodates
  898. both kinds transparently to the user.  Command SET PORT TES host (or * to see
  899. all available hosts) chooses the communications channel.
  900.  
  901. (5.5) General "Int 14h" Interceptors
  902.  
  903. Many network products are issued with what as known as an Int 14h support
  904. program.  Interrupt 14h is the BIOS support for serial ports, and it is very
  905. simple.     Kermit supports this via the command SET PORT BIOSn where n is 1 to 4.
  906. There are other variations on Int 14h, most well known of which is 3COM(BAPI).
  907. Older TES uses Int 14h too.  Kermit supports these through commands SET PORT
  908. 3COM(BAPI) and SET PORT TES.
  909.  
  910. Bios Int 14h does not provide feedback about baud rate, has no facility to send
  911. a BREAK, does not provide information about a network link closing, has no
  912. interrupt facility, etc.  Loss of a network connection is not reported to
  913. Kermit.     It is a very simple interface.     Further, it is a markedly slower path
  914. for networking than say 3COM(BAPI).
  915.  
  916. It is important to distinguish these Int 14h drivers from real serial port
  917. hardware.  For Kermit, the real hardware is touched by commands SET PORT
  918. COM1..COM4 and synonyms SET PORT 1..4. Int 14h drivers will not be used if
  919. Kermit is told to use the hardware.  Be sure to choose the proper kind of
  920. connection.
  921.  
  922. UnixWare NVT offers an Int 14h interceptor which Kermit may use.  Please see
  923. your UnixWare documenation for details.
  924.  
  925. CHAPTER 7.  INTERRUPTS AND MEMORY MANAGEMENT
  926.  
  927. Network communication problems are often really systems conflicts of one kind
  928. or another.  Some useful tips are summarized below.
  929.  
  930. Hardware IRQ (Interrupt) wires are not sharable.  Only one device can connect
  931. to an IRQ wire even if other devices are "not active."    No program can clearly
  932. identify which device is connected to an IRQ wire, you must look inside the
  933. machine.  The MSD program by Microsoft shows only "conventional" assignments,
  934. not actual usage.
  935.  
  936. Network LAN adapters can use shared memory to transfer packets between board
  937. and driver.  That shared memory MUST be protected against memory management
  938. programs, including Windows.  Exclude that memory at both DOS level and again
  939. in Window's SYSTEM.INI file [386Enh] section; see typically "exclude=" commands
  940. in your memory managment program manual, and the examples below.  SYSTEM.INI
  941. excerpt, WFW 3.11 -
  942.  
  943.   [386Enh]
  944.    ...
  945.   EMMPageFrame=EC00        << expanded memory page frame 
  946.   EMMExclude=C000-C007        << video bios signature area
  947.   EMMExclude=A000-BFFF        << video adapter work area
  948.  
  949. For greater detail about memory management, read section 19 of KERMIT.BWR.
  950.  
  951. CHAPTER 8.  WINDOWS FOR WORKGROUPS 3.11
  952.  
  953. This chapter contains collected hints and tips regarding how to use MS-DOS
  954. Kermit to make TCP/IP connections from Microsoft Windows for Workgroups 3.11.
  955. You might encounter contradictions among the various texts, but this does not
  956. mean that the contradicting items are necessarily wrong (or right) -- only that
  957. this is yet another extremely complicated and obscure topic, and that differing
  958. approaches are possible.
  959.  
  960. ------------------------------
  961. TEXT #1
  962.  
  963. Windows-for-Workgroups (WFW) networking is built upon LAN Manager NDIS board
  964. handler software.  MS-DOS Kermit can make TCP/IP connections from within
  965. Windows for Workgroups by using the DIS_PKT9.DOS and WINPKT.COM shims that come
  966. on the Kermit disk.  For WFW 3.10 and earlier, NDIS drivers are normal
  967. CONFIG.SYS device drivers, and DIS_PKT9 instructions apply.  For WFW 3.11 and
  968. later, which uses its own built-in protected-mode NDIS 3.0:
  969.  
  970.  . In the SYSTEM.INI file, [Network Drivers] section, add DIS_PKT9.DOS at the
  971.    end of the "transport=" line.  Make sure you are using DIS_PKT9 as
  972.    distributed on the MS-DOS Kermit diskette, and not DIS_PKT11 or any other
  973.    version.  See below about PROTOCOL.INI.
  974.  
  975.  . Also in the [Network Drivers] section of SYSTEM.INI file, include
  976.    "LoadRMDrivers=yes".     This means that the NET START command loads Real Mode
  977.    (RM) Drivers.  DIS_PKT9.DOS is a Real Mode Driver.
  978.  
  979.  . In AUTOEXEC.BAT, use NET START.
  980.  
  981.  . As with all network connections in Windows, you must either lock Kermit in
  982.    memory (Check Lock Application Memory in the KERMIT.PIF file) or else load
  983.    the WINPKT shim "on top of" DIS_PKT9, following the instructions in
  984.    WINPKT.DOC.
  985.  
  986. ------------------------------
  987. TEXT #2
  988.  
  989. A Noddy's Guide to Kermit over TCP/IP under Windows for Workgroups 3.11
  990.  
  991.   Gisbert W. Selke
  992.   WIdO, Bonn, Germany, January 1994
  993.  
  994. This document contains a brief outline of the problem and a step-for-step guide
  995. on how to overcome it.    If you are only interested in a quick solution, feel
  996. free to skip ahead to section 2.
  997.  
  998. 1. Where's the problem?
  999.  
  1000. Running multiple network protocols over a single Ethernet adapter has always
  1001. been a problem, since each application tends to try and gain complete control
  1002. over the board.     A solution has been developed, back in the good ol' DOS days,
  1003. by FTP Inc., in the form of so-called packet drivers.  The idea behind this
  1004. approach is beautifully explained elsewhere [1], so I will not attempt to give
  1005. a complete description here.  Suffice it to say that a resident module -- the
  1006. packet driver -- grabs hold of the networking board, and all software wanting
  1007. to access the Ethernet talks to the packet driver instead of directly to the
  1008. board.    This driver hands the network packets of each application down to the
  1009. networking board, and distributes packets arriving over the network back to the
  1010. individual applications, keeping track of which application uses what protocol.
  1011. Using this strategy, one could, e.g., concurrently run TELNET and Netware.
  1012.  
  1013. As time went by, other solutions were developed that basically served the some
  1014. purpose; the non-proprietary nature of the packet driver approach and the
  1015. availability of them for a huge range of adapter types ensured their
  1016. popularity. The situation grew worse with the introduction of Windows, however;
  1017. with its task-switching capabilities, the demand for multiple protocols grew,
  1018. while at the same time Windows' habit of shifting resident programmes around in
  1019. memory made it more difficult for applications to find the packet driver, which
  1020. had suddenly turned into a moving target.  Again, a non-proprietary solution
  1021. was found: on top of the original packet driver, a fake winpacket driver was
  1022. loaded, whose only purpose was to overcome the shifting around in memory.
  1023.  
  1024. In the meantime, Microsoft had discovered that a great number of places used
  1025. this kind of software which had Not been Invented There in Redmond; so it was
  1026. decided to re-invent the wheel and dub it NDIS.     Of course, nobody had to pay
  1027. any attention, really ...  But, to simplify things for people who, for some
  1028. reason, had to employ NDIS drivers, a shim was developed -- and given to the
  1029. public for free -- that made NDIS look like a packet driver.  So one could
  1030. continue to run, say, TCP/IP, Netware and the Microsoft networking method named
  1031. NetBEUI.
  1032.  
  1033. Then, however, Windows for Workgroups 3.11 came out, and all the magic
  1034. incantations that were necessary in order to run NDIS, and to make it
  1035. accessible to other software, changed again, with all the documentation buried
  1036. somewhere deep down on CD-ROM, if at all.  Since Microsoft, of course, did not
  1037. supply, say, TELNET or FTP clients, a solution had to be found -- that was the
  1038. situation at our site early in January 1994.
  1039.  
  1040. Without the many pieces of freely available software mentioned above, and
  1041. without the profound networking wisdom of and support by Joe Doupnik, we would
  1042. either have had to abandon our host computers or else turn away from MS Windows
  1043. for good.
  1044.  
  1045. Instead of delving into the merits of each of these possibilities, it is
  1046. preferable to explain the steps that are necessary for a successful setup of
  1047. Windows for Workgroups, so that its built-in incompatibilities with TELNET/FTP
  1048. applications (like, e.g., MS-Kermit 3.13) do not show up.
  1049.  
  1050. 2. The Nine Steps on the Stairway to Network Heaven
  1051.  
  1052. Requirements:
  1053.  
  1054. * You have the Windows for Workgroup 3.11 (WfW for short) setup diskettes.
  1055.  
  1056. * You have MS-Kermit 3.11 (or later) already installed on your disk.
  1057.   (Applications like NCSA TELNET, QVTNet etc. will also do; it is assumed that
  1058.   the application is configured for packet driver use, where necessary.)
  1059.  
  1060. * You have DIS_PKT9.DOS (this is version 1.09) and WINPKT.COM (version 9.x or
  1061.   later) (found, e.g., in the MS-Kermit distribution).    You know which version
  1062.   of WINPKT you have (if in doubt, execute it without parameters and see.)
  1063.  
  1064. Now follow these steps:
  1065.  
  1066. a) Remove all references to a packet driver from AUTOEXEC.BAT (or from
  1067.    whatever batch file you used to start it from).
  1068.  
  1069. b) Install WfW properly.Once you get to the item of "Network Setup", you should
  1070.    notice that WfW has recognized your network adapter and has installed
  1071.    NetBEUI support. When prompted later to enter a network name for your
  1072.    computer, go ahead and do so. At some point, you will be prompted to install
  1073.    an NDIS driver appropriate for your kind of network adapter. If the driver
  1074.    has been supplied with WfW, fine; if not, get out the support disk that came
  1075.    with your adapter and hope there is an up-to-date NDIS driver there.
  1076.  
  1077. c) At the very end of installation, choose "Return to DOS".
  1078.  
  1079. d) Copy DIS_PKT9.DOS and WINPKT.COM to a suitable directory, e.g., \KERMIT, if
  1080.    you have not done so before.
  1081.  
  1082. e) Use your favourite plain ASCII editor to edit file SYSTEM.INI which can be
  1083.    found in your main Windows directory:
  1084.  
  1085.    * Find the section "[network drivers]".There should be a line starting
  1086.      "transport=" among the next few lines. Add ";C:\KERMIT\DIS_PKT9.DOS" to
  1087.      the end of this line, without any intervening blanks. (If you have used a
  1088.      different directory in the previous step, you should, of course, change
  1089.      this entry accordingly.)
  1090.  
  1091.    * If there is a line "LoadRMDrivers=No" in this section, change the "No" to
  1092.      "Yes". If there is no such line, add a line "LoadRMDrivers=Yes".
  1093.  
  1094.    *  Save the changed file (making sure it is in plain ASCII format).
  1095.  
  1096. f) Use your favourite plain ASCII editor to edit file PROTOCOL.INI found in the
  1097.    very same directory:
  1098.  
  1099.    * Locate a section starting "[NetBEUI]".
  1100.  
  1101.      There should be a line like this: "Bindings=foo$bar". If there is no line
  1102.      starting with "Bindings=", you are in trouble, because networking support
  1103.      has apparently not been properly installed. Go and call the Microsoft
  1104.      Hotline in order to listen to some nice muzak.
  1105.  
  1106.    * If there is such a line, memorize the value of this field (the "foo$bar"
  1107.      part).
  1108.  
  1109.    * Go to the end of the file, add a blank line and then a new section:
  1110.  
  1111.      [PKTDRV]
  1112.      DriverName=PKTDRV$
  1113.      Bindings=foo$bar
  1114.      IntVec=0x7E
  1115.  
  1116.      It is a good idea to insert the name you remember from the previous step
  1117.      instead of the word "foo$bar", of course. The value of 'IntVec' can be any
  1118.      interrupt number that has been used with your old packet driver; in any
  1119.      case, it should be in the range 0x61 to 0x7F (in C-style hex notation).
  1120.      Remember the value you choose; you will need it below.
  1121.  
  1122.    * Save the changed file (again making sure it is plain ASCII).
  1123.  
  1124. g) Use your favourite plain ASCII editor once again to change file AUTOEXEC.BAT
  1125.    in your root directory:
  1126.  
  1127.    * There should be a line "...Net Start" there. (If it is not, you're
  1128.      probably in trouble anyway; cf. the helpful hints under f) in this
  1129.      case). Change this line to read "...Net Start NetBind".
  1130.  
  1131.    * Right after this line, add a new one with contents like this:
  1132.    
  1133.        c:\kermit\winpkt 0x7E    (if your WINPKT version is 11.x or later)
  1134.  
  1135.      or
  1136.  
  1137.        c:\kermit\winpkt 0x7D 0x7E           (otherwise)
  1138.  
  1139.      In the first case, the only argument should be the value you chose at the
  1140.      end of the previous step. In the second case, the second argument should
  1141.      be that value, while the first argument should be a hex number less than
  1142.      the second argument.
  1143.  
  1144.    * Save the changed file (yes, indeed, in plain ASCII).
  1145.  
  1146. h) Re-boot your computer -- you're done.
  1147.  
  1148. i) Check wether it worked:
  1149.  
  1150.    * While still in DOS, run Kermit.
  1151.  
  1152.    * Start Windows, insert Kermit into a program manager group, double-click
  1153.      on it.
  1154.  
  1155. HINT: The applications and the packet drivers talk to each others using DOS
  1156. interrupts; hence, they must both know which interrupt vector to use.  (Older
  1157. versions of WINPKT use two interrupts -- one to talk "upstream" to the
  1158. application, one to talk "downstream" to DIS_PKT or some other "real" packet
  1159. driver.)  MS-Kermit finds the packet driver interrupt itself.  If your
  1160. networking software must be configured for what interrupt vector number it
  1161. should employ (like NCSA TELNET/FTP must; look for a line like "ioaddr=0x7E" in
  1162. file CONFIG.TEL), be sure that the first -- or only -- argument to WINPKT
  1163. (cf. step g)) is specified.
  1164.  
  1165. 3. Acknowledgements
  1166.  
  1167. We would have been completely lost were it not for Prof. Joe R. Doupnik, Utah
  1168. State University, USA, his wonderful assortment of long-range crystal balls,
  1169. and his amazing readiness to help others. Thanks also to the Kermit people of
  1170. Columbia University, New York, USA, in particular to Frank da Cruz, for their
  1171. support and their channelling of vital information.  Duncan Phillips of
  1172. Staffordshire University, UK, succeeded first in what we were merely
  1173. attempting, and was very helpful in sharing his knowledge.
  1174.  
  1175. Finally, thanks to my colleagues who helped sorting out this mess, in
  1176. particular to Ernst-Peter Beyer, without whose ingenuity and patience I would
  1177. probably still be trying to find my way through a labyrinthine heap of windows.
  1178.  
  1179. References:
  1180.  
  1181. [1] Joe R. Doupnik: Packet Drivers, made simple.  To be found, e.g., in the
  1182.     Crynwr packet driver distribution as file PACKET.DOC
  1183.  
  1184. All trademarks etc. mentioned are owned by their respective owners.
  1185.  
  1186. Gisbert W. Selke
  1187. Wissenschaftliches Institut der AOK
  1188. Bonn, Germany
  1189. <gisbert@watsun.cc.columbia.edu>
  1190.  
  1191. ------------------------------
  1192. TEXT #3
  1193.  
  1194. Windows for Workgroups v3.11 and DIS_PKT9.DOS
  1195.  
  1196. Joe R. Doupnik
  1197. jrd@cc.usu.edu
  1198. Utah State University
  1199. 3 Feb 1994
  1200.  
  1201. Windows for Workgroups v3.11 introduces major changes to the network support
  1202. material.  If you wish to use a Packet Driver program, such as MS-DOS Kermit
  1203. or one of the winsock DLLs, while within WFW then two supporting shims will be
  1204. need to be loaded before WFW starts.  There are at least two situations to
  1205. consider and different shims are involved.
  1206.  
  1207. SITUATION 1: WFW runs over a LAN adapter dedicated to WFW.
  1208.  
  1209. This is the case we explore in detail below.  The two shims needed are
  1210. DIS_PKT9.DOS and WINPKT.COM, both available by anonymous ftp from
  1211. netlab2.usu.edu [129.123.1.44] in directory \anonftp\drivers and from sites
  1212. carrying the Crynwr Collection of Packet Drivers.  The important points are
  1213. that a Version 2 NDIS driver is required, not the newer Version 3 32-bit
  1214. protected mode NDIS kind, and that small edits will be needed to WFW text files
  1215. PROTOCOL.INI and SYSTEM.INI.
  1216.  
  1217. SITUATION 2: WFW runs over a Novell ODI handler. 
  1218.  
  1219. The two shims needed are ODIPKT.COM and WINPKT.COM, both available from netlab2
  1220. above.    Both are installed independently of WFW and no changes to WFW are
  1221. needed.     DIS_PKT9 will not run in this environment because no NDIS V2 interface
  1222. is provided by WFW when using ODI.  Instead ODIPKT provides the Packet Driver
  1223. interface on the top of ODI.
  1224.  
  1225. SITUATION OTHER: WFW runs over another network's handler.
  1226.  
  1227. We can't say much because the environment is not known to us.  The general
  1228. guidlines about NDIS V2 support still apply.
  1229.  
  1230. Please notice that we deal only with DIS_PKT9.DOS and WINPKT.COM.  If you have
  1231. another variation of DIS_PKT you will need to contact the persons responsible
  1232. for your variation. Similarly, people have circulated modified copies of winpkt
  1233. without source code or external identifying markings. The winpkt referred to
  1234. here uses two command line arguments and the entire package is bundled in
  1235. winpkt.zip as source code, doc, and executable. Both are available from netlab2
  1236. as cited above. If in doubt get these.
  1237.  
  1238. ODIPKT is on your Kermit disk.
  1239.  
  1240. Steps to follow after installing network support in WFW v3.11.    This presumes
  1241. that WFW owns the network adapter (Situation 1 above).
  1242.  
  1243. 1. Ensure that both PROTMAN.EXE and PROTMAN.DOS are in the WFW directory.
  1244.    You may have to uncompress them from the WFW distribution media.  Copy 
  1245.    files DIS_PKT9.DOS and WINPKT.COM there too.
  1246.  
  1247. 2. Edit PROTOCOL.INI to insert the [pktdrv] section as shown below.
  1248.    Changes to the intvec= and novell= lines are permitted.  An NE2000 
  1249.    NDIS v2 board driver, MS$NE2000, is used in this example:
  1250.  
  1251.     [pktdrv]
  1252.     DriverName=PKTDRV$
  1253.     bindings=MS$NE2000
  1254.     intvec=0x63
  1255.     novell=no
  1256.  
  1257. 3. Edit SYSTEM.INI [network drivers] section to add ",DIS_PKT9.DOS" to the 
  1258.    transport= line, and to ensure an NDIS v2 netcard= driver has been given. 
  1259.    Please do not confuse this transport= line with a similar one in the 
  1260.    [enhanced] section; the [enhanced] section refers to 32-bit protected 
  1261.    mode material.  An NE2000 board is used in this example.
  1262.  
  1263.     [network drivers]
  1264.     devdir=C:\WFW
  1265.     LoadRMDrivers=Yes
  1266.     transport=ndishlp.sys,*netbeui,dis_pkt9.dos
  1267.     netcard=ne2000.dos
  1268.  
  1269. 4. Before starting Windows issue DOS commands (once only)
  1270.  
  1271.     NET START
  1272.     WINPKT \x060 0x63        (example interrupts)
  1273.  
  1274.    The first command energizes the NDIS V2 handlers, and the DIS_PKT9 banner
  1275.    should be displayed ending with the Ethernet address of your board.    NET.EXE
  1276.    is in the WFW directory; also see next paragraph.  The second command starts
  1277.    Windows helper shim WINPKT, and that needs the Packet Driver (DIS_PKT9)
  1278.    active beforehand.
  1279.    
  1280.    A comment on the line "LoadRMDrivers=Yes."  NET START reads file SYSTEM.INI
  1281.    to obtain loading information, and the answer "Yes" tells it to run
  1282.    PROTMAN.EXE that loads the drivers with PROTOCOL.INI supplying details.  If
  1283.    the answer were "No" then the Real Mode (RM) drivers would not be loaded or
  1284.    available.  However, if "No" were stated then we could give command NET
  1285.    START NETBIND to run PROTMAN.EXE and get the same results as the "Yes" case.
  1286.  
  1287. SAMPLE WFW 3.11 PROTOCOL.INI FILE USING AN NE2000 ETHERNET BOARD
  1288.  
  1289. [network.setup]
  1290. version=0x3110
  1291. netcard=ms$ne2000,1,MS$NE2000,3
  1292. transport=ms$ndishlp,MS$NDISHLP
  1293. transport=ms$netbeui,NETBEUI
  1294. lana0=ms$ne2000,1,ms$ndishlp
  1295. lana1=ms$ne2000,1,ms$netbeui
  1296.  
  1297. [protman]
  1298. DriverName=PROTMAN$
  1299. PRIORITY=MS$NDISHLP
  1300.  
  1301. [MS$NDISHLP]
  1302. DriverName=ndishlp$
  1303. BINDINGS=MS$NE2000
  1304.  
  1305. [NETBEUI]
  1306. DriverName=netbeui$
  1307. SESSIONS=10
  1308. NCBS=12
  1309. BINDINGS=MS$NE2000
  1310. LANABASE=0
  1311.  
  1312. [pktdrv]                (dis_pkt9 section, use as shown)
  1313. DriverName=PKTDRV$            (spelling must be correct here)
  1314. bindings=MS$NE2000            (use board driver section name)
  1315. intvec=0x63                (Packet Driver interrupt to use)
  1316. novell=no                (use novell=y if Ethernet_802.3)
  1317.  
  1318. [MS$NE2000]                (NDIS v2 board driver section)
  1319. DriverName=MS2000$
  1320. INTERRUPT=5
  1321. IOBASE=0x360
  1322.  
  1323. [NE2000]
  1324. Adapters=MS$NE2000
  1325.  
  1326. SECTION FROM WFW 3.11 SYSTEM.INI FILE
  1327.  
  1328. [network drivers]            (You need to edit this section)
  1329. devdir=C:\WFW
  1330. LoadRMDrivers=Yes
  1331. transport=ndishlp.sys,*netbeui,dis_pkt9.dos
  1332. netcard=ne2000.dos          ^^^^^^^^^^^^^--+
  1333. ^^^^^^^^^^^^^^^^^^                 |
  1334. |                         |
  1335. ensure a netcard= line like this         |- add this by hand
  1336. exists right here.  It chooses the
  1337. NDIS v2 level board driver.
  1338.  
  1339. ------------------------------
  1340. TEXT #4 (Not directly related, but maybe useful)
  1341.  
  1342. X-News: cc.usu.edu comp.protocols.tcp-ip.ibmpc:4768
  1343. From: fks@ftp.com  (Frances Selkirk)
  1344. Subject: Re: PC/TCP+ WfWg3.11+ Novell 3.12
  1345. Date: Sun, 30 Jan 1994 21:21:01
  1346.  
  1347. In article <frank.25.0010A199@isis.wu-wien.ac.at> frank@isis.wu-wien.ac.at
  1348. (Mag. Wolfgang FRANK) writes:
  1349. > Is there any way to use Pc/Tcp Ver. 2.2 with WfWg 3.11 and Novell 3.12
  1350.  
  1351. You can run PC/TCP version 2.2 with WfWg 3.11 with one bit of additional
  1352. software - a driver that is freely available from our anonymous FTP server and
  1353. BBS - but if you wish to use our NetBIOS as well, you will need to upgrade to
  1354. 2.3. The standard instructions we have assume use of the NDIS. If you need to
  1355. use ODI, that gets more complicated. Please contact me (fks@ftp.com) or
  1356. support@ftp.com if you have problems with the instructions below:
  1357.  
  1358. How to Configure PC/TCP Network Software v2.3, DOS/Windows and Windows for
  1359. Workgroups, Version 3.11
  1360.  
  1361. Since our last newsletter, Microsoft Windows for Workgroups 3.11 was released.
  1362. There were some changes from the beta version of this release which alter the
  1363. configuration necessary for PC/TCP Network Software v2.3, DOS/Windows.    Follow
  1364. these steps to configure PC/TCP, DOS/Windows with Windows for Workgroups
  1365. Version 3.11:
  1366.  
  1367. 1. Choose Real Mode NDIS Driver (NDIS2) during Windows for Workgroups setup.
  1368.  
  1369. 2. Review the config.sys file to make sure:
  1370.  
  1371.  * The Windows for Workgroups installation program inserted the
  1372.    Device=drive:\path\ifshlp.sys entry which is necessary to load the NDIS2
  1373.    converter.
  1374.  
  1375.  * There are no entries that load protocol manager or an NDIS card specific
  1376.    driver.  If they exist in this file, remove them.
  1377.  
  1378. 3. Make the following changes to the autoexec.bat file:
  1379.  
  1380.   * Arrange the entries so that the net start command, inserted by the Windows
  1381.     for Workgroups installation program, precedes any TSRs (Terminate and Stay
  1382.     Resident programs).     The net start command should include the full path, if
  1383.     the command precedes the path statement in the autoexec.bat file.  If the
  1384.     netbind command is in this file, remove it.
  1385.  
  1386.   * Add the drive:\path\kernel command to load PC/TCP kernel after net start.
  1387.  
  1388. 4. Make the following changes to the Windows system.ini file:
  1389.  
  1390.   * Add the Secondnet.drv=drive:\path\pctcpnet.drv entry after the
  1391.     Network.drv=wfwnet.drv entry in the [Boot] section.
  1392.  
  1393.   * Add the Secondnet=drive:\path\vpctcp.386 and
  1394.     Device=drive:\path\wfwftp.386 entries to the [386Enh] section.
  1395.  
  1396. Note: You must use the wfwftp.386 file that FTP Software created specifically
  1397. for Windows for Workgroups Version 3.11.  You can get the file from our
  1398. Technical Support BBS (filename: wfw311.exe) or our vax.ftp.com anonymous FTP
  1399. server (filename:/support/fixes/pctcpdos/wfw311.exe).
  1400.  
  1401. This wfwftp.386 file will also work with Windows for Workgroups 3.1.  The
  1402. wfwftp.386 file created for Windows for Workgroups 3.1 will not work with 3.11.
  1403.  
  1404. * Review the [network drivers] section.     These entries must be present:
  1405.  
  1406. netcard=(your NDIS driver)
  1407. transport=ndishlp.sys,*netbeui
  1408. LoadRMDrivers=Yes
  1409.  
  1410. By the way, the asterisk in *netbeui is an accurate statement used by
  1411. Microsoft.
  1412.  
  1413. * Replace the Transport= entry with 
  1414.   Transport=ndishlp.sys,*netbeui,drive:\path\dis_pkt.gup.
  1415.  
  1416. 5. Make the following changes to the protocol.ini file.
  1417.  
  1418. * Add a [PKTDRV] section with the following entries:
  1419.  
  1420. [PKTDRV]
  1421. DriverName=PKTDRV$
  1422. Bindings=(The Windows for Workgroups name for the driver section)
  1423. IntVec=        
  1424. ChainVec=
  1425.  
  1426. The IntVec= and ChainVec= entries must be available software interrupts; common
  1427. settings are 0x60 and 0x65, respectively).
  1428.  
  1429. If you want to use the PC/TCP,DOS/Windows netbios.com program in addition to
  1430. the Windows for Workgroups NetBEUI stack, make the following changes:
  1431.  
  1432. 1. Add the drive\path\netbios.com entry to the autoexec.bat file.
  1433.  
  1434. 2. Make the following changes to the protocol.ini file:
  1435.  
  1436. * Change the lana0= entry to lanan (where n is the next available adapter
  1437. number) in the [network.setup] section.     An example of this entry follows:
  1438.  
  1439. lanan=ms$drivername,1,ms$netbeui
  1440.  
  1441. * Change LANABASE=0 to LANABASE=n in the [NETBEUI] section (where n is the same
  1442. number as the adapter number in the previous bullet.)
  1443.  
  1444. The lana0 and LANABASE=0 settings are reserved for the PC/TCP, DOS/Windows
  1445. netbios.com program.
  1446.  
  1447. 3. Edit the [pctcp netbios] section of the pctcp.ini file to include the
  1448.    following NetBIOS specific parameters:
  1449.  
  1450. [pctcp netbios]
  1451. Ncbs=64
  1452. Sessions=n
  1453. Names=32
  1454.  
  1455. Note: The Sessions= entry must correspond to the value set in the
  1456. Tcp-Connections= entry in the [pctcp kernel] section of the pctcp.ini file.
  1457.  
  1458. If you want to use the PC/TCP, DOS/Windows netbios.com program without the
  1459. Windows for Workgroups NetBEUI stack, comment out the NetMisc= and Transport=
  1460. entries in the [386Enh] section in the Windows system.ini file by placing a
  1461. semi-colon (;) before the entry.
  1462.  
  1463. Frances K. Selkirk                    fks@ftp.com
  1464. FTP Software, Inc.        Technical Support        support@ftp.com
  1465. Support's newsletter provides technical information on our products.
  1466. FTP to vax.ftp.com, or login to our BBS at 1-508-659-6240.
  1467.  
  1468. (End of NETWORKS\SETUP.DOC)
  1469.