Aus meinem Archiv: XNet und NETROM

[DMA284]

Moin!

Seit einigen Wochen experimentiere ich wieder mit Packet Radio und leider
muss man sagen, das man das Netz voellig vergessen kann und das trotz AXUDP
Verbindungen zwischen den Nodes.

Faellt denn Niemanden ausser mir auf das NETROM nicht wirklich funktioniert?

Ja, es gibt ein tolle Nodeliste, aber wenn man versucht vor allem entferntere
Nodes zu erreichen dann funktioniert das nicht. Der Grund ist auch voellig
klar. Es liegt daran das immer noch viel zu haeufig die Software XNet
verwendet wird.

XNet ist an sich gar nicht mal schlecht aber es hat einen grossen Makel. Es
mixt die beiden Routing Grundlagen naemlich die des Time Dependent Routing
(TDR) via INP3 und dem Qualitaets basierten Routingshema.

Das Qualitaets basierte Routing Schema ist das urspruengliche Verfahren wie
eine Route zu einem Nachbar NETROM Node berechnet wird. Der Sysop gibt den
einzelnen Ports seines Nodes eine "Qualitaet" fest vor. Jede Software die
NETROM kann muss also einem Port eine Qualitaet zuweisen. In der
Vergangenheit war das oft der Wert 192 fuer einen 1200 Baud Funkport im CB.

Ein NETROM Node schickt in regelmaessigen Abstaenden ein NODES Broadcast als
AX.25 UI Frame an das Call NODES aus. Damit identifiziert er sich bei anderen
Nodes als NETROM Node und gleichzeitig schickt er damit eine Liste mit NETROM
Nodes mit die er selber kennt. Ein Node Broadcast sieht so aus:

10:09:38T DNO284>NODES Port=1 <UI C> NODES broadcast from WITBPQ
  WITPBXBO284 via DNO284 qlty=192
  WITCNVNO284-4 via DNO284 qlty=192

Empfaengt ein NETROM Node so einen Broadcast, traegt er den sendenden Node bei
sich in der Nodeliste mit der Port Qualitaet 192 ein. Weitere Nodes in der
Liste ebenfalls, aber reduziert in der Qualitaet basierend auf der Port
Qualitaet und der Qualitaet die der sendene Node diese Nodes selber bei sich
eingetragen hat.

Zur veranschaulichung:

Wir haben 3 Nodes. NODE01 <> NODE02 <> NODE03.
                         
Alle Nodes haben eine Port Qualitaet von 192 eingetragen. NODE01 und NODE03
sehen sich nicht direkt.

NODE02 sendet an NODE03 das er NODE01 mit Qualitaet 192 empfaengt. NODE03
berechnet nun die Qualitaet von NODE01 so:
192/256 * 192/256 = 0,75 * 0,75 = 0,5625 * 256 = 144

Wuerde es jetzt noch einen NODE04 geben der NODE03 hoert wuerde NODE01 bei
ihm mit Qualitaet 108 eingetragen werden.

144/256 * 192/256 = 0,5625 * 0,75 = 0,421875 * 256 = 108

Und so geht das immer weiter wenn noch mehr Nodes in diesem Netz hinzukommen.

Die Qualitaet kann den Wert 0-255 annehmen. Und wie man in den Berechnungen
sieht kommt bei 192/256 der Wert 0,75 bei raus. Damit wollte man abbilden wie
zuverlaessig ein Funkverbindung zwischen zwei Nodes fuer gewoehnlich ist. Man
koennte auch schreiben 75% der AX.25 Pakete zwischen zwei via Funk
verbundenen Nodes kommen an. Dieser Wert kann erreicht werden, wenn zwei
Nodes die Frequenz ganz fuer sich alleine haben, aber nicht wenn auf diesem
Kanal noch weitere Stationen sind. Tummeln sich jetzt mehrere Nodes und ggf.
noch User auf einer Frequenz wie es bei CB-PR ueblich war, war 192 auch schon
immer zu hoch gesetzt. Wenn man Glueck hatte kamen vielleicht gerade mal 50%
der AX.25 Pakete an oder noch weniger. Dementsprechend muesste man die
Qualitaet  entsprechend anpassen bei 50% waere 128 ein guten Wert. Die
meisten Nodes haben Port Statistiken gefuehrt, anhand diesen haette man
ermitteln koennen wie gut ein Port performt.

