SafeFire PPP

v.0.9 beta

Concepts Guide

Introduction

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:

  1. User interface module (usually .exe file). Provides local user interface. Simple change of the module can give you new UI. For now sfppp.exe implements OS/2 command line UI.
  2. Manager module. Connects and manages all other module types.
  3. Plugin Libraries (usually pl_*.dll files). Plugin libraries implement muliple plugins, in most cases of the same functional category (See section about plugins below and SafeFire PPP Plugin Reference to get details).
  4. Rexx modules. They can be used by any of the modules. Manager provides basic REXX SFPPP API. Other plugins may extend this API by its functions. (See SafeFire PPP REXX API Extension book for more details)
  5. PPP security submodules (usually pla_*.dll files). This modules are intented to provide different authorization and authentication sources for PPP plugins. Two modules are available for now:
Configuration file is used by manager to load, bind (connect) and configure Plugins. Single configuration file can be used to load multiple different configuration by specifying "starting section" parameter.

Plugins

SafeFire PPP are to be used to input, process and output network packet streams. Modules are used to perform this task.

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:

  1. Filter modules
    They provides some data transformation and usually has two or more Stream Packs. The examples are: PPP NCPs (like CCP), Filter, NAT, etc.
  2. Gateway modules
    They provide gateway for SafeFire to external packet sources. Gateways can be divided into two groups: Exteral device gateways and Internal stack gateways.
External device gateways give access to external computer network modules like Eternet cards, Serial connections or ISDN adapters.

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

Configuration

SafeFire PPP is fully configured by a special configuration file. This file describes what plugins to load and its configuration. Configuration file consists of sections and each section can have multiple "parameter=value" lines that makes up configuration.

Plugin Instances

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

To allow plugins to perform tasks they are designed for, all plugins should be connected to each other. Connecting process is called 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:
ElementOptionalityDefault valueDescription
<name>requiredThis instance's Stream Pack name
[<startidx>]optional
0
This instance's starting connection index
<bindinstance>requiredConnected instance's name
<bindname>requiredConnected instance's Stream Pack name
<startbind>optional
0
Connected instance's starting connection index
,<bindnum>optional
1
Number of sequental connections to make.
[<startbind>,<bindnum>]optional
[0,1]

It is possible to have multiple "<bindinstance>.<bindname>[<startbind>,<bindnum>]" parts divided by ";".

This complex rule will be documented in two steps:

  1. Transforming fully specified rule into multiple "BIND=<name>[<startidx>]:<bindinstance>.<bindname>[<startbind>]" rules.
  2. BIND=<name>[<startidx>]:<bindinstance>.<bindname>[<startbind>]
    rule in <instname> Plugin Instance makes connection between <startidx> stream of the <name> Stream Pack of the <instname> instance to <startbind> stream of the <bindname> Stream Pack of the <bindinstance> Instance.

Loading

As you can see, there are two possible bind statements that makes connection from A to B:
BIND=APACK[AIDX]:B.BPACK[BIDX] in section A or
BIND=BPACK[BIDX]:A.APACK[AIDX] in section B.

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:

  1. Load Starting Instance as specified by UI module parameters (sfppp.exe default Starting Instance name is "PPP")
  2. Load all Instances that are binded using binding statements from Starting Instance section.
  3. Repeat loading Instances that are binded to already loaded Instances from its section.
Example:
If we have the next configuration file (Only section names and binding statements provided):
[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

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].
Return to documentation index SafeFire PPP (C) Link Guard Solutions 1999