Packet radio

(X)NET

... connecting the future...

Installation on ‘302 TNCs

 

 

 

 

 

· Installation of 3NET

· Token Ring

· KISS/SMACK

· SRPM

· HighSpeedBus

· IPKISS

Authors

Software: Jimy, DL1GJI,

Documentation: Manfred DL2GWA

Translation: Brian, N1URO and Volker, DL3LK

Table of contents

Table of contents *

General to MC68302 TNCs *

Illustration 1: Schematic construction of MC68302 Communication-Processor *

3NET on the TNC3 *

Table 1: SCC-Driver *

Table 2: TNC3 Program-DIP-Swiches *

Table 3: Settings of TNC3 DIP-Switches *

DIP 1: AAR single-board (normal TNC-Configuration) *

DIP 2: AAA single-board (3-Port) *

DIP 3: AAK (Two modems and KISS) *

DIP 4: AAS (Two modems and SMACK) *

DIP 5: AAT (Two modems and Token-Ring) *

DIP 6: HXR (Classic HighSpeedBus-Configuration) *

DIP 7: TXR (Classic Token-Ring-Configuration) *

DIP 8: HTR (HighSpeedBus and Token-Ring) *

DIP 9: AAH (HIGHSPEEDBUS) *

DIP 10: AAP (SERIAL-RING-PROTOCOL) *

DIP 15: UUU (User define configuration) *

3NET example-configurations *

Illustration 2: Example-Configuration *

3NET on the TNC31 *

3NET on TNC4e *

Table 4: TNC4 Program-DIP-Switches *

DIP 1: ETHERNET ROUTER *

DIP 2: ETHERNET DIGI (IPKISS) *

Illustration 3: Configuration of DB0PRT *

DIP 3: 3NET-START *

DIP 16, 17, 18: IPKISS-MODE *

Table 5: IPKISS-DIP-Switches and IP-Numbers *

The Ethernet driver ETHER.XTS *

Connection of stations via AXIP and AXUDP *

Utilization of TNC4-UART-Port *

External additional programs for 3NET *

UPDATE *

OUT *

Table 6: With OUT remote controlled I/O-Ports *

FLASHCPY *

LS *

POKE *

BLINKD *

KISS/SMACK *

How does KISS now work? *

Table 7: Basic KISS-Frames *

KISS with Checksum: SMACK *

Summary of the TNC3-KISS commands *

Table 8: Widened TNC3 - KISS *

HighSpeedBus *

The High-Speed-Bus and (X)NET *

Illustration 4: Logical Buss structure *

HighSpeedBus-Hardware *

Illustration 5: Bus wiring *

Illustration 6: HighSpeedBus-Wiring *

The KISS-Busprotocol *

Illustration 7: KISS-Frame *

Illustration 8: Address the (X)NET-Master *

Illustration 9: HS-Bus Typfield *

Table 9: HighSpeedBus-KISS-Frames *

HighSpeedBus-KISS-Software *

HSKISS.APL *

KTST.APL *

STRESS.APL *

RS232 Token ring *

Illustration 10: RS232-Token-Ring *

TRKISS on the TNC3 *

TRKISS-Portnumber *

Token-Ring baud rate *

TNC3-Extensions *

Duplex-PTT-Hold-Time *

Widened KISS-Commands *

SMACK *

Hardware-Watchdog *

Installation-tip *

Serial-Ring-Protocol *

Award of Portnumbers *

Illustration 11: SRP: Award of Portnumbers *

AXIP KISS (TNC4E) *

Illustration 12: AXIP-Frame *

Illustration 13: AXUDP-Frame *

IPKISS.APL *

Configuration of AXIP *

Illustration 14: Parameter-transfer via AXIP/AXUDP *

Table 10: AXIP/AXUDP-Commands *

Restrictions *

IP *

ICMP *

General to MC68302 TNCs

(X)NET was originally developed for the TNC3 and his modern hardware-architecture (MC68302 = MC68000 + RISC Communications Controller). That ' 302-processor of Motorola was specifically developed for telecommunication-applications. It posses three universal serial units with DMA access (SCC), that are fully used from (X)NET.

Illustration 1: Schematic construction of MC68302 Communication-Processor

One of the following operating modes can be assigned to each serial unit (SCC):

These operating modes run of course parallel on several SCCs in any combination. The TNC-Hostmode (by WA8DED) runs only on one SCC.

(X)NET for TNC3 (3NET) is identical for all ‘302 - TNCs. Because of the different hardware is for each TNC-type (TNC31, TNC3, TNC4e) an individual flash-volume necessary.

In order to start as simply as possible with 3NET, frequently used hardware-configurations are already contains in the Flash-File („EPFLASH.ABS „). By switching of a program-dip-switch are these standard hardware configurations are available.

It is not necessary to edit configuration-files to get the hardware first time running.

3NET on the TNC3

With (X)NET the SCCs inside TNC3 can be driven in different modes. Used as normal TNC the

Configuration looks:

SCC1 = Port 1 = modem 1

SCC2 = Port 2 = modem 2

SCC3 = serial interface to the PC

 

 

The mode a SCC is driven, can be fixed by the assigned driver:

ID

Drivers

Description

Anz. Ports

At

AX25

directly connected modem

1

H

HSKISS

HighSpeedBus

16

K

KISS

 

16

R

TERM

RS232-Terminal-port (only SCC3)

1

S

SMACK

KISS with checkpolynom

8

T

TRKISS

Token-Ring

16

P

SRPM

Serial-Ring-Protocol

8

U

 

User defined assignment

-

X

 

No driver assigned

-

 

Table 1: SCC-Driver

 

 

The basic settings and allocation of drivers and Ports are done with DIP-Switches. On this occasion, the assigned batch files (NETxxx.NET) are called and starts the contained instructions stored inside. These batchfiles are stored in ASCII-format and can be changed on own needs. But notice: After a reset these edited files are overwritten by the original files out of the EPROM or Flash-EPROM.

DIP

Conf

SCC1

SCC2

SCC3

Description

1

NETAAR.NET

AX25

AX25

TERM

TNC-Configuration

2

NETAAA.NET

AX25

AX25

AX25

3-Port single-board

3

NETAAK.NET

AX25

AX25

KISS

NOS-Frontend

4

NETAAS.NET

AX25

AX25

SMACK

TheBox-Node-Frontend

5

NETAAT.NET

AX25

AX25

TRKISS

Low Cost Digi

6

NETHXR.NET

HSKISS

 