Obiges war jetzt die Beschreibung fuer Funk Links. Im heutigen CB-PR kommen
vor allem AXUDP Links via Internet vor, welche die Nodes miteinander
vernetzen. Das ist im Grunde nicht schlimm da wir, anders als im AFU, keine
exklusiven Frequenzen fuer eine Backbone Vernetzung zwischen Nodes haben.
Haeufig wir hier dann gerne die Port Qualitaet fuer solche AXIP/AXUDP Links
von 255 eingetragen. Das ist aber genauso falsch, weil Internet, welches auch
Paket basiert ist, nicht 100% Fehlerfrei ist. IP Pakete koennen und duerfen
verloren gehen. Nun ist unzweifelhaft das Links ueber Internet stabiler sind,
also kann man hier einen besseren Wert fuer die Qualitaet eintragen.

Die NADA (NorthEast Digital Association), eine in den 80er Jahren in den USA
gegruendete Organisation von Funkamateur Packet Radio Sysops hat fuer ihr
Netz Richtlinien herausgebracht. Dort wurde unter anderem festgelegt das
fuer AXIP/AXUDP Links die Port Qualitaet 203 betragen soll. Ich denke das ist
ein gute Wert. Er liegt hoeher als bei Funk Links und laesst die Moeglichkeit
zu das Internet Routen besser dastehen als reine Funk Links. Fuer lokale
Dienste wie z.B. die eigene Box oder der Convers kann der Wert 228 genutzt
werden. Dann resultiert daraus im Nodes Broadcast bei Nachbar Node eine
Qualitaet von 203 und ist somit genauso hoch wie der eigene Node.

Das oben genannte Routing mittels Qualitaeten hat schon in den Anfangstagen
so seine Probleme gehabt. Wie sich ja aus der von mir oben hoffentlich
einigermassen beschrieben kurzen Beschreibung ergibt, gibt die Qualitaet
ueberhaupt keinen Anhaltspunkt wie gut eine Node zu Node Verbindung
tatsaechlich ist. Sie ist ja nur angenommen und von den Sysops parametrisiert.
Jeder weiss, wenn sich Bedingungen aendern, muesste sich auch die Qualitaet am
besten automatisch mit aendern. Das koennen verschiedene Dinge sein. Zum
Beispiel wenn ein Link oder eine Frequenz stark ausgelastet ist, sinkt der
Datendurchsatz. Ergo muesste die Qualitaet sich verschlechtern. Tut sie aber
nach dem alten NETROM verfahren nicht.

Ein weiterer Grund ist wie Nodes wieder aus der Nodes Tabelle verschwinden.
Das geschieht aus einer reinen Zeit Komponente heraus. Es gibt bei NETROM den
Parameter OBSINIT. Das ist der Startwert des Veraltenszaehlers. Wird ein Node
das erste mal in einem Node Broadcast empfangen bekommt dieser den
Zaehlerwert von OBSINIT. Sendet unser Node ebenfalls einen Node Broadcast
wird dieser Wert um 1 verringert. Ist dieser Wert auf 0, fliegt der Node aus
unserer eigenen Nodes Tabelle raus. Ein Zweiter Parameter ist der Wert
OBSMIN. Dieser gibt an wann ein Node unserer Nodes Tabelle nicht mehr weiter
gemeldet wird. OBSINIT und OBSMIN haengen also davon ab wie oft unser Node
seinen Node Broadcast sendet. Ein guter Wert sind meiner Meinung nach 10
bis 15 Minuten. Ich bin der Meinung wenn man einen Node seit einer Stunde
nicht mehr im Broadcast gelesen hat, sollte er aus der Liste fliegen. Also
setzt man OBSINIT bei 10 Minuten Broadcast Intervall auf 6. Bei 15 Minuten
auf 4. Alle Node in einem Netz sollten bei Node Broadcast Intervall und bei
OBSINIT und OBSMIN die selben Werte haben, ansonsten ist das Netz von vorn
herein zum scheitern verurteilt. Sysops die nicht angepasste Werte dort
stehen haben, sollte vom Netz ausgeschlossen werden.

Weil das alte NETROM Node Austauschverfahren so unzuverlaessig ist, hat man
sich INP3 fuer NETROM ausgedacht. Hier werden mehrere Dinge ueberprueft damit
ein Link und somit der Nachbar Node und dessen erreichbare Nodes in der
eigenen Nodesliste angezeigt wird und auch an andere Nodes weiter geleitet
wird.

* Es muss ein AX25 Link zwischen den Nodes dauerhaft bestehen.

