Android – Jitsi Probleme mit der Fritz!Box beheben

Im Chaos um die VOIP Probleme der einzelnen Linuxclienten, kommt hier nun der Fix für das Passwort-vergessen-Problem von Jitsi für Android.

Das Problem

Jitsi für Android, was ja nur eine jahrealte Alphaversion ist, hat offensichtlich Probleme die Verbindung zur Fritz!Box zu halten. Normalerweise gibt es dafür den KEEP ALIVE oder die REGISTER Funktion, aber hier macht Jitsi wohl soviel falsch, daß es der Fritz!box auf den Keks geht und es Jitsi rauswirft. Da sich Jitsi jetzt nicht mehr anmelden kann, kommt es zu einer Rückfrage bei der Jitsi das eingegebene Passwort, das zu allem Überfluss auch nicht gespeichert war, vergißt. Als Folge ist man laufend auf der Fritz!Box gesperrt, und muß dauernd das Passwort eingeben.

Da mich das an die Probleme mit SIPGate errinnert hat, habe ich da den gleichen Fix versucht: die Connection auf TCP umstellen. Nur dazu braucht man einen Proxyserver :)Also fragen wir bei AVM nach, was dort eingetragen werden muß und ob das überhaupt klappen wird.

Der AVM Support

Hier die erste Anfrage :

Detaillierte Beschreibung:
Guten Tag,die Frage ist allgemeiner Natur, da die Jitsi Androidversion immer wieder die Anbindung zum Server verliert und nach dem Passwort fragt.Da ich ähnliche Probleme mit Sipgate hatte und dort der Wechsel auf TCP via Proxyservereinstellung die Probleme behoben hat, wollte ich gern wissen, ob das mit einer FritzBox ähnlich gehen würde. Auch wenn das in einem lokalen Netz eher komisch klingt 😀mit freundlichen Grüßen,
….

Die von AVM kommende Antwort war schon etwas merkwürdig, aber fairerweise muß man ihm zugestehen, daß nicht jeder Jitsi kennen muß, nur weil er bei AVM arbeitet:

….
vielen Dank für Ihre Anfrage an den AVM Support.Leider muss ich gestehen, dass ich Ihr Anliegen anhand Ihrer Informationen noch nicht vollumfänglich verstanden habe. Für die weitere Analyse benötigen wir umfangreichere Informationen.Bitte beantworten Sie mir folgende Fragen:
An was für einem Internetanschluss von welchem Anbieter setzen Sie die FRITZ!Box ein (z.B. Telekom DSL 16 Mbit/s)?

  • Welche Geräte (z.B. Computer, NAS-System, Hub/Switch) verwenden Sie? Geben Sie Hersteller und Modellnamen an.
  • Wie ist das Android-Gerät mit der FRITZ!Box verbunden?
  • Was für ein „Server“ wird verwendet?
  • Welche Protokolle werden verwendet?
  • Was soll das „lokale Netz“ leisten?
  • Wie sieht Ihr Wunschszenario aus?
  • Wie äußert sich das Fehlerbild in Ihrer bisherigen Konfiguration?

    Senden Sie mir bitte anschließend die Fehlerbeschreibung und das ZIP-Archiv mit den Support-Daten zu.

Wir werden die Support-Daten nach Erhalt detailliert analysieren und Ihnen anschließend eine Rückantwort zukommen lassen.

Bitte beachten Sie, dass dieser Prozess eine gewisse Dauer in Anspruch nimmt.
Ich wünsche Ihnen schon jetzt einen guten Start ins Wochenende.

Freundliche Grüße aus Berlin
….

Ich mußte dem Mitarbeiter Recht geben, er hatte es nicht verstanden, also beschrieb ich es etwas sehr eindeutig :

Fritzbox -> wlan -> android handy -> Software: jitsi android per SIP > fritzbox

Ich möchte eigentlich nur wissen, ob es für die SIP Anbindung zur Fritzbox eine TCP Option auf der Box gibt und wenn ja, was man(wenn überhaupt) als Proxyserver eingeben muß.

Sehr Ihr da irgendwo die Erwähnung der FritzPhone-App ? Der Mitarbeiter wohl schon :

vielen Dank für Ihre Geduld.
Die Anmeldung der App an der FRITZ!Box ist technisch möglich. Hierzu muss eine IP-Nebenstelle innerhalb der FRITZ!Box angelegt werden.
Die Eintragung eines Proxys ist möglich, aber nicht erforderlich.

Wenn der Support ratlos ist

Wir halten fest: Problem nicht verstanden und Anfrage nicht richtig gelesen und damit bei der Antwort Thema verfehlt. Spätestens bei dem Stichwort SIP hätte es klingeln müssen.

In dem Fall hilft also nur ausprobieren und genau das tat ich 🙂

Lösung

Jitsi starten, dann ins Menü und die ACCOUNT SETTINGS aufmachen. Dann den Fritzboxeintrag auswählen und dessen Settings öffnen. Und kommt nach einigen Scrollen ein Schiebeschalter unter, der bei der automatischen Proxykonfiguration steht. Den abschalten und dann das „Proxy“ aka. die Fritzbox selbst angeben:

