Super Net 1

home *** CD-ROM | disk | FTP | other *** search

/ Super Net 1 / SUPERNET_1.iso / PC / OTROS / MSDOS / PKTDRVR / PKTMUX12.ZIP / PKTMUX.DOC < prev next >

Wrap

Text File | 1993-01-29 | 115.3 KB | 2,416 lines

/* C:\DOC\PKTMUX.DOC **** 29 JAN 93 ** 11:43 ******; G W Robinson R A L I B M P C U S E R G U I D E ----------------------------------------- PKTMUX Packet Driver Multiplexor -------------------------------- Contents ======== 1. Introduction and Disclaimer 2. Installation 3. Overview 4. Usage Guidelines 5. Program Description 5.1 PKTMUX.EXE 5.2 PKTDRV.EXE 5.3 PKTSTATS.EXE 5.4 WINPKT.COM 6. Examples 6.1 Packet Driver, PCTCP and PC-NFS Applications under DOS 6.2 MOS2 under DOS 6.3 Packet Driver and IEEE 802.3 (ISO 8802/3) applications 6.4 Packet Driver and Rainbow Applications 6.5 Packet Driver Applications under Windows 3 6.6 Packet Driver, PCTCP and PC-NFS Applications under Windows 6 7 Windows 3 Applications 6.8 Novell Netware 6.9 Packet Driver/PKTMUX/PKTDRV BAT files 7. Technical Description 7.1 Basic Methodology 7.2 Buffer Strategy 7.3 Channel Management 7.4 Control Programs 7.5 Listeners and /l Options 7.6 Port Duplication 7.7 IP Fragmentation 7.8 Other IP Protocols 7.9 IEEE802.3 (ISO 8802/3) Protocol Support 7.10 Use of Packet Driver Internal Buffer 7.11 Novell Protocol Support 7.12 Packet Driver Protocol Filtering 8. Problem Solving 9. Bugs/Features and Problem Programs 10. Differences in PKTMUX versions 11. Support 12. References 1. Introduction and Disclaimer ============================== The author and his employers accept no responsibilty for any damage done by this software. It is run strictly at the user's risk and all necessary precautions, such as backing up of discs, should be taken before hand. Similarily the vendors/authors of applications and Packet Drivers accept no responsibility for problems and malfunctions, and will give no support, when their software is used with PKTMUX. This document describes PKTMUX which is a program that provides a multiplexing interface to a Packet Driver. It thus allows several IP protocol stacks to be run in parallel either under DOS or a control program such as Windows 3 or DESQview. Multiplexing IP protocol stacks is a non trivial problem and this program is only likely to meet about 90% of user requirements. There will always be 10% who need a more sophisticated product. Because PKTMUX makes certain probability assumptions it is also highly likely that it will make a mistake every now and then when they are not valid. At best an application will recover from this situation and at worse something, possibly even the whole PC, will fail. It is therefore likely that PKTMUX will never be 100% reliable and in some situations it may be so flakey as to be unusable. This documents version 1.2b and differences from previous versions are detailed in Section 10. The programs from this version must not be mixed with those from previous versions as they are incompatible. Many thanks to those around the world who have reported problems and helped with their solution. 2. Installation =============== The system comes as a single program named PKTMUXxx.EXE where xx is the version number, currently 12. When this program is run it expands into several files. These are: PKTMUX.EXE The packet multiplexor PKTDRV.EXE The pseudo Packet Driver interface to PKTMUX PKTSTATS.EXE A program state and statistics display program PKTMUX.DOC This documentation In addition a free program WINPKT.COM and a source listing WINPKT.ASM is supplied since this provides some of PKTMUX's functionality and is rather smaller. The programs should be copied into a directory in the Path such as C:\BIN on RAL machines. PKTMUX.DOC should be put in a documentation directory such as C:\DOC on RAL machines. The BAT file INSTALL.BAT does this. 3. Overview =========== The Packet Driver interface was developed by FTP Software Inc as a standardised way of accessing different makes of communications cards. It is widely used especially over ethernets and a large amount of communications software is available for it. The ethernet implementation makes use of the fact that two bytes in the header define the packet type and this is used to provide a multiplexing mechanism between several packet types. However it looks no further into the protocol stack and thus this feature is of limited use when protocols of the same type, such as those from the TCP/IP family, are used. PKTMUX attempts to remove this limitation by providing a multiplexing facility for Internet Protocols (IP). This is done by not only switching on the packet type (which denotes IP) but also the IP protocol type (which can denote IP protocols TCP, UDP, ICMP and others). In the case of TCP and UDP it can also switch on the Port number being used. It is therefore possible to run more than one IP protocol stack at the same time. It is not possible to multiplex other protocol stacks or more than one of each IP protocol type other than TCP, UDP or ICMP. One protocol stack can be IEEE 802.3 (ISO 8802/3) protocol. PKTMUX was originally written to meet the needs of the RAL MOS2 system which is a TSR (Terminate and Stay Resident) program that provides IBM 3270 emulation over asynchronous and ethernet communications. In this context it provides two functions for the TCP/IP version of MOS2. On is that it allows additional communications applications to run alongside MOS2. This is useful because, since MOS2 is a TSR, you can hot key back to DOS and run other commands. Thus an LPR or FTP can be run alongside the MOS2 3270 session. A second requirement was to allow MOS2 to run under a control program such as Windows 3 or DESQview. This is an instance of a more general problem in running an application which uses a Packet Driver under a control program. It arises because the Packet Driver, which is loaded before Windows, calls the application when it has received a packet. This is quite satisfactory under DOS but under Windows there is no certainty that the application is currently running and there is therefore the risk of jumping into the middle of another program with dire consequences. A Packet Driver option -w gets over this by checking that part of the application program code is present and throwing away the packet if not. This leads to a rather slow data rate as the protocol timeout and retry mechanisms have to be brought into play to recover from the situation. A better solution is provided by the free software WINPKT which only works under Windows 3 Enhanced mode and uses Windows 3 facilities to make sure the application is running. A copy of WINPKT is provided in this package. WINPKT has the drawback that it does not work with other control programs such as DESQview and also with certain ethernet cards such as the BICC 16 bit varient. PKTMUX meets this requirement and gives the additional feature of being able to run communications applications in more than one window. Given the widespread use of Packet Driver it is surprising that nobody has written a PKTMUX before. It is probably because a general purpose multiplexor is impossible to implement. PKTMUX only attempts to meet the needs of IP protocols and is therefore likely to be of little use in other situations. It must however be emphasised that PKTMUX will only work when the probability of various identifying values being duplicated is low and that when duplication does occur then the various retry mechanisms can recover from the mess. If this is not the case the PKTMUX is of little use. PKTMUX has so far been tested satisfactorily with PCTCP, PC-NFS, NCSA, CUTCP, B&W TCP, Waterloo TCP and Novell Netware. It has also been tested with shims that interface onto a Packet Driver such as PDETHER for ODI and RAL LLCPKT for BICC MPS. It also runs on top of the RAL LLCPK2 program that provides a Packet Driver and BICC MPS interface. Further technical details are given in the Program and Technical Description sections. 4. Usage Guidelines =================== The following give basic usage guidelines. For more detail consult the Program Descriptions and Examples sections. All programs except WINPKT give help when run with the /h option. The normal procedure for running a communications application is to load a Packet Driver and then run the application. To introduce multiplexing into this PKTMUX and PKTDRV must be loaded after the Packet Driver and before the application. Thus under DOS type the following after you have loaded the Packet Driver: PKTMUX n ; n is the maximum number of packet ; driver channels to support - default 2 PKTDRV ; repeated n times - displays Interrupt ; used Then run the applications as required. Note the first ones must usually be TSRs otherwise you cannot get back to DOS to load subsequent applications. Applications which search for a Packet Driver will find the first free PKTDRV. Once an application starts using PKTDRV it becomes busy and is no longer recognised as a Packet Driver. Note that this only happens once the application has started communicating over the network so each application must be got to this state before further applications are loaded. If not then two applications will link into the same PKTDRV and fail. Applications for which you have to specify the Packet Driver Interrupt should be set for the highest PKTDRV Interrupt to avoid conflicts. For usage under a control program such as Windows 3 run PKTMUX as above but dont run PKTDRV until after the control program is active. Then run one copy of PKTDRV in any DOS session from which you wish to use a communications application that runs over a Packet Driver. All sessions must continue to run when in the Background and for Windows 3 the Background Priority should be at least 50 and it must be in Enhanced mode. For applications that run directly under Windows 3 (eg WINQVT) either use WINPKT or, if further packet driver channels are required, then run PKTMUX as above and then one PKTDRV before Windows 3 is loaded. Then start up the Windows application which will use this PKTDRV. Further applications running in DOS sessions must have their PKTDRV loaded in their DOS session before they are run. The program PKTSTATS gives details of program states and various statistics. 5. Program Descriptions ======================= 5.1 PKTMUX.EXE -------------- This is a TSR that provides, in conjunction with PKTDRV, multiple IP protocol channels to a Packet Driver. Its format is: PKTMUX chan_cnt pkt_drv_int chan_time_out /options which installs the multiplexor on the first packet driver it finds or hex interrupt "pkt_drv_int" is this is specified (note 1). "Chan_cnt" channels are supported - default is 2 (note 2). "chan_time_out" is the time in seconds a timed out channel waits before being reset (note 6). Any failure during loading will cause PKTMUX to abort and set the DOS ERRORLEVEL to 1. PKTMUX memory usage ranges from 15K for one channel to 34K for eight channels. The following options modify the action taken: a display additional information on loading. b look for and use buffer in Packet Driver (note 12). d drop packets if application has no buffers (note 5). o override use of specified interrupt (note 1). h display this help information. i support one IEEE 802.3 channel (note 9). p pause if error found (note 13). q query state of a PKTMUX (note 11). r reset timed out channels; rr resets internal flags as well and should be used with care (note 6). s silence output except warnings (unless /ss) or errors (unless /sss) (note 10). t terminate PKTMUX and Packet Driver (note 3). u unload PKTMUX if not being used by a PKTDRV (note 3). v set DOS Environment variable PKT_INT to interrupt used or found (notes 1 & 11). x multiplex all received packets - testing only (note 7). 1 to 9 allocate buffers for this channel count (note 4). Examples are: pktmux ; normal use - 2 channels pktmux 4 ; install to multiplex four applications pktmux 2 62 ; install on Packet Driver at Int 62 pktmux 4 /b ; try using Packet Driver buffer pktmux 4 /bi ; support IEEE 802.3 and also try and use ; Packet Driver buffer pktmux /u ; unload PKTMUX (dont forget to unload ; PKTDRVs first) pktmux 8 /4 ; install to multiplex eight applications ; but only allocate enough buffers for four pktmux /r ; reset timed out channels Notes: 1. By default PKTMUX searches for a Packet Driver and, on finding one, takes over its interrupt effectively hiding it so it cannot be found by any other application. There is then no confusion between the real Packet Driver and the pseudo ones provided by PKTDRV. If the /v option is given then the interrupt used is recorded in the Environment variable PKT_INT. Note that PKTMUX will refuse to load if during its search for a Packet Driver either another PKTMUX or a PKTDRV is found or if one of these is the specified pkt_drv_int. This latter restriction can be overcome by the /o (override) option. 2. By default PKTMUX supports two Packet Driver channels. This means it will communicate with up to two copies of PKTDRV and provide two pseudo Packet Driver interfaces. Each PKTDRV acts, within limits, as if it were a Packet Driver with its own ethernet card albiet with the same MAC address as any others. PKTMUX supports up to eight busy copies of PKTDRV. Note that supporting only one channel achieves the same effect as a normal Packet Driver and is only useful where PKTMUX provides additional functionality such as allowing an application to run under Windows 3. 3. The /u option causes PKTMUX to unload unless a PKTDRV is still busy. The /t option does the same thing but also sends a terminate request to the Packet Driver, which will also unload if it supports this facility. 4. By default PKTMUX allocates a basic set of buffers and then adds an additional one to each size group for each channel. Tests suggest this is adequate for most cases. However this can be overridden by giving /n where n is a decimal number in the range 0 to 9. PKTMUX will then allocate buffers as if this number of channels were to be used. This can be used to either save memory by reducing the buffer allocation or increasing the number of buffers when experience suggests it is needed. The memory overhead per channel is a little over 2K. The buffer allocation is shown by PKTMUX when it is loaded and in detail by running PKTSTATS /a after PKTMUX has been loaded. 5. PKTMUX does its best to avoid losing data by holding packets in its buffers when an application is unable to accept them. In some cases this can cause a shortage of buffers. The /d (drop) option causes PKTMUX to behave exactly as a Packet Driver and to drop any packet that is refused by an application because it has insufficient buffer space. This option acts on all channels and overrides a similar option on PKTDRV which works on a per channel basis. 6. When running under Windows 3 or DESQview with a PKTDRV and the application in a DOS session then, if the session is terminated without closing down the application, PKTMUX is left with the channel marked as Busy. It will either be freed after "Chan_time_out" seconds (default infinity) or the option /r (reset) can be used on a call to PKTMUX to reset all such channels. If /rr is given then the busy flags in PKTMUX are also reset which could cause it to fail. See also the PKTDRV /r option and the section on Channel Management in the Technical Description below for further details. 7. By default PKTMUX sends data direct to the application when only one channel is in use. If the /x option is given then packets are copied to a buffer and multiplexed by the normal mechanisms as if several channels were operational. This is therefore a test facility to check if PKTMUX is able to support an application irrespective of any other application that is running. Note that if /x is used with Novell and Windows 3 it can crash Windows. 8. PKTMUX only supports Accesses for Packet Driver Class 1 (DEC/Intel/Xerox "Bluebook" Ethernet). It will not refuse other Classes but the result is undefined and a failure is likely if the same Class is used over more than one channel. 9. If the /i option is given then PKTMUX opens the Packet Driver for all types and does its own filtering on the Type field in order to decide to which handle a packet is destined. This is order to allow one channel to Access as Packet Driver Class 1 and to accept IEEE 802.3 type packets where the Type field is the data length and is a value of 1500 bytes or less. This dramatically reduces the efficiency of PKTMUX so should only be used when IEEE 802.3 packets are to be used. Unfortunately the overhead remains irrespective of whether such packets are being used but this can be mitigated by the /b option. Note this is a new facility to evaluate feasibility and may not be very satisfactory. In particular if used with Novell and Windows 3 it can crash Windows. 10. If the /s option is given then PKTMUX does not give out any messages unless an error or warning occurs. The option /ss prevents any warning messages as well and /sss prevents errors as well. 11. The /q option causes PKTMUX to return the state of "pkt_drvr_int" in both text form and also via the ERRORLEVEL as follows: 0 No PKTMUX found 1 PKTMUX found If the "pkt_drvr_int" is not specified then a search is made from Interrupts 60 to 7F looking for PKTMUX. If the /v option is given then the interrupt used is recorded in the Environment variable PKT_INT. 12. The /b option causes PKTMUX to try and locate the data buffer within the Packet Driver so that it can look at the data before taking a copy of the packet. This option is specific to the Packet Drivers of certain ethernet cards and has been tested successfully on the following: Card Buffer Size Found in Bytes BICC 16 bit ISA and MCA versions 64 NE2000 23 WD8003 64 Note that if PKTMUX is unable to find the data buffer the option is disabled so it can be used safely in any situation. However if the card you are using is not in the above list then it would be prudent to check that all is well just in case the algorithm fails to locate the correct buffer. If the /x option is given then PKTMUX goes through the motions of trying to locate the buffer but does not use it. Note that PKTSTATS displays the current state of the algorithm and with the /a option gives more details. This is a new facility to evaluate feasibility and may not be very satisfactory in some cases. It is further explained in the Technical Description section below. 13. One of the problems in running PKTMUX from a batch file is that if an error occurs then the message often disappears off the screen before it can be noted. The /p option causes output to pause if an error is detected when PKTMUX is first loaded and wait for input from the user before proceeding. 5.2 PKTDRV.EXE -------------- This is a TSR which provides the pseudo Packet Driver interface in conjunction with PKTMUX. Its format is: PKTDRV pkt_drvr_int mux_int all_type /options which uses the multiplexor on hex interrupt "mux_int" or by default searches for it. It installs itself as a Packet Driver on hex interrupt "pkt_drvr_int" or, by default, the first free interrupt after the multiplexor (note 1). The "all_type" parameter (repeatable) defines the packet Type values used when an application asks for all types (eg PC-NFS v3.0). The default setting is 0800, 0806 and 8035 (note 2). Any failure during loading will cause PKTMUX to abort and set the DOS ERRORLEVEL to 1. PKTDRV memory usage is a little over 1K. The following options modify the action taken: c copy send buffers (note 3). d drop packets if application has no buffers (note 5). e extend search area under a control program (note 11). f force PKTDRV to be Free; !f forces to Busy (note 1) h display this help information. i asking for all types gives IEEE 802.3 channel (note 7). l act as listener for any protocol type (note 4). !l dont act as listener for any protocol type. lf act as listener for TCP FTP; !lf negates. li act as listener for IP; !li negates. lt act as listener for TCP; !lt negates. lt# act as listener for TCP port # (decimal); !lt# negates. lu act as listener for UDP only; !lu negates. lu# act as listener for UDP port # (decimal); !lu# negates. n only load PKTDRV if needed ie. there is no free PKTDRV already (note 8). o override use of specified interrupt (note 1). p pause if error found (note 12). q query state of a PKTDRV (note 10). r reset a PKTDRV that is busy (note 1). s silence output except warnings (unless /ss) or errors (unless /sss) (note 9). t terminate PKTDRV, PKTMUX and Packet Driver (note 6). u unload last loaded PKTDRV if Busy (note 6). uu unload last loaded PKTDRV even if Busy. ur repeatedly unload last loaded PKTDRV if not Busy. v set DOS Environment variable PKT_INT to interrupt used or found (notes 1 & 11). w# wake up using ethernet IRQ # (decimal) (note 13). Examples are: pktdrv ; normal use pktdrv /c ; copy send buffers pktdrv 66 62 ; multiplexor on 62, put Packet Driver on 66 pktdrv /t ; terminate PKTDRV, PKTMUX and Packet Driver pktdrv /u ; unload last PKTDRV to be loaded pktdrv /uu ; unload last PKTDRV to be loaded even if Busy pktdrv 63 /u ; unload PKTDRV on Int 63 pktdrv 0 0 800 806 1000 ; Application wanting all packet types will ; just get 0800, 0806 and 1000 pktdrv /!l /lf ; not a listener for any service except FTP pktdrv /lt21 ; listener for TCP port 21 pktdrv /w3 ; wake up with ethernet IRQ 3 Notes: 1. PKTDRV by default uses the next free Interrupt after that used by PKTMUX. It avoids Interrupts 61, 62 and 64, as these are used by PCTCP, Vista eXceed and Novell respectively, and also 67 as this is the EMS entry point. Interrupts 70 - 76 are normally in use on all but the XT type PCs. If the /v option is given then the interrupt used is recorded in the Environment variable PKT_INT. If the Interrupt is specified it is checked to see if it already in use by PKTDRV, PKTMUX or a Packet Driver and if so PKTDRV will refuse to load unless the /o option is given. Note that under a control program, such as Windows 3, PKTDRV will, by default, use the same Interrupt in each DOS session it is loaded in. This is because each DOS session has its own version of the Interrupts. For the same reason PKTSTATS will only see the PKTDRV, if any, in its DOS session yet will display the correct total that are busy. Part of the Packet Driver definition is the use of the string PKT DRVR just after the interrupt entry point in order to identify it. A communications application which does not require the explicit definition of the Packet Driver interrupt searches from Interrupt 60 up to 7f until it finds one. PKTDRV uses the same mechanism and so appears to be a genuine Packet Driver. However once a communications application has accessed PKTDRV the identification is changed and only reverts back when the application has given a release command. Thus several copies of PKTDRV can provide the impression that multiple Packet Drivers are present. The state of each PKTDRV is shown by calling PKTSTATS - Free means it can be used by an application and Busy means its identification has been changed and it is in use. One problem with this mechanism is when two applications can use the same Packet Driver - for example PCTCP running alongside a Novell Packet Driver using TYPE 8137 protocol - then doing this over one PKTDRV will fail. One solution is to use separate PKTDRV for each. Alternatively once the first application has been started and the PKTDRV is now Busy then a command of the form: pktdrv pkt_drvr_int /f forces the state back to Free. A second application can then be loaded which finds PKTDRV and can use it. The opposite problem is when an application is loaded, locates a Free PKTDRV but does not issue any commands and thus change the PKTDRV state to Busy. The call: pktdrv pkt_drvr_int /!f forces the PKTDRV to be Busy thus subsequent applications will not find it. If a PKTDRV is marked as Busy and the application has terminated (or crashed!) then calling PKTDRV with /r option will reset the specified "pkt_drvr_int" PKTDRV. Note that /r resets the channel whereas /f simply resets the program identification and leaves all the call details intact. If the PKTDRV was also terminated at the same time as the application, such as when a Windows DOS session is terminated, then the channel is Busy but there is no PKTDRV to send a Reset to. In this case PKTMUX will have registered that the PKTDRV has gone and giving the command: pktmux /r will reset any Busy channel for which there is no PKTDRV. Note that in the PKTDRV calls above if the "pkt_drvr_int" is not specified then a search is made from the last possible PKTDRV Interrupt number (7f) back to the first (60). Thus a generalised use of the feature is possible provided the PKTDRV being used is the last one that was loaded and/or the highest Interrupt number. See also note 11. The /f, /!f and /r requests are refused if they are directed at a PKTDRV which was loaded under DOS and the PKTDRV issuing them is running under Windows or DESQview. This can be overriden by repeating the option for example /ff, /!f!f or /rr. A copy of PKTDRV can be loaded at any time. If it is required to unload the system at some later time it is perhaps wise to load all the PKTDRV copies that are required under DOS just after PKTMUX. This minimises the chance of problems with interrupt chains but means that any use of the /f or /r options need the "pkt_drvr_int" specifying. 2. Instead of requesting certain packet types some applications, notably PC-NFS v3.0, ask for all packet types. PKTMUX does not allow this since it makes its job extremely difficult so PKTDRV intercepts such a request and replaces it by specific packet types. By default these are 0800 (IP Protocols), 0806 (ARP - Address Resolution Protocols) and 8035 (RAPR - Reverse ARP) and these are all PC-NFS really needs for its own use. Where further packet types are required these can be overridden and alternatives supplied. One limitation of this implementation is that an application with a genuine requirement for all packet types cannot be supported. An exception is IEEE 802.3 (ISO 8802/3) over a Packet Driver Class 1 as used by the RAL LLCPKT product and this can be supported by via the /i option. Note that a single PKTDRV will only support a single application when implementing all packet types (such as PC-NFS) or IEEE802.3. If another application is required, such as Novell, then it must use another PKTDRV. 3. Under Windows 3 (and possibly DESQview) some communications cards which use DMA (direct memory access) for sending data don't work properly. The same thing can happen when the application is located in upper memory (ie above 640K). The solution is to copy the data from the application's buffer into one in PKTMUX and send it from there. This is done by the /c option and it only applies to data sent via that PKTDRV. The only card so far found to require this is the BICC 16bit ethernet card though this may be dependent on the PC hardware and the EMM in use. 4. The /l and /!l options indicate whether or not the application using this PKTDRV should act as a listener for well known services. See Technical Description below for further details. 5. The /d (drop) option makes this PKTDRV channel behave as a normal Packet Driver and drop any packet for which the application has no buffer rather than holding it in a buffer which is the default. The PKTMUX option /d implements the same feature for all channels and overrides the PKTDRV setting. 6. The /u option causes PKTDRV to unload unless it is still busy with an application. Adding an /r requests all PKTDRVs be unloaded. Note this may not be possible if other TSRs where loaded between PKTDRVs. If it is known that an application is not Busy, such as when it has crashed, then the /uu option will force the unload. The /t option does the same thing but also sends a terminate request to PKTMUX which, if it is acceptable, will also send a terminate request to the Packet Driver. These requests are refused if the PKTDRV they are directed at was loaded under DOS and the PKTDRV issuing them is running under Windows or DESQview. If the "pkt_drvr_int" is not specified then a search is made from the last possible PKTDRV Interrupt number (7f) back to the first (60). Thus a generalised use of this feature is only possible provided the PKTDRV being unloaded is the last one that was loaded and also the highest Interrupt number. See also note 11. 7. If the /i option is given then a request for all types will result in IEEE 802.3 (ISO 8802/3) type packets (ie those 1500 bytes long or less) being routed up this channel. The PKTMUX /i option must also be given for this to work. Thus implementations of ISO CONS (Pinkbook in the UK academic community) can run over PKTMUX where Access is done using Packet Driver Class 1. UK Academic users of the RAINBOW software who wish to use a Packet Driver alongside to run say PC-NFS or any other TCP/IP stack thus have two options. They can either run the RAL LLCPKT2 product which provides a packet driver interface. This interface can then be either used directly by an application or via PKTMUX for several applications. Alternatively they can run LLCPKT direct to a PKTDRV with the /i option. Note however that the overheads of both methods are significant. However if the /b option is successfully used on PKTMUX then the latter is dramatically more efficient. Note this is a new facility to evaluate feasibility and may not be very satisfactory. Depending on feedback a better implementation may be included in the next version. 8. The /n option instructs PKTDRV to check either the specified "pkt_drvr_int" or, if this is not given, then Interrupts between 60 to 7f to see if a PKTDRV is already running and whether it is Free. If this is true it does not load and returns an ERRORLEVEL similar to the /q option as follows: 0 No Free PKTDRV found - PKTDRV loaded ok 2 Free PKTDRV found - PKTDRV not loaded 3 As 2 but Free PKTDRV loaded before Control Program 4 No Free PKTDRV found - PKTDRV load failed for another reason such as no PKTMUX present. The parameter settings of the free PKTDRV are also set to those of the PKTDRV call except for the /w (ethernet board interrupt) option which cannot be changed from its original setting. This option allows a BAT file to only load a PKTDRV if it is required. See also note 11. Note that the ERRORLEVEL denoting a failure is now 4 instead of 1 as it is when the /n option is not present. 9. If the /s option is given then PKTDRV does not give out any messages unless an error or warning occurs. The option /ss prevents any warning messages and /sss prevents error messages as well. 10. The /q option causes PKTDRV to return the state of "pkt_drvr_int" in both text form and also via the ERRORLEVEL as follows: 0 No PKTDRV found 1 Busy PKTDRV found 2 Free PKTDRV found 3 As 2 but Free PKTDRV loaded before Control Program If the "pkt_drvr_int" is not specified then a search is made from Interrupts 60 to 7F looking for any PKTDRVs. Reporting a Free PKTDRV takes precedence over a Busy one. See also note 11. 11. The rules for searching for a PKTDRV are modified when running in the DOS session of a control program such as Windows or DESQview. In this case, even if the "pkt_drvr_int" is specified, only the PKTDRV programs loaded in this DOS session are checked. To expand the search to all PKTDRVs, that is to include those loaded before the control program was run, the option /e must be given. Thus it is possible to target the effect of any option to either the current DOS session or all the PKTDRVs in the machine excluding those in other DOS sessions. If the /v option is given then the PKTDRV interrupt is recorded in the Environment variable PKT_INT. These search rules affect options /f, /!f, /n, /q, /r, /t and /u. 12. One of the problems in running PKTDRV from a batch file is that if an error occurs then the message often disappears off the screen before it can be noted. The /p option causes output to pause if an error is detected when PKTDRV is first loaded and wait for input from the user before proceeding. 13. Some applications use the ethernet hardware interrupt to drive their communications code. This gives problems with PKTMUX since when more than one channel is busy any received data is sent to the application after this interrupt has been processed. The outcome is that the application runs satisfactorily on its own but once a second channel becomes busy the application then slows down. The solution is to make the ethernet interrupt wake up PKTDRV by using the /w option. The IRQ value of the ethernet hardware interrupt must be specified in decimal and should be in the range 2 to 15. This option should thus be used with any application that requires the ethernet hardware IRQ or interrupt to be specified. It may also give improved performance if used for all applications. The only exception is when PKTDRV is running in a Windows or DESQview session when the option is ignored as it would crash the PC. Note that IRQs map onto the PCs interrupt values as follows: IRQ (Decimal) : 2 3 4 5 6 7 8 9 10 11 12 13 14 15 IRQ (Hex) : 2 3 4 5 6 7 8 9 A B C D E F Interrupt (Hex): A B C D E F 70 71 72 73 74 75 76 77 Interrupt (Dec):10 11 12 13 14 15 112 113 114 115 116 117 118 119 Applications that have been found to need this option are B&W NFS and Wollongong Pathway NFS. 5.3 PKTSTATS.EXE ---------------- This program displays program details and statistics from PKTMUX. Its format is: PKTSTATS /options The following options modify the action taken: a display further information - can be repeated (note 1). e extend PKTDRV search area under a control program (note 5). h display this help information. q query state of a Packet Driver, PKTMUX and PKTDRV (note 4). s silence output from /q option. v set DOS Environment variable PKT_INT to interrupt found by /q option (note 5). Examples are: pktstats ; normal use pktstats /a ; show further information pktstats /q ; query state pktstats /qe ; query state under Windows including ; PKTDRV copies loaded under DOS Notes: 1. The option /a can be repeated up to 3 times to give increasing levels of information. This is mainly intended for debugging purposes. Repeating /a 3 times can get the program in a loop or give misleading information since it scans queues which may be changing. This is intended only for cases when PKTMUX has stopped with a system error. 2. The counts given by PKTSTATS are 16 bit integers so will overflow over a period of time. The counts are not read at the same time but are obtained as they are required by PKTSTATS. As PKTMUX is processing data at the same time there may be some inconsistencies in fast moving values such as Broadcast and Ignored counts. 3. In the output from PKTSTATS where the name before a count value is in CAPITAL letters then this indicates that data is being lost or discarded for some reason. Further details are given in the section on Problem Solving. Each PKTDRV channel may have one or more of the following qualifiers againsts it: /Drop_buff PKTDRV /d option given /DV PKTDRV running under DESQview /DOS_to_Window PKTDRV running under DOS but application under Windows so application may loose packets. /TIMED_OUT PKTDRV appears to be no longer active. /TX_Copy PKTDRV /c option given /Win PKTDRV running under Windows /Zero_type All Packet Types requested so mapped onto specified Types - usually 0806 and 0800. /802.3 PKTDRV /i option given 4. The /q option causes PKTSTATS to search Interrupts 60 to 7f for the state of a Packet Driver, PKTMUX and PKTDRV and report back in both text form (unless /s option given) and also via the ERRORLEVEL as follows: 0 No Packet Driver found 1 Packet Driver found 2 PKTMUX and Packet Driver found 3 Busy PKTDRV, PKTMUX and Packet Driver found 4 Free PKTDRV, PKTMUX and Packet Driver found 5 As 4 but Free PKTDRV loaded before Control Program Reporting a Free PKTDRV takes precedence over a Busy one. See also note 5. 5. The rules for searching for a PKTDRV with the /q option are modified when running in the DOS session of a control program such as Windows or DESQview. In this case only the PKTDRV programs loaded in this DOS session are checked. To expand the search to all PKTDRVs, that is to include those loaded before the control program was run, the option /e must be given. Thus it is possible to target the effect of the /q option to either the current DOS session or all the PKTDRVs in the machine excluding those in other DOS sessions. If the /v option is given then the interrupt of whatever is found is recorded in the Environment variable PKT_INT. 5.4 WINPKT.COM -------------- This program is not part of the PKTMUX system but since it provides a subset of the facilities for a smaller memory requirement it is included. In is not supported by RAL. In accordance with the distribution licence the source is also supplied in WINPKT.ASM. The program COPYING mentioned at start up is not supplied as I dont have a copy. WINPKT is also part of the Crynwr (ex Clarkson) Packet Driver collection v10 and may be a later version. WINPKT acts as an interface between an application running under Windows 3 in Enhanced mode and a Packet Driver. It uses Windows 3 calls so is specific to this case. Its format is: WINPKT new_pkt_drvr_int old_pkt_drvr_int where "old_pkt_drvr_int" is the interrupt of the Packet Driver in either decimal or hex preceeded by 0x. "new_pkt_drvr_int" is the new interrupt to use and cannot be the same as "old_pkt_drvr_int". There are no documented options. Examples are: winpkt 0x63 0x64 ; Packet driver on Interrupt 64, WINPKT ; accessed via Interrupt 63 winpkt ; provide help information Notes: 1. WINPKT should be loaded after the Packet Driver and before Windows 3 is loaded. It is recommended that "new_pkt_drvr_int" is before "old_pkt_drvr_int" since applications that search for a packet driver will find the driver and not WINPKT. 2. WINPKT has no unloading mechanism so if unloading is required the RAL LOADSYS system or similar must be used. 3. WINPKT may not work with certain ethernet cards. The BICC 16 bit card is the only know example so far found. PKTMUX should be used in these cases along with the /c option on PKTDRV. 6. Examples ============ The following examples illustrate the use of PKTMUX and attempt to show the various possible uses of the system. It assumes a degree of familiarity with setting up and use of the various systems exampled. Examples include the RAL MOS2 IBM 3270 emulator since this system was one of the reasons for writing PKTMUX. The RAL LOADSYS program to load and unload TSRs and Device Drivers can also be useful in running multiple protocol stacks. Details of both are given in the Reference Section. It is usually the case that a sequence of commands is put into a BAT file and one section below gives examples of techniques that facilitate this. In general there are two classes of communications applications. The simplest are those that just need a Packet Driver in order to work, for example the CUTCP programs PING, LPR and FTPBIN. A more complicated type are those applications which require their own TSR to be loaded first. The applications then communicate via this instead of directly to the Packet Driver. Examples are applications that run over PCTCP and PC-NFS. Another twist are those applications that either are, or can become, TSRs and thus allow you to return to DOS. Thus further applications can be run. Examples are MOS2 which is a TSR and FTP which via the command ! becomes a TSR and starts up a DOS session. 6.1 Packet Driver, PCTCP and PC-NFS Applications under DOS ---------------------------------------------------------- The following illustrates how to run a Packet Driver application alongside those requiring their own TSR to be loaded. The first is for PCTCP and assumes IPCUST.SYS and IFCUST.SYS are loaded in CONFIG.SYS. ne2000 0x63 0x5 0x320 ; Load Packet Driver for NE2000 card pktmux ; Support 2 channels pktdrv ; PKTDRV for PCTCP to use pktdrv ; PKTDRV for Packet Driver application ; to use ethdrv ; PCTCP Packet Driver interface You can now run applications from the PCTCP program suite, such as FTP, PING or LPR. Programs that just require a Packet Driver can also be run such as FTPBIN from the CUTCP program suite. The following illustrates how to run a Packet Driver application alongside the PC-NFS TSR. It is assumed that SOCKDRV.SYS, PKTD.SYS and ANSI.SYS are loaded in CONFIG.SYS. pcnfs.sys /b1 ; loaded in CONFIG.SYS mbdndpd 0x63 /I10 /D3 ; Load Packet Driver for BICC 16 bit ; card pktmux ; Support 2 channels pktdrv ; PKTDRV for PC-NFS to use pktdrv ; PKTDRV for Packet Driver application cd \nfs prt * ; Normal PC-NFS loading net init PC-NFS applications such as NFSPING can now be run as well as those just requiring a Packet Driver such as FTPBIN from CUTCP. 6.2 MOS2 under DOS ------------------ The RAL MOS2 IBM 3270 Emulator v2.3 is a TSR. It supports the Waterloo TCP/IP protocol stack and is normally run by loading the Packet Driver and then running the file MOS2T.BAT. To achieve this using PKTMUX type: ne2000 0x63 0x5 0x320 ; Load Packet Driver pktmux ; Support 2 channels pktdrv ; PKTDRV for MOS2 to use pktdrv ; PKTDRV for applications to use mos2t ; Run MOS2 Once MOS2 is running you can then hot key (Alt-Esc) back to DOS and then any other communications application which runs over a Packet Driver can be used. For example PING from the Waterloo TCP/IP suite or FTPBIN or LPR from the CUTCP suite. For example: ftpbin ib ; establish FTP communications with IB To run MOS2 alongside applications from the PCTCP applications suite the following is suggested: ne2000 0x63 0x5 0x320 ; Load Packet Driver pktmux ; Support 2 channels pktdrv ; PKTDRV for PCTCP to use pktdrv ; PKTDRV for MOS2 to use ethdrv ; PCTCP Packet Driver interface mos2t ; Run MOS2 Once MOS2 is running the PCTCP applications can be used. A combination of the two cases, that is the ability to run applications from the PCTCP program suite or any other application that runs directly over a Packet Driver can be achieved by the following: ne2000 0x63 0x5 0x320 ; Load Packet Driver pktmux 3 ; Support 3 channels pktdrv ; PKTDRV for PCTCP to use pktdrv ; PKTDRV for MOS2 to use pktdrv ; PKTDRV for applications to use ethdrv ; PCTCP Packet Driver interface mos2t ; Run MOS2 Once MOS2 is running either the PCTCP applications or those requiring a Packet Driver can be used. Note that it is possible to run MOS2 before loading PCTCP but this is not recommended. Loading PCTCP first removes any problems with the provision of well known services such as an FTP listener. If MOS2 must be loaded first then its PKTDRV should have the /!l option so that any incoming calls for well known services are routed to the next PKTDRV which should be the one for PCTCP. 6.3 Packet Driver and IEEE 802.3 (ISO 8802/3) applications ---------------------------------------------------------- The following illustrates how to run an IEEE 802.3 application using a Class 1 access alongside one or more Packet Driver applications. One obviously must be a TSR in order to allow a return to DOS in order to run the other. If the Packet Driver application was a TSR (eg PC-NFS) then the sequence could be: ne2000 0x63 0x5 0x320 ; Load Packet Driver pktmux /ib ; Support 2 channels pktdrv ; PKTDRV for application to use pktdrv /i ; PKTDRV for IEEE 802.3 use You then load the Packet Driver application TSR then on returning to DOS run the IEEE 802.3 application. Note that PKTMUX and the PKTDRV used by the IEEE 802.3 application must have a /i option. In fact all PKTDRVs could have the /i option so that the IEEE 802.3 application could use any one. However the exception to this is an application, such as PC-NFS v3.0, which asks for all packet types. Its PKTDRV must not have a /i option. The /b option on PKTMUX is very strongly recommended for IEEE 802.3 work since, if it works, it should dramatically reduce the overheads. 6.4 Packet Driver and Rainbow Applications ------------------------------------------ UK academic users of the Rainbow product can run Packet Driver applications alongside by use of a similar sequence to the previous section. The Rainbow software (eg PINKBOOK) must be run over the IEEE 802.3 PKTDRV via the LLCPKT interface provided by RAL. Thus to run it alongside PC-NFS could be done as follows: pcnfs.sys /b1 ; loaded in CONFIG.SYS mbdndpd 0x63 /I10 /D3 ; Load Packet Driver for BICC 16 bit ; card pktmux /ib ; Support 2 channels pktdrv ; PKTDRV for PC-NFS to use pktdrv /i ; PKTDRV for PINKBOOK to use cd \nfs prt * ; Normal PC-NFS loading net init llcpkt ; LLCPKT Packet Driver to BICC MPS ; interface pinkbook ; PINKBOOK TSR rainbow ; Rainbow application 6.5 Packet Driver Applications under Windows 3 ---------------------------------------------- The following illustrates how to run Packet Driver applications under Windows 3 in Enhanced mode. Use under DESQview is very similar. ne2000 0x63 0x5 0x320 ; Load Packet Driver pktmux 8 /4 ; Support 8 channels but only 4 will ; will be active at once win ; Run Windows 3 To run an application open a DOS session and type: pktdrv ; PKTDRV for application to use followed by the application. The application could be the MOS2 emulator BAT file for example: mos2t To run further applications just open more DOS sessions and run PKTDRV then the application. For IEEE 802.3 applications the PKTMUX call must have the option /i added (and /b is also recommended) and the PKTDRV run under the DOS session should have a /i. Thus to run the Rainbow application in their Windows DOS session would type: pktdrv /i llcpkt ; LLCPKT Packet Driver to BICC MPS ; interface pinkbook ; PINKBOOK TSR rainbow ; Rainbow application Where a PIF file is used then the associated BAT file could contains commands similar to above. A little care is needed with error conditions since if there is no free channel then the PKTDRV load will fail. For example: pktdrv /p IF ERRORLEVEL 1 GOTO EXIT ; Jump if failed . run application . :EXIT If the loading of PKTDRV fails for any reason the /p option holds up processing allowing the user to see the error message generated. The complete BAT file for the MOS2 emulator would therefore be: pktdrv /p IF ERRORLEVEL 1 GOTO FAIL ; Jump if failed call mos2t command :EXIT Be warned that Windows, especially 3.0, can become unstable if you have insufficient memory and opening too many DOS sessions may result in a Unrecoverable Application Error. This usually does no damage and other sessions are unaffected. Note also that, unless the PC is quite powerful, applications may fail as they will not get enough CPU to process their communications in time and protocols may time out. This is especially so if IEEE 802.3 protocols are used. 6.6 Packet Driver, PCTCP and PC-NFS Applications under Windows 3 ---------------------------------------------------------------- This is essentially the same as under DOS but with the PKTDRV for the Packet Driver application run under a DOS session. For example to run both PCTCP and Packet Driver applications the following would suffice. ne2000 0x63 0x5 0x320 ; Load Packet Driver pktmux 8 /4 ; Support 8 channels but only 4 will ; will be active at once pktdrv ; PKTDRV for PCTCP to use ethdrv ; PCTCP Packet Driver interface win ; Run Windows 3 To run a Packet Driver application open a DOS session and type: pktdrv ; PKTDRV for application to use followed by the application. For PCTCP applications just run the application. 6.7 Windows 3 Applications --------------------------- Windows 3 applications are slightly different in that they do not run in a DOS session so it is not possible to run PKTDRV after Windows has been loaded. For those that run over PCTCP or PC-NFS then the appropriate TSR is loaded under DOS after PKTMUX and one PKTDRV as illustrated above. The application is then run under Windows as normal. For those that run over a Packet Driver, for example WINQVT, then the procedure is very similar to running them under DOS, that is the PKTDRV is loaded before Windows 3. For example to run WINQVT and also other applications that use a Packet Driver the following would suffice: ne2000 0x63 0x5 0x320 ; Load Packet Driver pktmux 8 /4 ; Support 8 channels but only 4 will ; will be active at once pktdrv ; PKTDRV for WINQVT to use pktint ; WINQVT Packet Driver interface win ; Run Windows 3 Then run WINQVT as normal with QVT_TCP.RC edited to contain the line: packet_vector=65 This is done because WINQVT has to have its Packet Driver interrupt specified and PKTDRV will use 65 by default in the above example. If there is any doubt then PKTDRV could have its interrupt number specified as the first parameter for example: pktdrv 65 If WINQVT is not going to be loaded immediately then there is a problem that another application may use the PKTDRV intended for WINQVT since it would the the first one found when searching down the Interrupts. To combat this it is recommended that WINQVT is given a high interrupt number (eg 7F) to guarantee it will be free. For example: ne2000 0x63 0x5 0x320 ; Load Packet Driver pktmux 8 /4 ; Support 8 channels but only 4 will ; will be active at once pktdrv 7f ; PKTDRV for WINQVT to use pktint ; WINQVT Packet Driver interface win ; Run Windows 3 Then run WINQVT as normal with QVT_TCP.RC edited to contain the line: packet_vector=7f To run further Packet Driver applications open a DOS session and run PKTDRV and the application as before. To run PCTCP or PC-NFS applications then modify the above to include the TSR before loading Windows. Alternatively for PCTCP the TSR can be run under Windows 3 inside a DOS session since it is effectively a Packet Driver application. IPCUST.SYS and IFCUST.SYS must have previously been loaded in CONFIG.SYS or could be loaded by the RAL LOADSYS system. 6.8 Novell Netware ------------------- Novell using a Type 8137 packet can be run in a variety of ways. Note that because PKTMUX hides the real Packet Driver by taking over its interrupt then the Novell Packet Driver interface IPX must use a PKTDRV. For example: ne2000 0x63 0x5 0x320 ; Load Packet Driver pktmux 2 ; Support 2 channels pktdrv ; PKTDRV for Novell to use pktdrv ; PKTDRV for application to use ipx ; Load Novell 8137 Packet Driver ; interface etc An improvement on this is to note that PKTDRV, like a normal Packet Driver, can support several protocol types so it is possible for one PKTDRV to support both Novell and an application. However the difference is that PKTDRV sets itself busy when it is Accessed so it must be made Free again before it can be Accessed again. For example: ne2000 0x63 0x5 0x320 ; Load Packet Driver pktmux 2 ; Support 2 channels pktdrv ; PKTDRV for Novell and one ; application to use ipx ; Load Novell 8137 Packet Driver ; interface pktdrv /f ; make PKTDRV free again pktdrv ; PKTDRV for second application to use etc Note that in this case the second application must not be one that uses all packet types (eg PC-NFS v3.0) or IEEE802.3. Further note that if the application does any form of filestore redirection such as PC-NFS or IDRIVE from PC/TCP then this must be loaded before IPX is run. This is because although at Packet Driver level there are no problems it appears that only the Netware filestore redirector can cope with another redirector following it in the chain. It must therefore be loaded last. If the Novell service is using the Standard Netware protocol, that is using in a standard IEEE802.3 packet, then the Packet Driver will map this to Type 8137 if the -n option is given. Thus the first line in examples above would become: ne2000 -n 0x63 0x5 0x320 ; Load Packet Driver 6.9 Packet Driver/PKTMUX/PKTDRV BAT files ----------------------------------------- It is frequently the case that a general purpose BAT file has to be written to load communications software. PKTMUX provides various tools to assist in this as are illustrated in the following examples. Note that the /s option can be added to all the calls to avoid confusing the user with the messages that are generated. It is also recommended that the /p option is added to all calls to load PKTMUX and PKTDRV so that the BAT file pauses if an error is found thus allowing the user to read the message. The following example checks if a Packet Driver or PKTMUX has already been loaded before loading both along with a PKTDRV ready to run a communications application. pktstats /qp ; Query state IF ERRORLEVEL 4 GOTO GOT_FREE ; Jump if got a Free PKTDRV IF ERRORLEVEL 2 GOTO GOT_PKTMUX ; Jump if got a PKTMUX IF ERRORLEVEL 1 GOTO GOT_PACKET ; Jump if got a Packet Driver ne2000 0x63 0x5 0x320 ; Load Packet Driver :GOT_PACKET pktmux ; Load PKTMUX IF ERRORLEVEL 1 GOTO FAIL ; Jump if failed :GOT_PKTMUX pktdrv ; PKTDRV busy so load new one IF ERRORLEVEL 1 GOTO FAIL ; Jump if failed :GOT_FREE ; All loaded and a Free PKTDRV etc ; available Alternatively the PKTDRV call could have the /n option which would remove the need for the second line jump to GOT_FREE and is a general purpose way of loading a PKTDRV only if one is not already Free. Such use does require a different testing of the ERRORLEVEL since a value is returned if the PKTDRV is not loaded because a Free one already exists. For example: pktdrv /n IF ERRORLEVEL 4 GOTO FAIL ; Jump if failed Note that ERRORLEVEL values of 2 and 3 mean not loaded due to a Free PKTDRV being present. If the application was one that terminated and then released the Packet Driver, for example LPR or TRUMPET, then the line: pktdrv /u could be added after the application had been run to unload the PKTDRV, if this is possible. This would reduce the memory occupancy and increase the possibility of being able to unload any other TSRs. Note that in all the above cases the /v option could have been added thus causing the interrupt used to be recorded in the DOS Environment variable PKT_INT. Thus in the above case the call: pktdrv /nv would set PKT_INT to either the Free interrupt it found or the Interrupt used by the new PKTDRV. Hence an application requiring to know the Interrupt value in its call could be passed this detail. However if such an application held the interrupt number in a file so that it could not be easily changed in a BAT file then checks for a PKTDRV on this fixed interrupt number, 7f in the example, could be done as follows: pktdrv /q 7f IF ERRORLEVEL 3 GOTO GOT_FREE ; Jump if got a Free PKTDRV IF ERRORLEVEL 2 GOTO FAIL ; Jump if got a Busy PKTDRV pktdrv 7f ; Load PKTDRV on 7f IF ERRORLEVEL 4 GOTO FAIL ; Jump if failed :GOT_FREE run application pktdrv 7f /u ; Unload PKTDRV if possible If there was already a Busy PKTDRV on Interrupt 7F then it would not be possible to run the application. All the above cases would also work under a control program such as Windows or DESQview provided certain conditions are met concerning any PKTDRV programs loaded under DOS, that is before the control program was loaded. They must all be busy when the control program was loaded, for example being used by PCTCP or PC-NFS. If they are still free then they must either be made busy as soon as the control program is loaded by the application, such as WINQVT, being loaded at startup, or they must use a high interrupt such as 7F. The reason behind all this is to avoid an application in a DOS session searching from Interrupt 60 and finding a free PKTDRV running under DOS rather than in the DOS session itself. Whilst an application will work in this case the response will be a lot slower and the likelyhood of failure much higher. If it can be guaranteed that any Free PKTDRV loaded under DOS has an Interrupt at the end of the range, eg 7F, then the examples above will work. If not then any Free PKTDRV under DOS must be made Busy to avoid any problems. The following suggests how and uses the /e option to widen the search outside the DOS session and the /v option to note the PKTDRV interrupt number: pktdrv /nv ; Load PKTDRV unless one Free ; in this DOS session IF ERRORLEVEL 4 GOTO FAIL ; Jump if failed :TEST_AGAIN ; Have a Free PKTDRV in the ; DOS session pktdrv /qve ; Check entire machine IF ERRORLEVEL 3 GOTO GOT_DOS ; Jump if Free PKTDRV under DOS run application ; All ok so run application GOTO EXIT :FAIL ; Failure to load PKTDRV Echo Cannot load PKTDRV GOTO EXIT :GOT_DOS ; Free PKTDRV under DOS pktdrv /e!f!f %PKT_INT% ; Busy it GOTO TEST_AGAIN ; Test again in case another :EXIT This BAT file forces to Busy any Free PKTDRV running under DOS with a lower Interrupt number than any in the DOS session so that an application does not use it. Note that this BAT file will run equally happily under DOS provided a PKTDRV at a high interrupt number is not Free. 7. Technical Description ========================= This section describes how PKTMUX goes about its task and is intended for those who wish to understand how the system works and why it has the limitations it has. An understanding of the Packet Driver interface is assumed. The various PKTMUX counts and states detailed below are shown the command: pktstats /a Additional states are given by the option /aa. 7.1 Basic Methodology --------------------- In essence the system is very simple. PKTMUX talks to the Packet Driver and receives data from it. Each PKTDRV passes all commands onto PKTMUX with the addition of the channel number. PKTDRV also sits on a timer interrupt and asks PKTMUX once per system tick if there are any packets for this channel and if so then gets them passed over. A PKTDRV is only Busy from when it has been asked by an application to Access a packet Type to when that is Released. In between it remains Free. Whilst PKTMUX makes every attempt to be efficient it does create a significant overhead when multiplexing between several applications. This is because the Packet Driver interface only tells you it has a packet and does not give a pointer so that you can see if you are interested in its contents. Where only one application is using this packet type then the packet is sent direct to the application. Otherwise it is necessary for PKTMUX to read the packet into its own storage, analyse its contents and then send it when asked by a PKTDRV to the appropriate application(s). Thus every packet received in this manner has to be copied once more than necessary unless devious cunning is employed via the /b option. 7.2 Buffer Strategy ------------------- When an application is unable to accept a packet, usually because it has no free buffer space, then PKTMUX keeps the packet in its buffers and every timer tick keeps asking the application to accept it. It does this even when it normally sends data direct to the application, thus those applications which operate on a small buffer pool may lose less data when under PKTMUX especially when they receive less CPU cycles when running under Windows 3. The decision whether to keep a packet when an application is unable to accept it is a difficult one and depends on the available buffer pool and activity on other channels. The ultimate criterion is the age of the buffer and after between 2 and 3 seconds it is dropped. Whilst this mechanism is satisfactory for most applications there are some that give problems. One that has been noted is TRUMPET which, when an interaction has been completed and it is waiting for user input, refuses to accept any more packets. Whilst PKTMUX's buffer strategy will cope in normal circumstances, under heavy loading this could give problems. The /d option is therefore available on PKTDRV which causes a packet to be always dropped when an application is unable to accept it. Thus it behaves exactly as a Packet Driver. The /d option is also available on PKTMUX to provide this feature on all channels and could be used in cases of extreme loading. 7.3 Channel Management ---------------------- Normally a channel is freed when the application Releases all the packet TYPEs is has Accessed. If this does not occur, usually because the application has crashed, then there are two possible cases. The first, and most normal, is where the PKTDRV being used by the application is still running and a call the PKTSTATS shows it to be Busy. The command: pktdrv /r will reset the PKTDRV and free the channel. The second case is when the PKTDRV is not running. PKTMUX detects this by the absense of any timer interrupts and frees the channel after about two seconds. However this technique fails under a control program such as Windows 3 or DESQview since the DOS session can be locked thus preventing the PKTDRV from sending its timer interrupts. An example is when an area is Selected under Windows 3.0 for such actions as cut and paste. To overcome this PKTMUX does not immediately free such channels when running under a control program but this gives the new problem that it now has no means of knowing the channel can be freed. Such channels are marked as having Timed Out and this is displayed by PKTSTATS. To reset such a channel use the following command: pktmux /r in a DOS session and this will make all such channels free again. An automatic means of recovery from this situation is provided by the third PKTMUX parameter, Chan_time_out. This is the time in seconds the call stays in a timed out state before being freed automatically. However this should be set with care since if you spend too long on your cut and paste the channel may be freed and your application will fail. One side effect of an application crashing is that it may leave PKTMUX in one of its internal busy states. This is shown by the PKTSTATS /aa output in the line "Busy Flags". If this occurs then PKTMUX will effectively go to sleep. When this is the case then the call: pktmux /rr will also reset these flags and PKTMUX may resume working. It may also crash! The maximum number of Busy channels supported by PKTMUX is 8 but realistically a rather lower number is recommended. This value is permitted in order to mitigate the problems detailed above by preventing timed out channels from blocking other applications. If say only 4 channels are actually going to be required but 8 are specified then to save memory the number of buffers should be reduced by a call such as: pktmux 8 /4 7.4 Control Programs -------------------- One of the problems with the Packet Driver interface is that when it receives a packet it then calls a routine in the application. This will not fail under DOS but if the application is running under a control program such as Windows 3 or DESQview, where the application can be swopped in and out of the current virtual memory, then there is a need to establish that the current application is the correct one. PKTMUX does this by noting the code it is to jump to when a packet is received and checking if that is present. This works satisfactorily unless two copies of the same application are running and in this case the application has to be tagged in a unique way. Note that there are two ways of using PKTDRV under a control program. The preferred way is to load it in a DOS session after the control program has been started and then run the application. In this way when PKTDRV asks PKTMUX if it has received a buffer it can be sure the application is in memory and so minimises any delay. Alternatively when an application runs directly under the control program it is therefore not possible to load PKTDRV in the same virtual memory so it has to be loaded under DOS before the control program. It therefore has no certainty that the application is running when it asks PKTMUX if any data has been received so sometimes has to wait until its timer interrupt coincides with the time slice of the application. This can slow things down considerably and may require PKTMUX to have a larger buffer pool in order to cope. 7.5 Listeners and /l Options ---------------------------- One of the problems PKTMUX has to solve is to which application to route packets for which it has no previous knowledge. Examples are ARP requests and calls to previously unused TCP or UDP ports. Experience has shown it is best to send ARP requests to all applications. For TCP and UDP ports the requests can be either for well know services (such as TELNET or FTP) in which case the default is to send it to the first application to sign up for that packet type in the hope that it has a listener for this service. This avoids more than one response to such a request. Alternatively it may be to a port previously notified by the application (an example is FTP) and in this case it is sent to all applications who use that packet type. This latter technique works provided the application is tolerant of such unsolicited messages. Tests so far indicate that PC-NFS and CUTCP dont mind. However PCTCP, Waterloo TCP and WINQVT are more strict and send back an error message. For TCP this is a RST (reset) and for UDP it is an ICMP Port Undefined message. Since this upsets the service being used such cases are trapped and the error message filtered out. Note that the WINQVT log may report "Packet received for invalid port - reset sent". In the PKTSTATS output such packets are counted under "Ignored: err Resp" and under "Ign" in the "PKTDRV channels:" tables. There is currently no way of preventing such unsolicited messages being sent to an application and the /l options only apply to packets for well known ports. The definition of a well known port is a little vague these days. Originally it was 0-255 but the Unix fraternity officially extended this to 1024 for Unix Standard Services and the current RFC 1106 list goes way beyond this value. As some applications assume this rule in their port usage so PKTMUX designates ports 0-255 as well known and routes them to only one channel. Any other services outside this range are likely to be provided by a specialist server so sending to all should locate it. This may be revised in the light of experience. The various /l options on PKTDRV override the default setting for well know services and indicate where such a request should be sent or not. Options of the form /l indicate this application has servers of this type and /!l indicates it does not. The absence of an /l or /!l option means the application provides all servers but it is used only when no other application has an /l option. The /l option types are implemented as an hierarchy with the specific protocol ports for TCP and UDP taking precedence over the protocols themselves which in turn take precedence over the protocol family (IP). Last in precedence is a general listener. The applications are also searched in reverse order of loading so that a later application can take precedence over an earlier one. The simplest method of making sure the main services such as FTP are found is to load that application first. Where this is not possible then the PKTDRVs for applications that do not support servers over a protocol should be marked as such by an /!l (ie not a listener) type option so that it is avoided when looking for the default. And any application that wants to take over from the default can be marked by an /l (ie I am a listener) type option. Note that requests will be discarded if no listener is found. PKTSTATS will display the listener settings for each channel. 7.6 Port Duplication -------------------- When an application makes a call to a service it specifies the port to which replies should be sent. How this port number is generated is dependent on the application. There is therefore a possibility that two applications could generate the same reply port number. To combat this PKTMUX inspects all reply port numbers in outgoing packets for TCP and UDP and replaces any new and duplicated number by the next one higher, if that is not in use. It also resets the packet header sumcheck if this is being used. Port numbers on incoming packets are similarily mapped along with ICMP packets containing TCP and UDP. Thus it is possible to run two copies of the same application without any problems of port duplication. However there are two areas that cannot be fixed. One is where the application specifies the reply port via the protocol. For example FTP usually specifies the port to be used for the file transfer via the PORT command in its controlling data stream. Since PKTMUX does not analyse the data going through it this is not noted. There is therefore the possibility that such a port number may be duplicated if two copies of the same application are run. Fortunately tests with the FTP implementations from PCTCP and CUTCP have not shown this to be a problem. The second is where the reply port is a well known port and an example of this is BOOTP. In this case it assumed that any duplicate use of this port is by an application taking over the function this well known port supports. Thus a BOOTP exchange on one channel will be assumed complete when a second channel uses BOOTP. If this is not the case, as it would be if two applications started up at the same time, then hopefully the BOOTP retry mechanisms will recover the situation. 7.7 IP Fragmentation -------------------- IP Fragmentation is a means whereby a large packet is carried through a network whose packet size limit is too small. It is done by simply putting the extra data into the data part of one or more IP packets ie. where you would normally expect the TCP or UDP header to be. The constituent packets of the fragment are linked by having the same IP Identification. PKTMUX notes the channel that the first fragment is sent to and then routes all further fragments with the same Identifier to that channel. This works satisfactorily for most cases but has some potential problems. The first is when the fragments arrive out of order. As PKTMUX needs the first packet in order to get the TCP or UDP header out then any fragment that arrives before this packet will be discarded. Such cases are recorded in the NO FRAGMENT count of PKTSTATS output. The protocol retry mechanisms should retransmit the packet and hopefully the first packet of the fragment will arrive first and everything will be ok. The second is a more difficult problem in that if the same IP Identification is used by two fragmentation sources then PKTMUX has no way of distinquishing between the two. Hopefully this will be very rare and the receiving application(s) should spot that they have the wrong fragments and their retry mechanisms should recover the situation. Note that when fragmentation is occurring then the number of received and copied fragments (excluding the first) is displayed by PKTSTATS. 7.8 Other IP Protocols ---------------------- PKTMUX is only able to multiplex on IP protocols it knows about. These currently are TCP, UDP and ICMP. Any other IP protocol type will be handled correctly provided there is only one channel using it. Multiple usage of another IP protocol will therefore fail. Provided any such protocol has a port mechanism of some form it would be possible add to support to PKTMUX if required. 7.9 IEEE802.3 (ISO 8802/3) Protocol Support ------------------------------------------- Since this protocol changes the meaning of the Type field to be the length, PKTMUX has to ask the Packet Driver to send it all packets and not just those of a certain TYPE. This dramatically increases the number of packets copied into PKTMUX and hence the overhead on the PC. It also increases the response time, especially under control programs such as Windows 3, so can give protocol problems as well. Use of the /b option (see next section) can improve this. This option is for those IEEE802.3 implementations that Access the Packet Driver as a Class 1. The correct way to support IEEE802.3 is via Class 11 but this is only available on recent Packet Drivers and gives problems as detailed in section 7.12 below. Users of the RAL LLCPKT2 product which allows the Rainbow software to run alongside a Packet Driver interface should note that PKTMUX now supports the simpler LLCPKT product which, if used with the /b option, can give a more efficient system. 7.10 Use of Packet Driver Internal Buffer ----------------------------------------- One of the limitations of the Packet Driver interface is that when it receives a packet it then calls a routine in the application asking for a buffer of a certain size. Thus PKTMUX only knows how big the data is but has no idea of the contents other than that provided via the handle used in the call. The generic Packet Driver code is actually provided with a pointer to the Type field which is also used to access the next byte but unfortunately the registers pointing to this are overwritten before PKTMUX is called. It is therefore reasonable to assume that somewhere within the Packet Driver program are held the first few bytes of the incoming packet and that they are valid at the point when PKTMUX is asked to provide a buffer in order to read this packet. The /b option instructs PKTMUX to search the Packet Driver for this buffer, to copy it and then to test it against the data it actually obtains from the Packet Driver. Should a consistent match be found then the Packet Driver buffer is used to filter out those packets that are of no interest and to send those packets for which there is in only one channel direct to the application. This should therefore reduce the copying of data and in the case of IEEE802.3 support can dramatically reduce the overhead. The gain in other cases is dependent on how much of the packet is found and hence how much of the protocol headers is available for analysis. How you locate the buffer is an interesting problem. So far two types of Packet Driver implementations have been found. One, exampled by NE2000, uses a fixed buffer every time so this is fairly easy to locate. A second type uses a buffer pool and this is rather more difficult to track. The BICC 16 bit card uses this technique and experimentation has shown that a segment register always points to the correct area of memory. An algorithm that copes with both these cases has been implemented. Testing with other cards will no doubt require it to be modified. PKTSTATS gives an indication of where the algorithm is and the eventual outcome of the testing. Please note that this is a test implementation to evaluate the technique. Once again PKTMUX is breaking all the rules. How effective this option is depends on the size of buffer available. When the available buffer is 64 bytes you get the full benefit and for all cases there should be a significant improvement in performance. Where the buffer is smaller then below 48 bytes the benefits tail off considerably. However if you are using IEEE802.3 then the /b option avoids the copying of all packets not for this address so gives a significant reduction in overheads. 7.11 Novell Protocol Support ---------------------------- PKTMUX has been tested satisfactorily with Novell Netware using their Type 8137 protocol. It has not been tested with the 802.3 varient but this protocol will probably work provided the -n option is given to the Packet Driver as shown in the examples section. Further details are given in the next section. 7.12 Packet Driver Protocol Filtering ------------------------------------- An area fraught with problems is the use of a Packet Driver in a mixed protocol environment. An example would be TCP/IP and Novell Netware using its 802.3 protocol. The following gives details of the filtering algorithm used by the Packet Driver and applies to Versions 9 and 10 of the collection. It has been gleaned by examining the code (mostly HEAD.ASM) provided to standardise the implementation of the Packet Driver and will only apply to drivers that use this code. Drivers from earlier versions of the collection may work differently. On receipt of a packet the Packet Driver examines the Packet Type field, which is the length field in IEEE 802.3, and checks if it is greater than 1500 bytes. If so it is marked as Class 1 (Bluebook Ethernet) otherwise as Class 11 (IEEE802.3). If the -n (Novell) option has been given then Class 11 packets are checked to see if the DSAP/NSAP (the two bytes after the Packet Type/Length) is 0xFFFF. If so then this is assumed to be a Novell 802.3 packet and the Class is changed to 1 and the Packet Type is changed to 8137. Class 1 packets are also checked and if a Packet Type of 8137 is found this is changed to 8138. Similarily any packet sent by the Packet Driver that has a Type of 8137 is modified if the the -n option is given by replacing the Packet Type by the length thus making it IEEE802.3 conformant. Thus the -n option dictates the protocol being sent to and expected from the Novell server and in both cases the Novell application is using 8137. The next test if to search the list of Packet Types that have been Accessed by the application. When such an Access is made the application specifies the Class and which Packet Type it wishes to receive. The Packet Type is either a specific one such as 0800 for IP, 0806 for ARP or 8137 for Novell or it can be for All Types implying that the application wishes to receive all packets of the given Class - whether it actually does so is dependent on whether it was the first Access or not as indicated in the rules below. 1. When an Access is made its Class and Packet Type are added as the next entry in the list unless it is a request for All Types. 2. If a request for All Types is the first Access for that Class it is added as the next entry in the list. 3. If the request for All Types is the second or subsequent Access for a Class then it is put at the end of the list and all subsequent Access entries added before it. 4. When the Packet Type list is searched to match an incoming packet the Class and Packet Type are checked against each entry until either a match is found or an All Types entry for any Class is found. Thus an All Types entry blocks any further entries in the table irrespective of their Class. The rules have been slightly simplified in that they describe the Class 1 case where the Packet Type is fixed at two bytes. For Class 11 there is the likelyhood of longer Packet Types since this now selects on the DSAP/NSAP and following bytes so complications arise when different lengths are specified. Should the shorter be a subset of a longer Type then the former takes precedence and the latter Access is rejected. These rules have several interesting consequences for programs, such as PC-NFS v3.0 (actually is the PKTD.SYS v3.0.2 program) and LLCPKT, which ask for All Types, and these are best illustrated by examples. Consider the case of PC-NFS 3.0 loaded first. As it asks for All Types of Class 1 then no other application irrespective of its Class will work alongside it. The second case is where PC-NFS is not the first application to be loaded. If any Access was for the IP or ARP Packet Types then PC-NFS would not work since it needs to receive these Types. However if the first Access was for the Novell Packet Type 8137 then PC-NFS would run alongside it. Note that the version of PKTD.SYS for PC-NFS v3.5 and later stopped asking for All Types so the problem effectively goes away and it can be run alongside Novell. But note that PC-NFS must be loaded before Novell for other reasons. Tests have also been carried out on Version 5 Packet Drivers and suggest that they will accept just one All Types Access or several specific Accesses but will not accept any combination of the two. The official BICC card driver, MBDNDPD, is based on this version. This card's Version 10 driver, named ISOLINK, is probably a much better bet. 8. Problem Solving ================== This section attempts to suggest how problems with PKTMUX should be tackled. It is worthwhile reading the meaning of the various options and also the Technical Description above in order to ascertain if your problem and its solution is documented therein. Also the section on Bugs/Features and Problem Programs should be consulted. One of the biggest difficulties with PKTMUX is sorting out why something is not working properly. To assist in this the utility PKTSTATS is provided which, when used with the /a option, gives details of what PKTMUX is up to and its various counts. Any count whose name is in CAPITAL letters indicates data being lost or discarded because there is a problem and the following attempts to explain what they mean. Note that such counts are usually only displayed when they have a value so their absence indicates all should be well. The first class of problems is where PKTMUX simply does not work with an application. The first test is to run the application on its own having loaded PKTMUX with the /x option. Normally in this situation PKTMUX would pass data direct to the application but with the /x option (multiplex) it copies data to its buffers and uses its multiplexing facilities thus checking if they can cope with the application. If this fails then the application probably has some quirk that confuses PKTMUX. If it is a standard application that works elsewhere then you may have a networking set up that PKTMUX cannot cope with. A second test is to add the /c (copy) option to each PKTDRV - PKTSTATS will show /TX_Copy for that channel. This causes it to copy the data sent to the network into its own buffers and this has been known to cure problems related to the use of upper and/or EMS/XMS memory. Where an application works with PKTMUX as above but not in conjunction with other applications then it is worth trying different combinations and seeing what does and does not work. This may isolate one application as being the problem or show a certain loading order to be the cause. Possible reasons are that a listener for a well known port is being usurped by another application (see PKTDRV /l option) or that one application simply prevents any other from running. Check the Bugs/Features and Problem Programs section for any indication of problems. It is also worthwhile checking if anyone else has a similar problem. Another class of problems is where PKTDRV is marked Busy when it should be Free or there are no Free PKTMUX channels. This is usually due to applications failing in some manner and the means of recovery are described in the Channel Management part of the Technical Description section. The final, and probably the largest, class of problems is where everything works for a while then things start going wrong. Using PKTSTATS can give an indication of the cause but in general it is only those cases where the problem can be reproduced that a solution can be found with any degree of certainty. Note that PKTMUX depends on probability for its successfull working and when the odds are wrong it will fail for no apparent reason. However for regular failures the suggestions below may help. If the /b option is in use on PKTMUX it should be removed to see if this is the cause. If you are running under a control program such as Windows 3 or DESQview then check that the application is getting a sufficient percentage of the processor especially if the application starts failing when running in the background. For Windows 3 a Background Priority of anything less than 50 can lead to problems and check that Execution in the Background is enabled. Also check that applications running in a DOS box have their own PKTDRV and are not using one loaded before the control program. This is shown by PKTSTATS and the PKTDRV entry at the start should have a /Win or /DV against it. If it has /DOS_to_Window then you are using a PKTDRV loaded before the control program and this should only be the case for applications that run under the control program such as WINQVT under Windows 3. A general technique is to run PKTSTATS /a and note the various counts. Then run the application(s) that cause the failure and subsequently run PKTSTATS /a again and note which counts have increased. This could give a clue about whats going wrong as detailed below. A possible reason for an application not working properly is that it, or PKTMUX, has run out of buffers with which to receive data. This is especially prevalent under a control program such as Windows where applications do not get enough CPU time to process their data. Details of buffer usage are given in the "Buffers:" table and for the case of PKTMUX running out of buffers the count "PKTMUX NO BUFFER" is given in the "Recv ignored reasons" line. Increasing the number of buffers used via the /1 to /9 options on PKTMUX should solve this one. Detecting that the application is running out of buffers is more difficult since PKTMUX may not be able to deliver the data for a variety of reasons. This can be isolated by running the application on its own over PKTMUX (without the /x option). As it has only one channel operative PKTMUX just passes all calls directly to the application. Any refusal by an application to supply a buffer causes PKTMUX to copy the data into its own buffers. This is shown in the Copied count on the "Recv total" line and and in the "Recv copy reasons" line. The PKTDRV channel counts also show the copied count for each channel. The only solution is to increase the applications buffers if this is possible. When PKTMUX has more than one channel Busy, and has to wait to pass received data to an application, this is also recorded in the PKTDRV table. The wait reason is either no buffer available from application (Buff) or, under Windows 3 or DESQview only, the application was not in memory (App). For the Buff case if the /d option is given then the data is discarded and the "Dropped" counts increamented. The App case is especially prevalent for background processes paticularily when a foreground process requires a lot of CPU. When it has to wait PKTMUX has to decide whether to try again later or discard the buffer. The latter is only done when PKTMUX has several channels that are actually moving data at the same time and it has insufficient buffers to meet all their demands. The "LOST" count in the "PKTDRV channels:" table would be incremented in this instance and again increasing the number of PKTMUX and/or application buffers is a possible solution. The count in the "Queues" section "LOST DUE TO APPLICATION ....." sums this total for all channels. It may be that, especially under Windows 3 or DESQview, the PC has simply not enough horsepower to cope with the communications load as well as any processing in progress at the same time. Thus the application(s) are not processing the received data fast enough to cope with the incoming rate. Alternatively it may be an application, such as TRUMPET, that refuses to accept packets when it knows it is not expecting data. Note that the /d option can significantly increase this count since packets are throw away at the first refusal. Another reason that data may be discarded is when there is no listener for the service that is being requested. The count "NO LISTENER" is incremented in the "Recv ignored reasons" list. There are several possible reasons for this but in general it is because the /l and /!l options on PKTDRV calls dont leave a suitable listener. Note that this count will not be incremented if there is a listener available but it does not support the service requested. In this case an application that supports the service must be run with a PKTDRV that routes requests for the service to it by using the /l or /!l options. A final reason for discarding data is when an IP Fragment arrives out of order. If it arrives before the first fragment then PKTMUX has no way of knowing to which channel it belongs and so discards it and increments the count "NO FRAGMENT" in the "Recv ignored reasons" list. The subsequent retry should overcome this problem provided that this time the first fragment arrives first. 9. Bugs/Features and Problem Programs ===================================== The following list of situations that need special action. It is based upon limited experience so only covers a few cases at present. The 16 bit BICC ethernet cards require the /c option on PKTDRV when running under a control program and dont work with WINPKT. The /c is not required when under DOS but is needed when a protocol stack such as PCTCP is run under DOS for a Windows 3 application such as Vista eXceed X Windows. When the X Window server Vista eXceed is running over PCTCP it must have enough buffers allocated via the ETHDRV command otherwise the call will be reset at intervals and thus fail. An ETHDRV call similar to the following is recommended: ethdrv -t 10 -p 20 Further details are given the Vista eXceed and PCTCP manuals. It may also be necessary to increase the PKTMUX buffer allocation when using this or other X Windows servers. PKTMUX will not work with the packet driver version of Novell IPX if the PKTDRV is using Interrupt 64. This is because Interrupt 64 is a Novell API and so from v1.1 onwards it is not allocated by default. IEEE802.3 support can give problems with other protocols due to the overheads it imposes. In particular Novell running over Type 8137 protocol has been found to crash in this mode. PKTMUX tends to operate a lot with interrupts disabled. This may cause problems with time critical communications methods such as asynchronous links using SLIP and ethernet communications via the PCs parallel port. TRUMPET refuses to accept packets when it is waiting for user input and expects no more data. This can cause PKTMUX to run out of buffers under heavy loading. It is recommended that the /d option be added to the PKTDRV used by TRUMPET. When PC-NFS is in use alongside PCTCP then a TSR, such as the MOS2 3270 emulator, is unable to run when the PCTCP FTP program is waiting for a command. The problem does not occur with the CUTCP FTP so it appears to be related to the wait loop used by the PCTCP FTP when waiting for a command. 10. Differences in PKTMUX versions ================================== 10.1 Version 1.0 ---------------- First release to prove that the techniques worked. Note this version does not support IP Fragmentation. 10.2 Version 1.0a ----------------- PKTMUX now checks that it is loading on top of a real Packet Driver and aborts if it finds its actually a PKTDRV. 10.3 Version 1.1 ---------------- The programs from this version must not be mixed with those from version 1.0 as they are incompatible. In searching for a Packet Driver PKTMUX now checks the interrupts to see if PKTMUX or PKTDRV is already loaded and aborts if one is. Similarily if the Packet Driver interrupt is specified this is checked to see if it is a real Packet Driver. This is to prevent multiple loadings of the system. The option /o (override) has been added to PKTMUX to override this restriction. PKTMUX now starts by default with 2 channels. PKTDRV options /f and /!f have been added to force a PKTDRV to the Free or Busy state. The PKTSTATS output has been changed to reflect this. PKTDRV no longer uses Interrupt 64 by default as this clashes with a Novell API. IP Fragmentation was not supported in previous versions. It is now supported within limitations (see Technical Description). The buffer management system has been improved especially with regard to discarding unwanted packets. The option /d (drop) has been added to tell PKTMUX to drop all packets for which the application has no buffer rather than keeping them until the application has space. The same option is available on PKTDRV which works on a per channel basis. The number base of buffers has been also been increased in some cases. A bug in the Packet Driver handle mapping when PC-NFS was in use has been fixed as has one in the area of duplicate handles. A bug in the mapping of ICMP packets onto channels has been fixed. The bug caused ICMP packets containing IP data to be sent all channels. PKTMUX v1.0 used a time out mechanism to determine whether a PKTDRV and its application had been forcably terminated under a Windows or DESQview environment. Unfortunately this mechanism was also triggered when the window was Selected under Windows 3.0 for actions such as cut and paste and caused the channel to be closed down. This has been changed in v1.1 so that in these circumstances a channel will not be closed down. The option /r has been added to PKTMUX to reset such channels otherwise they are permanently busy and there is no PKTDRV to reset them. A third parameter has also been added to PKTMUX to reset such channels after a given time. ARP Request Broadcasts are now sent to all channels. The /la option is therefore no longer needed. The handling of Broadcast packets has also been improved so that only those ARP requests that are not for this address are discarded. BOOTP did not work for second and subsequent channels because it replies on a well known port and this only went to the first listener. This has now been changed and the response is sent to originator of the BOOTP provided no other channel has done a BOOTP in between. If this occurs then the timeout and retry mechanisms should recover the situation. The problem solving section has been improved and the /x option (multiplex) added to PKTMUX to assist this process. 10.4 Version 1.2 ---------------- The maximum number of channels has been increased to 8 in order to improve the flexibility under Windows 3. If a Channel is in a timed out state then further channels can still be opened without reaching the maximum. The /q, /v, /e and PKTDRV /n options have been added and should enable a BAT file to work out the current state and load programs as required and this is illustrated by examples. Details of the options follows. The option /n on PKTDRV only loads PKTDRV if it is needed, that is if there is not already a Free one available, and reports the result via the DOS ERRORLEVEL. The option /q has been introduced on PKTDRV, PKTMUX and PKTSTATS in order to query the current state and returns the reply in text and the DOS ERRORLEVEL. PKTSTATS indicates the presence of a Packet Driver, PKTMUX and PKTDRV (Free or Busy). PKTDRV and PKTMUX return the state of their own program. The /v option causes the DOS Environment variable PKT_INT to be set to the hexadecimal value of the interrupt used or found by PKTDRV, PKTMUX or PKTSTATS when executing a command. The /e option extends the search under a control program to outside the DOS session and helps in determining whether a PKTDRV is running within the DOS session or not. The repeatable /s (silent) option has been introduced to reduce the output from PKTMUX, PKTDRV and PKTSTATS. /sss inhibits all output, /ss all but errors and /s lets through warnings as well. The /b option to reduce packet copying by trying to locate the data in the Packet Driver has been added. This can may give improved performance which in the case of IEEE 802.3 can be dramatic. This is a test implementation for evaluation purposes. Support for a channel using IEEE 802.3 over Packet Driver Class 1 is now included via the /i option on both PKTMUX and PKTDRV. This feature allows PKTMUX to support the RAL LLCPKT product instead of using LLCPKT2 and with the /b option can be very much more efficient. This is a test implementation for evaluation purposes and, depending on feedback, a better implementation may be incorporated in a future release. A bug in PKTDRV whereby the /d option did not work has been fixed. A bug in PKTDRV and PKTMUX whereby they could not be run by LOADHIGH when there was a limited amount of upper memory has been fixed. A bug in correct allocation allocation of buffer memory in such circumstances has also been fixed. PKTDRV and PKTMUX now release all their file handles so frequent unloading does not cause you to run out. A bug which caused WINQVT to crash the PC if it was run twice has been cured. This fix should cure problems with any Windows application which uses a DOS TSR (PKTINT in the case of WINQVT) to interface it to a Packet Driver. The decision criteria for sending a packet direct to an application rather than copying it has been improved. The algorithm whereby packets held in the buffer queue were dropped after a certain time has been improved. Packets are now held until the application requests them provided there are sufficient free buffers left. The numbers and sizes of buffers has also been revised in the light of experience. The filtering of broadcasts and especially ARP requests has been improved. Bugs in the handling of ICMP messages have been fixed. PKTMUX now copes with features in both NCSA and B&W software where unusual Access commands are made. PKTDRV actions on another PKTDRV such as /r, /u and /t are now checked under Windows and DESQview to see if they are being done on a PKTDRV that was loaded under DOS and refused if so. PKTSTATS output now gives more information especially that relevent to the effect of the /b option. 10.5 Version 1.2a ----------------- This fixes a bug in the /i (IEEE802.3) code which caused it to crash the PC. 10.5 Version 1.2b ----------------- The programs from this version must not be mixed with those from other versions of PKTMUX as they are incompatible. This is now checked for. The /w# option has been added to support those applications that use the ethernet board IRQ to drive them. Examples are B&W NFS and Wollongong NFS which run very slowly over PKTMUX unless this option is given on their PKTDRV. PKTMUX now works over the packet driver interface (DIS_PKT.GUP) provided under Windows for Workgroups. 11. Support =========== PKTMUX is supplied free and is supported, within the limits of its specification, for all users at RAL on IBM PC and PS/2 computers and near clones. Note that support is confined to bugs in the programs and clarification in the documentation of the systems limitations. Users outside RAL are requested in the first instance to obtain copies and help from their normal support sources. Academic user support organisations may seek help from RAL but the latter will only be given on a 'best endeavours' basis. There is no support for other organisations other than by private arrangement with the author. Updates of the software may be file transferred from the binary file PKTMUXxx EXE (xx being version number without a point - currently 12) on the RAL IBM mainframe (UK.AC.RL.IB on JANET, IB.RL.AC.UK on the Internet) disc PCSOFT 192. Be warned that the IBM file and disc naming format uses a space between the parts of a name (eg PKTMUX12 EXE and PCSOFT 192) when they are accessed by a user logged into the machine and this is replaced by another character, usually a full stop (.), for external access such as FTP (eg PKTMUX12.EXE and PCSOFT.192). Thus from the Internet an Anonymous FTP user should CD to PCSOFT.192 and binary GET PKTMUX12.EXE. Executing the file will produce the program and documentation. Bug reports or problems should be reported, ideally by email, to Graham Robinson: Via JANET : GWR@UK.AC.RL.IB G W Robinson Via Internet : GWR@IB.RL.AC.UK Atlas Centre UK Telephone : 0235 44 5636 or 6391 Rutherford Appleton Laboratory International: +44 235 44 5636 Chilton, Didcot Oxon,OX11 0QX,UK 12. References ============== The RAL LOADSYS system version 1.4 is held in file LOAD14 EXE on PCSOFT 192 as detailed above. It is a loader/unloader for both programs and device drivers. The RAL LLCPKT and LLCPKT2 systems are held together in file LLCPKTS EXE on PCSOFT 192. They map the BICC MPS ethernet interface onto a Packet Driver and are only of use to users of the Rainbow software. The RAL MOS2 IBM 3270 emulator version 2.3 is held in files MOS23 EXE, MOS23X EXE and MOS23Y EXE on PCSOFT 192. This TSR provides IBM 3270 emulation, EEHLLAPI and GDDM-PCLK support over asynchronous and ethernet communications.