SafeFire PPP was designed to became the most powerfull comunication suite. So it is internal architecture was carefully designed to implement high flexibility and extendability. To achieve this goal its structure was divided into multiple modules. This next module types is used in SafeFire PPP:
allows REXX module to be used for security functions. Some REXX modules provided to make an example and be used in simple cases.
Uses OS/2 User Profile Magement for security checks.
Note: It can't be used with CHAP authentication due to certain UPM limitations.
Module is fully independent piece of software that has some Stream Packs ("input/output" plugs) to peform module function. Each module performs its own data processing.
There are two main module types:
They provides some data transformation and usually has two or more Stream Packs. The examples are: PPP NCPs (like CCP), Filter, NAT, etc.
They provide gateway for SafeFire to external packet sources. Gateways can be divided into two groups: Exteral device gateways and Internal stack gateways.
Internal stack gateways make connections to internal protocol stack. They are identified by stack as virtual adapters (i.e. lanXX for Eternet or pppXX for Serial PPP connection in TCPIP stack).
Usually binding route from Device gateway must lead to Stack gateway (only if you has 'Stack-like' filter module that can implement partial or full Protocol Stack functionality you can connect Device <-> 'Stack-like' <-> Device).
One of the main SafeFire PPP features is that MULTIPLE External devices can be connected to a single Stack gateway (via a special routing plugin) and so you can overcome some internal OS/2 limits for a 8 lanXX adapters or 32 pppXX adapters. Single instance of routing plugin can group up to 65535 External devices and there can be multiple instances of plugin loaded.
Beta Note: Routing plugin is not implemented yet.
Modules are grouped by its categories into Module Libraries. You can find the next Module Libraries in the SafeFire PPP 0.9 beta package:
Library | Name | Type | Comment |
pl_ppp.dll | Provides PPP External and internat gateways plus some PPP NCPs | ||
PPPPort | External device gateway | Used to establish PPP connection over serial device (Modem, NullModem, ISDN emulated com ports) | |
PPPOE | Filter | Used to make PPP connection over Ethernet LAN | |
PPPSTACK | Internal stack gateway | Makes up a Point-to-Point OS/2 TCPIP stack adapter (i.e. pppXX) | |
CCP | Filter | Implements CCP NCP (Compression protocol) | |
pl_alias.dll | NAT | Filter | Implements Network Address Translation (NAT) functions |
pl_flt.dll | FILTER | Filter | TCP/IP Packet filter module |
pl_serv.dll | SERVICE | Filter | Implements different utility functions |
pl_templ.dll | PL_TEMPL | Filter | Sample filter. Does no processing. Can be used when "null" plugin needed |
While Plugin is piece of software, Plugin Instance is loaded and configured plugin. It is possible to have multiple instances of the same plugin loaded at one time. Each Plugin Instance identified by a section in configuration file. Section name is Instance's name. "LOAD" parameter tells SafeFire PPP what Plugin to load to make up this Instance. All the other parameters identifies Instance's configuration.
Here is format of "LOAD" parameter:
LOAD=<Plugin Library>:<Plugin Name>
Example: "LOAD=PL_PPP:PPPPort".
Binding
Each module has one or more named connection "plugs" to make connection to it. They are called Stream Packs. Each Stream Pack defines functionality or type of the data that will be passed to or from it.
Example: CCP Plugin has two Stream Packs: "DATA" and "COMPRESSED". It defines that all the data from "DATA"-connected stream will be compressed and put to "COMPRESSED"-connected stream. And visa versa - all the data from "COMPRESSED"-connected stream will be identified as compressed: CCP will try to uncompress it and put to "DATA"-connected stream.
It is possible to connect multiple streams to a single Stream Pack. Each stream must be connected to its unique connection index. You can connect up to 65535 streams (with connection indexes from 0 to 65534) to a single Stream Pack.
Note: Support and Processing of multiple-connect feature are fully dependant of the Plugin itself. You must check Plugin's documentation to find out if you can connect multiple streams to a single Stream Pack and how Plugin will process this connections. If not otherwise specified you must not make connection to the index other than 0.
All bindings are configured by a "BIND" parameter in configuration. Each plugin section may have multiple "BIND" parameters and all of them will be processed as distinct binding definition.
Here is format of "BIND" parameter:
BIND=<name>[<startidx>]:<bindinstance>.<bindname>[<startbind>,<bindnum>];...
where:
Element | Optionality | Default value | Description |
<name> | required | This instance's Stream Pack name | |
[<startidx>] | optional | This instance's starting connection index | |
<bindinstance> | required | Connected instance's name | |
<bindname> | required | Connected instance's Stream Pack name | |
<startbind> | optional | Connected instance's starting connection index | |
,<bindnum> | optional | Number of sequental connections to make. | |
[<startbind>,<bindnum>] | optional |
It is possible to have multiple "<bindinstance>.<bindname>[<startbind>,<bindnum>]" parts divided by ";".
This complex rule will be documented in two steps:
BIND=<name>[<startidx>]:<bindinstance>.<bindname>[<startbind>,<bindnum>];X
(where X is any number of "<bindinstance>.<bindname>[<startbind>,<bindnum>]" parts) is equal to the next two rules:By performing this recursively we will get multiple
- BIND=<name>[<startidx>]:<bindinstance>.<bindname>[<startbind>,<bindnum>]
- BIND=<name>[<startidx>+<startbind>]:X
BIND=<name>[<startidx>]:<bindinstance>.<bindname>[<startbind>,<bindnum>]
rules.Example:
BIND=DATA[15]:stack.port[23,4];filt.stack[13,10];cpp.compressed[1,5]
will be transferend intoBIND=DATA[15]:stack.port[23,4]
BIND=DATA[38]:filt.stack[13,10]
BIND=DATA[51]:ccp.compressed[1,5]where 38 = 15 + 23 and 51 = 38 + 13.
BIND=<name>[<startidx>]:<bindinstance>.<bindname>[<startbind>,<bindnum>]
is equal to the next serie of <bindnum> simplier rules:
1 BIND=<name>[<startidx>]:<bindinstance>.<bindname>[<startbind>] 2 BIND=<name>[<startidx>+1]:<bindinstance>.<bindname>[<startbind>+1] ... <bindnum>-1 BIND=<name>[<startidx>+<bindnum>-2]:<bindinstance>.<bindname>[<startbind>+<bindnum>-2] <bindnum> BIND=<name>[<startidx>+<bindnum>-1]:<bindinstance>.<bindname>[<startbind>+<bindnum>-1] Example:
BIND=DATA[15]:stack.port[23,4]will be transfered intoBIND=DATA[15]:stack.port[23]
BIND=DATA[16]:stack.port[24]
BIND=DATA[17]:stack.port[25]
BIND=DATA[18]:stack.port[26]
This two statemets produces equal connection (A.APACK[AIDX]<->B.BPACK[BIDX]). The only thing that makes difference is Loading.
During loading of Instances not all Instances in the configuration file will be loaded. The algorithm of loading composed from the next steps:
If we have the next configuration file (Only section names and binding statements provided):Note: It is not possible to bind two times to a single Connection Index. I.E. in the example above you can not load both A and E because this will produce duplicate connection to B.BPACK[0].
[A]
BIND=AOUT:B.BPACK
[B]
BIND=BOUT:C.CPACK1
[C]
[D]
BIND=DOUT:C.CPACK2
[E]
BIND=EOUT:B.BPACK
[F]
BIND=FOUT1:D.DPACK
BIND=FOUT2:A.APACK
We can load the next configurations:
Starting Instance Loaded Instances A A,B,C B B,C C C D D,C E E,B,C F F,D,C,A,B
Return to documentation index | SafeFire PPP (C) Link Guard Solutions 1999 |