Im alten Netrom Netz wurde mit den oben beschriebenen Nodes Broadcasts auf
sich aufmerksam gemacht. Nun konnte die Situation entstehen das er Broadcast
aussendene Node den empfangenen Node selbst garnicht hoeren kann. Der
empfangene Node traegt den aussendenen Node und die weiteren im Broadcast
enthaltenen Nodes aber in seine Node Tabelle ein und sendet auch die darueber
verbreiteten Nodes weiter aus. Kommt jetzt eine NETROM Paket an beim Broadcast
empfangenden Node an, kann dieses Paket nicht weitergeleitet werden zum zuvor
Broadcast sendenen Node.

Sieht also ein INP3 NETROM Node einen Nachbar Node via Node Broadcast, baut er
einen AX.25 Connect zu diesem auf. Nur wenn das klappt, wird der Node erst in
die Nodes Tabelle bei ihm eingetragen.

* Laufzeitmessung

Zwischen INP3 Netrom Nodes werden Paketlaufzeiten ermittelt. Laufzeiten geben
einen Anhalt wie schnell ein Paket von Sender zum Empfaenger und zurueck
braucht. Das Ganze nennt sich abgeuerzt RTT (RoundTripTime). Da die Bandbreite
eines Links ja vorgeben ist, bedeutet eine kurze laufzeit das hoher Daten
Durchsatz moeglich ist. Ist ein Link ausgelastet oder sogar von Stoerungen
betroffen, werden die Laufzeiten schlechter.

* Hopcount

INP3 weiss wie viele Nodes zwischen den Nodes sind.

* Gesicherte Uebermittlung von Routing Informationen

INP3 sendet zu den Nachbar Nodes keine Nodes Broadcast mehr aus. Sondern die
Informationen werden gesichert in der AX.25 Verbindung zwischen beides Nodes
uebertragen.

* Negative Routing Informationen

INP3 meldet nicht mehr verfuegbare Links und darueber gelernte Nodes sofort als
nicht mehr erreichbar zu seinen anderen Nachbar Nodes weiter. Anders als beim
Routing ueber Qualitaet wo erst ein Node aus der Tabelle fliegt wenn von ihm
nach einer bestimmten Zeit kein Nodes Broadcast mehr empfangen wird.


Was hat nun XNet mit dem ganzen zu tun?

Nun es ist eigentlich einfach. NETROM an sich ist erstmal nur ein Protokoll
was Verbindungen herstellt zwischen entfernten Nodes. Die Routing
Informationen werden aber wie oben beschrieben auf zwei verschiedene Arten
ermittelt. Qualitaet und INP3. Waehrend Routing nach Qualitaetsangaben sich
quasi nur auf die Einschaetzungen der Sysops aufbaut, ermittelt INP3 Fakten
anhand von Laufzeitmessungen und ob ein Link tatsaechlich existiert, also
zwei Nodes auch wirklich eine Verbindung herstellen koennen.

Es ist auch gar kein Problem wenn diese zwei verschiedenen Verfahren in einem
Netz zusammen kommen. Es muss aber sichergestellt sein das jeder Node diese
Verfahren getrennt haelt. Ausser XNet macht das jede NETROM Node Software die
ich kenne.

XNet berechnet aus Laufzeiten Qualitaeten und aus Qualitaeten Laufzeiten. Das
ist ein absolutes NoGo! Aber welche Folgen hat das denn nun?

Schauen wir uns das noch mal an. Qualitaet = Von Sysop festgelegt und wenn
ein Nodes ueber ungesicherte Broadcasts weiter gemeldet wird, verringert sich
von Node zu Node die Qualitaet. Ueber einen auch vom Sysop einzurichtenen
Veraltenszaehler kann ein Node, wenn er nicht mehr in Broadcasts gehoert wird
auch wieder aus einer Nodes Liste verschwinden.

INP3 = Zeitbasiert mittels RTT ermittelte Laufzeiten, gesicherte Uebertragung
von Routing Infos via AX.25 Link und negative Rueckmeldungen. Nodes fliegen
bei AX.25 Abbruch zum Nachbarknoten direkt aus der Nodeliste und werden auch
sofort als nicht mehr erreichbar an andere Nachbar Nodes weitergemeldet.
Somit eine vertrauenswuerdige Routing Umgebung, mit gesicherten Informationen
zum Netzzustand.

Die Folge ist nun, dass ein Node, der nur in der nicht vertrauenswuerdigen
Qualitaets Umgebung existiert und in dieser Umgebung moeglicherweise ausserhalb
unseres Qualitaets Horizonts lag, nun in der vertrauenswuerdigeren INP3
Umgebung auftaucht, wo er den NetRom veraltens Prozess umgehen kann. Die
Information koennte dann mit einer hoeheren "Qualitaet" in das qualitaets
Netrom-Netz zurueckkehren, als wenn sie ueber eine direktere reine Netrom-Route
empfangen worden waere.