TERM

HighSpeedBus

7

NETTXR.NET

TRKISS

 

TERM

Token-Ring

8

NETHTR.NET

HSKISS

TRKISS

TERM

Mixed

9

NETAAH.NET

AX25

AX25

Highspeedbus

High-Speed-Bus via Arbiter

10

NETAAP.NET

AX25

AX25

SRPM

SRP 115200 baud

15

NETUUU.NET

     

User defined

Table 2: TNC3 Program-DIP-Swiches

 

1

2

3

4

5

6

7

8

DIP-Swich setting

x

x

x

ß

ß

ß

ß

Ý

Dip1

x

x

x

ß

ß

ß

Ý

ß

Dip2

x

x

x

ß

ß

ß

Ý

Ý

Dip3

x

x

x

ß

ß

Ý

ß

ß

Dip4

x

x

x

ß

ß

Ý

ß

Ý

Dip5

x

x

x

ß

ß

Ý

Ý

ß

Dip6

x

x

x

ß

ß

Ý

Ý

Ý

Dip7

x

x

x

ß

Ý

ß

ß

ß

Dip8

x

x

x

ß

Ý

ß

ß

Ý

Dip9

x

x

x

ß

Ý

ß

Ý

ß

Dip10

x

x

x

ß

Ý

ß

Ý

Ý

Dip15

Table 3: Settings of TNC3 DIP-Switches

DIP 1: AAR single-board (normal TNC-Configuration)

This operating mode needs no hardware-alteration on TNC3. It is served so simple, as a normal TNC3 with turbo-firmware or TNC3BOX.

SCC1 = Port1 = Modem1 = logical Port 1

SCC2 = Port2 = Modem2 = logical Port 2

SCC3 = serial interface to the Terminal/PC

Contains this configuration assigned batch file (NETAAR.NET):

# 2 * AX.25 + Terminal

attach scc1 ax25 1 1

attach scc2 ax25 2 1

DIP 2: AAA single-board (3-Port)

Configuration for a small node existing from a TNC3. Instead of the serial interface to the PC another modem is connected to SCC3.

SCC1 = Port1 = Modem1 = logical Port 0

SCC2 = Port2 = Modem2 = logical Port 1

SCC3 = Port3 = Modem3 = logical Port 2

Contains this configuration assigned batch file (NETAAA.NET):

# 3 * AX.25

# First detach terminal from SCC3

detach scc3

attach scc1 ax25 0 1

attach scc2 ax25 1 1

attach scc3 ax25 2 1

DIP 3: AAK (Two modems and KISS)

This operating mode needs no hardware-alterations to the TNC3. It is usable as AX.25-Frontend for NOS.

Attention: The call cannot be set in via the KISS-Port. It must be set first with DIP1-Configuration.

SCC1 = Port1 = logical Port 0

SCC2 = Port2 = logical Port 1

SCC3 = Multiport KISS 19200 baud, Ports 2 to 4,

Contains this configuration assigned batch file (NETAAK.NET):

# 2 * AX.25 + Kisslink

# First detach terminal from SCC3

detach scc3

attach scc1 ax25 0 1

attach scc2 ax25 1 1

attach scc3 kiss 2 2 19200

DIP 4: AAS (Two modems and SMACK)

Like DIP3, only SMACK instead of KISS,

SCC1 = Port1 = logical Port 0

SCC2 = Port2 = logical Port 1

SCC3 = Multiport SMACK 19200 baud, Ports 2 to 4,

DIP 5: AAT (Two modems and Token-Ring)

Two directly connected (inside) modems and a Token-Ring with 19200 baud and 8 Ports.

SCC1 = logical Port 0

SCC2 = logical Port 1

SCC3 = Multiport Token-Ring-Kiss 19200 baud, Ports 2 to 9,

Contains this configuration assigned batch file (NETAAT.NET):

# 2 * AX.25 + Token Ring KISS

attach scc1 ax25 0 1

attach scc2 ax25 1 1

detach scc3

attach scc3 trkiss 2 8 19200

DIP 6: HXR (Classic HighSpeedBus-Configuration)

SCC1 = HighSpeedBus Ports 0 to 7

SCC2 = free

SCC3 = serial interface to Terminal/PC

Contains this configuration assigned batch file (NETHXR.NET):

# HighSpeedBus

attach scc1 hskiss 0 8

 

DIP 7: TXR (Classic Token-Ring-Configuration)

SCC1 = Token-Ring Ports 0 to 7

SCC2 = free

SCC3 = serial interface to the Terminal/PC

Contains this configuration assigned batch file (NETTXR.NET):

# Token Ring KISS

attach scc1 trkiss 0 8 19200

 

DIP 8: HTR (HighSpeedBus and Token-Ring)

SCC1 = HighSpeedBus Ports 0 to 7

SCC2 = Token-Ring Ports 8 to 13

SCC3 = serial interface to the Terminal/PC

Contains this configuration assigned batch file (NETHTR.NET):

# HighSpeedBus + Token Ring

attach scc1 hskiss 0 8

attach scc2 trkiss 8 8 19200

DIP 9: AAH (HIGHSPEEDBUS)

SCC1 = PORT 0

SCC2 = PORT 1

SCC3 = HIGH-SPEED-BUS

Contains this configuration assigned batch file (NETAAH.NET):

# 2 * AX.25 + Highspeedbus

attach scc1 ax25 0 1

attach scc2 ax25 1 1

detach scc3

attach scc3 hskiss 2 16

DIP 10: AAP (SERIAL-RING-PROTOCOL)

SCC1 = PORT 0

SCC2 = PORT 1

SCC3 = SERIAL-RING-PROTOCOL

Contains this configuration assigned batch file (NETAAP.NET):

# 2 * AX.25 + 8 Ports SRPM

# First detach terminal from SCC3

detach scc3

attach scc1 ax25 0 1

attach scc2 ax25 1 1

attach scc3 srpm 2 8 115200

DIP 15: UUU (User defined configuration)

In this case (X)NET starts with a configuration, that is written down in file AUTOEXEC.NET.

Example:

# DIP 15 = Start with netuuu.net

#

# HighSpeedBus on SCC1

attach scc1 hskiss 0 8

# Config SysOp Port

po 8 per 255

po 5 qua 0

po 2 txd 100

In that example the node is configured as High-Speed-Bus-Node. The Autoexec.net is user-definable. External processes can also be started here simultaneously, provided the L7-Programs (XTS or XTPs) is existing in the RAM-disk or it can be input corresponding parameters.