Da es die heimische Fritz!box ist, können wir hier natürlich die IP der Box eingeben und den Port 5060 benutzen. Als bevorzugten Transport dann wieder TCP auswählen und das Problem ist scheinbar erledigt. Denn, wenn Ihr diesen Beitrag lest, gab es eine Woche lang keine Probleme mehr und damit auch keinen Grund, den Beitrag zu löschen 😉 Telefonieren geht mit den Einstellungen auch noch, also scheint das so zu laufen.

Linux – Jitsi Probleme mit Sipgate beheben

Seit SIPGate vor einigen Monaten an Ihrer Infrastruktur unangekündigt Veränderungen vorgenommen hat, verliert die Linuxversion von Jitsi im UDP Modus häufig die Verbindung zum Server. Dabei ist es egal, welche Version und welches Java man verwendet.

Die Abhilfe ist aber sehr leicht zu schaffen, man schaltet das automatische Proxy ab und ersetzt es mit :

Proxy:  tcpproxy.sipgate.de
Port: 5060
Bevorzugter Transport: TCP <-! Wichtig

Seit der Anpassung, funktioniert Jitsi wieder stabil mit SIPGATE.

Jitsi kann keine SIP Anrufe mehr annehmen

Wer kennt das nicht, in der Firma läuft es ruhig. Kunden melden sich nur per Email, aber das Telefon schweigt seit Tagen. Das alljährliche Sommerloch, wegen dessen wir alle in den Urlaub fahren …, oder ?

Paranoide Menschen würden jetzt per Telefon sich selbst anrufen und entsetzt feststellen, daß die Telefone nicht klingeln, weil .. ja .. scheisse, wieso klingeln die nicht ????!!!!!!

Ab jetzt herrscht Panik in der IT-Abteilung:  Was ist passiert ?

Ist der SIP Provider pleite gegangen ?
Haben Mäuse die Glasfaserkabel geknackt ?
Oder liegt es etwa an uns ?
Gab es ein Update der Telefonsoftware ?
Gab es überhaupt irgend ein Update ?

Also prüfen wir zunächst mal, ob alle betroffen sind und stellen fest : Alle Jitsi SIP Softphones sind quasi tod, aber normale Telefone für SIP nicht. Jitsi kann zwar noch raustelefonieren, sonst wäre das ja auch eher aufgefallen, aber ankommende Anrufe gehen nicht mehr. Komischerweise geht Jitsi auf den Handies noch.

Das schliesst per se ein DSL Router und Netzwerkproblem aus, außer die lokale Firewall wäre im Spiel:

TEST:
systemctl stop firewalld
Anruf => kein Klingeln
systemctl start firewalld

Das wars nicht. Hatte Jitsi ein Update ? Seit Monaten nicht mehr.  Fällt somit als Ursache auch weg.  Hmm…

2 Tage und eine systematische Suche später ..

Das Problem, das  Jitsi keine SIP Calls mehr annehmen konnte, ist behoben worden.

Es lag NICHT an Jitsi, Sipgate, den Mäusen, dem DSL Router, den Kabeln, der Firewall sondern an :  JAVA.

Die Ursache

Fedora hat vor zwei Tagen ein neues openjdk 1.8.0.141_b16 eingespielt, das hat Jitsi und vermutlich andere Apps beeinträchtigt. Das Update war als Security Update markiert, es ist also potentiell gefährlich, die App weiter zu betreiben. Ist es in dem Fall nicht, da das Update pauschal als Security Update eingestuft wurde, weil 4 Security Tests beim Build nicht liefen. Dazu noch eine Menge normaler Updates, von denen vermutlich eins die Ursache ist.

Der Workaround

Der schnellste Workaround ist natürlich, Java zu downgraden auf die letzte funktionierende Version:

java-1.8.0-openjdk-1.8.0.131-5.b12.fc25.x86_64.rpm
java-1.8.0-openjdk-devel-1.8.0.131-5.b12.fc25.x86_64.rpm
java-1.8.0-openjdk-headless-1.8.0.131-5.b12.fc25.x86_64.rpm
java-1.8.0-openjdk-javadoc-1.8.0.131-5.b12.fc25.noarch.rpm

Wenn man das jetzt mit „dnf downgrade java-*“ macht, landet man bei einer uralten Version, was Securitymäßig keine gute Idee ist. Also lädt man die Pakete hier runter:

https://kojipkgs.fedoraproject.org//packages/java-1.8.0-openjdk/1.8.0.131/5.b12.fc25/noarch/java-1.8.0-openjdk-javadoc-1.8.0.131-5.b12.fc25.noarch.rpm
https://kojipkgs.fedoraproject.org//packages/java-1.8.0-openjdk/1.8.0.131/5.b12.fc25/x86_64/java-1.8.0-openjdk-headless-1.8.0.131-5.b12.fc25.x86_64.rpm
https://kojipkgs.fedoraproject.org//packages/java-1.8.0-openjdk/1.8.0.131/5.b12.fc25/x86_64/java-1.8.0-openjdk-devel-1.8.0.131-5.b12.fc25.x86_64.rpm
https://kojipkgs.fedoraproject.org//packages/java-1.8.0-openjdk/1.8.0.131/5.b12.fc25/x86_64/java-1.8.0-openjdk-1.8.0.131-5.b12.fc25.x86_64.rpm