Hier ein Beispiel wie das aussieht:

AP1DIG ==>n dnx284 +

routing WITXRONX284 v AP0NOD

  LOCAL      Inp 3    rx:  -.-  (unreach) tx:  -.-
  DAB563-9  Inp 3    rx:  1.48 ( 9 hops) tx:  -.-
> AP0NOD    Inp 3    rx:  1.21 ( 6 hops) tx:  -.-
  CB0ESN    Inp 3    rx:  -.-  (unreach) tx:  1.38
  CB0GER    Inp 3    rx:  -.-  (unreach) tx:  -.-
  AX25N0    Inp 3    rx:  -.-  (unreach) tx:  1.44
  CT1NET    Q BC      Obs  0 RxQual  0
  AP1NOD    Q BC      Obs  6 RxQual  0
  NL5POP    Q BC      Obs  0 RxQual  0
  Broadcasted 432s ago with quality 244

AP1DIG ==>
*** route: AP1DIG AP0NOD KS0NOD KS1NOD-2 AP0NOD* AP1DIG

DNX284 ist ein Test Node von mir, den ich jetzt seit mehrern Tagen Offline
genommen habe. Trotzdem ist er in Nodes Listen weiterhin vorhanden und wird
von XNet Nodes wie hier zu sehen mit der Qualitaet von 244 weiter
gebroadcastet und natuerlich somit auch via INP3 mit einer fiktiven RTT
weiter gegeben.

Ein weiterer Grund den ich nicht verschweigen moechte ist das einige Nodes
die z.B. mit BPQ laufen den Parameter AUTOSAVE fuer die Nodes Liste
aktiviert haben. Dieser sollte immer ausgeschaltet werden. Denn damit
werden bei jedem Neustart von BPQ ggf. alte nicht mehr vorhandene Nodes
neu ins Netz eingespielt, obwohl die schon lange weg sind.

Deswegen ist XNet fuer das CB-PR und fuer alle sonstigen Netze die schlechteste
Software die man AX.25 NETROM Netzen antun kann. Im AFU Bereich wo Packet
auch nur noch von wenigen betrieben wird, ist die Software so gut wie
verschwunden. Ich finde man sollte dieses auch im CB-PR so handhaben. Im
Grunde bleiben einem nur drei NETROM Node Programme uebrig wenn man sich
umschaut.

BPQ: Aktive Weiterentwicklung inklusive Source-Code verfuegbar. Fuer Windows,
Linux und auch auf nem RasPi lauffaehig. Aeltere Versionen auch auf DOS.
Zahlreiche Schnittstellen vorhanden. INP3 faehig und rudimentaer sogar schon
IPv6 faehig. Bevorzugt leider altes Qulitätsbasiertes NETROm Routing, kann
jedoch mit dem Parameter PREFERINP3ROUTES=1 dazu gezwungen werden INP3 zu
bevorzugen bei der Routing Entscheidung.

Xrouter: Aktive Weiterentwicklung. Leider closed Source. Nur auf Linux,
Windows und RasPi verfuegbar. Aeltere Versionen auch fuer DOS. INP3 faehig
und bevorzugt von Haus aus INP3, wenn vorhanden.

TNN: Keine aktive Weiterentwicklung. Open Source Quellcode aber nicht fuer
aktuelle Compiler angepasst und Probleme wenn auf 64Bit System compiliert
wird. Angepasste CB Versionen verfuegbar. INP3 faehig und bevorzugt von Haus
aus INP3, wenn vorhanden.

Ich moechte jedem Sysop bitten sich mal die Alternativen anzusehen. Zum einen
erweitert man dadurch seinen Horizont und tut, wenn man sich entschliesst
XNet aufzugeben, auch was Gutes fuer das Netz.

Fuer Sysops die nicht wechseln koennen, weil sie XNet in einem TNC3 oder TNC4
laufen haben. Sollten nur Links zu Nodes aufbauen die keine NODES Broadcast
aussenden. Ebenso sollten sie selber mit dem Befehl "ro bc del nodes" das
Aussenden von Nodes Broadcast abschalten.

Link Partner zu XNet Nodes sollten nur INP3 erlauben. Nodes Broadcast zum
XNet Nodes ebenfalls abschalten und Nodes Broadcast von XNet Nodes
ignorieren oder die Port Qualitaet auf 0 oder 1 setzen.

Falls das alles nix hilft bleibt nur noch, das XNet Nodes von Sysops ohne
XNet vom Netz ausgeschlossen werden.