3NET example-configurations

A more complex example of a user-defined (X)NET-Configuration: DB0XYZ is a node with

6 HF-Ports and a Mailbox (DB0XYZ-8). The node consists of a TNC3 with 1MB RAM as

Master-TNC with (X)NET inside the Flash-EPROMs.

Two TNC2H are connected via Token-Ring and two TNC3S via HighSpeedBus at the master. The Mailbox should be connected also directly via SMACK with 11500 baud to the master.

 

Illustration 2: Example-Configuration

This special configuration doesn't supports from (X)NET by standard. This special configuration has to be stored in the file „NETUUU.NET „:

# First detach the terminal to get SCC3 free

det scc3

att scc1 trkiss 0 2 19200

# \ \ \ \ \

# \ \ \ \ RS232-Baudrate of Token-Ring

# \ \ \ Number of Token-Ring-Ports

# \ \ First logical portnumber of Token Ring

# \ Token-Ring KISS-Driver

# serial port 1 of TNC3 (normal internal modem 1)

att scc2 hskiss 2 4

# \ \ \ \

# \ \ \ Number of ports on the HighSpeedBus

# \ \ Number of HS-Bus-Ports

# \ HighSpeedBus KISS-Driver

# serial port 2 des TNC3 (normal internal Modem 2)

att scc3 smack 6 1 115200

# \ \ \ \ \

# \ \ \ \ RS232-Baudrate to Mailbox

# \ \ \ Number of SMACK-Ports

# \ \ First logical portnumber of SMACK

# \ SMACK-Driver (Checksum-KISS)

# serial port 3 des TNC3 (normal PC/Terminal)

 

 

After this file was copied into the TNC3-Ramdisk, the Program-DIP-Switch of TNC3-Master can be set to 15. The present configuration is supported after restart of Master-TNC.

 

The port-command shows now the logical ports:

po baud interface txd per slt w ret qua dup dam duo

0 1200 0 SCC1 TRKISS 250 64 100 5 10 128 0 0 0

1 1200 0 SCC1 TRKISS 250 64 100 5 10 128 0 0 0

2 9600 0 SCC2 HSKISS 250 64 100 5 10 128 0 0 0

3 9600 0 SCC2 HSKISS 250 64 100 5 10 128 0 0 0

4 19200 0 SCC2 HSKISS 250 64 100 5 10 128 0 0 0

5 38400 0 SCC2 HSKISS 250 64 100 5 10 128 0 0 0

6 115200 0 SCC3 SMACK 250 64 100 5 10 128 0 0 0

The command "sa 1" shows info and statistics-data of three differently driven SCCs of the master TNC:

 

 

SCC1 : TRKISS Driver: 19200 Baud

111 Tokens/s TREC: 41 (15.02.00 18:18:31). Overrun: 64. NoBuf: 0.

PAREC: 0 FRMEC: 0 NOSEC: 0 BRKEC: 0

 

SCC2 : HighSpeedBus Driver Feb 05 2000

DLC resets: 0 [00] (06.02.00 01:09:52) Waits: 0

302 RISC statistics:

DISFC: 0 ABTSC: 578 CRCEC: 0 RETRC: 0 NMARC: 0

 

SCC3 : KISS/SMACK/TRKISS Driver Oct 20 1996 RS232: 115200 Baud

CRC err 0 (12.11.96 20:25:24)

3NET on the TNC31

Since the TNC31 did not have DIP-Switches, there is no reflection to think about the settings. The file EPFLASH.ABS has to be „Flashed" into the TNC, and starts with the configuration:

DIP

Conf

SCC1

SCC2

SCC3

Description

1

AUTOBOOT.NET

AX25

-

TERM

TNC-Configuration

The modem is configured to AX.25 and the serial interface as WA8DED - compatible terminal-interface. I.e., first, the software behaves like a TNC31 with turbo-firmware or TNC3BOX.

The file AUTOBOOT.NET looks with it as follows:

# 1 * AX.25 + Terminal

attach scc1 ax25 0 1

# Use autouser.net to attach further devices

exec autouser.net

The file AUTOUSER.NET is not contained in the Flash-EPROM. It can be used to enforce further configurations.

„AUTOUSER.NET „ for a Token-Ring at the serial (TNC -) interface looks for example as follows:

# Attach 38k4 Token Ring with 4 Ports starting with

# (X)NET port number 2.

attach scc3 trkiss 2 4 38400

 

3NET on TNC4e

Ethernet has established itself to the standard-network for LANs in the meantime. The necessary PC-Hard - and software is available everywhere. The prices for Ethernet-Cards have sunk on the price level of serial I/O-Cards despite their essentially higher capability. PC-Ethernet-Cards in PCI-Technology is very quickly, but much more important is thanks DMA it can handle the data transfer in the background of the PC. If several servers should be connected to a node or TNC, the advantage of Ethernet appears: The servers are simply plugged on.

In order to do a simple start with TNC4e, predefined configurations are already contained like the TNC3 inside the Flash-EPROM:

 

DIP

Conf. file

SCC1

SCC2

SCC3

Explanation

1

NETAAR.NET

AX25

AX25

-

TNC-Configuration

2

NETAAE.NET

AX25

AX25

-

TNC/AXIP-Configuration

3

AUTOBOOT.NET

-

-

-

 

16

IPKISS Slave 1

     

192.168.44.4

17

IPKISS Slave 2

     

192.168.44.8

18

IPKISS Slave 3

     

192.168.44.12

Table 4: TNC4 Program-DIP-Switches

DIP 1: ETHERNET ROUTER

Configuration 1 starts 3NET.APL and executes the start-file NETAAR.NET:

# (X)NET boot Configuration for TNC4e

#

# Start Ethernet Driver

#

start ether 192.168.44.1

#

# 2 * AX.25

#

attach scc1 ax25 0 1

attach scc2 ax25 1 1

#

# for further user defined attaches

#

exec autouser.net

The Ethernet-Driver is loaded and set his IP-Address to number 192.168.44.1. SCC1 and SCC2 are „attached „as normal AX.25-Modems.

The file „AUTOUSER.NET „ is not stored inside the Flash-EPROM. It has to be loaded into RAM to do more/further configurations.

DIP 2: ETHERNET DIGI (IPKISS)

TNC4e Ethernet-Node. Four TNC4S are joined together to a TNC4e-12-Port Digipeater. (X)NET-Master is started with DIP-Switch 2. The Slaves 1 to 3 in each case with dip-switch-positions 16 to 18.

