Sometimes a destination is available through INP3- and flexrouting. Example: DB0FHN ↔ DB0VOX ↔ DB0FOR ↔ DB0RHN ↔ DB0SIF. If a user now wants to connect from DB0FHN to DB0SIF via IGATE (“c db0sif igate” @DB0FHN), he will be routed through INP3. Wanted path is DB0FHN ↔ IGATE ↔ DB0SIF. Suggestion: Always use Flexrouting for Connectpath if “via-hop” is given on connect request.

TNC4 or DLC7 have Ethernetports. If you start the IP-router of (X)Net (start routed) and set the defaultroute to IGATE, all broadcastframes of the local LAN will be routed to IGATE and further. ARP-Table of IGATE:

Suggestion: Extending “start ether” with subnetmask to be able to detect such frames.

Example: start ether 192.168.42.100/24

After interconnection of the 44-network with the internet, we have to care about abuse through non-hamradio amateurs. By default access to telnet/ftp and other services should be only possible with password outside the network 44.0.0.0/8.

Currently routes learned through INP3 have lowest priority. IP-routes learned by INP3 should be added and deleted from “IPR”- and “ARP”-list. Such routes should be marked special if a user calls “ipr” or “arp”. There should be an option to switch of this feature due to abuse…

• Linuxsnet auf der BETA-Homepage verlinken

Der Link http://www.swiss-artg.ch/xnet/beta/zip/linuxsnet.zip ist zwar verfuegbar, aber noch nicht auf der BETA-Homepage eingepflegt.

• OpenWRT-user haben meist kein “unzip” fuer ein Update zur Hand. Ein “wrtxnet” ungezippt waere wesentlich einfacher fuer die Nutzer.

Ich habe das Changelog auf der Xnet-Beta-Seite mit der Dokumentation verglichen. Dabei ist mir folgendes aufgefallen:

• 1.31 Beta 17.04.01

NetROM- Broadcast- Einträge sind jetzt auch mit fester Qualität machbar. In diesem Fall werden keine L3RTT- Messungen mehr durchgeführt. Syntax: ro bc add <port> <call> [<viacall>] [- <Quality>]. Beispiel: ro bc add 2 db0xyz - 224

Habe ich in “xnet138.pdf” auf Seite 35/36 gesucht, aber nicht gefunden

• 1.35 Beta 14.02.03

Die maximale Grösse der MTUs bei AX.25 und SLIP sind nun bis 32 KB einstellbar (Neuer Befehl: ifc <interface> mtu <nn>). Der ARP-Timeout (auch für learning ARP) kann bis auf 40 Tage (57600 Minuten) hochgesetzt werden (Neuer Befehl: ifc <interface> arptout <nn>). Die Angabe erfolgt in Minuten. “Learnig ARP” lernt jetzt auch via-Calls (AX.25 Pfade) Segmentierte AX.25-Frames (mit PID 08) können nun auch gesendet werden. Die SLIP-Implementierung in der Turbo-Firmware 1.88 untersützt nun auch segmentierte Frames - so dass bei TCP/IP die MTU im Windows-Rechner nicht mehr heruntergesetzt werden muss.

Der Befehl IFC ist in “tcpip.pdf” nicht dokumentiert

• 1.37 Beta 27.02.04

Das Link-Reset Forwarding Feature macht im Zusammenhang mit Linux Probleme. Es ist deshalb nun abschaltbar (Befehlsfolge: pa tnc dislres 1). Es besteht die Vermutung, dass hier der Linux AX.25-Stack nicht korrekt arbeitet! Es wäre interessant zu wissen ob jemand ähnliche Erfahrungen gemacht hat?

“pa tnc dislres 1” nicht in “xnet138.pdf” gefunden

• 1.37 Beta 01.03.04

Die Linux-Version beinhaltet (zusätzlich) neue AX.25 Kernel Device Treiber “nax25” für neuere Kernel AX.25-Versionen bei denen kein zusätzliches Header-Byte vor den Daten-Frames mehr vorangestellt ist. Diese Treiber werden mit attach ax0 nax25 x 1 dev “attached”.

“nax25” nicht als Treiber in “xnet138.pdf” gelistet

• 5.1.15 RSTATD

