Kein Re-Connect möglich

Hallo zusammen,

nach mittlerweile sechsmonatiger Projektphase zur Umsetzung eines Echolinkgateways (Habs im Forum bereits beschrieben) konnte bei den vielen Tests immer wieder ein Problem feststellen:

Ein OM ist mit dem Gateway verbunden. Das kann kurz oder lang sein, spielt keine Rolle. Dann disconnectet er und versucht sich nach kurzer Zeit wieder zu neu zu connecten. Alternativ, es folgt ein disconnect wegen Timeout. Danach geht's auch oft nicht.

Dabei kann man im Protokoll zwei verschiedene Dinge sehen.

Entweder werden "spuriose" Daten erkannt und deswegen die Verbindung verweigert, oder es kommt eine Meldung, dass die eingehende Verbindung ignoriert wird.

Es hat nichts damit zu tun, dass der OM nichts gesagt hat und deswegen gesperrt wird oder ähnliches. Er taucht auch nicht auf eine Blacklist auf, die ihn für gewisse Zeit verbannt.

Man kann das auch nicht an einem bestimmten OM festmachen. Jeden kann`s treffen.

Hat jemand eine Idee?

Hallo Stefan,

wir haben hier fast die gleichen Probleme, aber es scheint, das SvxLink hier wirklich nicht schuld ist.
Ein OM kann, wenn er will, sich in einer Stunde gerne mal x mal connecten und disconnecten. Ist überhaupt kein Problem, wenn er das von einem Rechner aus macht.
Sobald er allerdings ein Smartphone nimmt, oder in den Einstellungen (Relay oder Proxy) verwendet, geht das in die Hose.

Jedesmal, wenn er über den Relay connected, bekommt er eine andere IP-Adresse. Die stimmt aber nicht mit der, die er vorher hatte, überein. Somit sagt SvxLink, spurious packets received (passiert dann, wenn der Link unterbrochen wurde, der Sender es aber noch nicht weis), oder einfach Connection Rejected. Der Directory Server von Echolink kennt einfach nicht die neue IP der Station und reagiert, als ob jemand das Rufzeichen kidnappen wollte.

Abhilfe gibt es hier leider nicht. Dafür ist das Echolink-System einfach zu alt.

Wir haben wir 3 Relais testweise miteinander verlinkt. Spätestens be der Zwangstrennung durch DSL irgendwann in der Nacht, haben wir das gleiche Drama: Spurious packets received. Denn woher soll die Gegenstelle wissen, dass die neue Stelle eine andere IP bekommen hat. Der Reconnect funktioniert nur, wenn die IP im Directory Server von Echolink gleich der alten IP Adresse ist. Da hilft leider nur warten, bis die neue IP in der Datenbank ist. Dann klappt es auch wieder mit den Reconnect.

LG es vy73 de

Wilm, DL4OCH

Hallo Wilm,

danke für Deine Ausführungen. Was diesen Reconnect vom Rechner aus angeht, da muss ich Dir leider wiedersprechen. Denn der OM Norbert, mit dem ich hier dieses Gateway auf den Weg gebracht habe, hat zu Testzwecken immer von seinem Rechner aus gearbeitet um z. B. Pegel oder Qualität der netzseitigen Aussendungen beurteilen zu können.

Vorgestern hat es auch mal wieder nicht funktioniert, dass er sich mit Svxlink verbinden konnte. Ok, möglicherweise hat er in dem Moment eine neue IP bekommen, aber es passiert zu häufig, als das ich das jedes mal an einem Wechsel durch Zwangstrennung festmachen würde.

In dem Zusammenhang ist auch interessant, dass wenn ich dann, also genau in dem Moment wo er es nicht schafft das Gateway zu connecten, in die Trickkiste greife und mit meinem Handy ihn dann per DTMF connecte, dann geht's wieder. Verbindung wurde umgehend aufgebaut und stand.

Wenn es denn nun so ist, wie Du sagst, was ja auch eigentlich ein nachvollziehbarer Grund für das Problem wäre, warum kann ich ihn dann per DTMF connecten? Es dauert ja oft Minuten, bis auf den Echolinkservern auch immer alles richtig läuft. Und die "neue" IP muss da ja auch bekannt gemacht werden. Warum klappt es auf dem Wege und nicht anders herum?

@Wilm mal ne frage am Rande. Würde das Problem mit euren Testlink Strecken (zwangstrennung) nicht besser
sein wenn man die 3 links in ein VPN legt?
Ich gehe davon aus das ihr 3 unterschiedliche DSL Anschlüsse habt.

Zu dem anderen Problem, ich connecte immer via Direct. Nutze kein relay oder Proxy.
Dadurch habe ich immer die die selbe IP, sollte ich das Programm schließen und wieder öffnen.
Nachteil: Du bekommst keine connects zum Smartphone, da der Port nicht an deine IP weitergeleitet wird.

Im Moment versuche ich es via VPN.
Mein Smartphone (iPhone) verbindet sich via VPN ( Mobilen Internet) mit meinem Router Zuhause und baut eine VPN Verbindung auf. Da das Telefon immer die gleiche IP zugewiesen bekommt, habe ich da die Möglichkeit die Ports weiterzuleiten an die zugewiesene interne IP.

Da im Moment mein eigener link noch im selben Netzwerk läuft ist es noch nicht 100% getestet.

Dieses würde natürlich die Probleme mit dem reconnect beheben, da das Smartphone immer die selbe IP des heimischem WAN Anschlusses hätte.

Was meint ihr dazu??

73
SA7BNT

Tim

Hallo Tim,

technisch denkbar. Aber musst Du nicht dem Router immer erst bevor Du das Haus verlässt mitteilen, dass Echolink portseitig nun auf Dein Smartphone geleitet wird?

Kenne auch nicht die Möglichkeiten Deines Routers, aber Handys arbeiten mit IPV6. Stell mir das schwierig vor. Aber falls das klappt, wäre toll, wenn Du deine Lösung veröffentlichen würdest.

Hallo Stefan,

also ich arbeite schon seit längerem mit VPN zum SVXlink. Ich nutze diese Verbindung um mich z.b via Terminal auf den svxlink zu loggen, da ich den SSH Port nicht gerne offen haben

Ob Handys mit IPV6 arbeiten weis ich nicht, ich weis nur das ich mit meiner VPN von überall, und da ist es egal ob Mobil oder von einem anderen WAN Anschluss an mein internes Netzwerk komme.

Quote from DG7JG

Hallo Tim,

technisch denkbar. Aber musst Du nicht dem Router immer erst bevor Du das Haus verlässt mitteilen, dass Echolink portseitig nun auf Dein Smartphone geleitet wird?

Ich arbeite mit verschiedenen Routern. Fritzbox und 2x Linksys
Bei dem Linksys habe ich die Firmware DD-WRT aufgespielt da diese um einiges besser einstellbar ist.
Dort gibt es eine Einstellung die da heißt "Port Triggering"
Sollte dieses dir kein läufiger Begriff sein kannst du hier den Unterschied zwischen Port Forward und Triggering nachlesen.
http://www.dslreports.com/faq/5799

Demnach sollte also wenn du da die Ports für Echolink eingetragen hast, für jeden der Echolink nutzen möchte der Port offen sein.
Nacheinander Versteht sich

Das heißt. Du stellst z.b via mobilem Internet eine VPN zu deinem heimischen Router her. Wenn diese Verbindung zustande kommt, bekommst du vom Router eine IP zugewiesen. Wenn dieses erfolgt ist bist du mit deinem heimischen Netzwerk verbunden.
Bei mir ist es so das dann der ganze Datenverkehr via meines heimischen Netzwerkes läuft. Lasse ich mir auf dem Smartphone meine WAN IP anzeigen, dann ist es nicht die vom mobilen Internet sondern die welche ich Zuhause gerade nutze.
Das nur nebenbei.
Wenn ich jetzt eine Verbindung mit Echolink nutzen möchte öffne ich die App und lege los. Dieses kann ich so oft wie ich es will machen da meine heimische IP sich ja nur 1 mal in 24 Std ändert, wenn überhaupt. Somit habe ich immer die selbe IP in der Datenbank. Wie gesagt ich habe es noch nicht 100% getestet, weil meine Ports ja durch meinen eigenen Link belegt sind.
Was noch zu Bedenken ist das der Upload stimmt. Wenn du via VPN arbeitest sendest du alles erst dadurch und dann erst ins WWW oder zu Echolink.

Sollte ich in dem was ich geschrieben habe falsch liegen möge man ich berichtigen. Bin kein Netzwerktechniker

Hoffe ich konnte dir vielleicht etwas helfen.

73
Tim
SA7BNT

Guten Abend zusammen!

Mehr als ein halbes Jahr ist vergangen und unser Projekt läuft eigentlich recht gut. Einige Probleme sind eben geblieben und wie ich feststellen muss sind auch andere davon betroffen.

Insbesondere spreche ich von Problemen beim Connecten. Insbesondere das auf einigen Sites diskutierte Problem der spuriousen Audio Pakete. Immer und immer wieder passiertes, dass im Log dieser Fehler auftaucht, wenn sich ein OM einloggt. Wie bereits oben beschrieben am häufigsten, wenn es eine Verbindung aus dem Mobilfunknetz ist. Somit habe ich mich heute wieder mal auf die Suche gemacht und einen interessanten Link gefunden:

http://herzberg-harz.dyndns.org:56125/svxlink.txt

Das ist ein recht aktuelles Logfile. Man suche nach dem Stichwort "spurious". Es gibt etliche davon. Und so wie ich das sehe meistens dann, wenn es Verbindungen von einem Smartphone o. ä. sind.

Die Therorie, dass sich wechselnde IP Nummern wegen Zangstrennungen die Ursache sind, das mag sein, aber es handelt sich oft so wie heute Mittag erst bei mir selber um eine Erstverbindung. Ebenfalls von einem Smartphone. Denke daher ist das das gemeinsame Vielfache.

Zeitweilig kommt dies zwar auch aus Verbindungen aus dem Festnetz zustande. Und wie bereits geschrieben, ist dann mit diesen spuriousen Pakten zu rechnen.

Tim, vielleicht kannst Du ja mal berichten, wie weit Du mit deinen Versuchen gekommen bist. Aber ich denke, selbst wenn es über einen Tunnel besser geht, das kann nicht die ultimative Lösung sein. Oder?

Hi,

habe mir das mal etwas näher angeschaut. Diese Meldungen kommen immer dann wenn der EchoLink-Client bereits Daten sendet bevor die Verbindung überhaupt aufgebaut wurde. Es sieht so aus, als sendet der Client die Connectanfrage und dann bereits die ersten Pakete ohne das OK abzuwarten, SvxLink versucht diese Connectanfrage zu bestätigen aber aus irgendwelchen Gründen kommen diese Pakete nicht oder nicht sofort beim Client an.
Ich werde mal auf WSF ein paar Debugausgaben hinzufügen und nachschauen was genau da passiert. Ohne das ist es ein bisschen wie lesen Im Kaffeesatz

73's de Adi, DL1HRC

Hi Adi,

gute Idee. Du hast ja Möglichkeit und Kenntnis dafür.

Zwei Dinge vielleicht noch zu dem Thema. Vorhin lief unsere OV Runde. Ein Teilnehmer hat sich über das Mobilfunknetz mit einem Smartphone auf dem RasPi mit Svxlink connected. Und es passierte wie so oft, kurz verbunden, rausgeflogen und mehrere Versuche wieder neu zu con schlugen fehl, begleitet von dieser spuriousen Fehlermeldung.

Ein anderer OM war ebenfalls bei mir con. Er betreibt Echolink für Windows, ganz klassisch. Da der Mobilfunkteilnehmer nicht zu mir direkt durchkam, hat er der OM mit der Windowsversion als Konferenzserver genutzt um letztlich doch na der Runde teilnehmen zu können. Und siehe da, es ging perfekt.

Somit denke ich, dass Router schon mal keine Rolle spielen.

Es kam hier auch der Gedanke auf, ob seitens des Raspi vielleicht eine Firewall dieses Problem erzeugt. Denn das wäre auch ein denkbares gemeinsames Vielfaches.

Ein weiterer Hinweis könnte auch dieses bereits beschriebene begleitende Piepen sein, was Mobilfunkteilnehmer mitbringen. Bei mir ja, über den OM mit Windows nein.

Hi Stefan,

ja, leider kommt noch erschwerend dazu, dass es keine (ausreichende) Dokumentation zum EchoLink-Protokoll gibt und alles nach dem Trial-and-error-Verfahren erkundet werden muß. Und selbst wenn gab es in der Vergangenheit schon Fälle, bei denen die exakte Implementierung nach Protokollbeschreibung zu Problemen führte weil ein Marktführer die Doku eben ein klein wenig....sagen wir mal _anders interpretierte_ und die die sich an Standards hielten das Nachsehen hatten
Es wird also leider auf sehr viel debugging hinauslaufen.

Dieses Gepiepe kann man abschalten. Es ist eine Implemetierung von mir, die einen Rogerbeep genau dann generiert, wenn der Audiostream vom Partner beendet ist. Leider kommt das offensichtlich vor allem von GSM/UMTS-Stationen stoßweise.
Die Idee wäre hier ein neuer Async-Timer, der die Ausgabe des Rogerbeep um z.B. 1Sek verzögert.

vy 73's de Adi, DL1HRC

Hi Adi,

dieser Rogerpiep ist ein anderer als (normale) welcher durch die Prozedur ausgelöst wird und ist auch der Modulation des sendenden irgendwie unterschwellig beigefügt. Und das zum Teil sehr häufig, während eines Durchgangs.
Nicht das es stört, es gibt ja somit ja auch den Hinweis, das irgendwas im argen ist mit dem Stream.

Ich habe auch auf irgendeiner Site gelesen, das Tobias den WireShark eingesetzt hat. Leider auch nicht ganz meine Welt, aber ich kenne da jemanden. Es wäre vielleicht auch da möglich, dem spuriousen Problem auf die Spur zu kommen.

Mal sehen.........

Hi Stefan,

es ist die Prozedur EchoLink::is_receiving (also in der EchoLink.tcl).
Einfach das playTone 1000 100 100; per locale-Konzept auskommentieren, dann hört der Spuk auf.

vy 73's de Adi, DL1HRC

Hallo Stefan, Hallo Adi,

die Gegenstelle zu Stefans Link ist übrigens http://www.lampensalat.de/svxlink.txt .Dann könnt Ihr auch die Logfiles von DB0EIG sehen.
Das Problem mit den spurious pakets kommt fast immer dann zustande, wenn entweder die Laufzeit ehlendig lang ist, der Teilnehmer über einen Proxy arbeitet, oder so gemein das klingen mag, über das Mobilfunknetz kommt.

Ein Beispiel:

- Ich starte die Echolink-App auf meinem Smartphone und connecte gleich mit DB0EIG. Das geht ohne Probleme
- Nun trenne ich die Verbindung und drücke den Home-Key meines Smartphones. Die Echolink-App läuft im Hintergrund weiter.
- Mein Smartphone geht in Standby. Da bleibt zwar die Netzverbindung für Telefonie (GSM) bestehen, jedoch nicht die Datenverbindung.
- Schalte ich nun mein Smartphone wieder ein, oder ruft die Mail-App neuste Emails ab, bekomme ich eine neue IP-Adresse zugewiesen.

-Ich starte wieder Echolink, in Wirklichkeit führe ich die App nur weiter aus und schon haben wir das Problem! Der Echolink-Server in Herndon hat immer noch meine alte IP-Adresse, da die App nicht die neue Adresse meldet. Das Problem tritt mehr bei Android, als bei IOS auf.

Das Gepiepe hat auch einen einfachen Grund: Wenn ich über UMTS connecte, dann habe ich einen echten Datenstrom. Also UDP über TCP. Ende der Übertragung = Roger-Beep.
Sollte ich die Verbindung mit EGDE machen, dann habe ich einen paketorientierten Dienst. Der kann eigentlich nicht UDP, sondern sammelt die Daten bis genug für einen STM-Container vorhanden ist und pushed diese in das Netz. Svxlink denkt also, dass die Übertragung abgeschlossen ist, es erfolgt ein Roger-Beep. Das ist systembedingt.

Wir müssen einfach damit leben, dass Echolink einfach nicht weiter entwickelt wird. Die Übertragungswege haben sich weiter entwickelt, die Technologie um Echolink leider nicht.

Das waren meine 2 Cent zum Problem.

vy73 es Liebe Grüße de Wilm,
DL4OCH

Hi Wilm,

vielen Dank für Deine ausführlichen und sehr gut nachvollziehbaren Erklärungen zum Thema. Ich denke auch, dass es an der Zeit ist mal etwas neues zu entwickeln. Leider fehlt mir da noch eine ganze Menge Wissen hinsichtlich Echtzeit-Protokolle.
Momentan baue ich an einer direkten SvxLink<->SvxLink-Kopplung, so als ersten kleinen Schritt in dieser Richtung. Das Nächste wäre dann wohl ein alternativer und richtig offener Verzeichnisdienst mit mehr Freiheitsgraden, z.B. multiple Anmeldungen unter einer IP mit verschiedenen Calls. Die Feature-Requests auf der originalen SvxLink-Seite, insbesondere die #30 klingen auch sehr interessant.
Das wird aber Arbeit für viele Leute nicht nur einzelne, also kramt bitte mal Eure C++/TCL-Bücher raus und fangt an
Ein schlechtes TCL-Skript für SvxLink ist immer noch um Größenordnungen wertvoller als das was normalerweise im Fernsehen geboten wird.

vy 73's de Adi, DL1HRC

Hi Adi,

genau da liegt der Hund begraben.... Auf welchen Übertragungsweg soll man denn entwickeln? Es gibt eigentlich genug Protokolle für die Sprachübertragung, die wir nutzen könnten. Sogar welche, die sich der Übertragungsstrecke anpassen könnten. Stichwort: ABR (Adaptives Bitraten Streamung), Silverlight....

Aber, wenn man einen solchen Dienst neu aufsetzen möchte, dann braucht man auch einen Registrar-Server. Da braucht es dann schon einen redundanten Anbieter. AWS scheidet aufgrund seiner Politik aus, Azure leider auch und selbst bei CloudSigma sehe ich da etwas schwarz. Mumble, wie es im Hamnet verwendet wird, könnte eine Alternative sein.

Aber was macht eigentlich Echolink? Es validiert eine Verbindung mit einer IP, dann geht alles sowieso P2P weiter. Da sind unsere Bestreben hinsichtlich der Protokolle doch offen.

Es würde schon reichen, wenn man statt Echolink eine Verbindung zwischen Relais mittels einer DynDns-Abfrage herstellen könnte. Damit wäre das Kriterium nicht mehr das Rufzeichen, sodern eine explizite URL. Das würde für die Verlinkung schon mehr als helfen. Noch mehr, man käme in diesem Fall aus dem dauerhaften Echolink-Modul heraus.

Das wird aber nicht denen helfen, die sich über die unterschiedlichsten Mobilfunknetze einloggen. Da ist halt das Problem, ob echtes Streaming, oder Paket-Verkehr statt findet.

Ein STM-Container hat halt den Nachteil, das ich ihn von vorne auffülle, aber auf der Gegenstelle von hinten auslese. Dann kommen halt die "spurious packets", da sie vor dem Connect ausgewertet werden.

Gerne hänge ich mich wieder in die Programmiererei, aber dafür brauche ich Literatur. "TCL for Dummies" habe ich nicht gefunden, also immer her mit guter Literatur um mich auch darin einzulesen.

Ich komme aus den Zeiten von Pascal, COBOL (zertifizierter Programmierer) und BASIC. Das sind alles Sprachen, bevor man mit der Maus gespielt hat..

LG,
Wilm

Hi Wilm,

ja wie schon gesagt, ich bin nicht der Audio-Stream-Datenübertragungs-Kenner. Ich könnte mir aber vorstellen, dass sich was mit dem Opus-Codec oder auch Codec2 machen läßt. Man könnte ja hier auf dem remoteTRX-Protokoll aufsetzen, auch wenn das momentan noch TCP ist.
Was ich mir letzte Nacht auch überlegt hatte, warum sollte man eigentlich einen eigenen Verzeichnisdienst aufsetzen. Es gibt einen TCP-basierten Dienst, der sogar noch viel besser ausgebaut ist als das EchoLink oder Dstar-Netzwerk: APRS. Die SvxLink-Stationen melden sich ohnehin dort an, Sie übertragen schon jetzt jede Menge Informationen ins Netz, das Protokoll ist offen und Erweiterungen sind für jedermann einfach möglich. Eigentlich müßte man dort nur entsprechende APRS-Stings für Verbindungsauf-und Abbau definieren usw.
Das einzige Problem wäre die Sicherheit, für den Anfang könnte man ja eine Whitelist definieren und den Verbindungsaufbau nur von definierten Stationen zulassen. Ist nur mal so eine Idee bei der man das Für und Wider diskutieren könnte...
Ich melde mich erst mal für 1Woche ab, muß auch mal sein

vy 73's de Adi, DL1HRC