55 & 73 Marc-Andre DMA284

[Brummbär]

moin Marc-Andre

ich verfolge ja einige Beiträge und stelle fest das du über wiegend grade Mimimi machst.... gegen Netrom.

ich habe so gut wie keine Ahnung von PR und den ganzen NODE Softwaren, aber was ich dauernd bei dir lese ist das du schreibst das mit NetRom es mehr als suboptimal funktioniert.
Was ich aber nicht lese ist wie es überhaupt dazu kommen kann?

Welche Softwaren gibt es aktuell auf den Markt( iNet) die sich mit den aktuellen Betriebsystemen einfach einrichten lässt um ein Node zu betreiben?
welche alternativen gibt es?
Gibt es Anleitungen um genau diese Alternativen Softwaren einzurichten mit einer 80% erfolgsgarantie?

man kann ja gerne meckern, aber wenn man keine konstruktive Lösung anbietet wird immer noch der "alte Weg" gegangen!


73 Karsten

---

nachtrag:

Wie kann ich als "DAU" das Problem mit dem Netrom von anbeginn vermeiden?

Ich habe mir, vor ein paar Jahren, erst ein paar Baycom-Modem besorgt und weil die nicht mit der Aktuellen PC-OS kompatibel sind habe ich mir noch zwei TNC besorgt.
mit diesen TNC (Stabo TNC2 /DK9SJ-TNC2S) und der PC-Software Paxon gehe ich "ON-Air".

Ist die Firmware auf den TNC die mögliche Ursache des Problem?

73 Karsten

[DMA284]

Hallo Karsten!

Das ist ganz einfach. RTFM! Ich glaube ich schreibe schon für nicht Techniker recht verständlich und wer Sysop sein will, hat sich nun mal mit der Materie auseinander zusetzen. Mich des Mimimi zu bezichtigen ist genau diese Einstellung von Sysops die hilfreiche Hinweise aufgrund von verletzen Stolz nicht annehmen. Es gibt keine DAU kompatible PR Netz Software. Nein ich habe mein Wissen auf nicht mit der Milchflasche als Kind verabreicht bekommen und es gab bei mir eine Menge Trail and Error. Aber dieses Wissen gebe ich gerne weiter, wenn es denn gewollt ist.

Du als reiner PR Anwender bis hier gar nicht angesprochen. Auch dein TNC hat damit nix zu tun. Es geht um Sysops die automatische Nodes mit Software wie BPQ, Xrouter, TNN und XNet betreiben und sich via Internet oder auch via Funk verbinden. NETROM ist ähnlich zum TCP/IP Protokoll im Internet. Arbeitet auf also auch auf dem OSI/ISO Schichten Layer 3 und 4. Und das Internet würde nicht so funktionieren wie es funktioniert, wenn nur Laien das Netzwerk betreiben würden wie es aber im CB-PR Netz nun mal häufig der Fall ist.

Auch du würdest es doch begrüßen, wenn du in einem Node wie z.B. LK0NOD mit "n" dir die Nodes Liste anzeigen lässt und dann mit c <call> deinen Wunsch Node auch connecten könntest. Weil dafür wurde NETROM in den 1980er Jahren entwickelt. Aber das ist in unserem Netz derzeit oft nicht gegeben. Ist doch blöde wenn das nicht funktioniert und viele Nodes zwar in der Liste stehen diese aber nicht erreichbar sind, weil sich im Netz Loops bilden durch schlechte Konfiguration der beteiligten Nodes oder weil manche Nodes so viele Links haben, das das Protokoll hier nicht mehr sinnvoll arbeiten kann. Weniger ist manchmal mehr.

Das erfordert aber Kommunikation zwischen den Node Sysops und klare Regeln. Netzplanung nennt sich das und wird so auch im Internet praktiziert. Wenn im Internet ein Provider aus der Reihe Tanzen und das restliche Internet stören würde, dann wären die recht schnell Offline. Weil die anderen Provider und Netze dieses disconnecten würden.

55 & 73 Marc-Andre

[Brummbär]

hi Marc-Andre.

ok, danke das es mich jetzt als Nur Nutzer nicht betrift.

aber auch ich habe das Interesse einen eigenen Node ggf. aufzusetzen, diesen vielleicht auch noch zusätzlich zu verlinken über TCP/IP damit ich auch einen Weiteren HF-AccesPoint zur Verfügung stellen kann.

