__FILES__________________________CXR__________________________________
5. FILES
The files are used to define the operation and administration of the device.
They contain: the initialization of the variables (cf. chapter VARIABLES), the
operating options for the modes and protocols and the
device's configuration commands. The lines contained in the files cannot
exceed 80 characters.
The administration of the actual files is accessible using the ls command,
given that these files are stored in the configuration memory (E2 prom or Flash
depending on the model).
The user can create certain files that are not included in the
standard shipment using the eestore command.
The creation of files starting with the '_' character is forbidden.
There are a number of files whose name starts with '_' that cannot
be modified and that will be used automatically when
files required for the device's minimal operation are destroyed
(e.g.: complete reset after losing the password).
If the name of file starts with "__", it is a file "by default";
a file "by default" is a file whose contents, in most cases,
do not need to be modified, but which can, exceptionally,
contain other data. To be able to replace the original data, you
will copy the contents of "__xxxx" in "xxxx" (command "cp"). As for the "xxxx" file,
it can be edited as with any file contained in the configuration
memory.
The modification of some files can be taken into account
immediately (e.g.: file "secret"), as opposed to others which require you
to reboot the device (e.g.: admin) or use commands with
certain options (e.g.: "orion -r" for the "fip" file). The name of these
files is followed by the mention "(dynamic)" in the manual.
A file with the suffix ".gz" (e.g.: pad.prf.gz) represents a file
compressed using "gzip". To decompress its contents, simply
request the file without the ".gz" extension (e.g.: cat pad.prf); the
file system will then decompress this file automatically
for reading.
[access]
contains the authorizations or inhibitions for using different
local TCP/UDP/ICMP services offered by the device; this makes it possible
to filter the device's incoming and outgoing communications.
This file is read when the system is reset; after any modification,
you must reboot the device in order for the modification
to be taken into account.
The file's structure is as follows:
command:
adr_machine
adr_machine
command:
!adr_machine
!adr_machine
where
command is a command name using one of the TCP, UDP or
ICMP services such as telnet, telnetd, tftp, tftpd, printerd, time, route, ping. The
':' character that follows the name of the command is imperative.
adr_machine is the address of a machine either in numeric format or with
a symbolic name if this name is defined in the hosts file. This declaration
authorizes the processing of commands by the machine with the adr_machine. If at least
one machine is authorized for a command, the list of all the
authorized machines must be specified.
!adr_machine is used to forbid the processing of commands by the machine
with the adr_machine. Here, the user must specify the list of all
the machines forbidden for commands.
Example:
ping:
123.45.67.89
telnetd:
!98.76.54.231
!89.67.45.123
tftp:
server
!89.67.45.123
In this case:
1. Only machine 123.45.67.89 is authorized as the destination of the
device's ping command.
2. All the machines, other than 98.76.54.231 and 89.67.45.123, can
connect to the device via telnet, whereby the tcpcomd daemon must be active.
3. Only the server machine can be given as an argument of the vtftp command
on the device.
Violating the authorization for an outgoing command will initiate the display
of the message "machine unknown", while an incoming connection will be unsuccessful.
Thanks to the ADDRTEST variable, this file can also be used to simply
filter routed frames.
[admin]
contains the system's different variables and those of the operation. This
file is read when the system is reset; it serves to associate
values with the variables defined (cf. chapter VARIABLES). In this file, the
variables are defined as follows: variable = value with no space or separation tabulation
on either side of the = sign, nor in the value field.
INITTAB=inittab
associates the inittab value with the INITTAB variable.
[aliases]
contains the definition of the aliases used by the shell. These declarations
are used to define command synonyms possibly accompanied
by parameters. The syntax of a line in this file is:
alias command [parameters]
Example of the contents of the alias file:
clear cls
c connect 3615
d disconnect
ATTENTION: these definitions are only accessible in an interactive shell
session, but not in the files (inittab, crontab, etc.).
This file contains the orders to be executed to initialize an external
modem. The 'i' placed as a suffix after the filename represents the relevant channel.
In this case, a modem is connected on the "serial" link and is used
to transfer data (see file "numip" and "Ci_Annn_script"
in the "num" part). When the device is reset, this
file is executed like a script. The character string(s)
that is/are to be sent to the modem will be sent using the "send" command and,
if waiting for an answer is necessary, the "wait" command will be used.
This file's use has been extended, in a
general manner, to commands that use the synchronous port such as asyncd,
paf, etc.
For greater flexibility, you can use the concept of a
section inside this file.
The section used for the channel's first initialization is represented
by a line starting with the sequence "[initialization]".
The section used at the closure of the channel is represented by
a line starting with the sequence "[closure]".
When the line is free, the section used when the CTS signal
changes from low to high is represented by a line starting with the
sequence "[cts/]".
Everything included between the start of the file and the description
of the first section will be executed when the channel is initialized
and closed.
If the "asini.1" file (for example) does not exist, the system will search
for an "asini" file for the same purpose. This "asini" file can be used
for all the channels available in the case where there is no "asini.xx"
(where xx is the channel number) file in the configuration.
[backup]
This is a highly specific file. In fact, it is not just a file,
but a group of files: the file with this name contains
all the configuration's files. It cannot be edited since
it contains non-ASCII characters, however it can be used to back up or
restore the entire configuration in a single transfer.
Some utilities (see sources in C language available from
your distributor) can be used to extract files contained in
"backup", then reassemble them to obtain a "backup" file again.
Note that when loading this file, all the previously recorded data
in the device's configuration will be deleted; the
data contained in the "backup" file will then be installed.
To back up or reload a configuration, use the
vtftp and ftp commands or the vtftpd and ftpd daemons.
Note that all the files must be closed before retrieving
a global configuration. If a file is open, you will get an error (access
rights) when writing to the backed up memory.
NB: do not use the "backup" file of one model in the range
to quickly configure another model. Some values can be
very different and the mismatch with the model can be fatal to
proper operation. However, this operation is possible
provided you immediately remodify the important values.
[bootptab]
This file contains the configuration of the bootps daemon. In it you will find the parameters
contained in the replies, the static addresses and the range of
dynamic addresses.
[crontabs]
contains the commands to be run off-line by the cron daemon. The syntax of
each line is:
minute hour day_of_the_month month_of_the_year day_of_the_week command
This syntax is exactly the same as that of the Unix crontabs/* files.
[fip]
contains the description of the filter used by the "orion" command and
certain operating options.
The recognized operating options are:
r_delay size[,time]
- where "size" indicates (in Kb, value 4 by default) after what
amount of bytes sent, for the delayed frames (see
below), you must ask the system to slow down the exchange.
To delay the exchanges concerned, you usually use an
ICMP/Source_quench frame (slowdown request) sent
to the sender. Some machines may take a while
to react and make this effect inoperative; in this case, instead
of sending this ICMP information, you can remove the last frame received,
which provokes an absence of acknowledgement and forces the sender
- after a few moments – to resend the frame (all data
managed by TCP). This delay makes it possible to slow down the exchange. This mode
is selected by assigning a negative value to "size".
- where "time" indicates (in seconds, value 1 by default) after how
much time the device should consider that it must
no longer slow down the exchanges, since only frames considered as "slowed down"
travel on the link.
When this function is used, the size of the frames
is accounted for.
If the number of bytes of "slowed down" frames exceeds by "size" Kb
the number of bytes of "normal" frames, and "delay" seconds
has not expired, a slowdown procedure is activated.
If only slowed down frames are travelling, no such procedure is
activated.
log
indicates that you wish to create a table of the
device's use by the machines on the LAN.
For each machine on the network, to each
IP frame is added the count of bytes sent in a table indexed
by the last part of the local machine's address.
The rejected frames are not accounted for.
Unless they are filtered, the frames being sent
are also accounted for.
This table can be displayed and reinitialized using
the options in the "orion" command.
This table will only be created if at least one filtering line
is present.
The size of this table is defined by the natural mask of
the device's address on the LAN (il0).
The filter's description is given in the form of orders. In the first order
satisfied (all the conditions described met), the appropriate action
is executed and the next frame is presented to the filter.
Each order is delimited by an opening brace (start)
and a closing brace (end). The description lines must not
exceed 80 characters; an order can contain more than one
line. If a line contains the '#' character, the portion contained between
`#' and the end of the line will be ignored (comment).
Attention: if at least one filtering line is valid, the last line
of the filter will implicitly be:
{to=RE,S}
The following keywords are recognized:
"from=" followed by "lan" or "wan" to specify whether this order
applies to a frame from the local network (lan)
or from the remote network (wan).
The absence of this information indicates that this order
applies, whatever the frame's source.
"from=" "from="
"tos=" through abusive simplification, the whole of the field containing
the "Type Of Service" is compared to the value provided
after the '=' sign. This field normally contains:
- 3bits specifying the size of the TOS
- 4bits specifying the value of the TOS
- 1bit which must be 0 in normal operation.
The absence of this information indicates that this order
applies, whatever this frame's TOS value.
"@src" represents the frame's source address.
It may befollowed by the '|' character which indicates that
you must perform a "logical or" between the source address
and the value that follows the '|' character.
It may be followed by the `&' character which indicates that
you must perform a "logical and" between the source address
and the value that follows the `&' character.
If a "logical or" and a "logical and" are
requested at the same time, the "logical or" will be performed first, then
the "logical and" will be performed on the result of
the previous operation.
Mathematically, the operation applied will be as follows:
(@src | value_or) & value_and.
If neither the "logical or", nor the "logical and" are requested,
the operation will be:
(@src | 0) & 0xFFFFFFFF, which is the same as @src.
If only the "logical and" is not requested, the operation will be:
(@src | value_or) & 0xFFFFFFFF, which is the same as
a @src | value_or.
If only the "logical or" is not requested, the operation will be:
(@src | 0) & value_and, which is the same as @src & value_and.
It must be followed by one of the character strings
below and a value:
"==" indicating strictly equal to between the expression
calculated and the value given,
">" indicating strictly greater than between the expression
calculated and the value given,
">=" indicating greater than or equal to between
the expression calculated and the value given,
"
<" indicating strictly less than between the expression
calculated and the value given,
"<=" indicating less than or equal to between
the expression calculated and the value given.
Outside the strictly equal to condition, you can
describe both a less than condition and a
greater than condition.
The value_or, the value_and and the resulting value can be written
in "dot notation" (e.g.: 255.255.255.0), in
hexadecimal (preceded by the "0x" string, e.g.: 0xFFFFFF00)
or using the following keywords:
- @iladdr (IP address of the Ethernet interface),
- @ilmask (IP mask of the Ethernet interface),
- @ilnet (network address of the Ethernet interface).
The absence of this information indicates that this order
applies, whatever the frame's source address.
"@dst" idem "@src", except that this information concerns the frame's
target address.
"prot=" followed by a protocol to specify that this order
applies to a protocol frame strictly equal to the
value given.
"protm=" followed by a protocol to specify that this order
applies to a protocol frame greater than or equal
to the value given (minimum protocol).
"protM=" followed by a protocol to specify that this order
applies to a protocol frame less than or equal
to the value given (maximum protocol).
Note that the use of the "prot=" keyword forbids the use of the
2 keywords "protm=" and "protM=", which will now have no object.
If only "protm=" is defined, the implicit value of
"protM=" will be 0xFFFF.
If only "protM=" is defined, the implicit value of
"protm=" will be 0.
The absence of this information indicates that this order
applies, whatever the frame's protocol.
"psrc=" followed by a port (logically linked to the protocol defined) to
specify that this order applies to a frame with
a source port strictly equal to the value given.
"psrcm=" followed by a port to specify that this order
applies to a frame with a source port greater than or
equal to the value given (minimum source port).
"psrcM=" followed by a port to specify that this order
applies to a frame with a source port less than or
equal to the value given (maximum source port).
Note that the use of the "psrc=" keyword forbids the use of the
2 keywords "psrcm=" and "psrcM=", which will now have no object.
If only "psrcm=" is defined, the implicit value of
"psrcM=" will be 0xFFFF.
If only "psrcM=" is defined, the implicit value of
"psrcm=" will be 0.
The absence of this information indicates that this order
applies, whatever the frame's source port.
"pdst=" idem "psrc=", except that this information concerns the frame's
target port.
"pdstm=" idem "psrcm=", except that this information concerns the frame's
target port.
"pdstM=" idem "psrcM=", except that this information concerns the frame's
target port.
"bits&" followed by a value (hexadecimal if starting with the
sequence "0x", octal if starting with "0" and decimal
otherwise) which validates the entry if, for
a logical AND with the contents of the FIPBITS variable,
you obtain a result other than 0. This makes it possible, without
reloading the filter and according to the outside conditions
(e.g.: time), to validate or invalidate the entry.
"to=" this keyword is not optional. It defines how
to route the frame. For this purpose, it must be followed
by one of the character strings below:
"CB" for a routing via a B channel,
"CD" for a routing via a virtual circuit (VC)
on the D channel,
"LL" for a routing via the synchronous serial line.
Depending on how the serial line is configured,
the frame will either be routed in a VC if it is
an X25 link, or it will be encapsulated in the protocol
defined on the link (e.g.: PPP),
"RE" to reject this packet,
"lan" for a routing to the local network,
"auto" for a routing according to the routing table, with
no constraints.
This keyword can be followed by different details given
in the form of character strings.
- the ",S" string to indicate that, if this packet cannot be
routed, it will be silently rejected, i.e., without sending
any ICMP frames indicating the rejection to the sender.
- the ",L" string to indicate that this packet must be
presented to syslog to inform the administrator of its
passage. Note that you are strongly advised against using
this option for all the packets, since the workload of both the device
and of the log machine would become needlessly high…
- the ",R" string to slow down the frames described, which
gives them a lesser priority.
If at least one order is valid,
the last line will always implicitly be: "to=RE,S", that is to say
that the non-described frames will be rejected. If the last
order line entered by the user is "to=auto",
the implicit order "to=RE,S" will have no effect.
"stat=" this keyword defines a condition on the routing link
indicated by "to=". The following conditions are
authorized:
"C" to only send the frame described if the
routing link is already connected,
"X" to send the frame described whatever the status
of the routing link.
The default value is "X", that is to say that the frames
will be sent whatever the link's status.
This information will have no object in the case where the value
of "to=" is "RE".
Example 1 of file "fip":
#order 1
{from=lan prot=icmp to=CD}
#order 2
{from=lan prot=tcp psrc=telnet to=CD}
#order 3
{from=lan prot=tcp pdst=telnet to=CD}
#order 4
{from=lan to=CB}
#order 5
{from=wan @src & 0xFFFF0000 == 172.21.0.0 to=RE}
#order 6
{to=auto}
- Order 1 directs the ICMP frames from the
LAN to ChannelD if the final destination can be reached by
this support. If the destination cannot be reached by this support, an
ICMP "machine unreachable" frame will be returned to the sender.
- Orders 2 and 3 impose the passage of the TCP/telnet frames from
the LAN by ChannelD, as with order 1,
if the destination cannot be reached, the sender will be informed.
- Order 4 imposes the previously non-described frames from
the LAN to use ChannelB.
- Order 5 rejects the frames from a remote network
if this frame's source IP address starts with 172.21
(wwxxyyzz & 0xFFFF0000 = wwxx0000).
- Order 6 indicates that the other frames must be routed
according to the routing table, with no particular constraints.
Example 2 of file "fip":
#order 1
{from=lan @src & @ilmask == @ilnet to=auto}
#order 2
{from=wan to=auto}
- Order 1 authorizes the frames from the LAN and belonging
to the network of the router's Ethernet interface to travel normally.
- Order 2 authorizes the frames from the WAN to travel
normally.
- Implicitly, the other frames will be rejected silently.
This filter is useful, for example, when the same physical network supports
several logical networks (different network IP addresses) and when you
do not wish to route those frames from the local network that do not belong to the
local network of the device's Ethernet interface.
Example 3 of file "fip":
#order 1
{to=auto}
#order 2
log
- Order 1 authorizes the transit of frames with no constraints.
- Order 2 is used to maintain a table that can be consulted using the
"orion -L" command, containing the use the machines on
the local network make of the router by accounting for the number of bytes sent
by the various machines.
This filter is an "all-pass" filter designed merely to enable
the recording of the use the machines on the network make
of the device.
contains the correspondence between the symbolic names of the machines and their
IP address in the form of lines with 2 or 3 fields:
adr_mach name_mach [alias_mach]
adr_mach address of the machine (in Internet 4-byte decimal format
separated by the character '.').
name_mach official name of the name.domain machine in the form of
uninterrupted character strings separated by '.'.
If this name takes the form "host.*", any request where "host"
corresponds will be served with the specified address, regardless
of whether or not the request contains the domain name.
alias_mach alias of the official name of the machine (in the form of an uninterrupted
character string).
For "name_mach" and "alias_mach", the following characters are authorized:
- letters (upper/lowercase)
- digits
- the characters '_' and '-'
The '.' character represents the separator between the name's different
parts.
Some names are reserved:
- localhost is always 127.0.0.1
- mx.domain see server "named"
The separation between the fields is either a space or the
tabulation character. The syntax is compatible with the file /etc/hosts on
Unix systems.
127.0.0.1 localhost
193.56.122.1 mymach.myplace.fr
Commands using this file: telnet, ping, netstat, etc.
To limit the number of entries present in this file, you can
use a Domain Name Server (DNS).
[codes]
This file contains the telephone codes used for channel
overflows (see variable OVERFLOW). Indeed, the overflow negotiation procedure
makes it possible to obtain the number to be called to establish the
overflow circuit. This number is provided with no code by the remote site; if a
code is required, it will be extracted from the number of the
primary channel by comparison with the codes provided in the
codes file.
Each line in this file specifies a code with a maximum seven digits.
Example: The codes file contains
0041
000949
If one of the B channels is connected to the number 000949113615 and if, for the
overflow attempt, the remote site provides the secondary channel number
113616, an overflow connection will be attempted with the
number 000949113616 on the other free B channel.
[inittab]
contains the different command lines to be executed when
using the system. You can give another file name
with the INITTAB variable.
[ipconf]
contains options for configuring the IP module.
You are strongly advised, except for specific applications,
to use this possibility; the default configuration is perfectly
adapted to normal device use.
The following parameters are modifiable:
keyword Unit Default Comment
tcp_keep_period second 45 period of TCP Keep Alive
tcp_keep_retry times 8 #Keep Alives with no answer accepted
tcp_keep_mode mode 1 TCP keep alive model **
**
mode 1: ack and seq are at -1 in relation to the last exchange
mode 2: only seq is at -1 in relation to the last exchange
[ipx.conf]
contains the configuration options of the IPX routing module when
the device works in IPX router mode (variable IPXNET(0). Each line only
contains one option followed by its parameters. These options are split
into several categories:
1/ option [num]
num is an integer defining a period in seconds. The default value of
num is 0.
saplan num
num represents the life duration of SAP information memorized in
the device. With no SAP announcement of a certain service for num seconds, the
service is announced to be unreachable to the remote devices connected, then is no longer
announced. The recommended value is CyberLS2 (2 minutes).
SAP service example: print service, remote console, etc.
sapwan num
like saplan but concerns the remote services. The recommended values are
0 for a switched connection and 240 for a permanent connection (leased line).
sapann num
where num is an integer defining the message period of the SAP services: to
the remote networks for the services detected locally, to the local network
for services announced by the remote router. The recommended value is
60.
riplan num
like saplan, but for RIP information (announces routings to the
internal and external networks). The recommended value is CyberLS2.
ripwan num
like sapwan but for RIP information. The recommended values are 0
for a switched connection and 240 for a permanent connection.
ripann num
like sapann but for RIP information. The recommended value is 60.
secann num
where num defines the period for sending IPX Serialization frames for the
remote services that are not on-line (remote device not connected). These frames
enable the servers to check that they are using software with a
unique licence number. The recommended value is 0 (no message). In
all cases, when the communication is established with a remote site, these
frames are sent.
triggered num
where num is an integer defining the message time for
modifications of SAP services or RIP routings to update remote sites
that are not connected. This mode, called triggered mode, is active if num is non-null.
The message for the modification of an SAP service or a local RIP routing is
deferred by num seconds before establishing the connection with the remote devices
to announce this modification to them. In the interests of operating costs,
we advise against using this function; the recommended value
is therefore 0.
2/ option [num]
num is an integer defining a wait in 1/50s of a second (20ms).
srwait num
where num is an integer defining the delay before the device answers
an SAP or RIP request. This mechanism can be used when a server's
answer delay is very long and where this server did not
announce itself beforehand. The recommended value is 0 (no declaration); this
mechanism is rarely used.
3/ option
defines an operating mode (no parameters).
track
validation of a "track" function similar to that of IPX servers which
display the receipt and transmission of the frames from services (SAP and RIP) via
syslog.
keepipx
validation of the local reply to the IPX watchdogs when the connection is not
open to the site concerned. You are advised to use it.
keepspx
validation of the local reply to the SPX watchdogs when the connection is not
open to the site concerned.
802.2
802.3
ethII
snap
selection of the type of IPX frame on the LAN. By default, the device
listens and sends frames in 802.3 raw (keyword 802.3). If the network
is configured in another mode, you will have to specifiy which one,
by adding the keyword in the configuration file. Note that
only one mode can be selected on the LAN. This mode plays no role
in the transmission on remote networks; it is perfectly
possible for two sites to communicate where one is in 802.3 raw and
the other in Ethernet II (keyword ethII). The keywords have the following
correspondence:
802.2 corresponds to IEEE 802.3 + 802.2
802.3 corresponds to IEEE 802.3 raw
ethII corresponds to Ethernet II
snap corresponds to IEEE 802.3 + 802.2 + snap
master
validation of the master mode when using a number of same-type devices
on the LAN. Master mode is essential when the
site has several such devices. Once of the devices
is in master mode, while the others are in slave mode. The master
device is the one visible by the local IPX servers. It broadcasts
the routings for all the remote sites. The master controls the slave
devices via the LAN by assuming the role of local router
for the slave devices. The slaves do not announce their routes
in broadcast mode, only to the master.
slave
validation of the slave mode when using a number of same-type devices
on the LAN. All the frames exchanged on the LAN
will be from or to the master device.
nobroad
validation of the transmission of frames broadcast on the LAN. This
function is useful to forbid the broadcast of SAP and
RIP messages. These messages are announced to the servers on the restricted list
defined.
hitch
used to set the source network address in the reply frame to a
Get Nearest Server SAP. This function is required for
interoperability with certain ISDN PC cards whose external address
cannot be set. The source network address will be that which corresponds to the number
in communication on this interface.
4/ option adr_ipx
* followed by an IPX address, used for compatibility with other equipment.
wanaddr adr
defines the source address of the service frames sent to the remote
networks. This declaration defines an IPX WAN required by certain
LAN-WAN routers of third party origin. If this parameter is not defined, the
IPX address of the WAN interface will be the IPX address of the LAN. If only part
of the address is provided (network or node), the rest will be extracted
from the address on the LAN.
* followed by an IPX address, used to filter the service frames
only.
gateway adr
declares the machine with the adr address as the target for the
SAP and RIP service messages from remote sites. There will be a gateway entry for each
target. This declaration can be used with the nobroad declaration
and the slave devices that ignore the messages in broadcast mode.
ipxlisten adr intf xxx
listens to the machine with the adr address for the service requests
sent to the device itself. By default, the device accepts the
service requests sent to it by all the machines.
If at least one ipxlisten declaration is used, the service requests sent
to it are all ignored except for those from machines declared
as ipxlisten.
"intf" is a separation keyword and "xxx" is "lan", "wan" or "all" depending
on whether you want to apply this restriction to the local network,
to the remote network, or to both.
ipxdonotlisten adr intf xxx
listens to all the machines whose address is other than adr for
service requests to the device itself.
"intf" is a separation keyword and "xxx" is "lan", "wan" or "all" depending
on whether you want to apply this restriction to the local network,
to the remote network, or to both.
ipxsendto adr intf xxx
only sends service requests to the machine with the adr
address. These service frames are those whose device is the source and not
coming from remote machines, i.e., resent.
"intf" is a separation keyword and "xxx" is "lan", "wan" or "all" depending
on whether you want to apply this restriction to the local network,
to the remote network, or to both.
ipxdonotsendto adr intf xxx
as opposed to ipxsendto, is used to exclude the adr target
("intf" and "xxx" have the same meaning as for "ipxlisten").
ripannounce adr intf xxx
only announces the network with the adr address, if known
("intf" and "xxx" have the same meaning as for "ipxlisten").
ripdonotannounce adr intf xxx
announces all the known networks except that with the adr address
("intf" and "xxx" have the same meaning as for "ipxlisten").
riprecord adr intf xxx
only records the network with the adr address in the table of reachable networks
("intf" and "xxx" have the same meaning as for "ipxlisten").
ripdonotrecord adr intf xxx
records all the networks except that with the adr address
("intf" and "xxx" have the same meaning as for "ipxlisten").
ripage adr intf xxx
only "ages" the network with the adr address (see riplan and ripwan), once
it is recorded
("intf" and "xxx" have the same meaning as for "ipxlisten").
ripdonotage adr intf xxx
"ages" all the recorded networks except that with the adr address, if it is
recorded (see riplan and ripwan)
("intf" and "xxx" have the same meaning as for "ipxlisten").
5/ option adr_ipx intf xxx [svc]
followed by an IPX address, the "intf" keyword, the location of the
information (xxx=lan or xxx=wan or xxx=all, as in ipxlisten) and
possibly a service number,
used to filter on the service frames only.
sapannounce adr intf xxx [svc]
the same as ripannounce, but for the service announcement with the possibility of
limiting it to one service.
sapdonotannounce adr intf xxx [svc]
the same as ripdonotannounce, but for the service announcement with the possibility of
limiting it to one service.
saprecord adr intf xxx [svc]
the same as riprecord, but for the service announcement with the possibility of
limiting it to one service.
sapdonotrecord adr intf xxx [svc]
the same as ripdonotrecord, but for the service announcement with the possibility of
limiting it to one service.
sapage adr intf xxx [svc]
the same as ripage, but for the service announcement with the possibility of
limiting it to one service (see also saplan and sapwan).
sapdonotage adr intf xxx [svc]
the same as ripdonotage, but for the service announcement with the possibility of
limiting it to one service (see also saplan and sapwan).
6/ option [num]
num is an integer whose contents depend on the parameter used.
pobro num
where num is a port number to which packets, whose "node" part
is 0xFFFFFFFFFFFF and whose "net" part has the value of a reachable network,
are authorized to transit (normally, these packets, whose broadcast is limited,
are rejected). You can enter this order as many times as necessary, one
per line. The notation used is decimal if the number starts with a
figure between 1 and 9, hexadecimal if the number starts with the
"0x" string, and octal if the number starts with 0. Only certain highly-specific applications
request the passage of this type of frame (which, despite everything, complies
with the novell specification). Consequently, this order will rarely be used.
If num is replaced by the '*' character, all the frames whose
"net" address will be specified, and whose "node" address will be broadcast, will be
sent. This function may be necessary for using
Prolog above IPX. In this case, "num" is generally equal to 0x4900.
[ipx.hosts]
contains the correspondence between the symbolic name of the IPX servers, their
address, their service number and their socket. These different fields are
described as follows:
address_IPX/service/socket symbolic_name
address_IPX address of the machine (in IPX format) xx.yy or xx (on 32
bits) and yy (on 48 bits) are two numbers in hexadecimal format.
service service number (in hexadecimal).
socket socket number (in hexadecimal).
symbolic_name symbolic name (character string limited to 48 characters).
This file is used for static IPX routings defined in the
numipx file, read by opera. The information extracted from this file will be
used in the SAP messages as long as the network described will not have been
reached. To fill in this file correctly, you are advised to establish
a connection with the remote site first, and to note the machines and services
announced using the following commands:
netstat -R
netstat -Rn
then to fill in the ipx.hosts file using this information (respecting
upper/lowercase).
Attention: Announcing invalid services can seriously disturb
IPX server and client operation.
[isdn.cfg]
contains the description of your ISDN subscription used by the device. The
file contains a single section consisting of a title (ISDN connector number)
and a list of parameters in the format:
parameter_name=parameter_value (one parameter per line). The parameters are as follows:
descriptor: name of the file describing the ISDN network used by the device.
A number of files are available. The descriptor files always have
the extension .ipo.
Examples: vn3.ipo for France Telecom VN3, ni1.ipo for Baby Bell
Companies, etc.
Default value: none.
spid_1: service number 1 profile identifier. This parameter is only to be used
on NI-1 (Baby Bell Companies). It contains a number
of values corresponding to the SPID to be used.
Default value: empty.
spid_2: service number 2 profile identifier. This parameter is only to be used
if two different SPIDs have to be used.
Default value: empty.
nac_connector: support connector number. Assign the same value as
that in the section's title, i.e., 0.
Default value: none.
nac_protocol: (physical protocol expected by the connector) 0x0414 is the only
authorized value.
Default value: none.
phy_power: 1 for yes, 0 for no. Energy loss detection
(cable disconnected, electrical failure in the network). The
value 0 is to be used if the connector is hooked up to a PBX
that does not supply any power on the junction.
Default value: 1.
Precautions must be taken when modifying the contents of the isdn.cfg file. The number
and names of sections, together with the connector and protocol parameters, must
never be modified.
To save on space, parameters taking their default value
(specified above) can be omitted. Comment lines can be
inserted in the file. In this case, the line's first non-blank character must
be the semi-colon.
For the 200 series (114, 118, 211):
- the section must be [1] and only the "descriptor" and
"phy_power" parameters are managed to date,
- for "descriptor", the following values are recognized (default "vn6.ipo"):
"vn3.ipo" (33/3), "etsi.ipo" (1000/3), "tr6.ipo" (49/4), "vn6.ipo" (33/3).
For the 100 series (CyberConnect, CyberPAD, 101, 111):
- for descriptor, the values that are acceptable are associated with the
description files present in the configuration (ls -a | grep .ipo).
[isdn.prf]
contains the description of the various ISDN profiles that can be used
to establish B channels. The file contains a number of sections, each of which
contains a title (profile number between brackets), and a list
of parameters in the format:
parameter_name=parameter_value (one parameter per line).
The parameters are as follows:
default_profile: 1 for yes, 0 for no. This parameter indicates whether this profile is
to be used by default on the physical link (see file plm.cfg)
specified by parameter ph_link_id. The default profile is used
for incoming calls, and for outgoing calls if no other
profile is specified in the call request.
Default value: 0.
ph_link_id: this parameter indicates the physical link to which
this profile is assigned by default. This parameter is ignored if
default_profile=0. The only significant value possible is 0.
Default value: 65535.
spid_number: 1, 2 or 0. Service Profile Identification number (SPID) to
be used. Put 0 if the SPID concept is not used (networks
other than NI-1).
The different SPIDs are declared in the isdn.cfg file.
Default value: 0.
rem_number_type: (remote number type)
- 0 for unknown (recommended)
- 1 for international number
-2 for national number
- 3 for network-specific number
- 4 for subscriber number
- 6 for abbreviated number
Default value: 0.
rem_number_plan: (remote number numbering plan)
- 0 for unknown (recommended)
- 1 for telephone/ISDN numbering plan
- 8 for national numbering plan
-9 for private numbering plan
Default value: 0.
rem_number_chk: 1 for yes, 0 for no. Verification of the remote subscriber's number
(type and plan only) for an incoming call.
Default value: 0.
rem_subaddr_type: (remote subaddress type)
- 0 for NSAP (X213 / ISO8348)
- 2 for user-specific
Default value: 0.
rem_subaddr_chk: 1 for yes, 0 for no. Verification of the remote subaddress
(type only) for an incoming call.
Default value: 0.
loc_number_type: (local number type)
- 0 for unknown (to be used in most cases)
- 1 for international number
-2 for national number
- 3 for network-specific number
- 4 for subscriber number
- 6 for abbreviated number
- 255 for unsupplied local number
Default value: 0.
loc_number_plan: (local number numbering plan)
- 0 for unknown (recommended)
- 1 for telephone/ISDN numbering plan
- 8 for national numbering plan
-9 for private numbering plan
Default value: 0.
loc_number_pres: (presentation of the local number to the remote subscriber)
- 0 for presentation authorized
-1 for presentation unauthorized
- 255 for information not used (recommended)
Default value: 255.
loc_number_chk: 1 for yes, 0 for no. Verification of the local subscriber's number
(number's digits only) for an incoming call.
Default value: 0.
loc_subaddr_type: (local subaddress type)
- 0 for NSAP (X213 / ISO8348)
- 2 for user-specific
Default value: 0.
loc_subaddr_chk: 1 for yes, 0 for no. Verification of the remote subaddress
local (type and value) for an incoming call
Default value: 0.
user_info_prot: (type of protocol for the user data in the
ISDN packets)
- 0 for user-specific protocol
- 1 for OSI higher layer protocol
- 4 for AI characters no5
- 8 for protocol Q.931
- 255 for unused user data
Default value: 4.
user_info_chk: 1 for yes, 0 for no. Verification of the remote user's data
(type only) for an incoming call.
Default value: 0.
high_layer_prot: (type of high layer protocol)
- 56 for X400 messaging
- 65 for X200 application
- 255 for information not used (recommended)
Default value: 255.
high_layer_chk: 1 for yes, 0 for no. Verification of the high layer protocol
for an incoming call.
Default value: 0.
low_layer_prot_1: (type of layer 1 protocol)
- 1 for adaptation of the standardized throughput as of 56Kbits/s
(calls to or from NI-1 subscribers)
- 9 for X31-compliant throughput adaptation
- 255 for information not used (recommended)
Default value: 255.
low_layer_prot_2: (type of layer 2 protocol)
- 6 for X25 link layer
- 255 for information not used (recommended)
Default value: 255.
low_layer_prot_3: (type of layer 3 protocol)
- 6 for X25 packet layer
- 255 for information not used (recommended)
Default value: 255.
low_layer_chk: 1 for yes, 0 for no. Verification of the low level protocol
(layers 1, 2 and 3) for an incoming call.
Default value: 0.
bearer_transfer: (bearer's operating mode) 8 for numeric information
with no restrictions in circuit mode at 64 kbits/s (value
unique and compulsory).
Default value: none.
bearer_capa_chk: 1 for yes (recommended), 0 for no. Verification of the bearer's
operating mode for an incoming call.
Default value: 1.
To save space, you are advised to omit parameters
taking their default value (specified above). Comment lines
can be inserted in the file. In this case, the line's first non-blank
character must be a semi-colon.
For the 200 series (114, 118, 211), the section must be [1] and only
parameters "loc_number_chk" and "loc_subaddr_chk" are managed to date.
This file contains the message displayed each time the session is closed.
[lapb.prf]
contains the description of the various LAPB profiles (X25 link layer)
that can be used to establish X25 virtual circuits. The file contains
a number of sections, each with a title (profile number
between brackets) and a list of parameters in the format:
parameter_name=parameter_value (one parameter per line).
The parameters are as follows:
default_profile: 1 for yes, 0 for no. This parameter indicates whether this profile is
to be used by default on the physical link (see file plm.cfg)
specified by parameter ph_link_id. The default profile is used
if no other profile is specified when the
physical link is established.
Default value: 0.
ph_link_id: this parameter indicates the physical link to which
this profile is assigned by default.
Default value: 65535.
auto_role: 1 for yes (recommended), 0 for no. Automatic determining of the
LAPB layer's role.
Default value: 1.
dce_role: 1 for yes, 0 for no. The LAPB layer plays the role of DCE. This
parameter is meaningless if auto_role=1.
Default value: 0.
set_mode_delayed: 1 for yes, 0 for no (recommended). The establishment of
level 2 is delayed by T1 (see below)
Default value: 0.
generate_clock: 1 for yes, 0 for no (recommended). The LAPB layer
generates the clock on the line.
Default value: 0.
extended_mode: 1 for yes, 0 for no. Use of extended numbering
(modulo 128).
Default value: 0.
line_speed: (to be supplied even if the clock is not generated
by the local LAPB layer).
Default value: 9600.
t1: timeout for frame retransmission (in tenths of a second).
Default value: 10.
t2: timeout for data frame acknowledgement (in tenths of a
second).
Default value: 1.
t3: timeout for inactive channel detection (in tenths of a second).
Default value: 50.
n1: maximum number of bytes that a frame can contain, header and CRC
included.
The most usual case is: max(o_packet_size, i_packet_size) + 7,
in other words for a subscription with 128-byte frames (which implies that
o_packet_size is equal to i_packet_size which is equal to 128); you
will set this value to 135.
Default value: none.
n2: number of frame repetitions.
Default value: 10.
k: size of window.
Default value: none.
Note: for "t1", "t2", "t3", the rules to apply are as follows:
t2 <= t1/2 et t3 >= t1*5
To save space, you are advised to omit parameters
taking their default value (specified above). Comment lines
can be inserted in the file. In this case, the line's first non-blank
character must be a semi-colon.
[lcd.conf]
| (dynamic, 114/118/211 only)
|
contains a script which will be displayed on an LCD
display. This script will be run in a loop, thus in the event
of an error or at the end of a file, the script will be rerun from the start. Since the loop
is permanent as of the initialization, you must set
the PAUSELCD variable to 1 and wait for the end of the current execution.
Subsequent to the modification, resetting PAUSELCD to 0 or removing this variable
will authorize the loop to restart.
[loceth]
contains the description of the presence frames, according to the same format as that
of the simeth file. This file is updated using the catch command.
if this file exists, the commands contained will be executed for each
connection to the device's desk (i.e., after ^G or password
on the console port or by telnet).
The syntax of the commands is the same as that used by the
"script" command. The contents of the "motd" file (if it exists) will be displayed
before the "login" file is run. This file is a relative equivalent
of the ".profile" or ".login" files on Unix machines.
Example, if this file contains:
date '+Hello, it is %T on the %D%n'
For each connection to the device's desk, the message:
Hello, it is HH:MM:SS on the DD/MM/YY
will be displayed (where HH, MM, SS, DD, MM, YY are, respectively, hour, minute,
second, day, month, year).
This file contains the message displayed for each connection to the desk (Message
Of The Day).
contains the correspondence between the symbolic names of the networks and their
address. These symbolic names can be used in place of the IP addresses
in numerical format. The lines in the networks file contain 2 or 3
fields:
name adr alias
name the network's official name (in the form of an uninterrupted character
string).
adr the network's address in IP format: 1 to 4 bytes in decimal, separated by
the '.' character depending on the network's class.
alias the alias of the network's official name (in the form of an uninterrupted character
string). The field separator is either a
space or the tabulation character. The syntax is usually
compatible with file /etc/networks on Unix systems.
[null]
this file does not exist, or rather, it does not contain anything and
cannot be filled or read. It can be used to test the
transfer by vtftp, ftp or hload. Whatever is transferred is forgotten
on receipt.
This makes it possible to transfer data for test purposes without changing
the configuration memory.
[numeth]
contains the associations used to establish MAC remote communications
(Ethernet address). The details of the different sites to
be reached are defined in the following format:
adr_ether=num:cdg[:type][:class][,num:cdg[:type][:class]].....
adr_ether is given using 6 bytes in hexadecimal; it
represents the address of the remote machine to be reached.
Fields num, cdg, type and class are the same as the fields in the
numip file.
[numipx]
contains the associations used to establish remote communications
to the IPX networks. The details of the various sites and/or machines
to be reached are defined in the following format:
address_IPX= num:cdg[:type][:class][,num:cdg[:type][:class]].....
address_IPX is given using 2 hexadecimal fields separated by the
'.' characters; it represents the address of the remote machine or network to be
reached.
If the second field is equal to 0, this entry will be considered as describing
a network.
Note that in order for a machine described in this file to be announced, you
must describe it in the ipx.hosts file. You must also
declare the network.
The other fields are the same as those in the numip file.
[pad.cfg]
This file is used to customize the unit's PAD service in terms of
the commands (characters) that can be sent to it and the
signals (characters) that it can generate. This file is described in the
PAD user's manual.
[pad.prf]
This file contains a set of PAD profiles supplied as standard. It
contains a number of sections, each with a title (profile number
between brackets) and a list of parameters in the format:
parameter_name=parameter_value (one parameter per line).
The parameters are arranged in order of their number (parameter 1 first,
parameter 22 last). The parameters with the PAD profile are described in
the PAD user's manual.
[pad.prf.usr]
This file contains a set of PAD profiles defined by the user. Its
contents are similar to those of the pad.prf file. However, with the
pad.usr.prf file, the contents are modifiable.
[paf.cnf]
This file contains the information required for the paf daemon. Its contents
are described after the command.
This file contains the passwords used for the optional authentication
(PAP) of remote sites when establishing PPP sessions.
It is also used to verify the password associated with the
user ID for the connection to the desk (according to the value of the PASSWD variable).
Each line in this file corresponds to a remote site and proposes the following fields
separated by ':':
1. field1: (max 16 char.) user name
2. field2: (max 16 char.) user's encrypted password. To enter a
new remote access (name/password), you must use the "defuser" command
then the "passwd" command.
CAUTION: never enter a password in this field using the
editor; the password is encrypted by the "passwd" command and
manually entering a character string here may
make you lose your access to the device.
The password encryption algorithm is incompatible
with that on Unix systems.
[plm.cfg]
This file contains the description of the physical links available for the
ISDN and X25 protocols. The file contains a number of sections, each with
a title (link number between brackets), and a list
of parameters in the format:
parameter_name=parameter_value (one parameter per line).
The parameters are as follows:
ccm_module: (link type – management module identifier)
- 1 for a leased line
- 2 for D channel
- 130 for B channels
Default value: none.
connector: support connector number:
- 0 for the S0 connector
- 1 for the serial channel
Default value: none.
protocol: physical protocol expected by the connector)
- 0x03fe for a leased line
- 0x0414 for D channel
- 0x007e for B channels
Default value: none.
direction: (direction of the link) its must always take the value 2 except for
the type 1 link (ccm_module=1) if the X25 layers must play
the role of DCE. In this case, the value to use is 1.
Default value: 2.
connection_id: this parameter must be set to 65535 except for the type
2 link (ccm_module=2). Its value is thus the number of the TEI to be used
to transfer X25 packets in the D channel.
Default value: 65535.
establish_mode: 1 for yes, 2 for no. This parameter indicates whether
the establishment of the physical link is to be monitored by a
timeout.
Default value: 1.
establish_timeout: this parameter indicates (in seconds) the duration of the
timeout monitoring the establishment of the physical
link. Parameter ignored if establish_mode=2.
Default value: 60.
release_mode: this parameter indicates when the physical link must be released
once no longer used.
- 0 for immediate release
- 1 for deferred release (see parameter release_timeout)
- 2 for inhibited release (appropriate for
type 1 or 2 links)
Default value: 2.
release_timeout: this parameter indicates (in seconds) the duration of the
timeout before the release of the physical link. Parameter
ignored if establish_mode=0 or 2.
Default value: 30.
local_number: not used (except for certain use of the pad).
remote_number: not used.
Precautions must be taken when modifying the contents of the plm.cfg file. The number and
names of sections, as well as parameters ccm_module, connector and
protocol must never be modified.
[plp.prf]
contains the description of the various X25 profiles (packet layer)
that can be used to establish X25 virtual circuits. The file contains a certain
number of sections, each with a title (profile number
between brackets) and a list of parameters in the format:
parameter_name=parameter_value (one parameter per line).
The parameters are as follows:
default_profile: 1 for yes, 0 for no. This parameter indicates whether this profile is
to be used by default on the physical link (see file plm.cfg)
specified by parameter ph_link_id. The default profile is used
if no other profile is specified when the
physical link is established.
Default value: 0.
ph_link_id: this parameter indicates the physical link to which
this profile is assigned by default.
Default value: 65535.
auto_role: 1 for yes (recommended), 0 for no. Automatic determining of the
X25 packet layer's role.
Default value: 1.
dce_role: The X25 packet layer plays the role of DCE: 1 for yes, 0 for no.
This parameter is meaningless if auto_role=1.
Default value: 0.
dce_diag_packet: the packet layer playing the role of DCE can send
DIAGNOSTIC packets: 1 for yes, 0 for no.
Default value: 1.
dte_restart_packet: 1 for yes, 0 for no. The packet layer playing the role of
DTE can send RESTART packets.
Default value: 0.
dte_restart_delayed: 1 for yes, 0 for no. The packet layer playing the role of
DTE sends the first RESTART packet after a period of T20 (see
below).
Default value: 1.
dte_cause_field: 1 for yes, 0 for no. The packet layer playing the role of DTE
can send cause fields codes 1xxxxxxx.
Default value: 0.
extended_numbering: 1 for yes, 0 for no. Use of the extended number
(modulo 128).
Default value: 0.
flow_negociate: 1 for yes, 0 for no. Negotiation of the flow control parameters
(window and packet sizes).
Default value: 0.
out_call_barred / in_call_barred: 1 for yes, 0 for no. Barring of
outgoing/incoming X25 calls.
Default value: 0.
cnt_perm_ch / cnt_in_ch / cnt_two_ch / cnt_out_ch: number of permanent virtual
/ incoming switched unidirectional / switched
bidirectional / outgoing switched unidirectional circuits.
Default value: none.
low_perm_ch / low_in_ch / low_two_ch / low_out_ch: number of the first permanent
virtual / incoming switched unidirectional / switched
bidirectional / outgoing switched unidirectional circuit.
Default value: none.
high_perm_ch / high_in_ch / high_two_ch / high_out_ch: number of the first
permanent virtual / incoming switched unidirectional / switched
bidirectional / outgoing switched unidirectional circuit.
Default value: none.
o_window_size / i_window_size: size of the window for sending/receiving.
Default value: none.
o_packet_size / i_packet_size: size of the packet for sending/receiving.
Default value: none.
o_buffer_size: size of the anticipatory buffer for sending.
Minimum value: 2 * o_packet_size.
Default value: none.
i_buffer_size: size of the anticipatory buffer for receiving.
Minimum value: i_window_size * o_packet_size.
Default value: none.
r20_counter / r22_counter / r23_counter: number of repetitions of the following packets:
RETART / RESET / RELEASE on the DTE side.
Default value: 2.
t10_timer / t12_timer / t13_timer: resend timeout for the following types of packets:
RETART / RESET / RELEASE on the DTE side (in seconds).
Default value: 60.
t20_timer / t22_timer / t23_timer: resend timeout for the following types of packets:
RETART / RESET / RELEASE on the DTE side (in seconds).
Default value: 180.
t11_timer: wait timeout for a reply to a call packet sent on the
DCE side (in seconds).
Default value: 180.
t21_timer: wait timeout for a reply to a call packet sent on the
DTE side (in seconds).
Default value: 200.
trs_timer: recovery timeout in the event of a level 2 or 3 drop (in
seconds).
Default value: 10.
To save space, you are advised to omit parameters
taking their default value (specified above). Comment lines
can be inserted in the file. In this case, the line's first non-blank
character must be a semi-colon.
[poolip]
contains the description of the dynamically-allocated addresses for connections
in PPP/IP only. The address extracted for a connection will be supplied
to the remote machine which must use it as its address. This
function enables you, for example, to provide Internet access to a
large virtual population of users while only using
a limited number of addresses (number of addresses usually equal to the number
of possible simultaneous connections on the device).
In the "ppp.conf" file, you must specify that you wish
to assign addresses to the remote devices or networks (parameter "+sa").
The recognized addresses that belong to the LAN will automatically be
declared in the ARP as "published" (similar to "opera -proxy").
The addresses of the "pool" can be defined as a range of addresses
in the format "minimum_address – maximum_address", whereby these two addresses
are included in the range, or in the format "address". You can
put as many lines as necessary, making sure, however, that you use only
one expression per line.
[ppp.conf]
contains the options of PPP sessions that can, if necessary, be negotiated with the
remote device/access on connection. Each line in the file only contains one
options and its arguments (if necessary). A comment starts with the
'#' character (after the option's arguments or on its own line).
The following options are possible:
-all invalidates all the options, even those by default.
-ac forbids the compression of control fields and
addresses in PPP frames.
active forces the active mode. By default, an incoming connection is
handled in passive mode, an outgoing connection in active mode.
-am invalidates the negotiation of the character map that must be
preceded by an escape sequence (asynchronous PPP
only).
-as val sets the character map that must be preceded by an
escape sequence (asynchronous PPP only).
val is a hexadecimal integer containing, in the form of
binary elements, the fact that the character concerned (bit 0 for
the character 0, etc.) is "escaped". This value only
concerns the first 32 characters (0 to 31).
You are advised against modifying the default character map.
autoroute for the IPCP/CI_ADDR negotiation
- If an address is given and no remote number has been
received, the remote number present in the log will be
deduced from this address, provided it figures in the
numip file.
- If an address is given and you are working in
IP address translation mode with a fixed address (other
than 0), the address received will be refused, and
the translation address proposed (if they are different).
- If an address is given and you are working in
IP address translation mode with a variable address (equal to 0),
the address received will be used as the translation address
for this interface.
- If no address is given (value at 0.0.0.0),
an address will be proposed: the translation address if you
are working in IP address translation mode, or the address of the
interface on the LAN side otherwise.
! Note that this keyword must or must not be present
! according to the remote device (only a test will give the
! reply). In fact, this keyword changes the address
! assignment strategy. You are advised to perform an
! initial test without this keyword. The communication will
! or will not work; the use of the strategy
! specified by "autoroute" does not affect the
! speed of the link.
callwait is an integer representing the time between
the event requesting the callback and the callback
order. This value is expressed in 1/50s of a second.
When the callback is on the initiative of the device
(option 'c' in numxx), it's default value is
50 (1 second), its minimum value 25 (0.5 seconds),
and its maximum value 500 (10 seconds). This period will
be used in RSD mode and/or in CHAP callback mode.
If the value given is outside this range, the default value
will be used.
When the callback is on the initiative of the remote device
(option 'CB' in numxx), it's default and minimum value is
200 (4 second) and determines the minimum delay
between 2 calls made to the remote device.
+chap imposes the authentication of the remote device in accordance with the
CHAP (Cryptographic Handshake Authentication
Protocol) protocol. The two devices in communication can
have the option set; in this case, the authentication procedure
is mutual since it is ensured by each
part. See file secret for the definition
of passwords and their association with the remote devices
and variables MYNAME and DOMAIN (see also this file's
"myname" option).
-chap forbids the CHAP. It may be necessary to use this keyword
for certain devices made by other manufacturers,
for example, when they can handle PAP and CHAP,
and only PAP is configured.
chaprange min max forces the minimum and maximum limits to use the
the "min" and "max" values for the CHAP challenge.
These values are usually defined by the RFC, but some
competitor devices have a problem in this regard. You
must therefore limit the size to interoperate
correctly with these devices. For certain versions of
Radius, you will have to use the value 16
for the min and max parameters.
If the values chosen are outside the authorized limits
(5 to 64), they will be ignored.
-cipx forbids the compression of IPX and NCP headers in IPX frames
when the device works as an IPX router.
-d validates the debug option.
debug equivalent to -d.
-mn forbids the negotiation of the magic number.
-mru forbids the negotiation of the maximum size of frames
being received.
mru n authorizes the negotiation of the MRU to the value n; the default value
is 1500 bytes.
myname name replaces the default chap user id ($MYNAME.$DOMAIN) with
"name". This makes it possible, when using a number
of profiles, for different names to be presented to the remote devices.
-p forces the passive mode.
passive forces the passive mode. The negotiation will always be on
the initiative of the remote device. If the remote device is also in
passive mode, the connection will necessarily fail.
-pap equivalent of -ua.
+pap equivalent of +ua.
-pc forbids the compression of the protocol field in PPP frames.
ppp_user user replaces the PAP user ID defined in PPP_USER by "user".
ppp_pwd passwd replaces the PAP password defined in PPP_PWD by "passwd".
+sa in the IPCP/CI_ADDR negotiation, proposes the IP address
corresponding to the connection parameter (remote number)
in the "numip" file. This option is used to
connect isolated machines or routers in address translation
mode, to which you must supply an IP address.
NB: in numip, the IP address corresponding to the remote number
must therefore not be "default" or "0.0.0.0".
+smip in the IPCP negotiation, on some devices, the
knowledge of the other part's address is
necessary (?) whether you are working with or without the address
translation. To specify our address (N.B.: disclosure
of sensitive information), if this option
has been validated, you send our address in the CI_ADDR parameter
right at the start of the negotiation.
-ua forbids PAP.
+ua imposes the authentication of the remote device in accordance with the
UPAP (User Password Authentication Protocol) protocol. See
commands "passwd" and "defuser", file "passwd" and
variables PPP_USER and PPP_PWD and options ppp_user and
ppp_pwd in this file.
NB: UPAP is commonly – and abusively – called PAP.
-vj forbids Van Jacobson compression of TCP/IP headers.
This keyword may be necessary for correct operation
with other manufacturers' devices
(ICMP or UDP transmissions are not affected (ping), however
TCP connections only work very, very slowly
(telnet, ftp, etc.)).
vjmode mode where "mode" can take the following values:
old for a header compression compliant with the old RFC,
rfc1172 for a header compression compliant with this RFC,
rfc1332 for a header compression compliant with this RFC,
by default, mode "rfc1332" is selected.
!! MP is available in versions from 02/99 onwards!!
mp activation of the MP overflow module.
This parameter is the only one required to activate the
overflow, since the following mp parameters have default
values designed for everyday use:
mpssnh requests and accepts the use of short MP sequence
numbers.
mpminnchan followed by an integer representing the minimum number of a channels
to use to the same destination in MP (default = 1).
mpmaxnchan followed by an integer representing the maximum number of a channels
to use to the same destination in MP (default = 2).
mpbasenchan followed by an integer representing the number of a channels
to use as soon as the connection is opened in MP (default = 1)
mpseuilhaut followed by an integer representing the threshold from which
an additional channel must be added in MP (default = 60%).
mpseuilHhaut followed by an integer representing the threshold from which
all the channels (max = mpmaxnchan) must be
open (default = 90%).
mpseuilbas followed by an integer representing the threshold from which
a channel must be removed (and thus disconnected) from the list
of channels connected to the same destination
in MP (default = 30%).
mpseuilBbas followed by an integer representing the threshold from which
the maximum number of channels must become mpminnchan
in MP (default = 15%).
mpbwsampling followed by an integer representing the sampling period,
expressed in seconds, of the line's throughput (default = 5).
mpbwchgdelai followed by an integer representing the delay, expressed in seconds,
during which – after adding/removing a channel – no
other addition/removal of a channel will be performed on this
group (default = 10).
mppmgt authorizes this device to be accessed by a manager
working above MP+ (default = no). On this
range of equipment and with certain options, the "cu" command
enables you to access this "virtual" console port.
To be valid, the mp parameter definition must satisfy the following conditions:
mpbasenchan >= mpminnchan
mpmaxnchan >= mpbasenchan
mpseuilbas >= mpseuilBbas
mpseuilhaut >= mpseuilbas
mpseuilHhaut >= mpseuilhaut
PPP proposes two solutions to authenticate machines connecting to a
site: CHAP and PAP.
1. PAP: the machine with the +ua option set requests the remote device
to provide its name and password on connection, whatever the
direction of this connection. The remote device must respectively provide its name
and password (i.e. the contents of variables PPP_USER and
PPP_PWD). The server then encrypts the password given and searches for the
same pair (user,passws) in the passwd file. If this search
is successful, the connection is accepted; if not, it is refused.
2. CHAP: SEE file secret.
Default configuration of PPP:
> compression of the control and address fields,
> passive mode if the connection is incoming, that is if the machine is
called, otherwise active, that is for the machines on the initiative of
the call and for the interfaces declared as leased lines,
> negotiation of the MRU,
> no authentication,
> VJ header compression,
> no debug.
You can define more than one profile. When the file is read,
as long as the '[' character is not found at the start of a line, the
configuration is stored in the default profile. This default profile
serves as the basis for all the other profiles defined. For example, if you find
the "-chap" sequence in this part, chap will be refused in all the profiles.
To define another profile, you separate the information by default (if this information
exists) by a line containing "[numpro]", where "numpro" is
the profile for which the parameters will follow ("numpro" must be
between 1 and 65534 inclusive) and the '[' and ']' characters enable
the profile number to be detected.
The options presented can all be given in a profile, but
whatever the profile selected, the "debug", "chaprange"
and "autoroute" options will have an effect on all the profiles.
These profiles can be dynamically assigned, both for
incoming and outgoing connections. To select a
specific profile in the list, in the "type" field of "numxx"
(numip, numipx, etc.), you will give the profile number preceded by the 'p' character.
If the selected profile number does not exist, the default profile
will be used.
Example of file ppp.conf:
-vj
[1]
-chap
ppp_user toto
ppp_pwd titi
[2]
+chap
And in numip, you can give profile 1 for the connection to an Internet
access provider, and profile 2 (imposing CHAP) for the incoming connections.
[radius.conf]
contains the operating functions of authentication requests and
RADIUS (Remote Authentication Dial In User Service) records.
Radius can be used to record WAN connections with
the device (PPP and FR only) and to make
authentication requests. Note that modifications to this file are only accepted
when the device is initialized and with the
"opera -r" command.
The recording part is grouped in the section that starts with the
mention "[accounting]".
In this section, you can find the following keywords:
.chap indicating that the recording of a session will only be requested
after "ppp/chap" identification.
.pap indicating that the recording of a session will only be requested
after "ppp/pap" identification.
.clid indicating that the recording of a session will only be requested
as soon as a call is received/sent. Note that the mention ".clid"
invalidates ".chap" and ".pap", since the call must take place
before any authentication.
.port nnn where "nnn" indicates the UDP port to be used (instead of 1813 by
default, value given in the RFC).
Note that historically, the "accounting" port took the value
1646. You may need to use this value to obtain
correct operation.
The authentication part is grouped in the section that starts with the
mention "[authentication]".
In this section, you can find the following keywords:
.chap indicating that if the remote_device_name/password pair is not
found in the "secret" file, the authentication
must be requested from the "radius" server.
Note: some Radius server versions require
a fixed-length challenge of 16. You will need
to specify this limit in the ppp.conf file.
.pap indicating that if the remote_device_name/password pair is not
found or is invalid, in the "passwd" file,
the authentication must be requested from the "radius" server.
.clid indicating that if the remote device number is not found in the
numxx file, agreement must be requested from the "radius" server.
An entry for verification in this mode will necessarily
have "CXR-CLID" as the password on the radius server.
.port nnn where "nnn" indicates the UDP port to be used (instead of 1812 by
default, value given in the RFC).
Note that historically, the "accounting" port took the value
1645. You may need to use this value to obtain
correct operation.
You should find at least one declaration in all the sections:
name key where "name" indicates the name of the machine (or its IP address)
with the radius server and "key" the key shared between
the device and the radius server. If several servers are
proposed, the first in the list will be used; if the device
does not receive any acknowledgement, the next one will be
queried. When the end of the list is reached, the pointer will be repositioned at
the start of the list.
[rap.conf]
contains the operation and restriction options of the
dynamic IP routing module based on the RIP protocol. These options are of two types:
1. restriction declarations including the following fields:
command IP_address intf {all | lan | wan}
with:
> command can take the values below:
listen accept the information from this address.
donotlisten do not accept the information from this address,
sendto send RIP frames to this address,
donotsendto do not send any RIP frames to this address,
announce announce this address,
donotannounce do not announce this address,
record record the routing for this address,
donotrecord do not record the routing for this address,
donotage do not "age" this address.
> IP_address is the IP address concerned by this command.
> intf is a separator keyword.
> {all | lan | wan} is/are the interface(s) concerned by this command.
* lan corresponds to the local network,
* wan corresponds to the remote network(s),
* all corresponds to the LAN and WAN.
For all these options, the order take priority over the counter-order, and makes
it useless for the configuration, and changes the default value
from "yes" to "no".
For example, if "listen" is used, all the accepted addresses must
be specified and "donotlisten" will no longer have any effect on the operation.
2. Operating options.
> noripin selects the transmission of RIP frames without receiving any frames.
> noreflect forbids the rebroadcasting of the routings found on the same type of
network (no announcement on the LAN of the routings found on the LAN
side and no announcement on the remote network of the routings found out on the remote
network side). As of 02/99, this option is the default option.
> reflect authorizes the rebroadcasting of the routings found out on the same type of
network.
> debug selects the display - via syslog - of routing recordings and erasures
(note that if a lot of routes have to be announced,
this information represents a considerable workload).
> direct limits the transmission of RIP frames to routers specified by the
ripgateway command.
> quiet selects the receipt of RIP frames without sending frames.
> ripgateway adr is used to define a router with the adr IP address to which a frame
will be sent by name in addition to the transmission in broadcast mode. You
will need one declaration of this type for each router. This declaration is
useful in complex architectures where routers are separated by
devices that filter the communication in broadcast mode.
> adv followed by "onconnection", "ondisconnection", "onchange", is used to announce
the routing table for the connection of a channel, the
disconnection of a channel and the change of status of a channel (sum of the 2
previous orders) respectively. By default, the "onconnection" option is
used. This announcement is performed in addition to the normal announcement.
> brec followed by the size of the receiving buffer in number of frames.
By default (and when the value is insufficient), the size of the
buffer is calculated automatically according to the frames received.
> itrame followed by the duration in milliseconds separating the transmission of 2
announcement frames. Some devices may become saturated when a
large number of routes has to be announced, and this interframe makes it
possible to limit the transmission speed. By default, there is no
wait and the maximum interframe accepted is 1000ms (1 second).
> version followed by 1 or 2, selects the RIP operating mode,
bearing in mind that the main difference between versions 1 and 2 is
the indication of the mask to be used in version 2.
Note that in version 1, only version 1 frames will be taken into account;
in version 2, the version 2 frames will be taken into account as well as
the version 1 frames, with the automatic calculation of the mask depending on the
target address. Before selecting version 2, you must check that the
machines on the network accept it.
If this file does not exist, a default configuration is provided (see
the details in the description of the "rapd" command).
[rcmds]
contains the machines, users and commands authorized for execution in
the context of the rshd daemon. The format is given below. Any line not
corresponding to this syntax will be ignored. Comments can be inserted using
using the '#' character. The authorization lines must contain
neither spaces nor tabulations.
{*|address|name}:{*|user}:{*|cmd1[,cmd2,...,cmdn]}
or, in other words
machine:user:commands
machine represents the remote machine which can be given as an
IP address, name (if known in the "hosts" file, or obtained
via the name server) or the '*' character, which corresponds to all
machines.
user authorizes the user to execute commands. The
'*' character authorizes all users.
commands represents the command(s) authorized for execution. In the
case of a series of commands, the names will be separated by the ',' character.
The '*' character authorizes all the commands to be executed.
Example 1:
# authorization of all the machines
# all the users, all the commands
*:*:*
Example 2:
# authorization of the numstat and disconnect commands
# for user "smurf" from all the machines
# on the LAN or directly connected
# (command run: rshd -lrR&)
*:smurf:numstat,disconnect
[reserve]
contains factory-defined system variables. These variables are ETHADDR
(device's Ethernet address) and HOSTID (device's serial
number). This file is not modifiable.
contains the remote identifiers and their associated passwords for the
CHAP PPP authentication procedure (see option +chap in the
ppp.conf file). The passwords are entered in clear text, but can be subsequently
encrypted using the secrypt command. The format of each line is
as follows:
remote_user_name password
This file is useful in the case where the user wishes to authenticate
the remote users on incoming or outgoing communications. The '$' or
'#' characters must be preceded by the '\' character if you do not want them
to be interpreted respectively as a variable or a comment.
Each communicator must have – in the "secret" file – a line
corresponding to the name of the remote user associated with the same password.
The contents of this file are dynamic, i.e., any modifications
will be taken into account immediately.
remote_user_name is the contents, in the remote part, of the MYNAME variable
followed, if the DOMAIN variable is initialized, by '.' then the
contents of the DOMAIN variable.
Be careful with the limits in length on the
DOMAIN and MYNAME variables; the latter may be automatically
truncated (with a message obviously).
Case (upper/lower) is not considered for this
parameter.
This name can be "default". This is a keyword which
corresponds to all the proposals that are not defined in the
file.
In the case of a communication with an access provider which
uses CHAP, it is usually the name of the remote router, but
some providers use more than one server for access to the
different names. In this case, you are advised to use the
"default" keyword.
password is the two communicators' common identifier. It is exchanged,
with the remote_user_name, in an encrypted packet according to the
MD5 Message Digest Algorithm of RSA Data Security, Inc.
Example:
* site paris:
- file ppp.conf: +chap
- admin file: DOMAIN=idf
- admin file: MYNAME=paris
- secret file: lyon.rhone cx_paris_lyon
* site lyon:
- admin file: DOMAIN=rhone
- admin file: MYNAME=lyon
- secret file: paris.idf cx_paris_lyon
If the paris site's DOMAIN variable was not initialized, you would find
the following on the lyon site:
- secret file: paris cx_paris_lyon
[simeth]
contains the description of the frames to be sent using the simula command. Each
frame is defined as follows:
the '{' character indicates the start of a frame,
the '}' character indicates the end of a frame,
the ' [' and ']' characters indicate the start and end of
a repetition sequence consisting of the value of the byte to repeat, the
* character and the number of times the byte is to be repeated: this last
parameter is to be specified in decimal format. Each sequence must be
fully described on a single line.
The value of each byte must be described in hexadecimal format using
two characters ('0' to '9', 'a' to 'f' and 'A' to 'F'). A frame can be
described on several lines (with the previously-indicated restriction concerning the
[OO*N] sequences).
Example:
{404040404040 303030303030 0800 AB CD [ff*10]}
represents a frame with the target Ethernet address 404040404040, the
source address 303030303030, type 800, followed by AB CD FF FF FF FF FF FF FF FF FF
FF.
Multicast source addresses are forbidden, as are frames whose
length exceeds 1000 bytes. The frame sent must be at least 60
bytes, even if the length of the description is less (padding with
null-value bytes).
[slot]
contains information used and which can only be used
by the "slot" command. Do not edit this file.
[tadi.prf]
contains the description of the various V120 profiles that can be used
to establish V120 virtual circuits. The file can contain
a number of sections, each with a title (profile number
between brackets) and a list of parameters in the format:
parameter_name=parameter_value (one parameter per line).
The parameters are as follows:
default_profile: 1 for yes, 0 for no. This parameter indicates whether this profile is
to be used by default on the physical link (see file plm.cfg)
specified by parameter ph_link_id. The default profile is used
if no other profile is specified when the
physical link is established.
ph_link_id: this parameter indicates the physical link to which
this profile is assigned by default.
lap_n200: this parameter indicates the maximum number of retransmissions.
lap_k: this parameter indicates the number of frames in the LAP window.
lap_t200: this parameter indicates the value of the delay before retransmission
(unit: 1/10 second).
lap_t203: this parameter indicates the value of the activity timer
(unit: 1/10 second).
lci_n201: this parameter indicates the frame size (in bytes) to be used.
nac_direction: 1 to play the role of the DCE, 2 to play the role of the DTE,
0 to automatically determine the role (DCE if the physical link
is incoming, DTE is it is outgoing).
Attention, some access providers (called therefore) need
to have a DCE (??) in front of them; if the connection
fails, you may have to modify this parameter.
[tcpad]
contains a series of lines defining how
PAD communications are opened above TCP.
Using this file, for incoming PAD connections, you can associate
a PAD connection to a given machine according to
the end of the X25 address requested (example 1).
For outgoing communications, you can associate – with a TCP port – an
X25 address that will automatically be called when a connection is
established on this dedicated port (example 2).
Example 1:
device's X25 address:
123456789
contents of the "tcpad" file:
99 duponT/telnet
xdef duponD/telnet
listen 4
log
If the number called is "12345678999", a telnet connection request will be established to the
duponT machine.
For any other number, you will attempt to establish a connection
to the duponD machine. The "xdef" key indicates that for unresolved
cases, this line will be used. If this entry is not present and if
there is no corresponding address, the communication will be refused.
The PAD connection will be closed automatically if the TCP session is closed.
Similarly, if the PAD connection is closed, the TCP session will be closed.
The "listen" keyword determines the number of simultaneous connections
that are acceptable for the device in the PAD->TCP direction. If the value is
not given or is less than 2, the value 2 will be taken by default.
The "log" keyword indicates that the establishment of connections will
produce a message sent via syslog.
Example 2:
contents of the "tcpad" file:
o -p51 -l -a112
o -p51 -l -a102 4201
If a connection on the TCP/4200 port is opened, a PAD connection will
automatically be attempted to the X25 112 address, using the
PAD 51 profile and saving the call request (see command padd).
If a connection on the TCP/4201 port is opened, a PAD connection will
automatically be attempted to the X25 102 address, using the
PAD 51 profile and saving the call request (see command padd).
For the first entry, you do not need to specify the port,
since port 4200 is assigned by default to command padd.
The PAD connection will be closed automatically if the TCP session is closed.
Similarly, if the PAD connection is closed, the TCP session will be closed.
[trans.conf]
contains optional and necessary information for using
IP address translation (see also file "numip").
- Necessary information:
The only necessary information in this file is the address that will be
presented on the remote networks. It must be written as
follows:
external IP_address
where "external" is the password and "IP_address" is the address that will replace
the LAN's source address when frames are sent
to the remote networks selected (file "numip", option ":t").
This address can be provided in the different formats used
in IP. If the value is 0 or "auto", it must be provided
by PPP when the connection is made with the remote site.
- Optional information:
Each item of information below has a default value; you do not
therefore have to enter any of them.
For the 1st series of parameters, the main purpose of the setting
appears when clearly-identified malfunctions occur, in other
words, you are advised against assigning values other than those
by default. The passwords used to modify
the default value of the different parameters assigned dynamically by
the device on translation are given below:
minudp value minimum value of the UDP port (default 8000)
maxudp value maximum value of the UDP port (default 32767)
mintcp value minimum value of the TCP port (default 8000)
maxtcp value maximum value of the TCP port (default 32767)
The second series of parameters enables you to access the device when
logical connections are established on external initiative. Validating these options
may represent a danger, but allows for easier management
by the operator. For all these parameters, "value" can be 0 (default)
to forbid, or 1 to authorize:
transicmp value ICMP access -> device by the translation address
lanicmp value ICMP access -> device by its LAN address
transudp value UDP access -> device by the translation address
lanudp value UDP access -> device by its LAN address
transtcp value TCP access -> device by the translation address
lantcp value TCP access -> device by its LAN address
NB: the LAN's address is that assigned to the "il0" interface.
The third series of parameters is used to select special functions
for the address translation.
mcast authorizes the receipt of multicast frames from the WAN and their
transmission on the LAN without being modified.
vdo authorizes the handling of VDOLive(tm) connections without having
to use this software with static ports.
sustain sec specifies the period during which a non-used
translation entry remains valid (value
expressed in seconds, 5 by default).
On expiry, the entry will be destroyed and a frame from
outside will not reach its recipient.
flush requests the immediate destruction of the entries concerned
by the address translation of the channel, which closes.
autoflush requests the immediate destruction of the entries concerned
by the address translation of the channel, which closes if
the translation address is acquired dynamically.
dropold forbids the establishment of a WAN connection to send
a reset of a TCP end of connection (often unjustified,
due to offhand server behavior).
tcpsum normally the TCP checksum is not verified
when datagrams are received, since the links
are reputed to be reliable. However, it may turn out that the quality
of the transmission or of certain hardware requires
an additional verification on this level.
When this keyword is present, the TCP checksum
is verified. Frames whose checksum
is false are eliminated.
debug val sets the debug level to the value "val".
Enables you to obtain, via syslog, the information required
for searches on the eliminated frames. It generally
concerns connection attempts from
outside on ports that are not redirected internally.
The fourth series of parameters is used to access machines on the
LAN when logical connections are established on the initiative of a remote device.
There is no doubt that this represents a breach in the protection function,
however this feature allows for standard operation of
certain address translation applications that were not originally planned for.
In principle, you define the address of a machine present on the LAN
for certain TCP or UDP ports. If a logical connection
is opened to this port from outside,
the target address will be that defined in this port's
configuration.
tcport IPAdronLan/TcpPort
udport IPAdronLan/UdpPort
For values less than 1024, the port must be specified by its
name. Beyond this value, the number will be accepted.
E.g.:
tcport $MYADDR/auth
An authentication frame, sometimes used more or less needlessly by
certain servers (the RFC931 indicates that this information is not
necessarily sure) intended for the translation address (the
only one visible on the WAN) will be directed to the device itself (provided
that $MYADDR does indeed represent the device's LAN address).
Since the device does not have any authd service, an ICMP frame will
be immediately returned, giving the information to the caller server
which, more often than not, will continue its job without waiting any longer for
a hypothetical reply. Caution: even if this configuration sometimes
proves necessary, it represents a breach in security, since an outside
connection attempt generates traffic in return.
If you wish to redirect a range of ports to the same machine, you
can either give as many tcport/udport lines as necessary,
or specify the limits by noting TcpPort/UdpPort as
minimal_port:maximal_port (the ':' character is the separator).
The minimal_port and maximal_port values are included in the range.
With this additional information, you obtain the following syntax:
tcport IPAdronLan/MinTcpPort:MaxTcpPort
udport IPAdronLan/MinUdpPort:MaxUdpPort
When the translation is carried out to a number of addresses
(special case to be examined with your access provider), you can
select the address seen on the remote network side by giving the offset in
relation to the basic address (defined externally). The syntax becomes:
tcport IPAdronLan/MinTcpPort[:MaxTcpPort] @offset
udport IPAdronLan/MinUdpPort[:MaxUdpPort] @offset
where "@offset" can be a value in the format "@+1" or "@-1", a value
which will give the address on the remote network side (default value: 0).
E.g.: with "external auto" and "192.168.1.1" assigned by the access provider
tcport 192.168.2.1/telnet @+1
will direct all the frames intended for 192.168.1.2/port 23 to
the machine with the address 192.168.2.1.
If you want to redirect a specific port on the WAN to a
specific address with a different port on the LAN, you will use
the following syntax:
tcport IPAdronLan/LanTcpPort @0/WanTcpPort
udport IPAdronLan/LanUdpPort @0/WanUdpPort
E.g.: with "external auto" and "192.168.1.1" assigned by the access provider
tcport 192.168.2.1/telnet @0/2200
will make it possible to reach the "telnet" port of the machine on the LAN with
the address "192.168.2.1" by requesting a connection from the
remote network on the address "192.168.1.1" (translation address), port "2200".
In this example, the offset is not used, but the configuration
authorizes it ("@0" can be, for example, "@-1").
You can also define a range of ports using the
syntax defined above:
("LanTcpPort" becomes "MinLanTcpPort:MaxLanTcpPort" and
"LanUdpPort" becomes "MinLanUdpPort:MaxLanUdpPort").
The port no. on the WAN ("2200" in the example) is sufficient to limit the range
of ports on the WAN, whereby the link is 1 port for 1 port.
E.g.: with "external auto" and "192.168.1.1" assigned by the access provider
tcport 192.168.2.1/telnet @0/2200
wan 192.168.1.1/2200 is directed to lan 192.168.2.1/23(telnet)
wan 192.168.1.1/2201 is directed to lan 192.168.2.1/24
wan 192.168.1.1/2202 is directed to lan 192.168.2.1/25(smtp)
NB: 1) The use of the offset is worthwhile and has the desired effect
only if the access provider handles it (routing of several addresses).
2) Redirecting a port to another
requires excellent knowledge of the network's topology and is
only used for highly specific needs.
You can also direct all the frames for a specific
WAN address to a specific LAN address.
To indicate this operation, use the following syntax:
static IPAdronLan @offset
E.g.: with "external auto" and "192.168.1.1" assigned by the access provider
static 192.168.2.1 @+1
will direct all the frames intended for 192.168.1.2 to 192.168.2.1
Symmetrically, all the frames with the source address 192.168.2.will appear,
after translation, as 192.168.1.2.
The port numbers will not be modified.
NB: The use of the offset is worthwhile and has the desired effect
only if the access provider handles it (routing of several addresses).
Note, the redirection of incoming ports (keyword "tcport", "udport") and
especially the static translation (keyword "static") reduce the
protection provided by the address translation.
One last series of parameters enables you to assign – if necessary
and if supported by your access provider – several
translation addresses.
To define the address used by a range of addresses, you
will use the following syntax:
segment lan_address_min [lan_address_max] @offset
"lan_address_min" represents the first address in the address range
on the LAN side to be considered.
"lan_address_max" is an optional parameter used to end
the range to be considered (if this parameter is not specified,
"lan_address_min" will be used).
"@offset" represents the offset in relation to the address obtained
dynamically ("external auto") or statically. The value of the offset
can be positive or negative and must be preceded by the '@' character.
A range of addresses that is not described will use the basic translation address.
The values of "lan_address_min" and "lan_address_max" are included in
the segment defined.
The "segment" parameter is ineffective for incoming IP connections,
as opposed to the "static" parameter. It can thus be accompanied
by the necessary "tcport" and "udport" keywords.
In operation, you can consult information on the address translation
using the "numstat –t" command.
[update]
This file is actually totally virtual. This name is used to update
the device's software version. When this file is loaded,
the end of its loading proposes an execution. This is when
the contents of the file will be placed in the flash memory (program memory).
Since this procedure must be performed by an authorized personnel member, we
will not give further details on the intrinsic operation.
NB: the update cannot be performed from one device to another
(code downloaded different from that present in the memory).
[watch.conf]
contains the configuration at the initialization of the program for displaying the
Ethernet frames received. You are advised against modifying the data contained
in this file other than via the watch command.
__________________________________CXR____________________________rev-__
[Back to index]