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: 07. Feb 2002, 10:50:16
Thomas Thiers wrote:
thomas osterried wrote:

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.

ja das kann man so machen.
wampes macht bei uns derzeit nur noch ax25 und IP routing bzw axip zum
pcflexnet und damit die anbindung des rechners an den digi.
wampes ist db0tud-10, hat keine eigene IP adresse mehr und ist fuer ax25
mode VC connects zustaendig (mit optionaler VJ tcp header-compression).
unix ax25d -> axspawn -> login ist db0tud-11 und macht mode DG.
dennoch, es hat eine lange zeit gedauert bis sich das rumgesprochen hat,
und z.B. db0nos-10 connectet uns immernoch nach db0tud-11 fuer IP mode
VC :(

das zieht ein paar probleme nach sich, die ich kurz beschreiben moechte:
die route fuer db0nos mit ARP db0nos-10 mode-VC hat der linux kernel
jetzt kennen gelernt.
frueher sendeten wir noch den login. das loeste bei der gegenseite einen
login aus.
bei manchen systemen hatten dann die shells gegenseitig viel spass.
bei db0nos kommt "login: " - der nach 60s in einen timeout rennt. d.h.
der ax25 layer steht max. 60s zur verfuegung, um IP pakete
auszutauschen.
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).

das nervte. deshalb habe ich den ax25d dahingehend gepatcht, dass bei
hosts die faelschlicherweise als ax25 mode VC hosts kennengelernt
wurden, kein ax25 login mehr durchgefuehrt wird. ax25d forkt zwar noch,
aber nur um den socket offen zu halten (damit der ax25 layer stehen
bleibt) und discarded incoming pid=Text pakete. damit hatten wir ruhe,
und db0nos ist auch gluecklich (auch wenn er nicht in den genuss von VJ
kommt). ach ja, wenn "*** ..." (ueblicherweise link failure messages)
kommen, trennen wir die verbindung aktiv (spart zeit).
das wird konfiguriert ueber ax25d.conf:
parameters_extAX25 VC-wait-login VC-disc-on-linkfailure-msg
VC-log-connections V
C-debug


den ax25 unix login von axspawn durchfuehren zu lassen anstelle von
WAMPES hat auch weitere vorteile. beispielsweise kann unser axspawn
"//COMP". das wissen unsere convers user zu schaetzen.

        for(ipp = Axlink;ipp->funct != NULL;ipp++){
                if(ipp->pid == pid)
                        break;
        }
wampes geht alle bekannten transport layer durch.

        if(ipp->funct != NULL)
(*ipp->funct)(axp->iface,axp,axp->hdr.dest,axp->hdr.source,bpp,0
);
ein passender gefunden?

        else
                free_p(bpp);
ansonsten verwerfe das paket


mit WAMPES hatte ich uebrigens ein problem mit outgoing IP mode VC
connections an einen XNET.
[..]
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.

hatten wir frueher auch.
 
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.

klappt, wenn alle link-partner das blicken. s.o.: die meisten user die
IP machen wollen connecten db0tud-11 fuer VC.
 
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.

ack.

Mode datagramm kann man als Benutzer via Digi zu einen Xnet-Knoten vergessen.
Das muss der Sysop dort fest eintragen.

ach deshalb ist mir das nicht gelungen ;)

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.
ungeschickt ist eben, dass wenn der ax25-link disconnected ist und daten
kommen, der link zum user nicht neu aufgebaut wird. der arp ist dem xnet
ja noch bekannt. aber vielleicht hat er angst vor den user-CText's nach
seinem SABM ;)

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.

das mit dem INP3 ist interessant. ich hatte auch mal in den TNN sourcen
geschaut. nette idee. dass vor jeder haustuere ein xnet oder tnn steht
ist jedoch illusorisch (und m.e. auch nicht noetig). interessant waere,
wenn linux kernel-ax25 und WAMPES die inp-daten der nachbarn pollen
koennten. aber wenn ich den source richtig verstanden habe, wird die
INP3 information in ein erweitertes flag des NODES broadcasts gepackt
(hmm, nachdenk' - laesst sich damit nur ein subnet announcen?). da jetzt
vor unserer wampe flexnet protokoll gesprochen wird, waere jetzt
spannend, wie man an diese routing-informationen herankommt ohne sich
als netrom anzumelden, und wie man selbst seine eigenen routen dort
einfuettern kann.

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.

moment. nochmal genau zum konzept von inp3:
ist der sinn, fuer ein subnet einen ARP zu vermitteln, damit ein xnet
einen ax25-layer direkt zum ziel-ARP aufbauen kann, oder nutzt er die
routing-info um das IP an seinen nachbarn weiterzurouten von dem er per
INP3 das subnet gelernt hat?

bei direkt-connects ueber mehrere l2 oder l3 digipeater zum ziel haette
ein xnet aehnliche probleme wie ich: hat die gegenseite seinen ARP nicht
per INP gelernt, wird die gegenseite den ax25 nicht neu aufbauen
koennen.

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.