aber!!! beim versuch BPQ auf meinem Linux zu installieren habe ich kein Fucking-Useable-Manual gefunden womit ich solch ein System zum laufen bekommen kann, und hier im Forum habe ich nur solche antworten bekommen wie "wir helfen dir ja, aber du musst schon von Anfang an alles alleine machen" da ist die aussage mit RTFM soviel aussagend wie das lesen eines Chiniesichen Handbuchs ohne aber die Sprache vorher gelernt zu haben!

Ich kann mir vorstellen das es da einige Sysops ähnliche Erfahrungen gemacht haben und dann haben die die dir verhaste Software gefunden, sie gestartet und es läut weil es vielleicht intuitiv einstellbar ist ohne das man 200MB an Webseiten durch stöbern muss um die richtigen Einstellungen zu finden.

um ein Einheitliches Netz zu bauen bedarf es der Aufklärung und vielleicht auch den Sprung über den eigenen schatten und eine Anleitung wie man ein System Sauber aufsetzt und auch von Anfang an die richtigen Einstellung vor einstellt. z.B durch eine fertige Beispiel *.conf, beim TCP/IP hat das auch nur so geklappt das es da "fertige Lösungen gab die einfach kopiert werden konnten, und da durch hat sich dieser Standard erst gebildet der jetzt als Regel gilt. hätte es das Copy&paste nicht gegeben würden wir vieleicht immer noch das ThinNet oder sogar noch das NetBios protokoll laufen haben über BNC oder ganz schlimm noch mit TokenRing.

nicht immer setzt sich das Bessere System durch, oft setzt sich das System durch welches einfacher und dadurch stärker verbreitet ist. schau dir die Videokassetten in den 80/90er an, das Video2000 System war dem VHS um Mailen in der Qualität voraus, aber da die Videotheken ausschließlich die Videos auf VHS ausgeliehen haben hat sich das viel schlechtere VHS-System durch gesetzt, nur weil es Mehr verbreitet war.

Stelle ein System zur Verfügung welches Einfach einzurichten geht, welches z.B. ich als DAU installiere ein paar Zeilen in der *.Conf anpasse und zack es läuft, dann hast du in relativ kurzer zeit ein Netzt welches genau den Anforderungen entspricht und über das Netzt, genauer die Community im Netzt, werden die Sysops die ein inkompatibles System Fahren selber einlenken und wechseln.

Der Mensch ist bestrebt mit möglichst wenig arbeit viel zu erreichen, so ist es auch Heute noch das viele PC-User gerne "Run&Forget" Software benutzen, denn da hat man keine Weitere Arbeit mit. auch in der Buissnes-IT ist es so das viele R&F (Run&Forget) tools eingesetzt werden.

wie ich bis jetzt Lese ist es bei PR leider so das wer ein Node zur Verfügung stellt regelmäßig, am besten Täglich, sein System überprüft und Anpassungen vornimmt.
was ich allerdings auch durch andere quellen festgesetllt habe, und PR gehört da auch ein bisschen zu, ist die Geschichte mit dem Mesh, das heißt loops ind ein eursche aus den Verbindngen der Masche

beispiel:
bei nur 5 Stationen die sich gegenseitig Lesen/Hören ergibt sich 10 Verbindungen.
erweitere ich die Masche um weiter fünf Stationen so das ich alles gegenseitig lesen können ergeben sich schon 45 Verbindungen.
(Metcalfesches Gesetz)

das dann die Verwaltung aller Verbindungen schwierig wird ist dann einleuchtend und genau das sollte eine gute Software übernehmen können, allerdings bleiben dann dennoch Fehler vorhanden was dann zu Loops führen kann.


also kurz gesagt wenn man mir eine einfache Software gibt die ein DAU schnell einrichten kann und den Anforderungen entspricht wird sich genau dieses System schnell durchsetzten und auch von den "alten" übernommen.

so viel dazu was meine Meinung darstellt, auch mein Ansicht kann falsch sein, denn auch ich bin ein Mensch der zum glück Fehler macht, mache ich keine Fehler wäre ich eine Maschine und würde nur das Tun wie ich programmiert wäre, die Fehler hätte dann der Programmierer gemacht nicht die Maschine


73 Karsten

[DQB906]

