häufige Echolink connects/disconnects einschränken

    Hallo Adi,

    gibt es eine Möglichkeit die häufigen Echolink-Connects die meistens direkt mit einem Disconnect enden ein wenig einzuschränken ?

    Ich habe da bereits schon selber ein wenig mit fail2ban (http://www.fail2ban.org) versucht aber das ist entweder das falsche Tool dafür oder mir fehlt der richtige "Trigger"

    Es sollte von der funktion her so sein, das eingehende Echolink-Verbindungen gezählt werden wenn diese unter einer einstellbaren zeit wieder getrennt werden.
    Falls jemand dann öfter als z.B. 5x connectet und trennt wird dises Rufzeichen dann für eine einstellbare Zeit in die "REJECT_INCOMING=" Liste geworfen.

    Vielleicht kann man soetwas ja leicht dierekt in svxlink einbauen.

    Moin,

    das ist im Moment noch nicht eingebaut. Ich halte diese Erweiterung aber auch fuer sehr sinnvoll. Dieses staendige Connecten ohne wenigstens mal "Test von ..." zu sagen ist schon ziemlich nervig.
    Es ist sicher nicht sooo schwer das einzubauen, man muesste eben eine dynamische Liste vorhalten mit der Zuodnung "Call"-"Anzahl Connects" und wenn diese Zahl ueberschritten ist, dann kann sich die Startion eben fuer xx Minuten/Stunden nicht mehr verbinden.
    Externe Tools wueder ich dafuer nicht verwenden, das geht denke ich recht gut SvxLink-intern zu machen.
    Momentan habe ich noch einiges mit meinem Linking zu basteln, mal schauen wie ich das einschiebe.

    vy 73s de Adi, DL1HRC

    Hallo Mathias,

    also das mit dem Zurückschreiben in die ModuleEchoLink.conf wird so einfach nix werden. Diese Einschränkungen wie ich sie gerade teste gelten nur zur Laufzeit von SvxLink. Ich hoffe Du kannst damit leben? Ich habe mal einen neuen Parameter eingeführt (ModuleEchoLink.conf):
    CHECK_NR_CONNECTS=3,3600
    bedeutet es sind je Station nur 3 Connects pro 60 Minuten (3600 Sekunden) erlaubt, ansonsten wird die Verbindung für >3600 Sekunden ignoriert.
    Ist das so wie Du das gerne hättest oder soll ich weiterbasteln? Willst Du dem gegenüber dann noch mitteilen, dass Dein Repeater keine Verbindungen von ihm entgegennimmt oder soll er das einfach ignorieren? Ich probiere das mal hier auf DB0WSF, wenn es so funktioniert wie ich mir das vorstelle schicke ich Dir mal was zu, ok?

    Alternativ hast Du für harte Fälle noch die "DROP_INCOMING"-Abteilung in der ModuleEchoLink.conf :D

    73's de Adi, DL1HRC

    Hallo Adi,

    es ist schonmal schön, das du da doch schon so schnell etwas probierst.

    Nun ist es aber so, das unser SvxLink täglich um 0:05Uhr per Cronjob einmal neugestartet wird (0:05Uhr damit die Zeitansage um 0Uhr nicht unterbrochen wird) damit würde ja dann täglich die "Datenbank" der gesperrten Rufzeichen zurückgesetzt was natürlich nicht sein soll.

    Wäre es denn möglich die Daten in eine seperate neue Datei zu schreiben die dann sozusagen als "Datenbank" arbeitet ?
    Mir geht es hierbei hauptsächlich darum das nach einem Neustart die vorhandenen Rufzeichen/Timestamps wieder eingelesen und bei Bedarf auch geändert werden können (falls kuzfristig mal Jemand wieder herausgenommen werden muss).

    //'Vision Anfang'
    Hmm, hierbei kommt mir gerade die Vision, das SvxLnk in Zukunft einmal auf eine SQL-Datenbank zurückgreifen kann und einige Parameter auch zur Laufzeit geändert werden können (was dann das ständige Config ändern und neustarten beseitigt).
    //'Vision Ende'

    Es wäre noch perfekt wenn SvxLink erkennen könnte (notfalls per Zeit-Parameter wie bei IDENT_NAG_MIN_TIME) ob jemand der per Echolink verbindet auch etwas sagt, denn wenn nur die Connects gezählt werden kann es auch einmal die falsche Person erwischen, z.B. Erkennungs-Zeit auf 12Std. und max. 3 Versuche dann hats Jemand mit UMTS unter Umständen schon schwehr falls mal die Verbindung abbricht o.Ä.

    Falls dann jemand abgelehnt wird soll diesem natürlich auch gesagt werden warum, hierfür wäre eine neue Audio-Datei bereits vorhanden. Man könnte natürlich auch die alte "reject_connection.wav" benutzen aber so kann man noch die Info übergeben das derjenige erstmal nur "temporär" gesperrt ist.

    So, dann wünsche ich noch frohe (rest-)Ostern

    Quote


    Nun ist es aber so, das unser SvxLink täglich um 0:05Uhr per Cronjob einmal neugestartet wird (0:05Uhr damit die Zeitansage um 0Uhr nicht unterbrochen wird) damit würde ja dann täglich die "Datenbank" der gesperrten Rufzeichen zurückgesetzt was natürlich nicht sein soll.

    Warum? Was soll das bewirken?

    73's de Adi, DL1HRC

    Hmm das ist im Prinzip so ne Art Vorsorge damit da nix hängen bleibt und alles frisch läuft.

    Weiss auch nicht ich habe das damals mal eingebaut weil ab und zu nach 24 - 48Std. mal die Sprache so am stocken war und nach nem Neustart war wieder alles normal. Da wir sowiso häufiger am Tag mal Neustarten weil wieder irgendwelche Parameter in den Configs geändert werden, hab ich das einfach so belassen.

    Das ist definitiv keine gute Idee! Wenn irgendwo was stockt oder Probleme macht, dann sollte man sich erst einmal darum kümmern. Der tägliche Neustart einer Applikation sollte nur das allerletzte Mittel sein wenn gar nicht anderes mehr geht und nur für einen extrem begrenzten Zeitraum. Was ist wenn um 0:05 gerade ein QSO geführt wird? Ich denke da sollten wir erst einmal ansetzen, bevor man gut funktionierende Programme verbiegt um Probleme zu umgehen.

    Habt ihr mal die Prozessor- und Netzwerkauslastung über einen gewissen Zeitraum beobachtet? Tonedetektoren (CTCSS, ZVEI, 1750, DTMF...) und Squelchdetektoren benötigen CPU-Leistung, habt ihr nur die aktiviert, die Ihr auch braucht? Welche Version läuft bei Euch (trunk, binary)? Welche CPU steht zur Verfügung? RAM, ...usw.
    Ich habe hier SvxLink-Laufzeiten von 100 Tagen ohne das was "hängenbleibt", was manchmal Probleme macht sind z.B. mal exterme USB-2-Seriell-Wandler.

    73's de Adi

    Also wenn gerade um 0:05Uhr ein QSO geführt wird dann weis eigendlich mittlerweile Jeder bescheid (Einmal 1750Hz und es geht weiter), aber du hast natürlich schon Recht.
    Ich meine die Probleme hatten wir damals auch nur mit der "new_audio_pipe", denke das brauchen wir also soweit nicht weiterverfolgen.
    Aber eine durchgehende Laufzeit von 100Tagen bekommen wir sicherlich auch so schon nicht hin,
    da ja pro Woche min. 1-2mal die Config geändert wird (und wenn es nur Änderungen an DROP_INCOMING sind) muss anschliessend ja auch SvxLink neu gestartet werden.

    Also damit du auch mal ein paar Daten hast:
    SvxLink trunk 2169
    Rechner: Boser HS-7250
    CPU: Intel Pentium(M) 600MHz
    CPU-Auslastung: < 20%
    Speicher: 512MB DDR-I
    Speicherauslastung: < 25%
    Es stehen 2 Serielle Ports zur verfügung (keine USB-Seriell)
    Wichtige Dienste die noch laufen: Webmin / SSHD

    73, de do6ep

    Moin moin,

    Deine Hardware sollte ausreichend sein. Das new_audio_pipe von Steve ist noch ein bischen in der Entwicklung, es kann schon sein, dass es unter bestimmten Bedingungen mal zu Problemen kommen kann. Der aktuelle Trunk geht aber ganz gut.
    Ich probiere hier mal noch ein bischen mit der Config, momentan machen die Stationen, die 4x pro Sekunde einen Connect anfordern Probleme, da muss ich mir mal was einfallen lassen obwohl ich das eigentlich auf einen Bug im herkömmlichen EchoLink schieben würde.

    Bis denne

    73's de Adi, DL1HRC

    Moin moin,

    so, wollte mal anfragen ob Ihr bereit seid als Versuchskanninchen herzuhalten? Habe das mal für ein paar Tage hier auf DB0WSF-R laufen lassen aber leider ist nur einer in die Falle getappt ;)
    Ich würde mal ein Päckchen machen mit 'ner Kurzanleitung und Dir zukommen lassen, ok?

    Die Konfiguration erfolgt über den (neuen) Parameter

    Quote

    CHECK_NR_CONNECTS=3,3600,60


    was für o.g. Beispiel bedeutet 3 Versuche in 3600 Sekunden sind erlaubt, sonst Sperrung für 60 Minuten wobei die Sperrzeit immer auf den letzten Connectversuch addiert wird. Der nächste Versuch innerhalb der Sperrzeit wird mit dem Hinweis "rejected" quittiert.
    Soweit erst mal was zum Spielen und Testen. Wenn Ihr das 'ne Weile betrieben habt können wir ja über Verbesserungen reden, ok?

    vy 73's de Adi, DL1HRC

    Hallo Adi,

    habe das nun am laufen auch mit deinem letzten Update, soweit funktioniert alles.
    Wenn ich das richtig gesehen habe ist chk_drop_time unter 60min nicht möglich ? Nur mal so als Frage.

    Werde nach ein paar Tagen nochmal die Erfahrungen berichten.

    73, de do6ep

    Quote

    Wenn ich das richtig gesehen habe ist chk_drop_time unter 60min nicht möglich ?

    jo, hatte ich mal so mit reingenommen und war eher als Sicherheitseinstellung gedacht, falls jemand in der Konfigurations Unsinn einträgt (-1 z.B.), ist aber kein Problem das zu ändern. Sag einfach was Du als kleinsten Wert haben willst wobei weniger als 10Minuten sicher keine erzieherische Maßnahme darstellen ;)

    73's de Adi, DL1HRC