Aber natürlich nur passenderweise für Fedora 25, andere Versionen bitte selbst bei koji suchen.

Nicht vergessen: /etc/dnf/dnf.conf editieren und java auf die Sperrliste setzen, sonst kommt das Update gleich wieder rein.

Warum ist jetzt der Downgrade auf b12 akzeptable und der auf die Fedora Downgrade Version nicht ?

Weil Jitsi nur Verbindungen zu bestimmten, vertrauenswürdigen Servern aufnimmt. Es ist daher kaum möglich etwaige SecBugs in Java über diesen Channel auszunutzen, zumal in der ML von OpenJAVA keine Hinweise zu Securitybugs enthalten waren. 4 Tests beim Build failten, das kann alles sein. in nächster Zeit wird es sicher Updates von Jitsi geben, damit es auch mit der aktuellen Java Version läuft, denn es steht zu befürchten, daß Openjdk, den „Bug“ nicht fixt.

Tip des Tages: Öfters mal Logfiles rotieren

Tomcat Logfiles können lang werden, daher sollte man diese desöftern rotieren.

Ganz unproblematisch ist das beim Tomcat aber nicht, denn im Gegensatz zu PHP Webanwendungen, stehen hier die Sessioninfos im RAM und nicht auf der Platte. Das hat beim Tomcat einen enormen Vorteil, weil der Server deutlich schneller an Infos kommt, als es z.B. PHP kann.

Der Nachteil liegt auf der Hand:  ein Neustart zerstört auch immer die Sessioninformationen. Gerade bei Shops ist das ein Problem. Hier muß die Sessionverwaltung dann auf Datenbanken ausgelagert werden, was bei verteilten Webanwendungen ohnehin gemacht werden muß.

Wo würde man daher das Logrotate ansetzen ?

Wer Serverdienste einsetzt, der braucht auch immer ein Startscript. Tomcat kommt zwar mit seinem eigenen startup.sh daher, aber auf ein klassisches Startscript ala init.d kann man eigentlich nicht verzichten. Hier ein Ausschnitt:

export CATALINA_HOME=/java/tomcat

ulimit -v unlimited -d unlimited -s unlimited -n 20000

PATH=$PATH:/usr/local/bin/

# See how we were called.
case "$1" in
 start)
 echo -n "Starting tomcat : "
 daemon /java/tomcat/bin/startup.sh
 RETVAL=$?
 echo
 ;;
 stop)
 echo -n "Stopping tomcat : "
 killtomcat
 RETVAL=$?
 echo
 ;;
 status)
 status tomcat
 RETVAL=$?
 ;;
 restart)
 $0 stop
 $0 start
 RETVAL=$?
 ;;
 *)
 echo "Usage: tomcat {start|stop|status|restart}"
 exit 1
esac

exit $RETVAL

und genau hier setzen wir an :

# See how we were called.
case "$1" in
 start)
 echo -n "Rotating Logs : "
 cd /usr/java/apache-tomcat/logs/
 echo "Deleting old files : "
 find . -ctime +100 -name "catalina.out*" -exec rm -fv {} \;
 COUNTER=0
 while [ $COUNTER -lt 99 ]; do
       echo The counter is $COUNTER
       let COUNTER=COUNTER+1
       if [ ! -f "catalina.out.$COUNTER" ]; then
           FILENAME="catalina.out.$COUNTER";
           break;
       fi
 done
 echo "Benutze $FILENAME";
 mv catalina.out $FILENAME
 echo "Compressing Logfile : $FILENAME"
 bzip2 -9 $FILENAME
 echo -n "Starting tomcat : "
 daemon /java/tomcat/bin/startup.sh
 RETVAL=$?
 echo
 ;;

Dieses Script ist natürlich nur ein Beispiel. Ihr müßt es noch anpassen an Eure Pfade und Präferenzen. Es wird Logfiles löschen, die älter als 100 Tage sind und maximal bis .99 zählen. Das kann je nach Häufigkeit des Starts Eures Tomcats dann eventuell nicht passen. Da müßt Ihr jetzt Eure Erfahrungen für Eurer System berücksichtigen.

Bitte beachtet, daß BZIP2 ein echter Zeitfresser ist, besonders in der Kombination mit 8 GB Logfile und -9 Option. Das packt hier auf einem nicht langsamen Server bereits seit 50 MInuten 😉 Das Ergebnis ist allerdings genial:

catalina.out.5: 53.987:1, 0.148 bits/byte, 98.15% saved, 8.250.838.531 in, 152.828.685 out.

Unter 2 % sind vom Logfile übrig geblieben 🙂

Wer jetzt meint, daß dieser Beitrag den 50 Minuten geschuldet ist, hat recht 😀 War leider ein echter Blocker.