Re: PID $4C und $8C ?

ampr.protocols.ax25Zur Gruppenliste
Betreff: Re: PID $4C und $8C ?
Von: dg4fdi@dg4fdi.ampr.org (Thomas Thiers)
Gruppen: ampr.protocols.ax25, ampr.de.tcpip.config
Organisation: Amateur Radio
Datum: 07. Feb 2002, 01:31:42
thomas osterried wrote:

Wie sollten auch $4C und $08C auch anders behandelt werden, wenn sie der
Kernel (2.2.20 mit DK1KJD-AX.25 bei db0spp) nicht kennt. Verbindung trennen
ist m.E. das einzig Sinvolle um aus
einem undef. Protokoll hereuaszukommen.

das sehe ich nicht so.

eine ax25-connection kann gleichzeitig verschiedene protokolle
transportieren.
nur, weil ein einzelner layer hoeher (gerade) nicht verfuegbar ist, muss
die connection nicht beendet werden. stattdessen sollte das paket
stillschweigend verworfen werden. m.e. sieht das ISO/OSI auch so vor.
hoechstens koennte eine icmp-alike control-message gesendet werden - das
ax25 protokoll kennt sowas aber (leider) nicht.

[waere doch eigentlich toll, wenn der digi nicht mit "*** link failure
with db0aaa" auf PID_TEXT antwortet (was dann mit viel tricks bei ax25
s&f erkannt und geloescht werden muss), sondern diese message mit einer
anderen PID senden wuerde - aber das ist eine andere geschichte]

anderes beispiel: du faehrst netrom protocol mit deinem nachbarn. linux
kennt die PID.
jetzt sendet dieser ein PID_FLEXNET paket, um zu schauen ob du das auch
kannst. natuerlich willst jetzt nicht, dass das zum disconnect des ax25
layers fuehrt.

Jetzt leuchtet mir das ein. Mann kann ja mehrere, unterschiedlich Ebenen
oberhalb ein und dergelichen AX.25-Verbindung fahren. Ich hab schon lange
kein Wampes, der nur eine AX.25-Adresse fuer alle hoeheren Protokolle kennt,
mehr benutzt ;-)
Beim Linux-Kernel, den ich hier benutze, werden ueblicherweise fuer Net/Rom,
IP, AX.25 versch. AX.25-Adressen eingestellt.
 
beispiel wampes:
static void
handleit(
struct ax25_cb *axp,
int pid,
struct mbuf **bpp
){
        struct axlink *ipp;

        for(ipp = Axlink;ipp->funct != NULL;ipp++){
                if(ipp->pid == pid)
                        break;
        }
        if(ipp->funct != NULL)

(*ipp->funct)(axp->iface,axp,axp->hdr.dest,axp->hdr.source,bpp,0
);
        else
                free_p(bpp);
}

Das kann ich leider nicht durchschauen. Habe mich mit C nur so am Rande
befasst.
Zu meiner Uni-Zeit war Pascal noch ueblich.

mit WAMPES hatte ich uebrigens ein problem mit outgoing IP mode VC
connections an einen XNET.
der ax25 link sei down. wampes baut eine ax25 connection auf weil ein IP
paket fuer diesen ARP geroutet werden soll.
XNET sendet grundsaetzlich PID_TEXT CText's. wampes fuehrte daraufhin
seinerseits entweder einen unix login des xnet-Calls durch (wo sich xnet
und unix shell mit wachsender begeisterung ueber ihre fehlermeldungen
unterhielten), bzw. -wenn ax25-login disabled- disconnectete die
verbindung nach dem PID_TEXT CText (mit aehnlichen effekten wie oben
besprochen (jedes IP frame triggert einen neuen connect, jede
nicht-erwartete PID fuehrt zum disconnect des ax25-I layers)).

mit linux kernel 2.4.x habe ich dieses verhalten gegenueber XNET
ebenfalls beobachtet (noch jemand?). kernel 2.2.x habe ich im moment
nicht zur hand. kernel mit kjd-patch auch nicht. es waere interessant
das zu sammeln.
TNN sendet keinen PID=text CText bei bekannten IP mode VC ARPs.

Das Login-Problem mit Wampes und PID_TEXT hat mich seiner Zeit auch genervt.
Ich glaube, ich hatte fuer einige solcher db0-hosts den Login gesperrt oder
per lokalen profile die Eingaben nach /dev/null umgeleitet.

Bei Kernel 2.2.xx-kjd gibt es eine Schnittstelle ipax0. Die zugehoerige AX.25-
Adresse ist fuer IP. Den axspawn fuer den AX.25 Login sollte man auf eine
andere AX.25 Adresse legen. PID_Text ist hier kein Problem wie beim Wampes.
ipax0 ignoriert eingehende PID_Text-Pakete und sendet auch keine.