The configuration 2 starts 3NET.APL and executes the start-file NETAAE.NET:

 

 

 

 

 

# (X)NET boot Configuration for TNC4e

#

# Start Ethernet Driver

#

start ether 192.168.44.1

#

# 2 * AX.25

#

attach scc1 ax25 0 1

attach scc2 ax25 1 1

#

# 9 AXIP-Ports without AXIP-CRC

#

attach ip0 axip 3 1 cp 192.168.44.4

attach ip1 axip 4 1 cp 192.168.44.5

attach ip2 axip 5 1 cp 192.168.44.6

attach ip3 axip 6 1 cp 192.168.44.8

attach ip4 axip 7 1 cp 192.168.44.9

attach ip5 axip 8 1 cp 192.168.44.10

attach ip6 axip 9 1 cp 192.168.44.12

attach ip7 axip 10 1 cp 192.168.44.13

attach ip8 axip 11 1 cp 192.168.44.14

#

# for further user defined attaches

#

exec autouser.net

The Ethernet-Driver is loaded and set his IP-Address to number 192.168.44.1. The SCC1 and SCC2 are „attached „ as normal AX.25-Modems. The other TNC4es are connected via AXIP.

This NETAAE-Configuration is used at DB0PRT for example.

Illustration 3: Configuration of DB0PRT

The connection of the Mailbox takes place in the file called at the end „AUTOUSER.NET „.

DIP 3: 3NET-START

Configuration 3 starts 3NET.APL and executes the start-file AUTOBOOT.NET. This file is not stored inside the Flash-EPROM. It must be loaded into the RAM and can contain a completely free configuration.

DIP 16, 17, 18: IPKISS-MODE

These configurations sets the TNC4e into the IPKISS-Slave-Mode with in each case different

IP-Addresses:

DIP

Software

Port0

Port1

Port2

16

IPKISS Slave 1

192.168.44.4

192.168.44.5

192.168.44.6

17

IPKISS Slave 2

192.168.44.8

192.168.44.9

192.168.44.10

18

IPKISS Slave 3

192.168.44.12

192.168.44.13

192.168.44.14

Table 5: IPKISS-DIP-Switches and IP-Numbers

The Ethernet driver ETHER.XTS

On the TNC4, the Ethernet port is activated by the driver-program ETHER.XTS and started as background-process. It installs altogether 16 IP-Devices, that are required for the connection (attach) of AXIP or AXUDP-Ports. Additionally, the driver installs also the UART-Device, with his help all serial drivers (KISS, SMACK, SLIP etc) are „attached„ via TNC4-UART.

Connection of stations via AXIP and AXUDP

As with (X)NET usually the connection takes place via AXIP/UDP Ports with „attach„-command. The syntax is:

attach <axip/axudp> <port> <count> {<opt>} <destIP> [<gwIP>]

For <axip/axudp> is declared either AXIP or AXUDP.

The Port is declared with <port>. With AXIP or AXUDP <count> is always 1!

For <opt> can be declared optional:

Option < opt >

Meaning

c

No calculation of checksum while transmitting and no test at receiving

p

Passing on of parameters (is required for IPKISS.APL)

The Destination IP-Address <destIP> is the address of the AXIP-partner. If this station can only be reached via one router, the address of the router (or gateway) where the partner can be reached must declared as <gwIP>

Example:

attach axip 5 1 c 192.168.44.14 192.168.44.65

# This attach carries an AXIP - connection to 192.168.44.14

# via 192.168.44.65 on Port 5. There is no

# Checksum-Test and calculation.

 

Utilization of TNC4-UART-Port

That UART-Device which is installed of by Ethernet-Driver, offers all asynchronous serial drivers, who exist also for the SCCs of the TNC4. Also the attach - syntax is the same.

The terminal must be turned off (Command: term 0) if serial drivers are attached on the UART-Device!

External additional programs for 3NET

The following commands are loadable as executable programs into the RAM-disk. Some commands therefore don't exist on some nodes. The sysop of a node adjudicates which programs he loads on the node and which commands are not needed to save RAM-storage area inside the TNC3. Which external commands (Or also info-texts) available can be checked by input of command HELP. Behind the Help - command listing is spent a list of external programs/commands. Is distinguished between „Externals" witch are only available by the SYSOP and commands that can be used by user.

Ultimately the Sysop itself adjudicates which external programs he wants to accept into the node and whoever should have access on the commands. The program files are loaded binary into the RAM-disk.

Deciding the program-extension whether only the Sysop can access the program, or each User can use it.

The Sysop can freely choose the program name. However the file extension is crucial:

*.XTP (eXTernal Public = for all usable) or as *.XTS (eXTernal Sysop = only by Sysop).

UPDATE

Updates very simply the 3NET FLASH - Eprom.

= > UPDATE

2 Flash EPROM(s) detected. Type: 29F010

Please send EPFLASH.ABS (BIN) file

After input of „update" command, the new Flash-Version can be sent directly to the node (File EPFLASH.ABS). Directly after reception, the Flash-EPROMs are programmed and the node was starting with the new software.

Of course, the correctness of the data is tested before programming (CRC). If an error occurs with CRC or during the update transfer, so the process is broken off and the node runs further normally with the old software.

OUT

The OUT-Command is used for remote control. It turns individual Portbits of the TNC3 off and on. Syntax:

OUT [<port>] <PortBit> [<Value>]

<Port> = a | b

<PortBit> = 0..15

<Value> = 0..1

The statement of the Processor ports (a or b) is optional. Provided no Port is declared, Port a is used.

Example:

=>OUT a 15 0

the CON-LED of the TNC3 goes on.

Example:

=>OUT a 15

PA15 = 0

shows the momentary condition (0 or 1) of output ports.

Following I/O-s can be remote* controlled via the OUT-Command:

PortBit

SCC

Modem

Pin

Modem-plug

0

2

RXD

15

J13

1

2

TXD

13

J13

2

2

RCLK

19

J13

3

2

TCLK

17

J13

4

2

CT

9

J13

5

2

RTS

11

J13

6

2

CD

7

J13

7

2

BEEPER

   

8

3

RXD

15

J10

9

3

TXD

13

J10

10

3

RCLK

19

J10

11

3

TCLK

17

J10

12

3

BEEPER

   

13

 

CON LED

3

(Layout CON 0 LED)

14

 

STA LED

3

(Layout STA 0 LED)

15

 

CON LED

1

 