Dies genügt um alle erforderlichen Statistikdaten an den Sammler (hier 44.130.55.100) zu versenden. Wichtig: Da UDP/IP verwendet wird, muß der (X)NET-IP-Router natuerlich aktiv sein. Aus diesem Grund sollte der automatische Start von rstatd auch in der Datei “IP.NET” eingetragen werden.

Ein Hinweis, dass “tcpd” auch noch gestartet werden muss wäre nicht schlecht. Ich hab sehr lange gebraucht, bis ich das verstanden habe. Änderung wäre in xnet138.pdf, postat.zip (postat.txt) und cgistat.zip (postat.zip) nötig.

Eingehende UI-Frames sollten nach den gleichen Regeln wie SABM-Frames gerouted werden. Also zum Beispiel die “lokalen Linkeinträge” beachten. Interessant wäre auch bei Paketen mit Zahl als letzten VIA-Hop auf dem Port <zahl> auszugeben.

DG3THX hat bereits Support fuer locals im TO-field eingebaut. Es fehlt noch UI-Routing fuer locals im VIA-field. Hierzu ein bisschen Trace:

IGATEB 0-15 ←flexlink→ DB0FHN 0-15.
IGATEB hat einen lokalen Link nach IGATEB-5.
User DG8NGN-0 schickt ein UI-Paket nach IGATEB-5 via DB0FHN (ist also auf einem Userport von FHN):
<T DG8NGN>IGATEB-5 v DB0FHN UIv> Testpaket

Und hier aus Sicht des lokalen Linkpartners IGATEB-5:
<R DG8NGN>IGATEB-5 v DB0FHN IGATEB* UIv>
Testpaket

Schicke ich jetzt ein Paket nach HALLO via DB0FHN, IGATEB-5:
<T DG8NGN>HALLO v DB0FHN IGATEB-5 UIv>
Testpaket2

So war die Frage, wie das Paket aus Sicht des lokalen Linkpartners IGATEB-5 aussehen muss:
1. Variante:
<R DG8NGN>HALLO v DB0FHN IGATEB* UIv>
Testpaket2

2. Variante:
<R DG8NGN>HALLO v DB0FHN IGATEB-5* UIv>
Testpaket2

3. Variante:
<R DG8NGN>HALLO v DB0FHN IGATEB* IGATEB-5 UIv>
Testpaket2

Also ich meine Variante 3 ist logisch. Der Stern ist das digipeated flag (bei diesem Trace immer nur beim letzten Knoten, der digipeated hat). Im Moment wird das Paket einfach auf den eingehenden Port mit IGATEB-5* digipeated wieder ausgegeben (also wie Variante 2, nur auf dem Port, wo das Paket eingegangen ist).

Man muss halt hoellisch auf die Seiteneffekte aufpassen. Also sich vielleicht das ganze nochmal durchueberlegen, wenn IGATEB nur die SSID-Range 0-4 und den lokalen Link IGATEB 5-5 eingetragen hat. Eine andere Variante zum testen ist meiner Meinung nach IGATE 0-15 und einen lokalen Link nach TEST.

Also das gleiche wie oben:
User DG8NGN-0 schickt ein UI-Paket nach TEST via DB0FHN, IGATEB (ist also auf einem Userport von FHN):
<T DG8NGN>TEST v DB0FHN IGATEB UIv>
Testpaket
(ich musste den via-Hop IGATEB mit eingeben, da IGATEB keine Destinations an DB0FHN weiterreicht. Sollte aber unrelevant fuer das Ergebnis des Tests sein).

Und hier aus Sicht des lokalen Linkpartners IGATEB-5:
<R DG8NGN>TEST v DB0FHN IGATEB* UIv>
Testpaket

Schicke ich jetzt ein Paket nach HALLO via DB0FHN, IGATEB, TEST:
<T DG8NGN>HALLO v DB0FHN IGATEB TEST UIv>
Testpaket2

<R DG8NGN>HALLO v DB0FHN IGATEB* TEST UIv>
Testpaket2

