OpenBCM V1.07b11 (WIN32)

Packet Radio Mailbox

DBO595

[LAU JN59RM]

 Login: GAST





  

DMA284 > PRNET    31.10.23 13:00l 74 Lines 3097 Bytes #1 (0) @ DEU
BID : 18400-MD2BBS
Read: GAST DAE595
Subj: Re:Kaputtes Nodes Netz - XNet Probleme
Path: DBO595<DBX320<MD2BBS
Sent: 231030/1843Z @:MD2BBS.#SAW.SAA.DEU.EU #:18400 [Salzwedel] $:18400-MD2BBS
From: DMA284@MD2BBS.#SAW.SAA.DEU.EU
To  : PRNET@DEU

Moin!

Mir sind noch weitere schlechte Eigenschaften aufgefallen die man zweifellos
auf Unwissenheit bei den verantwortlichen Node Sysops zurück führen kann.
Einige Sysops betreiben BPQ oder Linux Nodes ohne INP3. Sprich die NETROM
Routing Informationen werden nur als Broadcast via NODES verbreitet. Hier
sind wie Quality Einstellungen des Ports zu nennen. Manche Sysop geben dem
AXUDP/AXIP Port die Quality 255. Das ist falsch! Quality 255 sollte, wenn
überhaupt nur lokalen Dienste gegeben werden die auf dem selben System wie
der Node laufen. Sprich der Mailbox oder dem Convers. Schon Systeme die im
eigenen LAN verortet sind können nicht 255 mehr sein, weil sie mindestens
ein Hop weit weg sind.

Vor allem aber sollten sich alle beteiligen Sysops auf einen einheitlichen
Standard einigen. Ich weiß das war und ist schon immer schwierig gewesen in
PR gemeinsame Linien zu finden. Aber versuchen kann man es ja trotzdem
nochmal.

Schon zu frühen Zeiten im AFU haben sich Sysops dazu Gedanken gemacht.
Herausgekommen ist dieses Dokument:

https://packet-radio.net/netrom-tutorial-n2nov/

Dieses sollten alle Sysops von Systemen die reines NETROM Broadcast machen
umsetzen. Damit die Systeme einheitlich laufen und die Routen transparent
nachzuvollziehen sind.

Kurz das Dokument zusammengefasst:

Port Quality auf dedizierten Funklinks mit nur zwei Stationen und AXIP/AXUDP
Links: 203

Nodes Broadcast 900 Sekunden.

Initial Obsolescence Counter: 5
Minimum Obsolescence Counter: 3

Mit diesen Werten kann man gut arbeiten, denke ich. Wenn sie denn umgesetzt
werden.

Hinweisen möchte ich das dieses System durch XNet Nodes leider verfälscht
wird. Denn XNet vermischt die beiden Routing Domänen, Broadcast mit Quality
und INP3 mit gemessenen Laufzeiten.

Deswegen meine Forderung, wie in BID: 18208-MD2BBS nachzulesen, das man XNet
Nodes aus dem Netz verbannt.

Eventuell muss man das, nachdem ich mich mit XNet etwas auseinander gesetzt
habe, gar nicht tun.

Es reicht aus Nodes Broadcasts zu deaktivieren. Leider funktionieren Dinge
wie Initial Obsolescence Counter kleiner zu setzen wie Minimum Obsolescence
Counter nicht. Ebenso funktioniert es nicht MinQual auf 255 zu setzen um nur
den eigenen XNet Node weiter zu melden.

Leider hat XNet die Routen an die Broadcast Funktion gekoppelt. Wer also
XNet so betreiben will, kann selber keine Routen festlegen, sondern ist
darauf angewiesen das andere Nodes Routen zu ihm setzen und die Verbindung
herstellen. Zwei XNets können so aber keine Verbindung mehr aufbauen, weil
keine von beiden Nodes Broadcasts senden würden.

Deswegen bleibe ich bei meiner Meinung. XNet gehört auf den Müll geworfen.
Mit BPQ und Xrouter ist noch aktuell entwickelte Software im Umlauf, welche
alle Bedürfnisse eines jeden Nodes Sysops befriedigen. TNN kann auch noch
verwendet werden. Allerdings sollte man aufpassen, in 64 Bit für Linux
kompiliert gibt es Probleme mit Zählern. Lieber nur auf 32 Bit kompilieren
und die entsprechenden Abhängigkeiten beim 64 Bit Linux nach installieren.

55 & 73
Marc-Andre


Lese vorherige Mail | Lese naechste Mail


 27.04.2024 18:17:54lZurueck Nach oben