Table 6: With OUT remote controlled I/O-Ports

 

 

FLASHCPY

Flashcopy is used for a binary download of „running" software for Flash-EPROMs. Everyone, who want to get a software update, can download the currently software with it directly from the corresponding TNC3-node.

LS

With LS, the directory of the RAM-disk can be called on the node-level. That (List-Short)-Command passes out a directory list in short form. The command for a detailed list is:

LS - L

POKE

Events registered by POSTMORT can be deleted by Poke.

Input:

POKE W 100 0

Attention: If a wrong Poke-Command is sent to the node, the node can be brought to crash - therefore caution, otherwise a „Digipeater-invication" is due.

BLINKD

Background-process that the LEDs of the 3Net-Master TNC lets blink. That shows the operational-shaft of the node if no connected terminal is on the node.

Application: As background-process in the file AUTOEXEC.NET:

start blinkd [milli-seconds [LED-Nr]]

Optional can be declared the frequency in milli-seconds. The standard-value is 50 ms. The LED-Nr declares up to which LED should be „blinked" . Since some sysops use the LED-outputs of SCC3 for for remote control, they can limit the twinkle with this parameter from LED 0 to 3 (SCC1 and SCC2). Example:

start blinkd 50 4

Only the CON - and STA-LEDs of SCC1 and SCC2 are bilnking. The LEDs of the SCC3 can be used for remote control.

KISS/SMACK

KISS removes the work of AX.25-Protocol and commands from the TNC. The TNC only changes the synchronous HDLC-Format of HF-Side into a particular asynchronous Frame-Format used on the serial interface. That means of course that the AX.25-Protokoll as well as the user-interface must now be implemented to the computer, however the computer gets the complete control over the HF-Sides HDLC-Frames.

How does KISS now work?

The asynchronous protocol, with which computers and TNC talk, is very simply; its single task is to restrict the figurative frames. Each Frame begins and finishes with a particular FEND (Frame End) sign, quite similar, like HDLC-Frames. The TNC still leaves the formation and checkup of the CRC-checksum. RS-232-Handshake is not used, therefore suffices a simple three-wire-connection. Following particular signs are used for the transfer:

 

Abbreviation Description HEX-Number

FEND Frame End C0

FESC Frame Escape DB

TFEND Transposed Frame End DC

TFESC Transposed Frame Escape DD

Frames are certainly delimited with a before and after adjusted FEND-Sign, two consecutive FEND-Signs are, as well like with HDLC-Frames, not interprets as empty Frame. The Frames are sent transparently with eight data-bits, a stopbit and no parity.

A within a Frame occurring FEND-Zeichen is translated into the sequence FESC-TFEND, analogously an FESC-Sign is transferred as an FESC-TFESC. The respective recipient (PC or TNC) puffers the signs, a FEND means the end of a Frame. The reception of a FESC-Zeichen switches the recipient into the „Escaped-Mode" and induces him/it to write the subsequent TFESC or TFEND as FESC or FEND into the buffer. A TFEND or TFESC that is not received in the Escape-Modus is considered as a regular sign. This way of transfer may appear on the first gaze complicated, however very simply to be implemented and do min synchronization-problems. It is incidentally identically to „SLIP" (Serial Line IP).

The TNC only remains to change KISS-Frames into HDLC-Frames and back, to observe the frequency and to switch the transmitter. For that the computer must control some few TNC – parameters. The first byte in each Frame on the connection between computer and TNC distinguishes between command - and Data-Frames. The higher four bit contained the Port number, the lower four bits the command-number. Following commands are defined:

 

Comm.

Function

Remark

0

Data-Frame

The rest of the Frame consists of data

1

TXDELAY

The next byte declares the PTT/Data send delay (10 ms steps). Default is 50, i.e. 500ms.

2

P

The next byte declares the Persistence-Value p (0 – 255).

3

Slot-Time

The next byte is the slot-interval (in 10 ms steps). Default is 10 (i.e. 100ms).

4

Txtail

The next byte is the time that the transmitter is still transmitting after sending the data (10 ms steps).

5

FullDuplex

The next byte is 0 for Half Duplex, unequally 0 for Full duplex. Default is 0, i.e. Half Duplex.

6

Set-hardware

Specifically for each TNC.

FF

Return

Leaves the KISS-Modus. (Usually switch back into terminal-mode)

Table 7: Basic KISS-Frames

The original idea of a simple Computer/TNC-Protocol had Brian Lloyd, WB6RQN.

Phil Karn, KA9Q, one of the „fathers" of the AX.25-Protocoll, organized the specification and at the 6. August 1986 he put at a first KISS-Version.

Sources: The KISS TNC: A simple Host-to-TNC communications protocol Mike Chepponis, K3MC, Phil Karn, KA9Q

KISS with Checkpolynom: SMACK

SMACK is an expansion of the KISS-Modes, with which at each Data-Frame a 16-bit Checksum is attached. This expansion became necessary, as turned out, that sign-losses appear with PC and UNIX-Workstations with the reception of serial data.

Summary of the TNC3-KISS commands

Name

Description

Parameters

RSKISS

Data field

RSKISS [byte]

Data follow

0

0-328

TxDelay

TxDelay

0x1

1 [10 ms]

Persistance

0 to 255

0x2

1

Slot-Time

Slot-Time

0x3

1 [10 ms]

TxTail

TxTail [ms]

0x4

1

Fullduplex

0=Off, 1=On, n=PTT Hold Time

0x5

1 [s]

DAMA

0=Off, 1=On

-

1

Calibrate

Transmit carrier

0x8

1 [min]

Duo-Baud

Software-Prevent to transmit

0=Off, 1=ON

0x9

1

Reset

Cause TNC-Reset

0xFF

1

Frames sent

Message in DAMA-Mode, that all data were sent out

-

1

Table 8: Widened TNC3 - KISS

 

 

 

 

 

 

 

HighSpeedBus

The HighSpeedBus is a simple and leaps network-option for the TNC3-Nodes.

The High-Speed-Bus and (X)NET

A (X)NET-Node consists of a master (TNC3/TNC4 with 1MB RAM), and several Dual-Link-Controller (DLCs). The DLCs are minimally equipped TNC3, they are essentially responsible for transmitting of the AX-25-Frames (Medium-Access-Control-Level MAC). All cards are connected via the high-speed-bus (HS-Bus).

Illustration 4: Logical Busss Structure

The maximum transfer-rate on the HS-Bus is about 1,6 MBit/sec (caused by MC68302).

