SvxServer bugfix

    Hi alle,

    so, ich habe nun den Fehler im SvxServer (Absturz wenn ein Client keine Netzwerkverbindung hatte) gefunden und behoben.
    Bitte alle Nutzer des Servers ins svxlink-Source-Verzeichnis wechseln und ausführen:

    git checkout svxserver
    git pull
    cd src/build
    sudo make install

    Es beibt noch ein kleines Problemchen, dass eine erstmalige Authentifizierung ab und an fehlschlägt aber daran arbeite ist.

    vy 73s de Adi, DL1HRC

    Hallo Adi,

    vielen Dank für Deine Bemühungen! Ist es möglich, das SvxServer bugfix auf einem System zu installieren, auf dem es das SvxLink-Source-Verzeichnis nicht (mehr) gibt? Wenn ja, wie muss ich vorgehen? Oder muss ich dort auch wieder SvxLink komplett neu kompilieren?

    EDIT: Ich habe es einfach einmal komplett gemacht. Der SvxServer meldet sich nun mit Version v0.0.2. Scheint also zum Glück erst einmal alles geklappt zu haben ...

    Schönen Gruß
    Frank, DL3DCW

    Hi Christian,

    die Version stimmt :) Du mußt nur den svxserver neu kompilieren, den Rest nicht.

    vy 73s de Adi

    Hallo Adi,

    danke für die Info. Wie muss ich denn vorgehen, wenn ich nur den SvxServer neu kompilieren möchte?

    Schönen Gruß
    Frank, DL3DCW

    Hi,

    ich mache mal noch ne Seite/Anleitung dafür. Es ist nicht so ganz einfach mit git, das sehe ich ein.
    Ist glaub ich besser das auf der Webseite zu haben als im Forum, findet sich besser.

    vy 73s de Adi

    Vorhin ist folgendes passiert:
    Ich war mit meiner Remote-Logic mit WSF/FIB & Co. verbunden, es war BEtrieb auf einem Relais. In einer Sprechpause habe ich per DTMF den NetLink beendet, es kam auch keine NF mehr aber ein Dauerträger bis zum Timeout. Danach mußte ich Remotetrx auf dem Remote-Rechner neu starten.
    Hier die Logs von diesem Zeitpunkt:
    ============================= Log vom svxlink - Rechner ============================================
    28.05.2015 17:02:00: NetRx2: The squelch is CLOSED (0)
    28.05.2015 17:02:00: ### LinkManager::logicIdleStateChanged: is_idle=1 logic_name=NetLogic2
    28.05.2015 17:02:00: PiTx1: The transmitter is OFF
    28.05.2015 17:02:00: RemoteLogic: digit=9
    28.05.2015 17:02:01: RemoteLogic: digit=6
    28.05.2015 17:02:01: PiRx1: The squelch is OPEN (4.06237)
    28.05.2015 17:02:01: ### LinkManager::logicIdleStateChanged: is_idle=0 logic_name=RemoteLogic
    28.05.2015 17:02:01: ### LinkManager::logicIdleStateChanged: is_idle=0 logic_name=NetLogic2
    28.05.2015 17:02:01: NetRx2: The squelch is OPEN (1)
    28.05.2015 17:02:01: RemoteLogic: digit=0
    28.05.2015 17:02:01: RemoteLogic: digit=#
    28.05.2015 17:02:02: PiRx1: The squelch is CLOSED (4.40067)
    28.05.2015 17:02:02: ### LinkManager::cmdReceived: link=NetLink2 logic=RemoteLogic subcmd=0
    28.05.2015 17:02:02: Deactivating link NetLink2
    28.05.2015 17:02:02: ### NetLogic2 =X=> RemoteLogic
    28.05.2015 17:02:02: ### RemoteLogic =X=> NetLogic2
    28.05.2015 17:02:02: PiTx1: The transmitter is ON
    28.05.2015 17:02:08: NetRx2: The squelch is CLOSED (0)
    28.05.2015 17:02:08: ### LinkManager::logicIdleStateChanged: is_idle=1 logic_name=NetLogic2
    28.05.2015 17:02:10: NetRx2: The squelch is OPEN (1)
    28.05.2015 17:02:10: ### LinkManager::logicIdleStateChanged: is_idle=0 logic_name=NetLogic2
    28.05.2015 17:02:13: Rx1: The squelch is OPEN (4.51399)
    28.05.2015 17:02:13: ### LinkManager::logicIdleStateChanged: is_idle=0 logic_name=SimplexLogic
    28.05.2015 17:02:14: NetTx: The transmitter is ON
    28.05.2015 17:02:14: Rx1: The squelch is CLOSED (5.89367)
    28.05.2015 17:02:14: ### LinkManager::logicIdleStateChanged: is_idle=1 logic_name=SimplexLogic
    28.05.2015 17:02:14: Rx1: The squelch is OPEN (6.03314)
    =============================LOG von REMOETRX ===========================
    Thu May 28 17:00:35 2015: Tx1: Turning the transmitter ON
    Thu May 28 17:00:35 2015: Rx1: SetMuteState(ALL)
    Thu May 28 17:02:00 2015: Tx1: Turning the transmitter OFF
    Thu May 28 17:02:00 2015: Rx1: SetMuteState(NONE)
    Thu May 28 17:02:00 2015: NetUplinkTrx: DTMF digit detected: 9 with duration 100 milliseconds
    Thu May 28 17:02:01 2015: NetUplinkTrx: DTMF digit detected: 6 with duration 110 milliseconds
    Thu May 28 17:02:01 2015: Rx1: The squelch is OPEN (4.31237)
    Thu May 28 17:02:01 2015: NetUplinkTrx: DTMF digit detected: 0 with duration 110 milliseconds
    Thu May 28 17:02:01 2015: NetUplinkTrx: DTMF digit detected: # with duration 120 milliseconds
    Thu May 28 17:02:02 2015: Rx1: The squelch is CLOSED (4.15583)
    Thu May 28 17:02:02 2015: Tx1: Turning the transmitter ON
    Thu May 28 17:02:02 2015: Rx1: SetMuteState(ALL)
    Thu May 28 17:07:02 2015: *** ERROR: Transmitter Tx1 have been active for too long. Turning it off...

    Gleiches ist soeben wieder aufgetreten. Hier der Logauszug aus dem Remotelog, auf dem die Netlogic gelinkt war:

    Die Logik reagiert nicht mehr , der remotetrx - Prozess idled jetzt nur noch mit 0% CPU - Last und muß neu gestartet werden.

    na ja, das sagt leider nicht allzuviel. Da muß ich wohl mal ein paar Debugausgaben hinzufügen, wenn ich darf.

    Na klar - nur zu!

    Gleiches ist heute passiert: Ich mußte beide Prozesse auf den beiden Rechnern - Remote und Main-svx - neu starten und habe genau auf das Log geachtet. Die Remoteseite hat keine DTMF-Töne mehr decodiert, lediglich Sql-open/close wurde protokolliert.

    Erste Beobachtungen:
    Offensichtlich gehen Teile und komplette Aussendungen verloren. Ich habe das Log beobachtet, mein Squelch wurde geöffnet, der NetTX ist auf Sendung gegangen und während meines Durchgangs ausgegangen. Das habe ich nun schon bei beiden Teilnehmern unseres kleinen Netlink - Verbundes beobachtet. Leider ist das Phänomen nicht reproduzierbar und tritt nur sporadisch, aber bei regelmäßig auf.
    Svxlink-Log und QSO-Mitschnitte liegen vor.

    ... und kurioserweise - was bisher noch nie geschah - ist der Hauptprozess soeben stehen geblieben, auf dem der andere, interne, Netlink läuft:

    Danach mußte ich den svxlink - Prozess neu starten.

    <Nachtrach>
    Die server-Logdatei zeigt mit der neuen Version mehr disconnects/connects über den Tag verteilt.

    ich schaue morgen mal genau danach.

    Quote

    <Nachtrach>
    Die server-Logdatei zeigt mit der neuen Version mehr disconnects/connects über den Tag verteilt.

    Hm, kann ich mir nicht so richtig vorstellen, an der Netzwerkschnittstelle habe ich überhaupt nix geändert. Es ist lediglich genau ein Kommando mehr hinzugekommen. Wenn es Probleme mit Unterbrechnungen zwischen Server und den Nodes gibt so muß das andere Ursachen haben.

    73s de Adi, DL1HRC

    Beobachtung vom heutigen Tag:
    Alle 3 Teilnehmer unseres NetLinks sind wieder aktiv. Mehrere komplette, sowie Teile einer längeren Aussendung sind offensichtlich nicht über den Serverstream übertragen worden (ich kann die beiden anderen Teilnehmer per HF hören). Der Ausfall ist sporadisch und läßt sich nicht reproduzieren. :(

    Hm, könntest Du das mal bitte umstellen, damit ich da zentral ein paar Sachen einbauen kann (Debugausgaben etc.).
    Das macht sich besser wenn ich immer rankomme und es auf einer Umgebung läuft, auf der Änderungen mal schnell eingespielt werden können. Ein Raspi ist da einfach zu langsam.
    Ich habe glab ich noch eine Instanz laufen, Zugangsdaten kann ich zusenden.

    73s de Adi, DL1HRC

    Kann ich machen, klar.
    Zumindest die CPU (-Last) des RasPi lief nie über 10% mit dem Serverprozess (aktuell 4% bei 3 Teilnehmern - total load 0,20).

    PS: Bei der ersten Variante von svxserver waren keine Aussetzer zu beoabachten

    So, ich habe noch einen blöden Bug beim heartbeat gefunden, der sporadisch zu Netzwerk-timeouts führen konnte, weiterhin klappt jetzt die Authentifizierung auf Anhieb, nicht so wie in der Vergangenheit, dass es ab und an mal mehrerer Versuche bedurfte. Ich teste noch etwas, dann schiebe ich es hoch.

    vy 73s de Adi, DL1HRC