Das entspricht also auch Variante 3, wenn man sich das TEST als IGATEB-5 denkt und IGATEB mit SSID 0-4 laufen wuerde. Uebrigens habe ich das gleiche mal mit SABM+ durchgespielt. Da gibt es auch noch Unterschiede, wenn jemand einen lokalen Link in der eigenen SSID-Range betreibt und VIA connecten moechte, aber das ist jetzt erstmal unrelevant. Ich denke oben die Variante 3 einzubauen sollte ziemlich sicher ohne Seiteneffekte gelingen.

IGATE currently supports only flexrouting. We like to introduce INP3/NETROM. We need the linkparameter ”>” as implemented for flexroutingprotocol for INP3/NETROM. It should accept nodes and iproutes but only export IGATE with iproute 44/8 or 0/0 to linkpartners.

Aus der Usersicht würde ich es mir so vorstellen:
Aufruf des Befehls ARP:
DG8NGN de DB0FHN>arp

Weiter habe ich mir das noch nicht angeschaut. Du meintest man braucht einfach nur ein weiteres Modul. RFC-Nummer für IPIP ist 1853: http://rfc.net/rfc1853.html. Wampes spricht auch IPIP. Das müsste die src/ipip.c sein.

Tun ist das Analogon zu Slip und Tap zu Ethernet. Dateien sind: src/tun.c und src/ethertap.c http://x-berg.in-berlin.de/cgi-bin/viewcvs.cgi/ampr/wampes-import/ → Download Tarball

Auf dem Ethertapdevice kann man prinzipiell alle Ethernetprotokolle sprechen, so ist es möglichgleichzeitig über ein Device IP und AX25 (bpqether) mit dem Linuxkernel zu sprechen.

Gedankenspiel “Pfad bei VIA-Linkpartnern”

Als Beispiel: DB0VOX hat den Linkpartner DB0AMB via DB0AMB-4. Logisch wäre, wenn DB0AMB jetzt mit DB0VOX nur Linkprotokoll spricht, wenn der Connect via DB0AMB-4 reinkommt. Setzt nämlich DB0VOX den Link nach DB0AMB z.B. via DB0AMB-7, wird der Link zwar durch das SABM+ von DB0AMB nach DB0VOX aufgebaut, aber abgehende Connects von DB0VOX in Richtung DB0AMB würden weiterhin via DB0AMB-7 (also falsch) abgesetzt werden. Wenn jetzt viele Destinations von DB0AMB announced werden, sind diese alle nicht erreichbar. Daher die Idee den Flexlink-Connect nur zuzulassen, wenn der Connectpfad synkron ist.

Leider ist der Connectpfad eben nicht immer synkron. PC/Flexnet macht SSID-Routing. Läuft auf DB0AMB-4 ein Minidigi und auf Port 0 sind DB0AMB bzw. Port 1 DB0VOX erreichbar, so muss DB0VOX nach DB0AMB via DB0AMB-4 und DB0AMB nach DB0VOX via DB0AMB-5 connecten. Somit scheidet die Prüfung auf einen synkronen Pfad aus. Man könnte allerdings den Connectpfad auswerten und Aufbauversuche über den gelernten VIA-Pfad schicken. Aus DB0VOX-Sicht kommen die Pakete von DB0AMB ja via DB0AMB-4 (also kann ich Connects über den Pfad via DB0AMB-4 routen). Aus DB0AMB-Sicht kommen die Pakete von DB0VOX via DB0AMB-5 und Connectversuche können darüber geleitet werden…

Vielleicht wäre einfach ein Eintrag in XNET.LOG zum Hinweisen des Sysops auf das Problem eine “Lösung”.

Das Interface mit kleinerer TTL gewinnt:

Ipdump:

rx1: AX25 DB0HP-10 DB0SIP-6
IP : 44.130.49.6→44.130.42.3 frag=0 D. ttl=64 TOS=0 id=60028 len=52
TCP : 2460→14575 seqno=366213725 ackno=2705646497 win=31680 flags=….A.
0000 01 01 08 0A 13 D8 A2 16 02 96 01 22 ………..”

tx: AX25 DB0LJ
IP : 44.130.49.6→44.130.42.3 frag=0 D. ttl=63 TOS=0 id=60028 len=52
TCP : 2460→14575 seqno=366213725 ackno=2705646497 win=31680 flags=….A.
0000 01 01 08 0A 13 D8 A2 16 02 96 01 22 ………..”