noch ein wort zu XNET.
durch zufall sah ich neulich, dass xnet einen gerade noch aktiven AX25
layer (wo IP mode VC daten flossen) aktiv trennte, weil die session seit
genau 1h offen war, mit der PID=Text Meldung "Idle-Timeout". xnet
reseted den ax25 t5 timer (idle-timeout) wohl nur bei ax25 PID=text
paketen :((
das fuehrt ggf. zum sterben der IP.TCP session auf der remote seite
(hinter xnet), wenn ich selbst keien daten zu senden habe (also
meinerseits die connection nicht neu aufbaue), denn xnet selbst baut
nicht aktiv die ax25-session zu stino-usern auf bei anstehenden IP mode
VC paketen fuer meinen ARP.

Ist mir auch aufgefallen. DL1GJI habe ich bereits auf der HAmRadio Juni 2001
und auch
nochmal in Weinheim nahegelegt, das Behandeln von solchen temp. Benutzern dem
von
Wampes oder Linux-ax25 anzupassen, so das Verbindung auch reversibel sind und
Xnet
auch eine AX.25- Verbindung zu einen Bneutzer ueber einen oder mehreren Digis
aufbauen
kann.

Mode datagramm kann man als Benutzer via Digi zu einen Xnet-Knoten vergessen.
Das muss der Sysop dort fest eintragen. Wie es mit festeinzutragenden Routen
und ARP-
Eintraegen bestellt ist, sieht man bei TNN. Ich habe schon einige TNN-Sysops
im Norden
gebeten, doch mal die Regionen hier (41,52) einzutragen, damit es auch mal mit
Hamburg
klappt. Aber das kriegt leider keiner auf die Reihe.

DL1GJI meinte, dass es kein Problem gaebe, gelernte ARP-Eintrage laenger als
3600s und auch
AX.25 Pfade fuer Ziele, die in keiner Routing-Tabele stehen, in einem TNC3
oder TNC4
zu speichern. Ich finde die 3600s Lebensauer fuer AX.25-ARP-Eintraege recht
duerftig.

Jedoch ist er der Meinung, das es keine Problem gaebe, wenn alle Xnet und INP3
benutzen
wuerden. M.E. Wunschdenken und an der Realitaet vorbei. Ich stelle vorerst
keinen
teuren TNC4 an den Digi. Und wenn, dann sollte der Entwickler auch auf
Bug-Reporte
reagieren und praktikable Loesungen anstreben.

Bei INP3 wuerden Routen (32bit und Netzrouten) und APRs zw. Xnet-Hosts
ausgetauscht.
So ist auch der AX.25-Linkabbrauch zw. direkten AX.25 Nachbarn (Benutzer <>
Digi) kein
Problem. Bei direkt gehoerten Rufzeichen sendet Xnet sehr wohl ein SABM den
Benutzer.

Allerdings koennen Netzrouten fuer Benutzer, die mal den Digi wechseln oder
unterwegs
sind, den IP-Zugang verwehren, wenn man gerade nicht in die passende Netzmaske
faellt.
Ein Benutzer, der portableweise in IP qrv ist und seine koordinierte IP-Nummer
benutzt,
wird hier pech haben.
DL1GJI meint, dass man vom Xnet-Digi per GETIP bezogene, temp. IP-Nummern
benutzen sollte.
Wenn man nur CLients auf dem Rechner hat, kann man das tun, aber bei Servern,
die staendig
unter wechselden IP-Nummern berieben werden, stelle ich mir einige probleme
vor.

Ich habe Linuxnet auch mal ne Weile als IP_Router und AX.25-Switch hier
verwendet.
Das waren noch Versionen, die AX.25-Pfade nicht reversibel wiedergeben haben.
Mittlerweile ist zumidest dies gefixt.
Aber die Flaschenhals-MTU mit fehlender ICMP-Fehlermeldung bei zu grossen MSS
gibt es
bei Xnet 1.30 und 1.31 immer noch. Ganz zu schweigen bei der og. fehlenden
Reversibiltaet
bei IP-Verbindungen.

Notfalls muss die Endstelle (mit Linux-IP-Stack) die Schnittstellen MTU oder
bei den Routen
die MSS manuell so einstellen, dass ein Xnet-Router die Pakete weiterleiten
kann.

Bei Flexnet32, was sehr haeufig auf der Benutzerseite zu finden ist, geht das
aber nicht.
Diese benutzen bei TCP eine feste MSS von 1460.

 
73,
        - thomas
 
 73 de Thomas - Mannheim - JN49GM
 BBS : DG4FDI@DB0AIS.#HES.DEU.EU
 SMTP: dg4fdi@db0spp.ampr.org

/ack

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.