Home
News
Introduction
Documentation
Download
Mailinglist
Sysop Registry
Developer
|
FlexNet driver documentation
IPPD - AXIP driver
|
AXIP driver.
Warning: Configuring this driver is complicated. Knowledge
on TCP/IP is required to use the driver.
This driver encapsulates AX25 packets with an IP header and sends them
via a packet driver on an ethernet network. The method used is described
in RFC1226 and therefore compatible with the derivatives of KA9Q, such
as WAMPES, WNOS and JNOS. The driver accesses an already resident ethernet
packet driver.
-h, -? |
description of the parameters |
-i |
interrupt number of the packet driver |
-c |
This driver supports multiple channels and therefore multiple peer
stations. The maximum number of channels must be specified at driver installation
time. Only the first channel (channel 0) may be configured from the driver
command line, the other channels must be configured after activating PC/FlexNet
(with FLEX) using the application IPPDCFG. The channel
configurations may be altered at runtime. Default is one channel. |
-m |
own IP address (required) |
-p |
peer IP address (required) |
-g |
gateway IP address. All packets are sent to the gateway. Optionally,
the ethernet address of the gateway may be specified, separated by a comma,
in colon notation. This suppresses the ARP query of the gateways (or peers)
ethernet address at driver startup. |
-u |
Instead of encapsulating AX25 packets into RAW IP packets, UDP packets
are used. This uses 8 additional bytes per packet and is supported for
example by WAMPES. This option was implemented since some Linux hacker
kernel versions had problems with RAW sockets. UDP sockets are much less
prone to such problems since some very important services such as the DNS
(Domain Name Service) also use UDP sockets. RAW sockets are used quite
seldom. An optional port number may be specified, default is 93. |
-r |
Uses RAW IP encapsulation. An optional protocol ID may be specified,
default is 93. This is the default setting. |
This driver supports multiple channels. There are however situations,
where one nevertheless wants to load multiple IPPD:
- One IPPD driver uses one single IP address as the own address,
only the IP addresses of the peers may be specified independently.
- The driver only contains 6kByte buffer. This buffer is emptied by PC/FlexNet
normally every 55ms. If a very fast link must be serviced, it may pay to
put it onto a separate IPPD driver. If the buffer overruns, the QTY value
in the FlexNet infobox drops and the RX Overrun value in the driver statistics
increases.
If IPPDCFG is called without parameters, it displays a list
of all IPPD drivers found and of all channels. IPPDCFG with parameters
sets a channel. All the parameters of the driver may be used (without -i
and -m), and the following parameters are new:
|
|
|
if multiple IPPD drivers are loaded, this parameter distinguishes between
them. The last loaded driver has the number 0
|
|
|
This driver was developed to connect PC/FlexNet with a KA9Q derivative
over a LOCAL net. This leaded to simplifications.
The ARP implementation is minimal. At driver startup, the ethernet address
of the gateway is queried. If no answer is received during about 10 seconds,
the driver issues a warning and tries to get the ethernet address about
once every minute. ARP packets sent to the broadcast address are monitored
and evaluated. The driver responds to ARP queries during the driver run.
IP is also simplified. IP fragmentation is not supported, since
this would complicate the driver very much (it would need timers and reassembly
buffers). So all networks between the two stations must have a minimal
MTU of about 300 bytes! So the driver is not suited to build wormhole
links to australia. Only IP version 4 is understood (the currently usual
version). The protocol number used is 93 (consistent with RFC1226). The
TTL is fixed 64. IP options are not sent. For security reasons only packets
where both IP addresses match the expected ones are accepted. It is thus
not possible to realise broadcast nets as with IPXPD.
Only ICMP Echo Request messages will be decoded and answered with an
ICMP Echo Reply message. Other ICMP messages will neither be generated
nor received.
|
page created by
Thomas Sailer <sailer@ife.ee.ethz.ch>
last updated:
|