rx2: AX25 DB0LJ
IP : 44.130.42.3→44.130.49.6 frag=0 D. ttl=63 TOS=0 id=49826 len=149
TCP : 14575→2460 seqno=2705646614 ackno=366213725 win=53280 flags=…PA.
0000 01 01 08 0A 02 96 02 5C 13 D8 A2 16 44 42 30 48 …….\….DB0H
0010 52 43 2D 31 3E 41 50 4E 44 31 30 2C 57 49 44 45 RC-1>APND10,WIDE
0020 2C 71 41 43 2C 44 42 30 48 52 43 3A 3D 35 31 31 ,qAC,DB0HRC:=511
0030 35 2E 33 32 4E 2F 30 31 32 30 33 2E 37 35 45 23 5.32N/01203.75E#
0040 50 48 47 32 32 31 30 20 64 69 67 69 5F 6E 65 64 PHG2210 digi_ned
0050 2B 65 61 70 72 73 5F 30 2E 31 31 2B 6F 70 65 6E +eaprs_0.11+open
0060 57 52 54 20 28 4C 69 6E 75 78 29 0D 0A WRT (Linux)..

tx: AX25DG DB0HP-10 DB0TRI-9 DB0GH
IP : 44.130.42.3→44.130.49.6 frag=0 D. ttl=62 TOS=0 id=49826 len=149
TCP : 14575→2460 seqno=2705646614 ackno=366213725 win=53280 flags=…PA.
0000 01 01 08 0A 02 96 02 5C 13 D8 A2 16 44 42 30 48 …….\….DB0H
0010 52 43 2D 31 3E 41 50 4E 44 31 30 2C 57 49 44 45 RC-1>APND10,WIDE
0020 2C 71 41 43 2C 44 42 30 48 52 43 3A 3D 35 31 31 ,qAC,DB0HRC:=511
0030 35 2E 33 32 4E 2F 30 31 32 30 33 2E 37 35 45 23 5.32N/01203.75E#
0040 50 48 47 32 32 31 30 20 64 69 67 69 5F 6E 65 64 PHG2210 digi_ned
0050 2B 65 61 70 72 73 5F 30 2E 31 31 2B 6F 70 65 6E +eaprs_0.11+open
0060 57 52 54 20 28 4C 69 6E 75 78 29 0D 0A WRT (Linux)..

Das letzte Frame wird in AX25DG geschickt… Ob man bei “0” eine Ausnahme machen sollte?

Designproblem: fehlende PID (MTU-Problem) → Protokolländerung.

IP via AX.25 nicht INP3 zum next-hop weitervermitteln.

myip <IP>
subnet <Subnetz mit eigener IP>
dhcp/getIP <Adressraum aus dem Subnetz (ohne bereits vergebenen adressen)>
dg8ngn-10 –> dg8ngn-10.ampr.org
Auf Server mit “dg8ngn.ampr.org” gemapped.

Links:

• http://de.wikipedia.org/wiki/AXFR
• http://de.wikipedia.org/wiki/IXFR (http://www.ietf.org/rfc/rfc1995.txt)
• http://de.wikipedia.org/wiki/Dynamisches_Update (http://www.ietf.org/rfc/rfc2136.txt)
• http://groups.google.com/group/fa.linux.hams/browse_thread/thread/46f149ee1d34ceb6/2bb317d415f1624d?lnk=st&q=dhcp+ax25&rnum=1&hl=de#2bb317d415f1624d

• Eintragen von IP-Routen

Ich suche gerade eine sinnvolle Anwendung, dass man beim Setzen von IP-Routen das Interface mit angeben muss, aber ich komme einfach nicht darauf. Vielleicht hast du eine Idee. Ich denke für die Pflege des Systems wäre es besser, wenn IP-Routen nur mit <Netz> <Gateway> ohne Interface gesetzt werden. Das hatte mich früher immer etwas verwirrt, da das Gatewayinterface bereits über ARP festgelegt ist. Ich schätze allerdings, dass das etwas tiefer im Code eingebaut ist. Vielleicht hast du ja auch eine gute Idee, wozu man das Interface bei IPR braucht.

• TCP/IP-Betrieb mit anderer SSID?

