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: 12. Feb 2002, 21:37:20
Tschuldigung fuer die etwas verspaetete Antwort.

thomas osterried wrote:

Thomas Thiers wrote:

[...]

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 :(

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.
Bei dem vorletzten DG1KJD-AX25-Patch war es so, das UDP generell als DG
verschickt
wurde. Beim Letzten ist das nicht mehr so.
Vermutlich deshalb, weil die Xnets nicht antworten konnten.
Bei Flexnet32 war es aehnlich. Da gibts jetzt einen Schalter dafuer.
Ich ziehe jedenfalls VC vor.
 
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).

Ich habe hier noch einen Alias gesetzt.
alias ***="exit"
 
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.

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.
Ich wuesste nicht, was Wampes helfen koennte.
Allerdings kann der Wampes auch NETROM-ARPs lernen. Brauchen wir aber nicht.
 
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.
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.

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.

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.

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?

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..


Aus der Doku:

IP-Autorouting mit INP3
INP3 kann pro Knotencall nicht nur den Alias melden, sondern ist auch in der
Lage beliebige weitere Information
über den Knoten (Node Options) weiterzuleiten. Eine dieser Knotenoptionen ist
das IP-Subnetz des Knotens. Mit
dem Befehl Subnet wird das Subnetz für den (X)NET-Digi festgelegt. Diese
Information wird über INP3 an alle
anderen Knoten automatisch weitergeleitet. Wenn nun irgendein Knoten im Netz
eine IP-Adresse für dieses
Subnetz empfängt, kann er das Paket an den entsprechenden Knoten automatisch,
d.h. ohne weitere
Konfiguration weiterleiten. Natürlich muß der Zielknoten nun soweit
konfiguriert sein, daß er alle eintreffenden
IP-Pakete für sein Subnetz auch zustellen kann. D.h. der IP-Router sollte für
die IP-Nummern des Subnetzes
auch entsprechende Routing (IPROUTE) und ARP Einträge (falls erforderlich)
haben. Mit Hilfe des N <call> -
Befehls kann das über INP3 gemeldete Subnetz abgefragt werden.

Zitat Ende.

Eigentlich muessen die fixen Routen/ARP-Eintraege nur so gesetzt sein, dass
sie nicht
nicht den Subnetz-Routen aus INP3 kollidieren.
 
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.

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.


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.