home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
CICA 1994 September
/
CICA_Shareware_for_Windows_Walnut_Creek_September_1994.iso
/
win3
/
util
/
pktmux12.exe
/
PKTMUX.DOC
< prev
next >
Wrap
Text File
|
1993-01-29
|
118KB
|
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.