Die Netroms sauber aus dem Netz und Hf zu bekommen wird schwer. Da redet man gefühlt gegen Wände.
Viele Stationen laufen vor sich hin und man weiß nicht einmal wer überhaupt der SysOp ist, geschweige denn man sieht ihn online irgendwo noch auf HF.
Habe schon paar angeschrieben aber wegen allgemeinen Sachen, selbst hier sieht eine Rückmeldung dürftig aus.
Das Hobby packet Radio ist nicht mit ein paar Klicks getan, da hebe ich dir recht, es ist eine ständige Betreuung und Abänderung Anpassung usw im System.
Das LK0NOD ist seit Dezember 2024 online und seit dem werden pro Tag im Schnitt 60-90min geopfert um das System sauber zu halten und zu verbessern.
Manchmal schwer mit der Arbeit und dem privaten zu vereinbaren, aber auch das Hobby muss gepflegt werden.
Wenn ich alleine schauen wie oft Fassberg und ich uns austauschen um die Systeme sauber zu halten, grenzt schon an Wahnsinn und beklopptheit 🫣

Ein System welches man per Klick zum laufen bekommt, gibt es meines Wissens nur als paxon Variante, da es nicht viel kann aber dem User auf dem neuen System zumindest die ersten Eindrücke vermitteln kann.
Ein BBS oder Node System zu erstellen, bedarf viel lesen und experimentieren. Wie gesagt, BPQ wird seit 12.2024 stetig von mir verbessert optimiert und bin bei weitem noch nicht am Ziel, dass ich sage, so könnte es bleiben.
Aber genau hier ist ja der Kern des Ganzen vergraben. Das testen das Fehler suchen, Fehler finden und ausbessern.
Das Netzteil broadcast ist ein großer Teil, welche sich in jeder Software leider wie auch schon geschrieben wiedergibt und das leider fehlerhaft, da die Parameter hierfür wahrlos zusammen gewürfelt werden und es keine einheitliche Abgabe der Werte gibt.
Aber Marc, wir können gerne mal einen internen Testlauf vom System machen und schauen wie sich das ganze auf einer gesiegelten Version mit angepassten Parametern auf Dauer verhält und wie der Austausch der broadcast Daten und Wege dadurch stabil oder trotzdem abweichend im System sich hinterlegen.

[DMA284]

Hi Karsten!

Also ich hasse keine Software, man muss nur dessen Eigenheiten kennen und damit umgehen können, wie z.B. mit XNet. Gilt aber für jede Software. Die Intention der damaligen Programmierer der Software war an sich nicht schlecht. Im Grunde wollte man eine Schnittstelle zwischen NETROM und Flexnet haben. West Deutschland war nämlich was das angeht zwei geteilt. Im Süden war RMNC/Flexnet vorherrschend und im Norden TheNet Node, eine NETROM Software. Soweit der kurze Hintergrund. Die TheNet NETROM Leute haben aber auch schon lange festgestellt das ihr Routing Protokoll, basierend auf vom Sysop geschätzter Qualität von Verbindungen und der Mechanismus wie der Zustand des Netzes anderen Nodes mitgeteilt wird, schlecht ist.

Also wurde INP3 entwickelt, welches diese Probleme angeht. Ob XNet das nun nur übernommen hat oder direkt auch an der Entwicklung von INP3 beteiligt war, entzieht sich meiner Kenntnis. Fakt ist, beide konnten irgendwann INP3 und das war gut so. Während aber die TheNet Node Leute wohl von Anfang an wussten, das man INP3 und altes Qualitäts basiertes Routing nicht miteinander mischen konnte, hat XNet dafür einen Algorithmus geschaffen der zwischen beiden hin und her rechnet. Allerdings mit Nachteilen die wir heute im Node Netz sehen. Deswegen ist es so wichtig, das man als XNet Sysop darauf achtet, das man bei vorhandenen INP3 Links zu Nachbar Nodes nicht auch noch Links zu Node Nachbarn unterhält die nur altes auf Qualität basiertes NETROM Routing setzen.

Des weiteren wurde PR Software vornehmlich für Funk Links entwickelt. Das man die Möglichkeit geschaffen hat AX.25 Verbindungen auch via IP Protokoll über das Internet zu tunneln wie es heute im CB-PR Netz gang und gäbe ist, war nicht so gedacht. Denn auf einmal hatten Links wo INP3 oder auch Flexnet drauf läuft nicht mehr Laufzeiten von mehreren hunderten Millisekunden bis Sekunden sondern teilweise nur noch geringe zweistellige Millisekunden Laufzeiten. Wenn ich dann Nodes im Netz sehe die teilweise dutzende oder mehr AXIP Links haben, kann man sich schon vorstellen das INP3 an seine Grenzen stößt was das berechnen der Metriken betrifft. Du hast ja mit deinem Beispiel des Metcalfesches Gesetz den Hintergrund schon irgendwie verstanden. 

