This manual was written with great care. However, it may contain errors. Therefore, there is no warranty of any kind nor any other legal responsibility of the author or the translator.

Copyright (C) 1995 Gunter Jost, DK7WJ, Lichtenbergstr. 77, D-64289 Darmstadt, Germany

All rights reserved. No part of this manual may be reproduced or duplicated without prior written consent of the author.

With this command a line of text can be sent to another user who is connected to the infobox. The output is similar to the "/s"-command in convers mode. This command is not implemented on RMNC fullmasters.

Turn off port y

On this port, you will always be sysop as long as there are no digipeaters in your path. For security reasons, on RMNCs this may only be set in the MRMNC compiler. On these ports the loop detector is inactive.

ATTENTION: This attribute should only be set on local(wired) links. Even here, it must be impossible to connect back to the node, otherwise everything can be reprogrammed freely.

C Only relevant in KISS mode: Force CRC mode. On some PC/Flexnet drivers: Activation of software DCD.

M DAMA master (see separate discussion)

S Channel synchronization (see separate discussion)

U This port is a user port. Activates following features (on RMNC fullmaster only partially implemented):

• Port never goes into DAMA-Slavemode

• TxDelay-Measurement (see separate discussion)

• If in DAMA mode: Disconnect of users who poll the digi several times (i.e. they are no proper DAMA slaves)

The Hearlist, up to now only used internally for routing, can be displayed now. All heard callsigns are inserted into the list. This also improves the port routing. The list contains max. 200 callsigns and is saved to HD on PCs every ten minutes.

Options:

First ideas for the software came back in 1987, and the first version was developed in 1988. First tests were run at home and later at the digipeater DB0ODW in Odenwald, Germany. This digi was equipped with a complete 6809-development system and made it possible to test new versions by uploading them. In 1989 the work on the RMNC version began. The RMNC (Rhein-Main-Network-Controller) was developed by the PR-Group of Frankfurt (RMPRG) and offered an optimal platform for FlexNet. Since 1991 a version for MS-DOS-Computers has existed, but it has been used only internally and never been distributed. However, after a growing demand for such a PC/FlexNet, in 1994 a new modular driver concept was developed in cooperation with DL8MBT, the author of the BAYCOM software. This makes PC/Flexnet usable for almost everybody. PC/FlexNet is freely configurable and may be used with any I/O-modules. It also offers an application interface for high level applications, such as terminal emulations. Development kits for this interface and the IO-drivers are available. PC/Flexnet is usable also for end-users which do not need a whole node. User are offered by this an AX25-driver with the advantages of FlexNet, like the very easy parameter setting and the modular driver concept. It runs with almost every terminal program which supports the WA8DED Hostmode.(See File TFEMU.DOC for details) In this case, FLEXDIGI.EXE is not loaded, and therefore no work needs to be wasted in setting it up.

RMNC/FlexNet V2 was a version which had many differences to previous versions for users and sysops, both operational & optical. The RMNC/FlexNet V3.0 had some new features, where the autorouter was the most important one. V3.2 was completely revised and became faster and more comfortable again. V3.3 brought the DAMA channel access method and is forerunner of a completely new access method which is also usable on echo duplex nodes. Maintenance of the RMNC was even more simplified, the change of the whole software of the node can now be done by changing one single EPROM. All L2- and L1-parameters except TxDelay are set adaptively to the current working conditions; this means that the sysop has almost no work in setting up parameters. We found it unnecessary to have parameters for every special cases.It was reached the point where the node runs without any maintenance, except for dropouts, of course. Some statistics are useful for the sysop in optimizing the interlinks and make the network transparent to the user. The permanent development and the very cheap hardware made RMNC/FlexNet to the most popular system within Germany, and the growth rates in foreign countries are impressive. From now on FlexNet for MS-DOS is available. The RMNC is not intended to be replaced, it is still the preferred platform for unattended nodes. However, it is an alternative for existing PC-based nodes and makes it possible to experiment with FlexNet without prior high investments in hardware.

2.2.1 Hop-to-Hop-Acknowledgement

Since V2 an important feature has been the immediate acknowledgement of received frames of QSOs which run via the digi. This greatly improves the stability of the links. The possibility of a failure used to be increased exponentially to the number of digipeaters in the path. Now the whole link is as good as the worst interlink on the way.

2.2.2 Connectability

Since V2 the RMNC-digi has been connectable, i.e. QSOs are now possible with the digipeater itself (previously it was only a L2-digi). The digi offers several service functions, for instance convers mode, link information and some information pages.

2.2.3 Remote Control

The FlexNet-software makes it possible to enter sysop mode of the digipeater remotely. This allows changing of parameters, information pages, link information and so on after successful authorization as sysop.

2.2.4 Installation

Updating to a new RMNC/FlexNet-software version is easy, just one EPROM needs to be programmed and changed. To simplify the configuration of the node, an IBM-PC(and compatible) based program is available for doing this job. Please refer to the chapters "Installing RMNC/FlexNet and "Generating a MASTER EPROM".

The software is available at no costs for use in amateur radio and may be copied freely in binary form (Disk/EPROM) as long as you accept the legal terms. (see section 6)

Most parameters which had to be set manually on traditional node systems are set automatically by FlexNet according to the actual conditions.

After many experiments, RETRIES were set to 10, but this caused QSOs on fast links to break on short interrupts. To fix this, the node polls at least 90 seconds before giving up. The number of polls, therefore, indirectly depends on the data rate and the use of the channel. FRACK (Frame-Acknowledge-Time, T1) is permanently adjusted to the time the other station needs to acknowledge the I-Frames. MAXFRAME is set according to the reliability of the connection. When all frames are acknowledged reliably, MAXFRAME is quickly set to 7. On 1200Bd, however, 7 frames are sent relatively rarely, since the maximum time of one transmission is restricted to 12 seconds. All QSOs are handled equally, i.e. they share the 12 seconds transmission time. If one station needs a retransmission of frames (e.g. by REJects), MAXFRAME is decreased instantly. In this case it is provable that the throughput is significantly higher when MAXFRAME is set between 1 and 3. Only the quality of the connection TO the other station is checked, not the connection FROM the other station. A poll which gets the acknowledgement of all frames or a lost acknowledgement does not affect MAXFRAME. PERSISTENCE is the most critical parameter when many users are using the same channel. A fixed parameter setting is always only a bad compromise between collision probability and transmission willingness. FlexNet, therefore, makes use of a new access method, which works fully adaptively.

3.2.1. Link Setup

