Re: PID $4C und $8C ?

ampr.protocols.ax25Zur Gruppenliste
Betreff: Re: PID $4C und $8C ?
Von: dl9sau@db0tud.ampr.org (thomas osterried)
Gruppen: ampr.protocols.ax25, ampr.de.tcpip.config
Organisation: amateur radio
Datum: 19. Feb 2002, 11:26:58
Tschuldigung fuer die etwas verspaetete Antwort.

meine zeit war auch zu knapp..

Wozu soll denn der DG-Zugang gut sein ? Ausser fuer eilige DNS-Anfragen
per UDP, waherend einer FTP-Uebertragung um die TCP-Sendeschlange zu
uebergehen,
sehe ich keinen grossen Nutzen darin.

direkt am einstieg vom digi, und ohne packetloss (gute timer settings,
kein aloah, wenig user) macht DG einen besseren durchsatz bei weniger
overhead.

Bei dem vorletzten DG1KJD-AX25-Patch war es so, das UDP generell als DG
verschickt
wurde. Beim Letzten ist das nicht mehr so.

das ist eine TOS basierte entscheidung. kann man so machen, ja,
funktioniert aber nur dann wenn beide seiten so verfahren. sonst ist der
client permanent am ARP umtragen..

Ich ziehe jedenfalls VC vor.

sobald der link ueber mehrere digi's geht, oder ax25 user->digi->user
bevorzuge ich auch VC.
hast du einen digi direkt vor der haustuer und ueberlaesst ihm das
routing, dann spricht nichts gegen DG (unter der packetloss
voraussetzung, s. oben).

und was richtig aetzte war, dass wenn ein link zusammengebrochen war
(*** link faulure with.."),
loeste dies ebenfalls einen login aus -> shell hat spass mit nem digi,
bzw. user wird eingelogged wegen der fehlermeldung und fliegt gleich
wieder raus (abbau des ax25 links).

Ich habe hier noch einen Alias gesetzt.
alias ***="exit"
jepp.
alias '***'='exec true'
(exit echo't das exit, und triggert vielleicht noch unnoetig auf der
remote seite den login ;)

die ganz hartnaeckigen probleme hatten wir vor dem patch gebannt mit
exec echo "*** NO MODE VC via DB0TUD-11" in der .profile..

Hier gibts solche Problme nicht. DB0SPP-10 ist fuer IP, vorzugweise VC/VJ.
DG wird allerdings mit VC beantwortet. Der ax25rtd scheint den Mode nicht
richtig
zu erkennen. DB0SPP-11 ist axspawn.

ax25rtd: lutz hatte bei db0zwi beim erkennen von modeVC und lernen von
IP routen auch probleme, wir nicht. ich vermute das liegt irgendwo in
den verwendeten ax25tools/utils.

wenn ihr modeDG requests mit modeVC beantwortet, fuehrt das wieder zur
eingangsfrage: bestimmt senden viele user einen CText. den verwerft ihr,
wenn ich das richtig verstanden habe und trennt nicht einfach den link.

der vollstaendigkeit halber habe ich das jetzt nochmal mit db0tud kernel
2.2.19 getestet:
wenn auf einem ax25 der fuer VC aufgebaut wurde aktiv von db0tud zu mir,
und ich einen CText sende, dann werden meine PID=text pakete bei db0tud
verworfen. sie werden unter diesen umstaenden dort vom kernel nicht and
den ax25d weitergereicht.
damit macht xnet's CText vermutlich keine probleme mit kernel 2.2.x
usern.

Ich wuesste nicht, was Wampes helfen koennte.
Allerdings kann der Wampes auch NETROM-ARPs lernen. Brauchen wir aber nicht.

nichts. ich hatte nur unsere config beschrieben.
 
zu speichern. Ich finde die 3600s Lebensauer fuer AX.25-ARP-Eintraege recht
duerftig.

doch das geht. wenn denn der timer resettet wird wenn daten (jegweder
protokolle) fliessen. dann wuerde im zweifelsfalle auch ein ping alle
30min genuegen, um die verbindung zu halten.
So habe ich das auch schon gemacht.
Aber wenn ein db0-Host mal einen Benutzer-Host sucht, taugen 3600s nichts.
Oder wenn der Sysop vergessen hat, einen db0-Zielhost nicht fest eingetragen
hat. Die Routen/Arp-Tabellen sind meist nicht auf der Hoehe der Zeit.

ja, leider.

Das Weiterleiten von einem Subnetz ist auch Xnet implemntiert. Ein Knoten kann
fuer sich nur ein Subnetz in Anspruch nehmen.
Ob INP3 mehrere Subnetze pro Node-Eintrag zulaesst, weiss ich im Stehgreif
nicht,
aber das ist ja gut dokumentiert.

ich habe mich mal auf dahingehend konfigurierte tnn's umgeschaut.
das routing geschieht innerhalb des netrom netzes auf L3 (netrom.ip),
und in z.B. richtung flexnet statisch eingetragen als L2 (via digi),
d.h. wenn von via netrom empfangen an diesem punkt umgesetzt.


Ich vermute mal das Erste. Xnet und wohl auch TNN Subnet-IP routen ueber
Net/Rom-Node-Adressen direkt wischen den beiden beteiligten IP-Nodes ueber
deren Net/Rom-Schnittstellen. Der AX.25
Das ist auch besser so, da INP3-Nodes immer den besten Node-Pfad nutzen, wenn
man vom Netrom-Wasserkopf einmal absieht.
IP-Gatewaying von Nodes auf einem Pfad ist nicht noetig.
Das erfordert auch nicht, dass solche Zwischenknoten etwas von IP verstehen
muessen..

ack. allerdings bereitet das probleme bei zu grosser MTU (> 216), und
fehlenden icmp messages.

Eigentlich waere das auf der Xnet-Seite einfach zu loesen, wenn sie sich
AX.25-L2-Pfade
merken wuerde. Das habe ich DL1GJI auch schon vorgeschlagen.

ack

73,
- thomas

Datum Thema#  Autor
30.01. * PID $4C und $8C ?8Thomas Thiers
31.01. `* Re: PID $4C und $8C ?7thomas osterried
01.02.  `* Re: PID $4C und $8C ?6Thomas Thiers
05.02.   `* Re: PID $4C und $8C ?5thomas osterried
07.02.    `* Re: PID $4C und $8C ?4Thomas Thiers
07.02.     `* Re: PID $4C und $8C ?3thomas osterried
12.02.      `* Re: PID $4C und $8C ?2Thomas Thiers
19.02.       `- Re: PID $4C und $8C ?1thomas osterried

"News-Portal" auf dem HAM-Web-Servfer DB0ERF.