In letzter Zeit gab es häufiger Problemberichte von Usern, welche sich per HAMNET mit dem EchoLink-Netzwerk verbinden wollten. Hier
http://svxlink.de/download/Workaround.pdf
ist eine Anleitung von Jann/DG8NGN zu finden, mit der man diese Probleme umgehen kann.
Hallo Adi,
eine kleine Berichtigung: Das Problem haben wohl die User, welche sich über das Internet via Proxyserver mit dem EchoLink-Netzwerk verbinden. Falls sie dann zufällig einen Proxyserver mit HAMNET-Adresse (die IP beginnt mit einer 44) erwischt haben, sind manche Zielsysteme nicht erreichbar. Hier handelt es sich dann um die Repeater/Links, welche sowohl über eine Internet- als auch über eine HAMNET-Anbindung verfügen.
Der Workaround von Jann ganz kurz zusammengefasst: Internet-User sollten Proxyserver mit HAMNET-Adresse (44.x.x.x) vermeiden. Dann klappt's auch mit dem EchoLink ;-).
Schönen Gruß
Frank, DL3DCW
Vielen Dank für die Hinweise und sorry, hatte mich mit dem Problem bisher gar nicht beschäftigt.
Aber nur mal für mein Verständnis: War nicht eigentlich ursprünglich angedacht HAMNET und Internet vollständig zu trennen, jetzt mal abgesehen von eventuellen VPN-Verbindungen zwischen HAMNET-Inseln?
vy 73's de Adi
Hallo Adi,
ja, das war/ist wohl auch der ursprüngliche Gedanke. Hier in DL und auch in vielen anderen Ländern wird das genau so gehandhabt: Das HAMNET ist ein Intranet für Funkamateure, es gibt keinen direkten Zugang vom Internet aus und auch kein Routing der HAMNET-Adressen im Internet. Das HAMNET soll zudem möglichst weitgehend ein reines Funknetz sein.
In manchen Ländern sieht man das jedoch etwas anders und benutzt die HAMNET-IP-Adressen auch im Internet (für Amateurfunkzwecke). Begründet wird dies u.a. damit, dass die öffentlichen IPv4-Adressen recht knapp sind und daher alternativ ja prima auch die 44er-Adressen benutzt werden können. Das ist erst einmal nicht besonders schlimm, macht in der der Regel keine Probleme und man kann es niemanden verbieten. Aber in manchen Fällen - so wie z.B. bei bestimmten EchoLink-Proxyservern - ist es leider nicht immer sinnvoll ...
Schönen Gruß
Frank, DL3DCW
Hallo Frank,
vielen Dank für die Info. Was mir nur auffällt, dass IP's im Bereich 44.137.75.240ff sehr häufig innerhalb kürzester Zeit (neu) vergeben und diese Änderungen aber von den Nodes nur jede 10Minuten neu abgefragt werden bzw. beim Connectversuch. Nur kann da die Zuondung IP<->Call schon wieder eine andere sein. Ich weiß nicht so recht, ob das nicht zu Problemen führen kann. Wahrscheinlich ist das auch eines der Probleme, oder?
73s de Adi
Hallo Adi,
genau das ist der IP-Bereich (44.137.75.x) des Servers, bei dem die ganze Geschichte erst aufgefallen ist (PI9NOZ). Im Bereich 44.137.75.1-44.137.75.200 werden wohl Echolink-Proxyserver und im Bereich 44.137.75.240-44.137.75.249 EchoLink-Relayserver betrieben.
Die von Dir beobachteten Umstände der schnellen Wechsel in der Zuordnung IP<->Call müssten eigentlich aber bei allen Proxy-/Relayservern bestehen. Denn das passiert ja immer, wenn ein User die Verbindung zum Server trennt und ein neuer User sofort wieder zum gleichen Server eine Verbindung aufbaut. Dann ist die IP unverändert, nur das Call hat sich geändert ...
Schönen Gruß
Frank, DL3DCW
Hi Frank,
ich verstehe es aber trotzdem noch nicht so ganz. Habe gerade den SvxLink-Quelltext vor mir:
Angenommen: Eingehende Verbindung von Call=DL1ABC mit IP=1.2.3.4
Wenn sich diese Station außerhalb des eigenen Subnets befindet werden die Daten vom Verzeichnisdienst in diesem Moment neu abgerufen, also genau diese Zuodnung Call<->Ip-Adresse. Das geht jetzt nur noch schief, wenn die connectende Station inzwischen eine andere IP bekommen hat und diese nicht sofort im Verzeichnis registriert wurde. Dann erfolgt die Ausgabe:
"*** WARNING: Ignoring incoming connection from DL1ABC since the IP address registered in the directory server 1.2.3.4 is not the same as the remote IP ?.?.?.? of the incoming connection"
Wo ich noch nicht weiter weiß warum der Connect ohne Fehlermeldung abgebrochen wird. Das kann dann eigentlich nur die Ursache haben, dass die connectende Station nicht (mehr) im EchoLink-Verzeichnis geführt wird. Denn bei jedem Versuch werden alle Daten von SvxLink neu geladen, über die Funktion getDirectoryList(). Diesen Fall hatte ich gestern mal beim Basteln.
vy 73's de Adi
Hallo Adi,
die von Dir beschriebene Fehlermeldung habe ich auch schon öfter's gesehen. Auch hier im Forum habe ja einige OM's in der Vergangenheit ebenfalls davon berichtet. Das scheint aber vermutlich erst einmal unabhängig von den oben beschriebenen Problem mit den HAMNET-Adressen zu sein. Vielleicht hat der Proxyserver das neue Call ja noch nicht schnell genug an den Verzeichnisserver gemeldet?
Leider kenne ich mich mit EchoLink auch nur sehr oberflächlich aus. Wenn es jedoch immer nur oder besonders häufig bei den oben beschrieben IP-Adressen auffällt: PI9NOZ benutzt nicht den "originalen" EchoLink-Proxyserver sondern eine selbstgeschriebene Software ...
Schönen Gruß
Frank, DL3DCW
Hallo,SVXer
Habe folgende Beobachtung gemacht: Besagte fehlerhafte Connects treten auf,wenn jemand versucht,über ein Smartphone
unser DB0CSD zu connecten. Der Handy-Nutzer arbeitet ohne Proxy-Einstellungen.
Irgendwo wird dann die Absender-IP umgerubelt in eine Absenderadresse der bekannten Proxyfarm.
(Vermutung: Vieleicht sind auch Provider mitbeteiligt, die missliebigen VOIP-Verkehr dann umleiten?)
Oder leiten die Registrierserver den Smartphone-Verkehr über die Proxyfarm?
Kommt jemand von seinem PC aus,ist stets alles in Ordnung.
Grundlage: DB0CSD hängt am Hamnetknoten Chemnitz, SVXlink ist eingestellt als Proxyclient,arbeitet auf einen
Echolinkproxyserver (ebenfalls Hamnetadresse) dieser Proxyserver geht bei mir auf einen Router,der die Trennung nach aussen Richtung Internet macht. Abgehender Verkehr,Registrierungsanforderung,Sprache,Daten verlassen meine Fritzbox nur mit Adressen meines lokalen Netzwerks und der über Dyndns zugeteilten Adresse.
Auch in der Gegenrichtung taucht beim Trace der FB nirgend ein Hinweis auf 44-ziger Adressen auf.
Beim Connectversuch mit einem Smartphone tauchen Pakete auf,die als Zieladresse zwar die normale lokale Adresse meines Routers haben,jedoch als Absender eine 44.137.75.xxx haben.
Ist die Quelle des Verkehrs ein PC oder anderes SVX oder Echolinkrelais, sind beim Trace an der FB keine Hinweise
generell auf 44-ziger Adressen vorhanden und es funktioniert alles.
73 von DL1JAC,Jürgen
Hallo Jürgen,
der Handy-Nutzer hat vielleicht nicht bewusst einen Proxy eingestellt, es wird aber vermutlich automatisch ein Proxy- bzw. Relay-Server benutzt (z.B. wenn "Auto" angewählt ist, siehe unten). Und wenn es sich dann zufällig um den besagten PI9NOZ-Server handelt, tritt das Problem auf. Darauf lässt die von Dir angegebene IP-Adresse schließen ...
Schönen Gruß
Frank, DL3DCW
Hallo zusammen,
ursächlich für die beschriebenen Probleme ist ja die Verwendung von HAMNET-IP-Adressen (44.0.0.0/8) auch im Internet. Sobald ein EchoLink-Proxyserver über eine 44er-IP-Adresse via Internet erreichbar ist, kann häufig eine Verbindung zu Stationen, die sowohl über eine Internet als auch ein HAMNET-Anbindung verfügen, nicht mehr hergestellt werden.
Grund: Bei den HAMNET-Stationen wird das komplette Netz 44.0.0.0/8 standardmäßig über die Antenne geroutet. Nur der "Rest" geht über das Internet. Dies sieht auf dem Router am HAMNET-Standort dann ungefähr so aus:
Das Ganze macht keine Probleme, solange die beteiligten 44er-Stationen alle über die Antenne erreichbar sind. Für bestimmte Zwecke macht jedoch das Routing einzelner Netze aus dem 44er-Bereich auch im Internet Sinn. Und dann funktioniert diese Lösung leider nicht mehr.
Auf der HAMNET-Tagung in Aachen hat Jann, DG8NGN nun einen möglichen Lösungsvorschlag vorgestellt (Script siehe hier). Demnach soll ein kleiner Teil des 44er-Netzes (nämlich 44.240.0.0/12) abgesplittet und zur Verwendung für bestimmte Dienste im Internet vorgesehen werden.
Auf dem Router am HAMNET-Standort sehen die erforderlichen Einträge dann in etwa so aus:
0.0.0.0/0 -> via Internet (default route)
44.0.0.0/9 -> via Antenne
44.128.0.0/10 -> via Antenne
44.192.0.0/11 -> via Antenne
44.224.0.0/12 -> via Antenne
Der Lösungsansatz wurde bereits mit dem "Besitzer" des 44er-Netz (Brian Kantor, WB6CYT) besprochen. Jetzt müssen eigentlich nur noch die Betreiber der betroffenen Dienste (wie z.B. bestimmte EchoLink-Proxyserver) informiert und von einem "QSY" auf 44.240.0.0/12 überzeugt werden. Wenn diese Lösung von allen akzeptiert/umgesetzt wird steht einem problemlosen Miteinander nichts mehr im Weg ...
Schönen Gruß
Frank, DL3DCW