During the connection setup the received SABM-frames are routed normally, the UA is not sent immediately. This means that the connection is established only if the called station is reachable. When the called station answers with an UA, this will be routed to the calling station. At this moment, 2 QSOs are in the user list, one from the calling station to the called station, and one back. A special feature of FlexNet is, that the connection can be established in one single step without disadvantages, the common L2 digipeating is simulated. At home, you can directly "Connect <user> via <entrynode> ,<exit node>" or "Connect <destination node> via <entry node>". You do not need several "Connect" commands to make your way to the destination. As hop-to-hop-acknowledgement is still active, the quality of your QSO is not affected.

3.2.2. Information Transfer

During the information transfer, hop-to-hop-acknowledgement gets activated. Every I-Frame is immediately acknowledged by the digipeater. Now the digipeater tries to route the packet further on to its destination. REJects due to interference or collision only happen at one section, not in the whole route.

3.2.3. Link Failure

If the connection breaks at one side during information transfer, the digipeater interrupts the whole connection and displays the message: "*** OK0NE: link failure". Thus, the partner gets informed that something does not work.

3.2.4 Disconnect

As mentioned above, not every digipeater in between needs to be named, only the entry and the destination digipeater must be known. There are 4 methods to route a frame to its destination, tried in the following order:

1 destination table routing

2 link table routing

3 Heardlist routing

4 SSID routing

3.3.1. Destination Table Routing

The first method is based upon the callsign information. The digi tries to look up the destination callsign in a table maintained by the autorouter. If the callsign is found in this list, the frame is sent to the corresponding neighbor.

Example: DB0ODW has the following interlinks: 1:DB0KT 2:DB0AAC 3:DB0IE

and knows the destinations: DB0EQ, DB0ZDF etc. The frame: <fm DG3FBL to DK7WJ via DB0ODW, DB0ZDF> gets expanded to <fm DG3FBL to DK7WJ via DB0ODW*,DB0AAC,DB0ZDF> DB0AAC is now the next call in the digipeater field, and is known as a neighbor of DB0ODW on port 2. So the frame is sent on port 2 to DB0AAC which will then route it to DB0ZDF.

3.3.2. Link Table Routing

When the router does not find a matching entry in the destination table, the digi now tries to look up the call in the link table as set up by the sysop. If a route is found here, the frame is sent to the right port.

Example: DB0ODW has the following interlinks: 1:DB0KT 2:DB0AAC 3:DB0IE 4:DB0AIS #

The frame <fm DG3FBL to DK7WJ via DB0ODW,DB0AIS> is transmitted on port 4, although there is no entry in the destination table. In this case, only the link table is used for routing.

3.3.3. Heardlist routing

The node remembers the last 200 stations heard in an internal list. The SSID of the station is taken care of, if possible. So it is possible to be standby on different ports with different SSID’s without any problems; you will always receive your frames on the right port. Incoming connection wishes and UNPROTOS are routed according to this list.

3.3.4. SSID routing

The last chance to get the frame delivered is the SSID specified for the digipeater. The sysop can assign SSID’s to certain ports using the PARMS command. To make use of the SSID routing, the user just specifies the SSID of the port where he wishes his frame to be transmitted.

Example: DB0ODW has the following mappings of the SSID’s to the port numbers:

port 1 has the SSID -0, port 5 the SSID -12, port 6 the SSID -3

When there is a connect request received which specifies a SSID for the node, the frame is sent on the port specified by the SSID:

<fm DG3FBL to DK7WJ via DB0ODW-12>

This frame is transmitted on port 5, which owns the SSID -12, provided there is no other way known to DK7WJ. On port 5 the following frame appears:

<fm DG3FBL to DK7WJ via DB0ODW-3*>

This ensures that someone on port 5 knows where the frame came from, i.e. the entry-SSID is put into the frame. This SSID change is needed to ensure that the receiver knows where to send his UA to, i.e. port 6 with the SSID -3. This is an important feature of FlexNet. All paths are reversible, i.e. transparent to the receiver, even if the connection came by connecting further on at a node. This routing method is used mainly on user ports.

When all these routing methods fail, the frame is discarded. If the frame was created by an "Connect" command at the node, the user gets the message: "*** <call>: can’t route"

User commands are all the commands normal users can access. The sysop has a set of additional commands or may specify additional parameters to normal user commands. In this documentation, <CR> means entering of a Carriage Return, $0D. The "=>" is the system prompt of FlexNet;input is expected now. All input can be made either upper or lower case.Is another command entered than those listed below, the node answers with: "invalid command".

Syntax: A <CR>

The A-Command shows the text for latest news as set by the sysop. After a cold reboot this text is empty.

Syntax: B <CR>

The B-Command shows the current beacon file. In this file you can see which beacon is sent on which port in which interval. After a cold reboot the default beacon is sent on port 0 or 1.

Syntax: C <CR>

If no callsign is given, the CONNECT command puts you in convers mode. By this mode, a great number of stations can have a round table conversation There are 255 different convers channels available. After entering the C-Command, you get a list of all stations connected to the node and, if they are in convers mode, too, the channel on which they are. Now the node prompts for a number, which selects the channel you want to join.

=>C <CR>

users:

0: DL1AA 0:DL1ZZ —: DL2XY 73: DG3FBL 73: DK7WJ

channel ? 73 <CR>

While being in convers mode you have the following commands at your disposal:

"/w" shows all stations connected to the node (with convers channel number if available)

"/c" shows the actual channel number

"/c n" switches to channel n

"/s <call> <msg>" sends private msg to <call> only

"/m <call> <msg>" sends private msg to <call> only

"/q" quits convers mode

If there is no channel number entered on convers start-up, convers mode is ended immediately. You are then prompted for a new command.

Syntax: C Call [via] [digi1 digi2 ... digi8] <CR>

The CONNECT command is used to connect further onwards. The node will try to connect you to the station via the path you specified. To confirm your command, you get the message "link setup...".As soon as the connection is made, you will get "*** connected to <call>" from the node. When the called station did not respond, you get "*** failure with <call>". If the called station sends a Busy (DM), the message "*** busy from <call>" is sent to you. The link setup can be interrupted by sending a single <CR> to the node. If you see the message "*** can`t connect twice", you have tried to establish a QSO which already exists with the same callsign fields.

With the C-Command it is also possible to change the user port, if the node has more than one. By typing "C -7" you change to the port with the SSID 7. This is acknowledged by the message "*** <call>: SSID OK".

If you connect to another station from the node onwards, and that station disconnects you, you will get reconnected to the node. To show you what happened, you get a "*** reconnected to <call>" then.