Zu deinen anderen Aussagen folgendes. Copy und Paste ist genau das Problem an der Geschichte. Ich lasse mir vom Nachbar Sysop seine Config geben, oder finde irgendeine AFU Config im Internet, passe maximal meine Calls an, die Software startet, ich füge ein paar Links zu anderen Nodes hinzu und voila, ich hab ne laufende Node Software. Du hast keine Ahnung was die Software macht, weil es dich nicht interessieren will und weil du nicht gewillt bisst die Grundlagen zu lernen bevor du so ein System aufsetzt. Ja ich habe auch durch Learning by Doing mir mein Wissen angeeignet. Das war damals aber noch im Funknetz und Fehler waren wenn dann nur lokal begrenzt. Im AXIP CB Node Netz haben wir aber das Problem das ein falsch konfigurierter Node das ganze Netz beeinträchtigt. 

Glaubst du das das Internet einfach so ohne Probleme vor sich hin läuft? Warum wohl haben alle Provider ein 24/7 besetztes NOC (Network Operation Center) am Start wo gut ausgebildete Experten sitzen die ständig den Daten Fluss in ihrem Netz und den Übergabepunkten zu anderen Netzen überwachen und es immer irgendwo was gibt wo die eingreifen müssen. Sprich da ist etwas mehr nötig als wenn du ne FritzBox bei dir zu hause anzuschließt, die entweder schon vom Provider fertig konfiguriert zu dir geliefert wird, oder die sich die Config vom Provider übers Netz holt. Stichwort TR-069 Protokoll. Ein Sysop eines Packet Nodes muss im Grunde das selbe leisten wie die Leute im NOC. Du bezahlst deinen Internet Provider dafür das er dir stabile Internet Konnektivität bereit stellt. Dafür sorgen im Hintergrund Menschen die das für dich im Blick haben. Als PR Node Sysop bist du verantwortlich für deine Station und das Netz an dem du teilnimmst.

Du willst verstehen wie das Internet funktioniert? Bitte, kannst dir nen Router mal von Grund auf bauen z.B. mit https://vyos.io/. Hier kannste dich dann mal mit Protokollen wie BGP, OSPF, RIP, RIPng, IS-IS, MPLS, LDP, policy-based routing und Multicast Routing beschäftigen. Bauen alle auf IP auf, genauso wie NETROM auf AX.25. Klar kein Mensch der nur Nutzer eines Netzes sein will muss sich damit auseinandersetzen. Wenn du Sysop eines Packet Nodes werden willst, musst du wohl anfangen dir die Grundlagen zu erarbeiten, so wie alle anderen mehr oder weniger vor dir auch. Bei konkreten Fragen wird dir sicherlich geholfen. Wenn einem aber schon Google die Lösung präsentieren könnte, wundere dich nicht das man dir mangelnde Eigeninitiative vorwirft.

Offtopic, bezüglich bestes Videosystem, das lag auch mit daran das die Erotik Industrie für ihre Filme auf VHS gesetzt hat.

55 & 73 Marc-Andre

[DMA284]

Hi!

Aber Marc, wir können gerne mal einen internen Testlauf vom System machen und schauen wie sich das ganze auf einer gesiegelten Version mit angepassten Parametern auf Dauer verhält und wie der Austausch der broadcast Daten und Wege dadurch stabil oder trotzdem abweichend im System sich hinterlegen.

Es ist meiner Meinung nach kein Problem das INP3 und Quality Broadcast NETROM parallel existieren. Solange die beiden Routing Domänen nicht durch nen XNet Konten zusammen gewürfelt werden. Das Ganze stelle ich mir so vor. Auf HF Seite macht man nur NODES Broadcasts mit fest definierten Parametern auf allen Nodes.

HF Port Quality 192 (entspricht 75% Zuverlässigkeit)
ObsInit = 6
ObsMin = 5
Brodcast alle 10 Minuten
MinQual = 63

Internet Port Quality 203 (entspricht 80% Zuverlässigkeit, NADA Empfehlung)

Auf Internet Links wird beides gemacht. INP3 und Quality Broadcast. Auf Funk wie gesagt nur Quality Broadcast NETROM.

Was bedeutet das? Auf nur Funk Nodes die per Quality NETROM angebunden werden sind auch nur diese Nodes in dieser Routing Domäne zu sehen, aber auch über Internet Links hinweg andere so angebundene Nodes.

Problem ist wie immer die Software. Während das meiner Meinung nach BPQ und Xrouter können ist bei TNN das nicht gegeben. Zu einem Nachbar kann TNN entweder altes NETROM oder INP3, aber nicht beides.

55 & 73 Marc-Andre