HighSpeedBus-Hardware

Illustration 5: Bus wiring

 

 

 

 

 

 

 

 

 

 

 

 

The HighSpeedBus consists of simple electronics. On the TNC3, the wiring of the bus with the corresponding SCC-Port looks so:

Illustration 6: HighSpeedBus-Wiring

An Arbiter is necessary to run a HighSpeedBus. This circuit regulates the bus-access and prevents collisions.

The KISS-Busprotocol

The primitive Busprotocol is modeled on the TNC-KISS-Protocol. However the KISS-Data are packed into an HDLC-Frame. On the basis of the transparency of HDLC-Frames all sign doublets (FESC, TFEND,…) can slipped. Transfer-errors are rare because of short wiring and collision-freedom. If nevertheless transfer-errors are appear they are recognized to 99,99% by the help of automatically generated checksum of HDLC-Frames (CRC) .

The addresses are longer coded than with KISS. The address recognition takes the MC68302-RISC-Controller completely.

Illustration 7: KISS-Frame

Address fields are necessary to communicate to the individual DLC-Cards. The DLC-Software (HSKISS.APL) is already contained in each TNC3 by standard. This software is started by

DIP-Switch 7. Since no RS232-Baudrate has to set, these three-baud setting switches can be used as DIPSwitch to set the DLC-Number. Attention: The bits are a little bit „contorts „:

DIP-Switch: 1 2 3 4 5 6 7 8 DLC (X)NET-PORTS)

Number Modem1 Modem2

0 0 0 0 0 1 1 1 0 0 1

1 0 0 0 0 1 1 1 2 2 3

0 1 0 0 0 1 1 1 4 4 5

1 1 0 0 0 1 1 1 6 6 7

0 0 1 0 0 1 1 1 8 8 9

...

1 1 1 0 0 1 1 1 14 14 15

Because of the wiring of the DIPSwitches an inversion occurs:

1 = Open = OFF = DIP-Position above

0 = Closed = ON = DIP-position below

The (X)NET-Card has a solidly pre-determined HighSpeedBus-Address:

Illustration 8: Address the (X)NET-Master

The FI-Field is two bytes big and has following bit-pattern

Illustration 9: HS-Bus Type field

The coding of the type field corresponds to KISS

Type field

Name

Description

Size [byte]

0x0

Data

Data follow

0 to 328

0x1

TxDelay

TxDelay [ms]

2

0x2

Persistence

0 to 255

1

0x3

Slot-Time

Slot-Time [ms]

2

0x4

TxTail

TxTail [ms]

2

0x5

Fullduplex

0=Off, 1=On, n=PTT Hold Time [s]

1

0x6

DAMA

0=Off, 1=On

1

0xD

Reset

DLC-Resets cause

1

0xE

Frames sent

Message in the DAMA-Mode, that all data were sent out

1

0x8001

TxDelay?

2

0x8002

Persistence?

1

0x8003

Slot-Time?

2

0x8004

TxTail?

2

0x8005

Fullduplex?

1

0x8006

DAMA?

1

0x8007

Baud rate?

Modem-baud rate

[100 Hz]

2

0x8100

DLC program version?

Sign-chain

n

Table 9: HighSpeedBus-KISS-Frames

Differences to KISS:

All time-parameters are declared in milli-seconds, because at future TRXs is to be reckoned with smaller TxDelays and slot-Time. Most numerical values are coded in two bytes, 68000-format. „Escape„-Sequence as well as sign dubbing („Character Stuffing„) inside data not used.

Another KISS-Completion: With help of the bit „enq" itself interrogated also values (enq = 1). The interrogated values are sent back in the same format to the interrogating station.

The advantages opposite the TheNet-Token-Ring are shown:

• 20 to 40 times higher baud rates on the local bus, essentially higher throughput, and higher dynamics

• essentially more inferior answer-times because there is no access-control by tokens, timedelays in the area of microseconds

• Collision-free guarantees by Arbiter; the bit-error on the bus is low

• Error-recognition by package of all KISS-Frames into HDLC-Frames with CRC-Checksum

• No RS232-levelconverter necessary

• Checksum calculation and examination by the 68302-RISC-Communications-Controller, no CPU-Load

• Data exchange via the bus doesn't load the individual DLCs (optimal support via Address recognition of the MC68302 RISC-Communications-Controller).

