Connect nicht immer möglich?

    Hallo zusammen,

    ganz meiner Meinung. Ich gehe immer noch von einem Konfigurationsfehler am EchoLink-Proxy aus.
    Das Problem müsste m.E. an allen Relais-Standorten auftauchen (wie bei mir), wo eine Anbindung an das HamNet realisiert ist.
    Das ist unabhängig von den EchoLink Nutzern und deren eingesetzter Technik, die bekommen halt einfach keinen Connect. Wenn das EL-Proxy-Cluster via HamNet nicht erreichbar ist
    (kann ja vorkommen, ist halt HamNet und kein Hochverfügbarkeitsnetz), ist das Chaos perfekt.
    Nochmal zur Konkretisierung: Die Connects von den Adressen 44.137.75.x kommen bei mir via Internetanbindung rein, nicht über das HamNet!

    Nachtrag: Ich habe mal die statische Hilfsroute entfernt und die Anbindung an das HamNet nun mit gutem Durchsatz via Tunnel realisiert, funktioniert auch alles nicht.
    Problem hierbei ist, das TCP SYN und TCP ACK beim EchoLink-Proxy über 2 verschiedene Wege reinkommen und dann wahrscheinlich ein Filter (Firewall, Paketfilter) der Verbindung den
    Garaus macht-es fängt dann an zu flappen und es wird alles noch schlimmer. Es bleibt wirklich nur die statische Route zum Proxy-Cluster via Internet als Lösung über. :(

    73 de Michael
    DL5OCD

    Edited 3 times, last by dl5ocd (February 23, 2015 at 6:48 PM).

    Hallo zusammen,

    ich habe gerade mit Jann, DG8NGN (AMPR IP Koordination DL) telefoniert. Er hat das Problem bestätigt. Es lässt sich derzeit wohl nur durch den Eintrag einer festen Route der "Problem"-Netze von PI9NOZ ins Internet lösen. Also genauso so, wie das Michael weiter oben beschrieben hat.

    Hauptursache ist wohl, dass die 44er-Netze von PI9NOZ auch im Internet geroutet und für die Echolink-Proxyserver benutzt werden. Daher melden sich die Proxys auch mit einer 44er-Adresse. Es ist also kein Fehler von SvxLink oder dessen Konfiguration.

    Jann steht mit Rob u.a. auch wegen der beschriebenen Problematik in Kontakt. Es besteht darüber hinaus weiterer Koordinierungsbedarf, damit solche Probleme in Zukunft vermieden werden. Da es in verschiedenen Regionen bzw. Ländern aber unterschiedliche Sichtweisen bezüglich der Verwendung des 44.0.0.0/8 Netz gibt, ist das nicht ganz einfach.

    Bei den zukünftigen Koordinierungsgesprächen bzw. der Erarbeitung eines möglichst übergreifenden Konzeptes soll angestrebt werden, das 44.0.0.0/8 Netz aus Sicht des Anwenders möglichst nur über die Antenne und nicht über das Internet zu routen.

    Schönen Gruß
    Frank, DL3DCW

    Hi alle,

    vielen Dank für die Klärung der Ursache. Ich hatte in den letzten Wochen keinen richtigen Nerv auf Bugsuche, sri. Und ob ich das durch Analyse des Svx-Quellcodes gefunden hätte wäre eher fraglich gewesen. Danke an alle, weiter so!

    vy 73's de Adi, DL1HRC

    Hallo zusammen,

    bei einem Test vorhin habe ich mit meinem Smartphone mein Echolinkgateway connected. Beim Beobachten des laufenden Logs kam auch eine 44.137.XX.XX zustande.

    Mir kam dabei so ein Gedanke. Wenn ich bei meinem Smartphone in die Einstellungen blicke, dann gibt es bei den

    Settings ->Network Connection >Choose Network Options

    u. a. den Auswahlpunkt "Relay"

    Nur mal so ein Gedanke. Der Autor der App wird sich ja was dabei gedacht haben. Möglicherweise dient diese Einstellung "Relay" auch dazu, einen bestimmten Knoten bzw. Relay zu connecten, der den Nutzer dann weiterreicht. In der Einstellung braucht man sich um Proxy`s oder direkte Verbindungen keine Sorge zu machen. Das geht nämlich fast immer.

    Aber vielleicht ist das die Spur zum ungewünschten Routing übers HAMNET. Reine Therorie, Kanns weder beweisen noch habe ich Grundlagen dazu.

    @Adi: Nach langem Suchen, Du hattest Recht. Meine Variante den SSH-Port zu verriegeln mit IP-Tabels hat den wirklich doofen Nachteil, dass jeder, der eine IP hat, welche in dieser Tabelle steht, erst gar kein Login bekommt, respektive alle Ports werden abgeriegelt. Das gilt dann auch für eingehende Verbindungen über Echolink.
    Letztlich erklärt es damit auch, dass ein Connect von ein und demselben OM manchmal durchgeht und manchmal eben nicht, was ja auch das Eingangsthema war. Heute hat er diese IP (gesperrt) morgen jene(frei).
    Es erklärt auch, warum Du damals vom QRL keinen Zugang hattest, jedoch von zuhause aus.