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

> Hm ich wuerde sie auch nicht verstehen. War wohl ein bissl im Tran vorhin.
> Ich meinte, dass ich meine Sessions auf die Funktionstasten gelegt hatte,
> d.h. mit f1 die erste, f2 die zweite etc., einfach aus der Faulheit
> heraus, <esc> und dann 'sess x' einzugeben. Auf F10 habe ich mir den
> Status-Befehl gelegt. Meine Frage war, ob's auch bei den HP-Terminals
> Funktionstasten gibt, und ob die Ansi-Sequenzen da irgendwie genormt sind.
> Bei mir ist f1 z.B. ^[OP, f2 ^[OQ usw.  Wenn die Terminals da kompatibel
> waeren, koennte man damit auch das esc-Problem erschlagen, da dann der
> Druck einer F-Taste zum Wechseln der Session bzw. zum Wechseln in den
> Commandmode fuehren wuerde.
> Hoffentlich war das jetzt verstaendlich, werde nun erstmal ins Bett gehen,
> sonst kommt eh nichts mehr raus.
> 73s,
> noch einen schoenen Abend
> Olaf

Jetzt habe ich Dich  verstanden.  Die Codes fuer HP  Terminals  und ANSI
Terminals sind zwar verschieden, aber das eigentliche  Problem ist, dass
der  momentane  ttydriver  so lange  Sequenzen  nicht  dekodieren  kann.
Bisher versteht er nur

  ESC   [   <char>
        ^
        |
     optional

Langfristig  koennte man das schon einbauen, aber momentan  drueckt mich
das CRC Problem mehr.

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

- CHECK:        overflow in mail buffers

- IMPLEMENT:    ax25 blimit

- IMPLEMENT:    netrom blimit

- ping (record route) does not work

- brauchen die Broadcast Addressen noch das E-Bit?

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

    &TCB Rcv-Q Snd-Q  Local socket           Remote socket          State
   62880     0  1017  dk5sg:ftp-data         dc3sn:1008             Closed

Local: dk5sg:ftp-data Remote: dc3sn:1008 State: Closed
      Init seq    Unack     Next Resent CWind Thrsh  Wind  MSS Queue      Total
Send: 3c580000 3c58e809 3c58e9ba  11233   432   216  1080  216  1017      59401
Recv: 7538eff0          7538eff1      0              1080          0          1
Backoff 11 Retrying Timer stopped SRTT 12130 ms Mean dev 7213 ms

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

- richtige Verwendung von Mycall pruefen

- "will echo" implementieren und testen (all telnet options)

- ax25 rtt cache?

- netrom rtt cache?

- rip request testen

- remote_kbd: stop tracing to stdout

- tty.h; ttydriv an session koppeln (Schwierigkeit: keine CmdSession)

- ttylink?

- trace for netrom selfconnects

- don't switch STREAM -> DGRAM after connection

- wo soll retry = 0 gesetzt werden ?

- AX.25:  VC Mode fuer IP einbauen

- AX.25:  axserver auch in die Liste haengen?

- AX.25:  gibt es mehrere strtopath ?

- Netrom:  Knoten sollen durch Ident ansprechbar sein

- Netrom:  print_destname ueberall verwenden

- Netrom:  den Ident wie eine AX25 Adresse behandeln

- Netrom:  struct circuit doppelt verpointern

- Netrom:  TTL default auf 25 erhoehen ?

- Mailer:  Alle Message Delimiter entfernen

- Mailer:  Use hierarchical addressing

- Mailer:  Use 'host-mode'

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

From dl5ue Wed Mar 22 14:44 MEZ 1989
Received: by db0sao; Wed, 22 Mar 89 14:44:33 mez
Date: Wed, 22 Mar 89 14:44:33 mez
From: Jan Schiefer <dl5ue>
Return-Path: <dl5ue>
To: dk5sg
Subject: netrom.c
Status: R

Hallo Dieter,

leider bin ich erst heute dazu gekommen, mir netrom.c in Ruhe anzusehen. Am
Montag war mir aufgefallen, dass von den WAMPI sehr haeufig gebroadcastet
wurde. Heute trat das Problem scheinbar nicht auf, hast Du was geaendert?

Beim Lesen Deines Codes sind mir einige Dinge aufgefallen: In calculate_
routes ziehst Du den Broacast-Timer auf 10s auf. Ich finde, man sollte da
unbedingt eine Zufallszahl in der Groessenordnung 0...60s dazuaddieren, da
sonst folgendes passieren koennte:
A broadcastet Aenderungen, B und C hoeren dies, bei beiden ergeben sich
auch Aenderungen. Sie starten ihre Broadcast-Timer und broadcasten zwar
ohne Kollision, aber doch fast gleichzeitig. Da ist die Chance sehr gut,
dass der Bs BC im TNC wartet, bis Cs BC vorbei ist. Anschliessend BCed B
veraltete Routen, was wiederum A und C hoeren....usw.

Ausserdem fiel mir auf, dass auch bei einem BC 'ausser der Reihe' immer
alle Routen gebroadcasted werden. Was haeltst Du davon, bei solchen BCs
nur neighbor und quality derjenigen Destinations zu senden, bei  denen
force_broadcast != 0 ist? Dadurch wuerde das Datenvolumen auf dem Kanal
kleiner, ausserdem koennten mitlesende Spanner leichter beobachten, ob es
Probleme bzw. Schwingungszustaende gibt. (Dann allerdings sollte man die
normalen BCs grundsaetzlich immer machen, wenn der obsolesence_timer aus-
laeuft, da sonst bei anderen Stationen der obs-counter u.U. veraltet, wenn
laenger als 1/2 h kein vollstaendiger BC kommt).

Das was eigentlich das, was mir ins Auge stach. Ach ja, nochwas: So schwer
ist das ja eigentlich gar nicht zu lesen + verstehen....

Gibt's was Neues von Deinem 70er Funk?

Bis bald,
Jan

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

bbs mailer:

- wenn ich eine SID bekomme antworte ich mit meiner SID

- nach dem S Kommando wird auf OK/NO gewartet

- bei OK wird die Msg gesendet

- bei NO wird die Msg dem return_mailer uebergeben

- ich sende wenn moeglich hierachical adresses

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

HP:
---

ftp> put /hp-ux /tmp/x
200 PORT command okay.
150 Opening data connection for /tmp/x (127.0.0.1,1103).
226 Transfer complete.
802432 bytes sent in 6.72 seconds (116.58 Kbytes/sec)

ftp>

WAMPES:
-------

put /users/funk/dk5sg/p.Z
200 Port command okay
150 Opening data connection for STOR /users/funk/dk5sg/p.Z
Put complete, 3638 bytes sent
226 File received OK

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

S DC3SN    < DK7WJ
OK, go ahead
SEARCH U. WAMPES
R:160289/1113  @DB0GV  [RMPRG Maintal-Frankfurt JO40KD OP: DF5FF (438.025 MHz)]
de DK7WJ @ DB0GV

hallo Thomas, du hast den Finger auf der Wunde hi
Ich hab die Sache bereits mit DB0IE ausprobiert, wo Wampes ja seit einiger
Zeit auch laeuft. Der Suchframe (UI mit Poll) wird von Wampes normal
digipeated, dummerweise aber nicht der Antwort-DM. Der wird von Wampes
verschluckt, weil es vermutlich alle Frames ausser UI nur in dem High-
Level-Pseudodigi (schoenes Wort) verarbeitet und dort feststellt, dass
der DM zu keinem laufenden QSO gehoert. Also wird er verworfen.
Bei Flexnet ist das so gemacht, dass alle Frames, die nicht zu einem QSO
gehoeren, normal digipeated werden, was auch den Vorteil hat, dass bei
vollen QSO-Tabellen oder nach einem Restart des Knotens die QSOs per
L2-Digipeating weiterlaufen. Dadurch kommen auch die DMs durch. Diese
Loesung bringt natuerlich auch noch weitere Schwierigkeiten, so muessen
z.B. alle QSOs nach dem Disc noch ein paar Minuten weiter gefuehrt werden,
damit die Trennung auch bei DISC-Retries noch funktioniert. Dies ist auch
so gemacht, sie tauchen nur nicht mehr in der Userliste auf. Weiterer Vorteil:
Noch vorhandene I-Frames bleiben fuer einen eventuellen Reconnect noch ne
Weile gespeichert, leider fuehrt das manchmal zu doppelten Ctexten, aber das
ist m.E. das kleinere Uebel.
Der Suchframe ist ueberigens so aufgebaut, dass er garnicht zu einem laufenden
QSO passen kann, der absendende Digi guckt naemlich erst in seiner QSO-Liste
nach, ob der Gesuchte schon mit ihm connected ist. Wenn ja, wird sofort die
"gefunden"-Msg gesendet.
Waere fein, wenn Dieter die Sache bei Wampes umbauen koennte, ev. gleich
mit Integration des Suchframes. Dieser sieht uebrigens wie folgt aus:
<Absenderdigi> -> <Gesuchter> via <Suchender> <Absenderdigi>* [Digis] UI cp
Leider ist im Moment der Link DA<->ID sehr schlecht, weshalb solche Frames
leider oft verlorengehen... Wenn diese Msg nicht ausreicht, kann ich aber
trotzdem gerne mal nen Suchpfad bei ODW einbauen, pse kurze msg!
73 Gunter   DK7WJ @ DB0GV

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

Hallo Jan, ich denk mir eben dass ich euch die Konzeptbaustelle schon mal
zuschicke, dann koennt ihr parallel daran arbeiten und Fehler suchen helfen.
Zum Codieren komm ich eh erst in 2-3 Wochen, vorher gibts fuer den RMNC noch
nen Update mit einigen Features mehr und einigen Bugs weniger, die Version
mit Router will ich so ca. zur Ham Radio fertig haben... kann sein dass in
dem folgenden Papier noch Fehler drinstecken, ist wie gesagt nur der Entwurf
fuer das Skript, also pse Nachsicht... so los gehts:

                    Features FlexNet Sink-Tree-Router      Stand: 20.04.89
                    =================================

-   Netzknoten unterhalten untereinander staendig eine L2-Verbindung fuer
    Routing Updates und zur Kontrolle des Links
-   Nach (Wieder-)anlauf eines Knotens hat dieser keinerlei Informationen ueber
    die Netztopografie, die Kenntnis seiner Nachbarn ausgenommen. Also meldet
    der Knotes diese Tatsache seinen Nachbarn, worauf diese ihm sofort alle
    ihnen bekannten Nodes zuspielen, diese Info enthaelt einen Parameter fuer
    die Route-Qualitaet, die analog zur Netrom-Loesung ermittelt wird.
-   Unser Knoten hat nach dieser ersten Lernphase eventuell mehrere Routes zu
    einem Ziel erhalten, er speichert die 3 besten und benutzt hinfort den
    besten.
-   Diese Liste wird nun durchgesehen, unser neunmalkluger Knoten hat nun
    sicherlich fuer manche Ziele viel bessere Pfade gelernt, als er sie von
    einem seiner Nachbarn gemeldet bekam. Sicher gilt das z.B. fuer die jeweils
    anderen Nachbarn, zu denen er ja bereits eine Verbindung unterhaelt.
    Jetzt wird es aber kritisch: Meldet er diese besseren Pfade einfach weiter,
    kann es passieren, dass nach einem Ausfall dieser momentan noch besseren
    Strecken eine Loop entsteht, denn er wuerde ja dann sofort den zweitbesten
    Weg waehlen, der dann aber leider genau der Rueckweg ist. Um dieses Problem
    zu loesen, greifen wir zu einem Algorithmus, der in der Literatur als "Sink
    Tree" bekannt ist.

    Bezogen auf ein bestimmtes Ziel steht jeder Knoten an einer Gabelung eines
    Baumes. Er muss stets informiert sein, wo in diesem Baum die Nachbarn
    angeordnet sind, d.h. ob sie auf dem Weg zum Ziel liegen oder ob umgekehrt
    diese ihre Packets fuer den Zielknoten ueber uns routen. Er darf NIEMALS
    Packets in der Gegenrichtung routen, also zu einem Knoten, der von ihm aus
    weiter hinten liegt. Wenn wir nun den Ausfall unserer Strecke bemerken und
    auch keine Alternative im obigen Sinne finden, senden wir einen Hilferuf an
    die Knoten unter uns: "Ich kann Knoten x nicht mehr erreichen!" Wenn der
    Knoten darunter eine Alternative hat, sendet er diese Information zurueck,
    der Fall ist erledigt, fuer dieses Ziel haben die beiden Knoten ihre
    Position auf dem Baum getauscht. Wenn unser Nachbar auch keine Alternative
    kennt, sendet er diesen Hilferuf ueber alle Links weiter. Dies setzt sich
    fort, bis irgendwo im Netz ein Knoten einen alternativen Weg kennt. Diese
    wird dann normal bekanngemacht, wobei die Knoten ihren neuen Platz auf dem
    Baum einnehmen. Die Hilferufe fuehren natuerlich bei jedem Knoten dazu, dass
    die entsprechende Routinginformation geloescht wird. Wohlgemerkt: Dieser
    Baum existiert fuer jedes im Netz bekannte Ziel, Die Implementierung der
    Nodestabelle ist recht einfach: Fuer jeden Nachbarn wird eine Spalte
    eingerichtet, in der die Streckenqualitaeten zum jeweiligen Zielknoten
    stehen. Ein Nachbar, der ueber uns routet, wird mit der Qualitaet 0
    versehen. Wenn wir einem Nachbarn eine Linkinfo senden, gehen wir immer erst
    davon aus, dass dieser den Weg ueber uns auch benutzen darf. Sofern er uns
    eine Strecke meldet, wird er niemals ueber uns routen, und wir koennen
    diesen Weg verwenden.

    Wenn wir keinen verwertbaren Weg zu einem Ziel mehr haben, senden wir auf
    allen Links einen Hilferuf aus, der besagt, dass wir keinen Weg zum
    Zielknoten mehr kennen. Die Nachbarn loeschen draufhin den Weg ueber uns und
    schauen dann nach, ob sie eine Alternative haben: Wenn ja, teilen sie sie
    uns mit, wenn nein, senden sie den Hilferuf weiter. Dies setzt sich fort,
    biss alle Knoten den Ruf erhalten haben und keiner einen Pfad zum Ziel
    kennt. Gibt es jedoch einen solchen, dann wird diese Information wie beim
    Kaltstart verbreitet. Die Routinginformationen fuer diesen Zielknoten bauen
    sich dann neu auf, sobald irgendwo ein Weg bekannt ist. Wenn ein Knoten
    nicht mehr erreichbar ist, wird er auf diesem Wege aus allen Knoten
    ausgetragen.

--------------
                    Datenstruktur Routing Table
                    ===========================

Fuer jede gemeldete Node ein Eintrag, ausser fuer die Nachbarn, diese
stehen samt Kanalnummer in einer eigenen Liste (Nachbarliste)

<CALL(7)> <3*[<Nachbar-Nummer>,<Qualitaet>]> <Upstr Flags> <Updt Flags>

Nachbar-Nummer: Index in Nachbarliste
Qualitaet: Link-Qualitaet, Berechnung wie NET/ROM
Upstr-Bitflags: Fuer jeden Nachbarn ein Bit als Kennung: Nachbar ist Upstream
Updt-Bitflags: Fuer jeden Nachbarn ein Bit als Kennung: Update Info senden

Summe: 21 Bytes/Node bei max. 32 Nachbarn

           Verwaltung der Routing Table (Pseudocode)
           =========================================

Kaltstart:
    {
    Routing Table loeschen
    Hauptschleife:
        {
        Alle ca. 5 Minuten:
            {
            L2-QSO zu L3-Nachbarn initiieren, falls nicht connected
            ((( Nachbarn identifizieren, Versionen abgleichen )))
            }

        Neues L2-QSO mit bekanntem Nachbar:
            {
            In allen Routes Update-Flags fuer diesen Nachbarn setzen
                und Upstream-Flags loeschen
            }

        L2-QSO zu Nachbar zusammengebrochen:
            {
            Alle Flags (Update und Upstream) fuer diesen Nachbarn loeschen
            Route-Qualitaeten via diesem Nachbarn loeschen, wenn dadurch
                zu Zielen der beste Weg verlorengeht, Update-Flags fuer alle
                Upstream-Nachbarn fuer dieses Ziel setzen, d.h. Update-Bits
                von Upstream kopieren
            }

        periodisch (z.B. alle 100ms eine Route oder alle 10s alles)
            {
            Plaetze ohne verwendbaren Weg loschen, falls kein Update-
            Flags gesetzt

            Eine Route auf gesetzte Update-Flaggen testen:
                {
                Routing Info senden, wenn gelungen, Update loschen und
                    Upstream setzen, sofern gemeldete Qualitaet > 0
                Eventuelle Route-Qualitaet via diesem Nachbarn auf 0 setzen!!
                }
            }

        Route-Info erhalten?
            {
            Neue Node && Qualitaet > 0 (kein Hilferuf)?
                {
                Tabellenplatz fuer Node einrichten, alles auf 0 setzen
                }

            Qualitaet > 0?
                {
                Upstream-Flag f. Nachbar loeschen
                }

            Gemeldete Qualitaet <= den bekannten?
                {
                Wenn dieser Nachbar besser ueber uns ginge, da sich fuer ihn
                ein besserer Weg ergibt als gemeldet, Update Flag setzen!
                }

            Bereits 3 Routes gespeichert?
                {
                Schlechteste Route loeschen und neue Route eintragen, falls
                nicht die schlechteste
                }

            Beste Qualitaet besser geworden (auch wenn neue Node!)
                {
                Fuer alle Nachbarn mit eingetragenen Qualitaeten berechnen,
                ob sie ueber uns besseren Weg haetten, wenn ja->Update-Flag
                }

            Durch Meldung beste Qualitaet schlechter geworden?
                {
                Fuer alle Nachbarn OHNE eingetragene Qualitaet Update-Flag
                ausser fuer den meldenden Nachbarn
                }
            }

                    Syntax Routing Updates
                    ======================

    --- noch zu definieren (moeglichst eigene PID)

                    Link-Qualitaeten
                    ================

Aufgrund dews Sink-Tree-Algorithmus ist es unabdingbar, dass eine Strecke
auf beiden Seiten die gleiche Qualitaet besitzt. Alternativ koennte man
in der Setup-Phase eines QSOs zwischen Nachbarn die eigene Qualitaet
uebertragen. Ein automatisches Update der Qualitaet in Abhaenigkeit der
Belegung erscheint nicht sinnvoll, da dies zu zuvielen Updates im Netz
fuehren kann. Folgende Qualitaeten werden beim RMNC voreingestellt
(Aenderung durch Sysops nicht vorgesehen):

          Baudrate   Vollduplex  Halbduplex

            9600        252         249
            4800        249         243
            2400        243         232
            1200        232         211
             600        211         175
             300        175         120

Die Berechnung einer Route-Qualitaet geschieht wie bei NET/ROM:
                Rc' = (Cc * Rc + 128)/256

Rc': Neue Routequalitaet; Rc: Alte Routequalitaet; Cc: Kanalqualitaet

                    Routing-Algorithmus
                    ===================

Konzept:
   Virtual Circuit Router unter Verwendung des AX25-Adressfeldes

Wird bei FlexNet-QSOs nur bei SABM und UI durchlaufen, ausserdem bei
Frames, die nicht zu einem laufenden QSO passen.
Routing uebertragbar auf Digis ohne Hop-to-Hop-Ack

Wir sind nicht naechster Digi?
    {
    verwerfen!
    }

Wenn auf exclusivem Linkkanal empfangen: Letztes Call als Nachbar
  bekannt?
    {
    verwerfen!
    }

Letztes Call als Nachbar bekannt && nicht 1. Digi && vorletztes Call als
  Node bekannt?
    {
    Letztes Call aus Callfeld loeschen, folgende Calls aufruecken
    }

Naechstes Call als Node bekannt && Route vorhanden?
    {
    Call des Nachbarn, ueber den gerouted wird, nach unserem einschieben
    }

Jetzt routen nach V2-Methode, also entsprechend SSID oder Nachbarn

H-Bit und ev. SSID fuer unser Call setzen

Frame senden (Bei FlexNet-SABM QSO-Allokierung)
}

                Vorteile von FlexNet Virtual Circuit
                ====================================

- Keine Fragmentierung von langen I-Frames durch Network Header Overhead
- Das vorhandene Digipeaterfeld im AX.25-Protokoll wird sinnvoll weiter-
  verwendet
- Jede monitorende Station sieht sofort, wer mit wem ueber welche Strecke
  arbeitet, Up- und Downlink sind symmetrisch, d.h. man kann die anrufende
  Station ueber den gemeldeten Pfad zurueckconnecten
- Deutlich groesserer Durchsatz durch:
    a) Entfall des Rechenaufwandes durch Routing jedes einzelnen I-Frames
    b) Kein festes End-to-End-Window, das Window ergibt sich durch die
       Summe der eingestellten MAXFRAMES der auf der Strecke liegenden
       Knoten
    c) Fuer jedes QSO individuelles Flow-Control moeglich, dadurch optimale
       Auslastung von schnellen Teilstrecken; ueberlastete, weil z.B. lang-
       same Teilstrecken bremsen nur noch die QSOs, die ueber diese Strecken
       laufen muessen

- Durch die Transparenz Unprotos und andere Protokollvarianten moeglich, z.B.
  Netrom-Vekehr ueber FlexNet-Teilnetze mit 2 anzugebenden Digis
- Keinerlei Einschraenkungen bezueglich PIDs
- Einstufiger Verbindungsaufbau mittels Angabe von Einstiegs- und Ausstiegs-
  knoten
- Endstellen, die als Nachbarn definiert sind (z.B. Mailboxen), koennen
  von entfernten Knoten ohne Angabe des letzten Digis connected werden,
  z.B. "C DB0CZ via DB0ODW"
- Wenn beim Verbindungsaufbau bei einem Knoten auf der Strecke kein RAM frei
  ist, wird QSO nach gleichem Routingverfahren auf dieser Teilstrecke per
  L2-Digipeating ausgefuehrt, dadurch kein hartes Limit der QSO-Anzahl
- Sehr einfache Implementierung, zumindest bei FlexNet und, wenn ohne Hop-
  to-Hop-Acknowledge realisiert, auch bei anderen Knotenrechnerkonzepten
- Durch Entfall des speziellen L4 kuerzerer Code

            Nachteile gegenueber Datagram-Routing (z.B. NET/ROM)
            ====================================================

- Jedes QSO, das ueber einen Netzknoten abgewickelt wird, belegt Speicher-
  platz, sofern es per Hop-to-Hop-Ack abgewickelt wird (bei FlexNet ca.
  200 Bytes + zwischengespeicherte Frames)
- Dynamisches Umrouten bei WAEHREND eines QSOs ausgefallenen Knoten und
  Strecken nicht moeglich, Verbindung muss neu aufgebaut werden
   (Riesennachteil!! Relativiert durch durchschnittliche QSO-Dauer, zuver-
    laessiges Netz, Zusammenbruch ergibt aussagekraeftige Fehlermeldung des
    Knotens, der die Verbindung nicht weiterfuehren konnte)
- Es koennen mehr als 8 Digis im Rufzeichenfeld entstehen, dieser Fall muss
  entsprechend behandelt werden, entweder zurch Zulassen von 10 Digis oder
  durch Verwerfen dieser Frames

                       Auswirkungen fuer User
                       ======================

- User brauchen sich nicht umzustellen, es kann nach wie vor der komplette
  Pfad angegeben werden
- User kann am Einstiegsdigi die Nodesliste abrufen, wenn sein Ausstiegsdigi
  in der Liste steht, kann er die dazwischenliegenden Digis weglassen
- Nach wie vor einstufiger Verbindungsaufbau ueber das bekannte Netzwerk
- Uebergang erfolgt gleitend, Vorteile entstehen sobald min. 3 Digis in
  Reihe dieses Verfahren beherrschen (mittlerer Digi kann weggelassen werden)

                  Allgemeine Argumente gegen NET/ROM
                  ==================================

1. Router (L3)
  - Ein Netzknoten besteht in Wirklichkeit aus mehreren "Nodes", die man
    zwar verstecken kann, aber sie existieren und belasten die Routing-
    tabellen
  - NET/ROM hat Schwierigkeiten mit Loops, die beim Ausfall von Linkstrecken
    oder Netzknoten entstehen koennen
  - Ausgefallene Nodes werden zu langsam bekanntgemacht, Erhoehen der Update-
    rate belastet Netz zu stark, zumindest bei 1200 Baud-Links
  - Durch Sendung der Routinginfo als Broadcast geringe Uebertragungssicher-
    heit, u.a. deshalb periodische Wiederholung noetig
  - Konzipiert fuer ein sehr dynamisches Netz mit vielen Linkpartnern auf
    einer Frequenz, daraus resultieren z.T. obige Maengel.
  - Prinzipbedingt (Datagram Routing) Probleme mit Flow Control, dadurch
    u.U. schlechte Frequenzauslastung

2. Transport (L4)
  - Trennen der Verbindung nach ~10 Minuten ohne Aktivitaet, waere behebbar
    durch "L4V2" mit Command/Poll

3. Up-Downlink
  - Beim Monitoren ist der Pfad nicht ersichtlich
  - Zwecks Rueckruf muss der Einstiegsdigi des Partners bekannt sein
  - SSID-Drehung, dadurch eingeschraenkte Verwendbarkeit von SSIDs und
    moegliche Irrtuemer beim Zurueckconnecten
  - Verbindungsaufbau uebers Netzwerk generell dreistufig, dadurch kein
    automatischer Verbindungsaufbau mit normalen Terminalprogrammen durch
    Funktionstastenbelegung moeglich
  - "Weiterconnecten" fuehr bei vielen QSOs zu Zickzackroutes mit unnoetiger
    Netzbelastung
  - Digi sendet nicht unter seinem Rufzeichen, dadurch z.B. Irrtuemer bei
    Feldstaerkeermittlung

Sodele, oje, ist doch schon etwas laenglich fuer diese Betriebsart hi
also, bei Bedarf werd ich die Updates auch wieder rueberspielen, hab aber
wie gesagt in den naechsten Tagen sehr wenig Zeit fuer den Kram
73 Gunter

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