• Receive and transmit of KISS-Frames on the bus runs completely in the background; No Interrupts are necessary. (Receives and sending are steered by the RISC-Communications-Controller in cooperation with the Arbiter,

The above points speak in behalf of itself. It is nevertheless mentioned, that it is not possible to reach the above features with help of a parallel bus on throughput and answer-times with simultaneously minimal processor-load, except with (expensive) intelligent special-hardware.(1,6 MBit/sec corresponds to 200 KBytes/sec = >) For one byte program-controlled transfer only 5 µses would stand to the disposal (This is not to be reached with program-controlled parallel transfer, since as well to regulate by program that „Handshaking „) The processor would fully be employed to capacity during the Bus-data-transfer, it would therefore not possible for the processor to do parallel-work.

HighSpeedBus-KISS-Software

Programs for HighSpeedBus:

HSKISS.APL

HighSpeedBus-DLC-Software. This program is already contained in each TNC3 and enables each TNC3 to use it on the HighSpeedBus as DLC (Dual Link controller). The HighSpeedBus-Port numbers are set directly on DIPSwitches instead of RS232-Baudrate.

KTST.APL

KTST.APL is a HighSpeedBus-Test monitor. The program is started on the master-card and shows all connected HighSpeedBus-DLCs and their configuration. It is very well suitable to test the functional ability of the bus and shows the card-addresses of the DLCs. The program makes even the modem-baud rates of the individual DLC-Ports visible.

r:>ktst

====================================================================

Kiss - HighSpeedBus - Testmonitor

(b)roadcast: Busteilnehmer anzeigen # shows DLCs

(k)iss Configuration anzeigen # shows conf

(q)uit # quit

====================================================================

KTST.APL is on the Node-System-Disk and has to be loaded from there.

STRESS.APL

STRESS.APL is also a test-program for the HighSpeedBus. The number of the DLC witch should be tested has to be declared with the call. No errors have to appear also in the duration-business.

 

 

 

 

 

 

r:>stress 1

*** HighSpeedBus - Stress-Test ***

 

Key...

 

Statistic DLC [01]:

Fehler (gesamt) : 0

Packet (gesamt) : 0

Bytes (gesamt) : 0

Bitfehlerrate : 0 E-8

Packet/s : 0

Bit/s (Netto) : 0

Discarded Frames: 0

Abort Sequences : 0

CRC-Errors : 0

Retransmissions : 0

Non matched Adr.: 0

 

 

RS232 Token ring

The Token-Ring is an annular network of TNC via their serial V.24 (RS232) - interface. On this occasion, a TNC has exactly two connections: one to his predecessor and one to his successor. This network was invented 1991, to be able to serve via a serial PC-Port several TNCs and with them several HF-Ports.

 

Illustration 10: RS232-Token-Ring

 

In order to distribute the transmit authorization on the ring a „Token" is used, which is generated of the master-computer and is relayed to the TNCs. The data are transferred as adapted KISS-Frames with Port number via the ring. After a TNC has gotten the Token, he is allowed to put his received data on the ring. After that he relays the token it to his successor.

+---------------+ +----------+

¦ T ¦ RS232 ¦>-3-----3->¦ terminals¦

¦ ¦ ¦<-2-----2-<¦ PC/Atari ¦

¦ N +-------¦ +----------+

¦ ¦ MODEM ¦>-----+

¦ C ¦ RS232 ¦<---+ ¦

¦ +-------¦ ¦ ¦

¦ 3 ¦ ¦ ¦ ¦

¦ ¦ ¦ ¦ ¦

+---------------+ ¦ ¦

¦ ¦

+---------------+ ¦ ¦

¦ ¦ RS232 ¦>-3-+ ¦

¦ TNC2 ¦ ¦<-2-+ ¦

¦ +-------¦ ¦ ¦

¦ KISS- ¦ MODEM ¦ ¦ ¦ +-----------+

¦ Adr.0 ¦ ¦----¦-¦---¦ TRX Port0 ¦

+---------------+ ¦ ¦ +-----------+

¦ ¦

+---------------+ ¦ ¦

¦ ¦ RS232 ¦>-3-+ ¦

¦ TNC2 ¦ ¦<-2-+ ¦

¦ +-------¦ ¦ ¦

¦ KISS- ¦ MODEM ¦ ¦ ¦ +-----------+

¦ Adr.1 ¦ ¦----¦-¦---¦ TRX Port1 ¦

+---------------+ ¦ ¦ +-----------+

¦ ¦

+---------------+ ¦ ¦

¦ ¦ RS232 ¦>-3-+ ¦

¦ TNC2 ¦ ¦<-2-+ ¦

¦ +-------¦ ¦ ¦

¦ KISS- ¦ MODEM ¦ ¦ ¦ +-----------+

¦ Adr.2 ¦ ¦----¦-¦---¦ TRX Port2 ¦

+---------------+ ¦ ¦ +-----------+

: :

: :

¦ ¦

+---------------+ ¦ ¦

¦ ¦ RS232 ¦>-3-+ ¦

¦ TNC2 ¦ ¦<-2---+

¦ +-------¦

¦ KISS- ¦ MODEM ¦ +-----------+

¦ Adr.x ¦ ¦----------¦ TRX Portx ¦

+---------------+ +-----------+

Token-Ring: Example of a TNC-Wiring

Up to the appearance of the TNC3, the maximum baud rate of the Token-Ring was restricted to 38400 baud. Only few Ports or only slow links could be built by it. A bigger problem is the transfer-errors because of missing signs and tokens that often appeared.

With TNC3 in the Token-Ring, some of the old problems are solved:

TRKISS on the TNC3

TRKISS.APL is a Token-Ring software for the TNC3, that is completely compatible to the corresponding TNC2-Software, however some expansions shows.

TRKISS-Port number

The Port numbers are read from settings of Program-Dip-Switches when starting the program. Only the bits 1-3 of the program-number are used to get the formation of port number:

 

 

Program-DIP | KISS-TNC-Port1 | KISS-TNC-Port2 | trkiss

16 0 1 DIP16.APL

18 2 3 DIP18.APL

20 4 5 DIP20.APL

 

Attention: With application of SRP the Port number is fully automatically set in the ring-sequence of the TNCs! The positions of the DIPSwitches are ignored.

Token-Ring baud rate

The baud rate is set usually at DIPSwitches on the TNC (Exception 1200 baud):

DIP 1 2 3 Baud

==================

0 0 0 External clock

0 0 1 2400

0 1 0 4800

0 1 1 9600

1 0 0 19200

1 0 1 38400

1 1 0 57600

1 1 1 115200

An external cycle (16*Baudrate) is wired to TCLK and RCLK-inputs of SCC3 (RS232). The allowed maximum of external cycle is:

CLK = *

i.e. with the TNC3 maximum CLK = 5,9 MHz, that is equal to 370 kBaud.

TNC3-Extensions

Duplex-PTT-Hold-Time

The Fulldup parameter can be declared in the value-area between 0 and 255 (until now only 0 and 1). A delayed falling of PTT can be set in the Fullduplex-Mode.

Values with >= 2 sets the PTT hold time in seconds.

Fulldup Explanation

0 Halfduplex

1 Fulldupex

2 Fullduplex PTT-Hold-Time 2 s

...

n Fullduplex PTT-Hold-Time n s

...

255 Fullduplex PTT-Hold-Time 255 s

Widened KISS-Commands

FEND <port 8 <min> FEND

Calibrate No. 8: The TNC switched TX-ON on the stated port.

The Field <min> declares the TX-On time in minutes.

FEND <port> 9 <on> FEND

Duo-baud No. 9: on = 1 Switch the TX bolt for both on

on = 0 stop of TX bolt

SMACK

The Definition of SMACK-Checksum-KISS was now also adopted for the Token-Ring-KISS. SMACK is activated by the Host-PC, in that the PC sets at TX-Data the 7. bit of port number to 1. I.e. the port number 0x00 becomes for example the number 0x80, (see SMACK-Explanation). As a result SMACK is activated and the TNC3 equips all following received data with an additional SMACK-CRC.

At the moment Token-Ring-SMACK can only activated with compatible Nodesoftware ( (X)NET.

Hardware-Watchdog

The TRKISS-Software is now overseen by the built-in TNC3-Hardware-Watchdog. If (for which reason however) that TNC3 receives a minute long no Token the software executes a Hardware-Reset of the TNC3 automatically.

Installation-tip

If a parameter is declared in the command-line when starting the program, the program reports as follows:

r:>c:trkiss x

TNC3 Token Ring KISS Mode Version 1.14 Jan 10 1998 (C) DL1GJI

Modem 1: 1200 Baud Adresse 0

Modem 2: 1200 Baud Adresse 1

The modem-baud rates of the TNC3 and the currently put in Port-Addresses can be checked with it.

Serial-Ring-Protocol

The Serial-Ring protocol is used like the Token-Ring described above or that FlexNet-6Pack-Protocol for network of TNCs via the serial interface. The TNCs are connected also annular - only the communication-protocol is changed. SRP puts the advantages of the two implementations, 6-packs and Token-Ring, together to a new protocol.

The construction of the Frames is leaned against KISS. The essential difference to Token-Ring consists of that was abstained completely on the Token.

The Slave-Software (TRKISS.APL) for the TNCs connected in the ring is at the moment only available for the TNC3. From the version 1.16 TRKISS.APL can switch automatically between Token-Ring-KISS and SRP.

Award of Port numbers

With SRP the Port numbers are set automatically. The ports are simply numbered in direction to TX.. This has the advantage that all Slave-TNCs can now be driven with identical DIP-Switch-Settings.

Illustration 11: SRP: Award of Port numbers

 

Since the Token-Ring-Software determines the port number on the basis of Program-DIP-Switch- Settings, it is possible the port numbers are changed with a switch from TRKISS to SRPM.

AXIP KISS (TNC4E)

IPKISS is a type Ethernet-Kiss-Mode, which makes nothing more to send out received AXIP-Frames via an AX.25 Port of the TNC4e. In order not to alter existing software, an individual IP-Number is assigned to each TNC4-HF-Port. So it is possible for each AXIP-able software to build fast links via a TNC4e. IPKISS is comparably with the KISS implementations RSKISS, TRKISS, HSKISS - only the transportation of data takes place via Ethernet.

Illustration 12: AXIP-Frame

That in RFC 1226 described protocol AXIP is used (RFC 1226: „Internet Protocol Encapsulation of AX.25 Frames" B. Cantor). Some operating system-platforms (Windows 95/98 and NT) do not allow to send and receive AXIP-Frames. In order to be able to communicate with these platforms, the protocol UDP must be used instead of AXIP. On the basis of the Port number 93 the AXUDP-Frame can be recognized. It has the following construction:

Illustration 13: AXUDP-Frame

The 16-bit checkpolynom (CRC) contained in AXIP is used for safeguarding of AX.25 data-contents. Consequently, falsifications or sign-losses can be discovered with the transportation via the Internet. If AXIP is used exclusively in a local Ethernet-Net, this safeguarding of course is superfluous since each Ethernet-Frame is anyway already tested by a 32-bit CRC-Procedure.

IPKISS.APL

In order to drive a TNC4e in an IPKISS-Mode the program IPKISS.APL is required. With the call of IPKISS.APL, the following parameters can be declared in the command-line:

Syntax:

IPKISS [<opt>] <myip> (AXIP|AXUDP) [<DestIP>]

< myip > IP-Number of the first TNC4-Ports. Respect! It must be divisible by four. The three further Ports get the next to following IP-Addresses.

AXIP the TNC sends and receives by AXIP protocol

AXUDP the TNC sends and receives by AXUDP protocol

< DestIP > Address of the PC, at which the AXIP or AXUDP-Packets should be sent. If no address is declared here, so al packages are sent to IP-Broadcast-Address 255.255.255.255 . This is normally not meaningful since all stations in the local network must read then all information and are incriminated by it.

< opt > The option of -c allows to deactivate that checkpolynoms described by RFC 1226. The CRC-Value is neither calculated at transmitting than checked at receiving. The two CRC-Bytes however are transmitted but contains undefined values. By deactivating of CRC-Check the attainable troughput is increasing noticeable!

Example:

ipkiss -c 192.168.44.4 AXIP 192.168.44.1

This command puts the TNC4 into the AXIP-Modus. The AXIP-CRC-Calculation is deactivated by parameter „-c „. The TNC gets a separated IP-Number for each of his Ports:

Port

IP-Number

0

192.168.44.4

1

192.168.44.5

2

192.168.44.6

-

192.168.44.7

With these numbers, each Port of TNC4 can now attached separate. The not existing Port 4 also gets an IP-Number.

All on the modem ports received data are sent to the computer with the IP-Address 192.168.44.1.

Configuration of AXIP

Differently like with the KISS-Modes, it is not intended to send parameters with the AXIP-Protocol definition. In order to set parameters like TxDelay, Duplex, Persistence etc at TNC4 all AXIP-Frames with a length of 4 Byte are recognized as TNC-Parameter:

Illustration 14: Parameter-transfer via AXIP/AXUDP

IPKISS uses the following parameter-codes:

Name

Description

Parameters

Data field

[Byte]

Data follows

0

5-328

TxDelay

TxDelay

0x1

2 [ms]

Persistence

0 to 255

0x2

2

Slot-Time

Slot-Time

0x3

2 [ms]

TxTail

TxTail [ms]

0x4

2 [ms]

Fullduplex

0=Off, 1=On, n=PTT Hold Time

0x5

2 [s]

DAMA

0=Off, 1=ON

0x6

2

Calibrate

TX-Carrier

0x8

2 [ms]

Duo-Baud

Software-TX-Bolt.

0=Off, 1=On

0x9

2

Reset

Cause TNC-Reset

0xD

2

Frames sent

Reports in DAMA-Mode, that all data are sent out

0xE

TxDelay- retrieval

0x8001

Persistence- retrieval

0x8002

Slot-Time-retrieval

0x8003

TxTail- retrieval

0x8004

Fullduplex- retrieval

0x8005

DAMA- retrieval

0x8006

Baud rate -retrieval

Modem-Baudrate[100 Hz]

0x8007

2

IPKISS Program-Version- retrieval

Sign-chain

0x8100

Table 10: AXIP/AXUDP-Commands

Restrictions

IPKISS is primarily used for coupling of (X)NET-Nodes with a TNC4 via a local Ethernet-Net. Therefore following simplifications are done:

IP

IP is implemented only minimally. It supports no „IP-Fragmentation". Consequently all networks between these two stations must possess a MTU of 350 bytes! Also only IP-Packets of version 4 is understood (At present usual version). The used protocol-number is 93 (as stipulated by RFC1226). TTL is solid set to 16. IP-Options are not send.

ICMP

The ICMP Echo Request Message (Ping-Command) is recognized and an echo reply is sent back. Other ICMP-Messages are neither sent appraised.