A connect request will be denied, if it causes a loop in the network. If, for example, you are connected to DB0KT via DB0ODW, you cannot connect back to DB0ODW nor to other nodes behind DB0ODW. You should quit the QSO with DB0KT then and retry after the reconnect.

=> C DB0ODW <CR>

link setup...

*** connected to DB0ODW

RMNC/FlexNet V3.3d - DB0ODW - JN49 IQ - Help mit H

=> C DB0HP <CR>

*** DB0ODW: loop detected

=> Q <CR> 73!

*** reconnected to DB0HP

Syntax: D [call] <CR>

The DESTINATIONS command prints out the destination table maintained by the node. In this table all nodes, where the autorouter knows a way to, are shown. For every callsign there are the SSID range of the callsign and the average round trip time in 100 ms steps are shown. As an optional parameter a destination callsign may be given. The node will now try to work out the way to this node and will show it (after some seconds, depending on the (round-trip time). Uppercase callsigns mean that the node knows the FlexNet protocol, lower case callsigns are inserted by the autorouter to reach the next FlexNet node. The characters "???" mean, that the previous digi does not know the way to the destination. This may happen, when the route to the destination is reorganized at the moment or when the destination is not reachable anymore. The "D-Table" is usually the same on all nodes. Only when round trip times get too high, a node is not shown anymore. Only nodes that you can reach without link loops are shown by default. This reduces link load and has the advantage that you will see only the nodes that are not in your direction. By using the option "*", you will get the complete list. Another possibility is the selective display of a part of the list. By entering "D HB9" for example, you get all destinations starting with "HB9", i.e. the whole Swiss network. Both parameters may be used together. If you type "D * HB9" you will get all Swiss destinations, including these you cannot reach without loops.

Syntax: F call <CR>

With the FIND command it is possible to look for a station which is standby on this or another node. When the F-Command and the callsign are entered, the digi sends UI-frames with the POLL-bit set to this station via some neighbor nodes. Source callsign is the callsign of the OM who issued the FIND command. If the called station hears the frame, it will answer with a DM- Frame. The node analyses all frames coming back and is able to determine if this was an answer of the FIND command. If this is the case, you will get a message via which node the station was found. If the called station is already connected to the node, no special frame is sent and the user will get the message that the user is QRV on the digi.

=>F DK7WJ <CR>

*** DK7WJ found via DB0ODW

Only the node via which the called station was found is put out. It will be known to the autorouter. If the station was not found, a system prompt "=>" appears again. Since the used UI and DM frames may get lost, it is advisable to use the FIND command more than only once to be sure the user is not QRV. Due to the protocol, the SSID of the called station must be known.

Syntax: H <CR>

The H-Command prints out the text-file HELP. The text can be entered by the sysop only and should give short help text about using the node. After a cold reboot the text is empty.

Syntax: I <CR>

The I-Command prints out the text-file INFO. This text can be entered by the sysop only and should provide information about the node (QTH, equipment, antennas and so on). After a cold reboot the text is empty.

Syntax: IO <CR>

The IO-Command shows the state of the I/O-ports of the RMNC reset card. There are 16 lines in and 16 lines out. The latter may be set only by the sysop. Using this ability it is possible to remote control the node by hardware. There are no limits to the fantasy of the sysop. The data is shown binary.

Example: =>IO<CR>

The input lines are shown first and then those of the output. 0 means "low", 1 means "high". The meaning of the single bits needs to be documented by the sysop.

Syntax: L <CR>

=>L <CR>

DB0KT 0-7 60/68 P1

DB0AAC 0-15 (—) P2

DB0IE 0-1 583 P3

@ DB0EQ 0-8 (355/399) via DB0IE

DK7WJ 8-11 44/67 P0

- DB0ABA P4

In the first column the callsigns of the neighbor nodes are shown. Second column shows the SSID ranges of these stations (default: 0-15). In the third column you read the round trip time to the neighbor in 100 ms -steps. No number here means that the round trip time is not calculated. Three hyphens mean that the link is not available at the moment. Three hyphens within brackets mean that the link is not available but the autorouter is aware of another way to the station. If there is only one number in the column, the link partner does not know about the FlexNet protocol, or the internode QSO could not be established. When the sysop knows that the neighbor does not know the FlexNet protocol, he may set the attribute "@" to the link. Then only the link is tested, not if the partner knows the protocol. If the round trip time is surrounded by brackets, the link is so bad that it is not made known to the network. If there are two numbers, separated by a diagonal stroke, the neighbor is a FlexNet node. In this case the round trip times of both directions are shown. If these values are within brackets, the autorouter knows a better way to the destination, i.e. the direct link is not used. The 4th column shows either the port number of the link to the neighbor (on direct links) or the stations via which the neighbor is reachable. A hyphen behind the port number means that the link is not made known to the network. This may be used for temporary links or software tests for example.

Syntax: LO <CR>

The LO-Command shows the text-file LOCAL. This text is appended to the CTEXT for local users, but it can be displayed by the LO command separately. The text may only be entered by the sysop. After a cold reboot this text is empty.

Syntax: M <CR>

The MAIL-Command connects you to the nearest BBS as defined by the sysop. This command therefore works like a "Connect" command with predefined destination. The BBS callsign can be shown with "M ?" (notice the space!)

Syntax: MH [options] <CR>

The MHeard-Command by default displays the last 30 direct heard callsigns. Optionally, a port number, a callsign (with or without SSID) or a number (16 ... 200) of entries to be listed, may be given.

Syntax: MY <CR>

=> MY <CR>

mycall: DB0ODW, SSID’s: 0-7

Syntax: P <CR>

The PARAMETERS command puts out a list of the current parameters and some channel statistics. Additionally, the links as shown with the <L> command are displayed.

=> P <CR>

po id td qso usr tifr rifr tkby rkby qty mode links ssids time

1 — 10 30 1 365 287 50 33 100 9600d*+ DB0KT 0-10 6/6

2 — 1 36 1 271 908 30 163 99 19200d*+ DB0GV 0-0 4

3 — 1 1 1 0 0 0 0 100 9600d*+ DB0GV 6-6 10

4 — 40 3 1 27 3 2 0 82 1200*+ DB0TCP 0-15 580/647

5 — 1 50 1 835 377 102 55 100 19200dtr*+ DB0SHI 0-15 11/39

6 — 1 39 1 582 546 78 42 100 38400d*+ DB0GV 10-12 1/1

7 — 40 4 1 31 3 2 0 70 1200*+ DB0ASF 0-15 229/243

The single columns mean:

po: Port number

id: Port SSID, on interlink-only ports "—"

td: TxDelay in 10 ms units

qso: number of QSOs on this port, internode QSOs are also counted

usr: number of stations heard on this port (since 3 mins)

tifr: transmitted I-frames within the last 10 mins

rifr: received I-frames within the last 10 mins

tkby: transmitted kilobytes within the last 10 mins

rkby: received kilobytes within the last 10 mins

qty: quality of the channel; this is updated every 10 mins, but not if there was nothing to send.

mode: Baudrate on this port, additionally:

"c" KISS: CRC-Mode, HDLC: Software-DCD (depends on hardware)

"d" fullduplex

"t" xternal TX-Clock

"r" external RX-Clock

"z" NRZ mode

"m" DAMA master

"s" port is synchronized

"u" port is user port

"y" autosysop

"+" 8 Mhz CPU-Clock (RMNC)

"!" 12 Mhz CPU-Clock (RMNC)

"#" 16 Mhz CPU-Clock (RMNC)

links: see <L>-Command

When counting the I-frames, re-iterated frames and frames which got lost due to DISC are not counted. The kilobyte statements are only the contents of the acknowledged I-frames, re-iterations are not counted, too. Thus, this is the genuine net data rate.

Syntax: Q <CR>

The QUIT-Command ends the QSO with the node. After a "73!" you get disconnected. If you are connected from another FlexNet node, you will be reconnected to that node.

Syntax: S <CR>

=>S<CR>

search digi’s:

DB0ODW

DB0KT via DB0ODW

DB0AAI via DB0ODW

DB0DA via DB0ODW

DB0IE via DB0ODW

The frame generated by the FIND-Command would be sent via DB0ODW, DB0KT, DB0DA, DB0AAI and DB0IE.

Syntax: T <call> [<text>] <CR>

With this command you can talk to other users connected to the node. There are two modes: If there is a text given behind the callsign, then this line is sent and you get back to the prompt. Thus, you have to issue a new Talk-Command for each line. By "T <call> <CR>" you get into the permanent talk mode which can be left later by using "/q". This is similar to convers mode, with the difference that it does not happen on a convers channel. All Convers-Commands are active and the current status can be displayed with "/c".

Syntax: U [n] <CR>

The USERS-command displays all users which have a QSO with or via the node. Additional information is provided: Example:

1: S5 P0: DB0ODW>DG3FBL

6: S7 U1 P0: DB0ODW>DK7WJ

35: S5 P0: DL1AA>DB0GV v DB0ODW DB0KT

i.e.

The QSOs with the node are shown first, then the ones which run via the node. Additional parameters may be specified on the "U" command line. If you enter an "i", only QSOs with the node are shown. If you enter a port number, you get all QSOs via that port. Using "U *" you get additional information about the QSOs. The parameters may be combined. For example, "U * 4" shows all QSOs on port 4 with detailed information.

1: S5 F100 M3 P0 : DB0ODW > DG3FBL

6: S7 U1 F87 M7 P0 : DB0ODW > DK7WJ

35: S5 ! F50 M4 P0 : DL1AA > DB0GV v DB0ODW DB0KT

In addition to the commands a "normal" user may use, the sysop has some extra privileges. This includes additional commands, or additional parameters to the user commands. Commands which have additional parameters are the as followed:

Syntax: CAL <ch> <mins> <CR>

The CALIBRATE-Command turns on the TX of a specified port (parameter <ch>) for one minute. While this time the carrier is modulated by a continuous sequence of 0 and 1, producing a "diddle" tone with a 50:50 ratio. The command is useful in 2 cases: - It makes it possible for the link partner to set his antenna to the right direction. - The symmetry of the modulation may be checked and the modem maybe adjusted for best results. If there are frames in the buffer, they are sent before the calibration starts. To trigger the PTT watchdog the CAL signal is interrupted every 15 seconds for a short time. Optionally, the calibration time in minutes may be given.Default is one minute. With the command "CAL <ch> 0" the CAL signal is cancelled.

Syntax: IO <bit_no> 0|1 <CR>

With the IO-Command the output-lines of the reset-card may be set or cleared. <bit_nr> specifies the number of the bit to be changed, and 0 or 1 says whether the bit should be set to "high" or "low".

Syntax: K <QSO-No> <CR>

The KILL-Command terminates an existing QSO. The QSO number must be specified (U-Command, 1. column). Why this command? It is not made to let the sysop feel like the "big boss", but sometimes it is necessary to kill a QSO.

Example: Station A is connected to station B, and A transmits a longer text to B. After a certain time, the receiver of the text, station B, gets busy, i.e. his TNC sends RNR. When this state is not fixed by B itself, the QSO will last for ever, at least up to the next blackout.

Syntax: L <ch|CALL|-> <CALL> [#|$|-|@|>|)|!] <CR>

The LINK-Command is used to set up interlinks. Two parameters are needed, a 3rd one is optional. Callsigns may be written either as upper- or lowercase.

1st parameter: port: set up direct interlink on this port callsign: set up interlink via that callsign, i.e. the destination is reachable via a neighbor already specified. - : the minus sign deletes the link entry

2nd parameter: Here the callsign of the link partner is given. If no SSID’s are specified, 0-15 are assumed. When only the SSID 0 is to be linked, -0 has to be added to the callsign.

3rd parameter: options

"#" link is not shown to the users, thus hidden links, for example for service reasons, are possible .

"$" link is not checked for availability and not made known to the network.

"@" no internode communication on this link , but may be used, if the partner is not aware of the FlexNet protocol (i.e. mailboxes)

"-" partner is not made known to the network. This makes emergency- or testlinks possible. Internode communication takes place, thus destinations are routed, only the partner stays hidden.

">" Subnet-Link. This is used to set up subnets, which will receive all information from the network, but are not made known to the network. The partner callsign and the destinations from it are saved for routing reasons, but not sent to the other network nodes.

")" Works like ">", but the link is hidden (">" + "#")

"!" no forwarding of Subnet destinations: Same like ">", but the difference is that the "gateway" node is made known to the network.

It is possible to have more than one link to the partner on different ports. The router will always use the best link available. You should remember this if changes are made. The old entry may still be valid under circumstances. It is also possible to link partners with the same callsign, or a callsign covered by the SSID range of the node. This is interesting for mailboxes, service computers, DX clusters and similar systems. Using this feature, only the node is forwarded to the network and not every single SSID of the different computers. This helps keeping the D-list in the network smaller.

MYCALL DB0AIS 0-10

L 1 DB0AIS-8 @ (Mailbox)

L 2 DB0AIS-9 @ (Cluster)

Only DB0AIS 0-10 is known to the network. If there is a connect request to DB0AIS-8, it is sent out on port 1 to the BBS. The links are not tested as usually. If the link is not available, the user gets connected to the node itself. Here, the user should get to know what is wrong, perhaps by the C-text. This routing method works on user ports, too. In our example, if DB0AIS would have a user port, the node may be connected as DB0AIS or as DB0AIS-3, and the BBS DB0AIS may be directly connected without digipeaters.

On port 1, 2 link partners are reachable, so the setup has both calls on port 1.

There is a principle which says that if no SSID’s are specified behind the link callsign, all SSID’s are routed via this port. But when a SSID is specified, only the SSID is routed. Example:

All frames route to DB0KT, i.e. also the frames to DB0KT-1, DB0KT-2 are routed to port 1.

Only the frames to DB0KT-7 are sent to port 1. Other SSID’s are routed by the D-List, when no other links to DB0KT are specified. On FlexNet partners the SSID-Range is automatically adapted.

To remove an entry from the link list, a "-" is given instead of the port number as the first parameter.

Example: DB0ODW has the links

1: DB0KT 2: DB0EAD 3: DB0IE "L - DB0KT" deletes the routing entry for DB0KT. If there is more than one link to the partner, the command has to be given several times to delete every entry. Always only the first entry is removed from the table. Links to NET/ROM partners should be set up as shown in the appendix.

Syntax: MO <port> <mode> <CR>

This command sets the operating parameters of a specified port. The mode parameters are:

<num> baudrate (on internal clock)

"d" fullduplex (halfduplex is default)

"t" external TX Clock (depends on hardware)

"r" external RX Clock (depends on hardware)

"z" NRZ mode (depends on hardware, NRZI mode is default)

"c" KISS: CRC mode; HDLC: Soft-DCD (depends on hardware)

"m" DAMA master

"s" synchronize channel with other "s"-channels

"u" user port, activates for example TxDelay measurement

"y" auto sysop: Stations which connect on this port without digipeaters in their path are automatically sysops. For security reasons, on RMNC this may only be defined in the EPROM.

"-" deactivate port

"." dummy, if there are no arguments needed on special hardware

The parameters baudrate, "d", "t", "r", "z" and "c" depend on hardware. Check out the hardware or driver documentation.

MODE 3 19200d ;port 3 19200 baud fullduplex

MODE 3 38400trz ;port 3 38400 baud ext. clock, NRZ

When a MODE command is entered, all Layer1 modules of all channels get initialized. This is not problematic, only frames currently being transmitted or received are involved. QSOs are not affected. A Mode-Command may re-initialize "hanging" SCCs. Therefore you should always try a Mode-Command first before a RESET or RESTART since all QSOs get lost in this case. The port number is not relevant, a "MO 11" will do the job.

4.2.6. <M>ail

Syntax: M <call> <CR> With this command, a BBS callsign is assigned to the node, which can be reached by the users issuing the "M"-Command. It must be reachable in a single step and known to the autorouter.

Syntax: MY <call> [<ssid1> <ssid2>] <CR>

The MYCALL-Command is used to set up the callsign of the node. With the optional SSID’s a range may be defined by which the node can be connected. The SSID range must include the SSID’s of every port, no port SSID must be outside the SSID range defined by MYCALL.

The node callsign is set to DB0ODW. The node may be connected as DB0ODW-0 to DB0ODW-7. When the MYCALL is changed, this will affect only new QSO’s. Existing connections stay valid under the old callsign. The internode communication is re-initialized completely, since the change of the callsign needs to be forwarded to the network immediately.

Syntax: P I <value> or P S <value> <port> or P T <value> <port>

The PARAMETER command is used to set up the TxDelay, SSID and the node timeout of a specified port.

"P I <n>" sets the node timeout to <n> minutes where a range from 60 to 255 is valid. n=0 (recommended) disables the timeout.

"P T <n> <port>" sets the TxDelay of port <port> to <n> in 10ms units.

"P S <n> <port>" sets the SSID of port <port> to <n>. When an already-set SSID has to be deleted, <port> has to be 16.

Why do we need SSID’s ? They do two jobs: Only on ports which do have a SSID, everyone is allowed to connect. Exclusive interlink ports therefore should not have SSID’s (exception: links to NET/ROM partners, see appendix). The SSID is also needed for routing purposes, if a user who is not in the MHeard-list shall be connected on a specified port. The connect then needs to go via the according SSID, i.e. via <nodecall>-<port-SSID>.

Syntax: RESET <CR>

This command cold-reboots the node. All QSOs, parameters in the RAM and the text files get lost. The default parameters as stored in the RMNC master EPROM are set. You should use this command only when your parameters got disordered and you want to reset to EPROM defaults. This command is available only on RMNC systems.

Syntax: RESTART <CR>

The RESTART-Command basically does the same as the RESET command. However, parameters and text files remain in memory, so usually you should use this command instead of RESET. You should use both commands only in emergency, since all QSO’s and the routing information get lost. This command is also available only on RMNC systems.

Syntax: SY <CR>

The SYSOP-Command is used to do the sysop authorization. When a remote request is sent to the node from the sysop to enter the sysop mode, the node answers with a random number. This number has to be answered by the sysop with the exact combination. The algorithm used is easy enough to do the calculations without a calculator, therefore security is limited. Perhaps the algorithm will be changed in future. How does it work ?

Example:

The reply included a 5 digit number which is the seed for your calculation to compute the reply. In order to respond, and log in as sysop you need to know the seed and the sysop code.

Assumed that the sysop code programmed in the node is 54321 and the number the node sent as the seed is 12345 (as above.) Now the calculation:

* multiply the coinciding random & sysop numbers :

1 2 3 4 5 <- random number

5 4 3 2 1 <- sysop secret number

1*5=5; 2*4=8; 3*3=9; 4*2=8; 5*1=5

* Now sum up the products: 5+8+9+8+5=35

Ready. 35 is the number the node expects to receive. Now you are sysop (provided, your calculation was OK). To make it more difficult for spies, you may send the SY-Command more than once. The calculation has to be right only once. If the other answers are wrong, it is more difficult for a spy to catch the secret code. After successful login as sysop no message is returned. You may now try out whether it went all right by a harmless command like TIMEOUT. If you are logged in as sysop, the node timeout is not valid for you anymore, i.e. you may stay connected to the node as long as you wish. The sysop authorization is removed by disconnect, reconnect (link reset) or a Connect-Command. It is possible that more sysops are logged in at the same time.

Syntax: TRACE <ch> [<call>] [<] [>] [#] [$] <CR>

By using the TRACE-Command, you can monitor the traffic on a given port. This of course only works as long as the buffers do not overflow. When your own QSO is fast enough, you may monitor for a longer time. Compressed QSO’s are shown only if your node is the source or the final destination of the QSO. The command is cancelled if the buffers overflow or you type another command. Only one sysop may monitor only one port at one time. You should note that this command needs a large amount of memory and bus capacity, which will slow down specially the monitored channel. Therefore, you should not use it too often and under no circumstances permanently. This command is only available on Solomaster systems.

Options:

# do not display RR/RNR/REJ-Frames

$ suppress the I and UI texts, i.e. display only frame headers

<call> trace only this callsign. Only source and destination callsigns of a frame, i.e. no digipeater calls are checked. SSID is taken into account if specified.

> only frames sent

< only frames received

Syntax: WRITE <A|B|C|H|I|L|S> <CR>

By using the WRITE-Command, the texts for L(A)test news, (B)eacon, (C)-Text, (H)elp, (I)nfo, (LO)cal and (S)etsearch may be entered. All texts except (B)eacon and (S)etsearch may have any desired format. The C-text is sent after the standard system prompt at the beginning of a connect. Standard prompt is "xxxx/FlexNet Vx.x". The C-Text is shown after this.

After any Write-Command, the amount of available memory on the RMNC is shown.

We recommend the following usage of the texts:

LATEST NEWS: recent information about the node and things every user should know

INFO: general information about the digipeater. QTH, hardware, antennas, use of IO-ports etc. You should not forget to mention the user QRG’s.

LOCAL: this text is appended to the C-Text, when the user comes direct, i.e. without digipeaters in the path. This is the right place for information about the channel access method and other information which is only interesting for local users.

HELP: A short user’s guide to the system with the most important commands

The text files cannot be saved in the EPROM due to space limitations. The end of the text is marked by either /EX or Ctrl-Z. The text is saved up to the last line before the /EX. Since many PR-stations use "split screen" programs, it is recommended to begin every text except the C-Text with a single <CR>. This looks much better.

The Beacon-file has a special format. You may set up any beacon on any port. The file format is as follows:

# <t> <p> <tocall> [via [via ...] ] :Beacon text..........................#

<#> delimits the different beacon information

<t> time between two beacon transmissions, in minutes. (1..255 minutes)

<p> port number where the beacon is to be sent

<tocall> Destination call of the beacon, for example "BEACON", "RMNC", "FLXNET", "TEST" or similar , there may be up to 8 digipeaters specified, via which the beacon will be sent.

Example:

Our example consists of 3 beacons, each delimited by a "#":

(beacon1...#beacon2...#beacon3...)

Between the single statements there may be <CR>s to improve readability. It is not important whether the callsigns are upper- or lowercase. Source callsign of the beacon is always the mycall of the node. When no beacon-text has been entered since the last cold-reboot, the default-beacon is sent every 3 minutes:

#3 0 FLXNET:RMNC/FlexNet V3.3d

All beacons are sent as UI (Unproto-Information) with the command bit set.

<call1>

The SETSEARCH-file contains all paths via which the FIND-Command sends its UI-Frames. The first callsign in the line is the digipeater which shall send the UI to the user, the following digipeaters specify the path to the destination digi. These paths should always be identical to the path a user will use. This means, digipeaters on the route to the destination should be left out, the autorotter will know the way.

Example:

DB0ODW DB0DA via DB0ODW DB0KT via DB0ODW DB0AAI via DB0ODW

The first line says that the UI-frame is sent via the local user port. Second line demonstrates how a path to DB0DA is set up. DB0DA is reachable from DB0ODW via autorouter.

The following restrictions have only the purpose to guarantee the quality and the development of the software and, of course, to avoid commercial use of it, except in special cases agreed on with the author of each module. By experience, on uncontrolled distribution it happens that only parts of the software or obsolete versions of it are spread. This results into problems at the end-user’s and into unnecessary and annoying check-backs. Bad experiences cause the list to grow constantly...

• RMNC/FlexNet, PC/FlexNet and the accompanying utilities and the documentation are products of Gunter Jost, DK7WJ. Exceptions are marked as such. All rights reserved by the author. The user is granted the right to use the software under the following conditions:

• The software is used only for non-commercial purposes within amateur (HAM-) radio. All other usages, especially in other radio services, need a written consent by the author in each separate case.

• The legal rules of amateur radio operation are strictly followed.

• Commercial copying and sale of the software is not allowed without prior written consent of the author.

• No changes must be made at the software which are not explicitly agreed with the author. This does NOT apply for setting specific parameters.

• Copyright marks and copyright messages of the software modules must not be changed or removed.

• The software must not be distributed via BBS systems or public accessible bulletin boards, neither in part nor as a whole.

• Neither the author nor the distributors of the software may be liable for any damages, no matter of what kind, which may occur when using the software. THE RISK OF USING THE SOFTWARE IS ENTIRELY YOUR OWN!

Neither the author nor the distributor of the software may be liable for any damages that may eventually occur when using the software RMNC/FlexNet or PC/FlexNet. The software is provided "AS IS", without warranty of any kind, including but not limited to the warranties of merchantability and fitness for a particular purpose. No features should be taken for granted. The documentation may contain errors or mis-translations.

By using the software you agree to the conditions above.

The RMNC consists of an port controller card for each port on a euro-sized board (100 * 160 mm). Additionally a so called reset card is needed which contains the system watchdog and the In/Out-ports for supervisor and control reasons. The cards are run in master/slave mode, i.e. one card is the master, the other cards are the slaves. The whole communication on the system bus is controlled by the master, that means the master polls every slave for information and mediates them where they belong. The only hardware difference between the cards is that the master contains a different EPROM than that of the slaves. This has the advantage that only the master needs to be configured, all slaves receive their configuration information from the master. After a reset, the master determines the number and the addresses of the attached cards. Then these cards get initialized with their parameters. If there is a malfunction at one of the port controller cards, the master gets to know this after the watchdog-reset which will occur. The defective card will not be polled anymore, and the node will still work - provided that the damage does not block the bus.

When installing the RMNC/FlexNet software, the card addresses need to be configured. Attention, the master card has no address, i.e. all DIP-switches need to be open! For addressing the other cards, please refer to the hardware manual. The cards may be addressed in any desired order, gaps do not matter.

In the parameter table (P-command) the master always is port 0. When using a Solomaster, then no port 0 is shown. Now the EPROMS can be installed on their boards. Only ONE master EPROM has to be installed, all other cards must be equipped with (identical) slave EPROMS.

The software is distributed unconfigured. To configure it, you need at least an EPROM programmer capable of programming 27C512 EPROMS, and an IBM compatible PC.

7.4.1. Parameter Compiler

The master EPROM is configured with a PC program. With the aid of this compiler and a parameter file, a configured binary file will be created which is ready to be programmed into the EPROM. The slave EPROMS do not need to be configured as they are the same on every RMNC. To get the compiler to make the binary file, you have to create the parameter file first. The parameter file is a plain ASCII file which can be made with any editor. This file contains all necessary parameters. The syntax of the file is similar to the syntax of the sysop commands. When you have finished making the file, you can start the compiler. If you are lucky you now have a file with the same name as that of the text file, but with the extension ".BIN" in the directory. This file also exists when warnings occur there. If the compiler detects syntax errors, no .BIN-file will be created. For control reasons a second file with the extension ".LST" is produced. You should have a look at it to ensure that the compiler understood everything. The .BIN file can be burned into a 27C512 EPROM now.

Syntax of the compiler:

MRMNC <parmfile> [<binfile>] <CR>

The first command line parameter is the file name of the parameter file with extension. Specification of the <binfile>-name is optional and will only be necessary if the name desired is different from the name of the text file. If a file with the same name exists, the compiler will ask if you want to overwrite it. The compiler creates a list file (".LST") which contains all default parameters.

7.4.2. Structure of a parameter file

Everywhere in the file, except inside of commands, comments are allowed. Everything which stands behind a "*" or a ";" is ignored. Empty lines are ignored, too. The syntax of the commands is the same like entering the commands into the digipeater. The file is not case sensitive. It is recommended that you note down everything carefully. This makes changes easier later.

The slaves need not to be configured. The EPROM file RM_SLAVE.BIN is intended for programming into an 27C128 EPROM. When a 27C256 EPROM is being used, the file must be placed at the upper half, beginning at $4000.

7.5.1. EPROM Patch Slaves 9-15

The RMNC2 controller cards contain only a 3bit address switch, thus you can only address a maximum of 8 cards (1 master and 7 slaves). For the slaves 9 - 15, the byte $3F00 ($7F00 on 27C256) must be patched to a value different to $FF. This adds "8" to the address setting of the DIP switches. On RMNC3 cards this is not necessary anymore, here the address can be set directly.

7.5.2. KISS-Slave

It is possible to use the KISS protocol directly with the node. There is no separate KISS EPROM anymore, on the RMNC2 you have to add a single wire between pins 18 and 39 of the 6522. On RMNC3 you have to short the jumper JP1. Since the KISS protocol is not secure, a CRC mode was added. It can be activated by a MODE-command. Specifications of this new mode are available from the author.

At the beginning, all files must be copied into a directory which should be in the DOS search-path. The start of PC/FlexNet should be done via a batch file because most of the L1 drivers need additional command line arguments. Occurring errors should abort the batch file. A sample batch file is on the distribution disk and can be easily changed to fit your needs.

FLEXNET.EXE must be loaded first, then - if a node is to be installed -FLEXDIGI.EXE. Pure endpoints (Terminal, Cluster, BBS and so on) should not use it. Then the L1 drivers follow in the order you require. At last, the activation of the modules is made by the utility "FLEX". After doing this, no more port drivers can be installed.

FLEXNET.EXE has an optional parameter, which specifies how many RAM may be used by FlexNet. Default is 15kb, but this lasts only for few QSO’s. The minimum for nodes with several ports is about 80kb. Depending on how many ports you use, you should experiment with this value. FlexNet loves memory more than everything else and runs best when it has about 30kb per port and additional 20kb for administration.

To load the modules, generally (from DOS 5.0 onwards) you should use the "LOADHIGH" or "LH" command. It does not do any harm if there is not enough memory in the UMB; the file is loaded into conventional memory then. You still gain a little memory, since the environment blocks do not fragment the memory. You may check this by using the "MEM /D" command.

Calling FLEX.EXE with the argument "/U" uninstalls all L1 drivers and removes FLEXNET.EXE from memory. As usually on DOS, no other TSRs should be loaded after FlexNet, otherwise your machine might crash.

The first start of FLEXNET.EXE creates an empty parameter file. Port 15 is generally the interface for applications. The parameter AUTOSYSOP ("y") is set on this port, you should not change it. Now you should set the sysop secret code using "SYSNUM.EXE". The secret code becomes valid at the next start of PC/FlexNet. With "TNC.EXE" you can connect the node now and continue in setting the parameters. If you made a mistake, you could simply delete the file "FLEXNET.FPR" and begin again. "TNC.EXE" is a simple TNC emulation. With "<ESC> H <CR>" you get a short help. The node can be connected with "<ESC> C <CR>".

The parameter setting of the software can be done now either by the TNC emulation or via remote control. Please check the documentation of the L1 port drivers. Like always on FlexNet, the rest of the parameter settings is very easy and can be finished in a short time.

Before you decide to build a digipeater using PC/FlexNet now, you should think about the following: The RMNC is still the preferred platform for FlexNet, and something that does not work there will not work on the PC either, except from some bagatelles. The user shall find a uniform and well known (from the RMNCs) user interface. Who prefers the optimum of reliability and performance for minimal costs and maintenance should use the RMNC.

Up to FlexNet V3.1 the p-persistence algorithm was used. This had the disadvantage that the send-willingness of the station could only be adjusted manually. Since V3.2 there has existed a fully adaptive channel access method, which adapts itself by determining the number of users and the channel allocation to calculate an optimal compromise between throughput and the collision-probability. Variables used:

B Baudrate (1/s)

TxD Tx-Delay (s)

R Random number (1 .. 10)

U Total of the users on the channel

K channel allocation

t1 waiting time after transmission (s)

t2 waiting time between two TX-tries

19200/s

K = (————— + 1 ) * (U + 1)

B

If K > 255, then K is set to 255. This prevents an increase of t1 on more than twenty users on 1200Bd.

t1 = K * (R+1)*8 * TxD

If t1 > 10s, then t1 is set to 10s, this can only happen on baudrates below 1200Bd.

t1 starts when its own transmission has ended. t1 is stopped as long as the channel is busy. As long as t1 is active, the TX is blocked. When t1 has expired, and the node wants to transmit, the DCD is checked in t2 intervals. If there is only one user, t2 becomes 0.

t2 = 2*TxD * (U-1)

The second column of the user list shows the actual L2 states. They shall be briefly explained here. For more information, please refer to the AX25-V2 protocol specification. Attention, we are using other numbers for the single states. Only the numbers 1-7 are the same as in the specification. The other states, which are only relevant for BUSY (NR) states, have been done by using bit masks, i.e. there are offsets added.

State Description

1 disconnected

2 link setup

3 frame reject

4 disconnect request

5 information transfer

6 REJ frame sent

7 waiting acknowledgement

Disconnected

This state is the default state. No QSO exists at the moment, therefore it is not shown in the user list.

Link Setup

A connection is being set up, i.e. SABM-frames are being transmitted, the acknowledge (UA) has not been received yet.

Frame Reject

Due to a sync error a FRMR-frame was sent, the connection is restarted. This may happen due to a software error or due to two stations with the same callsign.

Disconnect-Request

A connection is being disconnected, i.e. DISC-frames are being sent. The acknowledge (UA) has not been received yet.

Information Transfer

Hopefully, the most seen state. The connection is established, info-frames are being exchanged.

REJ Frame sent

A REJ-frame was sent, because a received frame was not in the correct order. A retransmission is requested.

Waiting Acknowledge

The link is being polled, either because I-Frames have not been acknowledged or because the link has to be checked.

Busy-States

—> Only available on Solomaster systems!

In the address field of the L2 protocol, up to eight digipeaters can be specified, which identify the path of a frame. In contrast to other node concepts (Net/ROM), FlexNet uses these fields for the routing of the frame to avoid a separate L3 header. All routing information is put into this address field. A disadvantage is, that this address field may grow very long, since every callsign allocates 7 bytes. Due to the VirtualCircuit-concept, however, this becomes redundant when a L2 connection is established. So with FlexNet V3.2 a compression of these headers was introduced. Instead of the 14 - 70 Byte, the header is now only 7bytes long, which causes a significant increase in performance. Especially short frames (RR, short I-Frames) shrink to 10 - 25% of the original length, which speeds up some interlinks to the double speed! Of course, this method can only be used if both partners of the interlink are capable of the protocol used. Address fields are only transmitted completely during link setup, during the QSO itself only the shortened addresses are used. Another shrinking of the header would be possible but could be dangerous if used on non exclusive channels. An obvious callsign needs to be transmitted to avoid mistakings. During the link setup, the own QSO number is sent behind the control field as a 14bit integer. As opposite to the address field, this number is transmitted right-justified. In the UA frame, the QSO number is transmitted also. Now every partner knows the QSO number of the other node. As soon as the connection is established, the compression kicks in. In the compressed address, the callsign and the QSO number of the receiving digipeater is transmitted.

format of the callsign (example DB0ODW)

byte# bit# data

0 7 d

0 6 d

0 5 d

0 4 d

0 3 d

0 2 d

0 1 b

0 0 b

1 7 b

1 6 b

1 5 b

1 4 b

1 3 0

1 2 0

1 1 0

1 0 0

2 7 0

2 6 0

2 5 o

2 4 o

2 3 o

2 2 o

2 1 o

2 0 o

3 7 d

3 6 d

3 5 d

3 4 d

3 3 d

3 2 d

3 1 w

3 0 w

3 7 w

3 6 w

3 5 w

3 4 w

3 3 ssid3

3 2 ssid2

3 1 ssod1

3 0 ssid0

Every character represents the ASCII code minus 0x20. In the first both bytes of the address field, the QSO number, C-bit and F-bit are encoded. The explicit setting of the Final-bit (bit 0) makes sure that the frame is not confused with the conventional AX25 address field.

9.9.1. Operating modes of the SCC

The ZILOG 8530 SCC contains two separate serial ports, every channel has its own clock generator. Since a HDLC channel needs two different clocks (x and 32times x), the clock generator of the second port (port B) is used to generate the single clock(x). Thus, port B is not usable for data transmission. If you had used both ports for data transmissions, the RX-Clock would have needed to be generated externally and additional parts would have needed on the card. When using RMNC2 cards with their own AFSK modem, the clock is derived from the PCLK supplied from the reset card (RMNC3 has a local oscillator). Port A of the SCC is used for data transmission. The clock generator A supplies the clock for the DPLL of the receiver(32*x), the clock generator B supplies the TX-Clock(x). On RMNC3, the A-port supplies the 32*x-Clock needed for the FSK modem. The TX-Clock is generated by the modem. Thus, "external clock" needs to be set here.

9.9.1.Clock Options

During the development of RMNC3 it proved necessary to change the clock options. Especially affected is the combination of external TX and internal RX clock. However, who uses some of the clocks on the RMNC for attached modems should have a close look at the following table. The new options and pin functions are as follows:

Mode: —: internal RX and TX I: Input

t: external TX O: Output

r: external RX tr: external RX + TX

FlexNet V3 makes it possible to link Netrom neighbors and to forward these interlinks, provided they are working. For the following explanations, we assume that our FlexNet node DB0FLX has an interlink to the NETROM node DB0NR. The Netrom node consists of several TNC’s with different SSID’s. The user port usually has the SSID -0. DB0FLX is on DB0NR-4 for example. Obviously, we should add DB0NR-4 to the link table of DB0FLX as it was done in V2. However, this has disadvantages:

FlexNet now knows a way to DB0NR, but only DB0FLX knows that it has to go to DB0NR-4 directly, and to the other SSID’s of DB0NR via DB0NR. In the D-lists only a DB0NR (0-15) appears. The user port DB0NR-0 is directly reachable. If there would exist a Convers-TNC DB0NR-8, it could be directly reached, too. The thing becomes even more Wizzardly when DB0NR has a second FlexNet neighbor. We assume DB0ZZZ is reachable via DB0NR-2. We add the following two link entries:

That has been the good news, and now the bad news:

The D-command shows a route to DB0NR-14 now, even if it does not exist. The Link-command is only capable of linking single (-0 -1 -2) or all (0-15) SSID’s...

The Netrom linkports have to turn on L2 digipeating. When accessing DB0NR-0, this should cause no trouble, since the diode matrix works without collisions.

The FlexNet-Group of Darmstadt, and therefore the authors and the maintainers of the software are reachable by mail:

FlexNet Gruppe Darmstadt

Gunter Jost, DK7WJ

Lichtenbergstrasse 77

E-Mail: <[email protected]>

Mario Lorenz,

DG0JAB@DB0JES.#SAA.DEU.EU,

As I am not a native English speaker, this translation surely contains mistakes. Please send bug reports or suggestions to my Email-address. Thanks.