Könnte man den TCP/IP-Betrieb auf eine andere SSID legen? Nach unseren Traceergebnissen schaut Xnet beim IP-Routing erst durch die “sap 2”-Tabelle und wenn eine Verbindung zwischen Destination- und Sourcecall besteht bzw. aufgebaut wird, dann wird das zu routende Paket dort in die Queue gesetzt. Da haben wir zwei Probleme.

Erstes Beispiel:
IGATE und DB0SAO sind direkte Linkpartner. Fällt der Link zwischen den beiden aus, so wird IGATE und DB0SAO sehr oft den Linkpartner mit SABM+ rufen. In dieser Zeit ist der TCP/IP-Betrieb über die über das Flexnetnetz bekannte Alternativroute nicht möglich. Der Flexnetrouter kommt auch völlig durcheinander wenn der Linkpartner plötzlich über das Flexnetnetz connected. Er begrüßt mit dem Linkprotocoll…

Zweites Beispiel:
DB0HST hat zwei Flexnetlinks nach IGATE stehen. Einmal zum primary IGATE ohne Laufzeiterhöhung und einmal zum secondary IGATE mit Laufzeiterhöhung. IP-Pakete werden nun an das falsche IGATE gerouted, wenn der Connect zum secondary IGATE in der “sap 2”-Liste vor dem Connect zum primary IGATE auftaucht. Ich denke auch dort könnte man zu einer Lösung kommen, wenn man IP mit der SSID -10 macht. Ein weiterer Vorteil ist natürlich das Einsparen des Connecttextes…

• Verwaltung von IP-Routing

Wir haben uns eben nochmal Gedanken zum gewünschten Verhalten des IP-Routers gemacht und in “tcpip.pdf” geschaut. Du schreibst:

IPROUTE definiert, an welche IP-Adresse über welches Interface
geroutet wird. Die IP-Adresse als Zielangabe reicht nicht aus, denn
IP-Pakete können von (X)NET auf verschiedene Arten weitergesendet
werden: Über AX.25 mit PID CC, über NetROM oder als SLIP-Paket.
Deshalb erfolgt ein IPROUTE-Eintrag mit der Angabe eines Interfaces.

Warum reicht nicht einfach die IP-Adresse als Zielangabe für ein Netz aus (insbesondere dann, wenn für das Netz eine GatewayIP-Adresse definiert wurde, für die ein ARP vorhanden ist)? Jede IP-Adresse ist über den ARP mit der Hardwareadresse + Interface verknüpft. Das sollte für das Routing ausreichen. Problematisch ist dieses Verhalten nämlich, wenn der Sysop 44/8 via AX25 routed und ein Ping-Paket mit Source-IP aus 44/8 via NETROM ankommt. Der IP-Router will das Paket zurückrouten, aber versucht es über AX25 wo er keinen passenden ARP-Eintrag findet.

Auffällig war auch das Schaubild über den Weg eines IP-Paketes durch den Xnetrouter. Wenn kein Eintrag der IPROUTE-Tabelle matched, routest du trotzdem über den ARP-Eintrag das Paket.

Unser Vorschlag zum Abhandeln des Routing schaut folgendermaßen aus: Es gibt eine ARP-Tabelle in der Form “IP, Iface, Hardware”. Außerdem gibt es eine IPR-Tabelle in der Form “IP-Net+Mask, via IP”.

Bei der Routingentscheidung sollte zuerst die ARP-Tabelle nach einem Treffer untersucht werden. Ist dies der Fall, so kann das Paket sofort gerouted werden.

Erst bei negativem Ergebnis sollte zur IPR-Tabelle gesprungen werden und dort nach einem Treffer gesucht werden. Ist dort ein zutreffender Eintrag vorhanden, so kann anhand der “via IP” und einem Lookup in der ARP-Tabelle das Paket an das Ziel transportiert werden. Ist es nicht der Fall, so wird das Paket verworfen bzw. könnte noch eine über INP3-Vermittelte Route matchen.

Sysops haben die Möglichkeit IPR-Routen und ARP-Einträge statisch z.B. über die “IP.NET” zu setzen. Diese Einträge expire'n nicht. Hier wäre es noch schön, wenn ARP-Einträge erstellt werden können, die ebenfalls nicht expire'n, aber die Hardwareadresse umgelernt werden kann.