Fedora: Pinephone als LAHA Client

Hallo Linuxphone-Fans,

Ja, LAHA geht 😀 Es gibt aber TĂŒcken im Pinephone. Das beste, es lĂ€uft bereits mit Pipewire 😀

Fedora: Pinephone als LAHA Client

Ich wollte das schon lange ausprobieren, aber mit den ganzen bisherigen Pineproblemen bin ich da nicht zu gekommen. Heute hat sich das geÀndert.

in GrĂŒn der Audiodatenstrom vom C&C Center ins Pinephone.

Der Shellclient macht jetzt nicht direkt was her, zumal er nur ein Kommando ist:

Da der Client normalerweise vom C&C direkt auf dem C&C Server benutzt wird um den Ton abzuspielen, kommt der bislang ohne eigene UI aus, schliesslich spielt er nur ab, was man im C&C ohnehin sieht.

Das könnte sich jetzt aber Ă€ndern, wenn ich etwas mit der LibHandy vernĂŒnftige OberflĂ€chen fĂŒr Pine bauen kann. Dann sollte es am Ende eine der Androidversion Ă€hneliche FunktionalitĂ€t haben. Ob ich es hinbekomme, daß die JAVA Pakete von einem Clienten sauber gelesen werden können, wage ich aber zu bezweifeln, daher wird wohl auf eine Java-Client-C-GUI Mixanwendung hinauslaufen.

LĂ€uft auch mit Pipewire

Ganz ohne mein Zutun, funktioniert die Anwendung out-of-the-box auch mit Pipewire. Da scheint sich jemand bei der KompatibilitĂ€t zu PulseAudio MĂŒhe gegeben zu haben. Da PA aber nur ein Pirewireclient ist, war das so gedacht. Wenn Ihr das austesten wollt, braucht Ihr neben java-1.8.0-openjdk fĂŒr LAHA auch nmap-ncat und die pulseaudio-utils.

Spezielle Anpassungen sind fĂŒr LAHA nicht nötig. Einfach so starten: java server/Server

Beim Test sind dann allerdings andere Probleme des Pinephones aufgetreten: Netzwerkaussetzer.

Oben im Bild seht Ihr ja einen kontinuierlichen Datenstrom zum Pine, das ist aber nicht immer so:

Ihr seht hier Aussetzer des Netzwerkes alle 15 Sekunden. Das lies sich nur mit einem Reboot fixen und betraf alle Apps auf dem Handy, auch SSH und Ping. Die Aussetzer sind aber nicht neu. Die sind immer mal wieder seit ich das Handy bekommen habe aufgetreten.

Bugreport ist raus.

 

 

 

LAHA jetzt auch auf Raspberry PI

Jetzt ist es also passiert, die LAHA Multiroom HomeAudio-Lösung lÀuft auf der Zielplattform Raspberry PI.

Was war jetzt LAHA nochmal?

Kurzform: Damit kann man Audio an mehrere EndgerĂ€te streamen … verteilen, so daß es ĂŒberall im Gleichklang erschallt. Hervorgegangen ist das aus einer einseitigen Wette mit den Heise Redakteuren, das man das auch ohne BĂ€ng & Teufelschen Co. mit OpenSource hinbekommt : LAHA – Netzwerklautsprecher mit Linux . Wie sich herausgestellt hat, geht das auch, nur leider nicht ganz so wie anfangs geplant. Das es trotzdem geht, bedeutet natĂŒrlich einige EinschrĂ€nkungen oder Umstellungen.

PulseAudio

Wenn man PulseAudio mit einem römischen Gott vergleichen wollte, wĂ€re es Janus, der Gott mit den zwei Gesichtern. Auf der einen Seite ist PulseAudio echt super einfach, z.b. beim Abnehmen des Sounds vom Player und dem ins Netz stellen, auf der anderen Seite könnte ich dem Entwickler auch gern mal eins reinwĂŒrgen, weil die interne Latenzkontrolle Ihren Job nicht macht. Da letzteres nicht sauber klappt, könnte man auf AlsaPlay ( aplay ) ausweichen, aber das benutzt, sobald PulseAudio da ist, richtig geraten, PulseAudio als Backend, womit die Latenzfalle wieder da ist … Ă€chtzzzz. Man hats nicht leicht mit der OpenSource-Plattform 🙂 Es nutzt ja auch nichts, daß es Open-Source ist, wenn bei so komplexen Dingen wie PulseAudio Modulen/Programmen zwar der Source lesbar ist, aber auf 1000 Zeilen Code genau 2 Kommentare kommen und dazu grober C UnFoo getrieben wird.

Das Raspberry PI

Nachdem Android und der lokale PAPLAY Backend soweit waren, daß man darĂŒber was abspielen konnte, ohne das es gleich sofort zusammenbrach, war gestern das Raspberry PI dran. Eine genervte Viertelstunde brauchte es schon um das RasPI Image auf die 64GB SD zu bekommen, dazu morgen mehr, aber am Ende war das Pi dann doch kooperativ, bis .. ja bis PulseAudio installiert wurde 🙁 Das lief zwar auf dem PI und mit den nötigen Zusatzprogrammen war das auch nett, aber, und das ist entscheidend, die PI Devs haben der PulseAudio-Welt den Hardwarehack vorenthalten, mit dem Sie den Sound auf den Kopfhöreranschluß umlegen. Ums kurz zu machen, solange PulseAudio installiert und aktiv ist, geht das nicht ĂŒber die Kopfhörerbuchse, sondern immer ĂŒber HDMI raus, egal was die OberflĂ€che sagt.

Da gab es natĂŒrlich nur eine Lösung: Back to the Roots aka. PulseAudio wieder löschen, rebooten und Alsa als Backend benutzen. Wenn man dann dem PI erzĂ€hlt, daß es den Kopfhörer nehmen soll, dann geht das auch.

Der Stand der Dinge

Wir haben jetzt also PI Playback und das auch synchron mit dem Desktop PC und Android. Android ist auch so eine Krankheit fĂŒr sich, aber das nur neben bei. Es gibt schon Beweisvideos, allerdings war es bislang fĂŒr Filmaufnahmen zu dunkel, Ihr mĂŒĂŸt Euch nicht mehr gedulden, unten ist ein Video mit 4 GerĂ€ten zusehen. Damit Ihr Euch schon mal ein Bild davon machen könnt, wie das funktioniert, hier selbiges aus der LAHA PrĂ€sentationsfolie :

Der Aufbau von LAHA als Flußdiagramm

So war das bis gestern angedacht, nun muß der RasPi Teil aber auf ALSA als Backend umgebaut werden, weil PulseAudio ja nicht kann 😀

LAHA und die Latenzfalle

Kleines Update zu LAHA, dem Multiroom Sound und PulseAudio.

Stand der Dinge

Wie man es drehen und wenden will, die fertigen Tools zum Abspielen von PCM Sound haben alle irgendeine Macke.

PAPLAY benutzt PulseAudio. Das ist praktisch ein Todesurteil fĂŒr eine stabile Latenz.
APLAY   benutzt Alsa, das defaultmĂ€ĂŸig … PulseAudio benutzt. Siehe erstens 🙂
*JACK*  nun Jack möchte gern alleine tÀtig sein, ohne Konkurrenz. FÀllt auch aus.

Da APLAY und PAPLAY per Default einen PA Stream zum Abspielen benutzen, haben beide in der Form das gleiche Problem: Die Audiolatenz des Playstreams steigt mit der Zeit an. d.b. alle anderen GerĂ€te mĂŒĂŸten mitwandern. Blöd nur, das Androids gar keine Latenzwanderung haben und selbst wenn Sie es hĂ€tten, wĂ€re das eine blödsinnige Lösung. Jetzt fragt Ihr Euch natĂŒrlich: was labbert der da? Da muß man jetzt weiiiiiit ausholen.

Also, wenn man mit PAPLAY Sound ausgibt, geht PAPLAY zum PAServer und sagt dem, das DER eine Latenz wĂ€hlen soll. Das macht der dann auch, nachdem die ersten Daten geflossen sind und die pegelt sich mit 16Bit Stereo und 48000″hz“ bei rund 1,9s ein. Richtig gelesen 1,9 Sekunden. Nach 40 Minuten sind wir bei knappen 5 Sekunden, wenns dumm lĂ€uft. Wenns gut lĂ€uft bei 2,4s . Das entscheidet PA selbst, ich nehme an, nach internen Fehlberechnungen aller gestarteten, gestoppten, bewegten etc. Streams die auf dem System drauf sind. Ich hab es noch nicht im Source gefunden. Es ist eigentlich das Ziel eines Audioservers die Latenz niedrig zu halten, aus irgendeinem Grund, ist dem PA-Latenzalgorithmus das egal.

Wenn man jetzt denkt, daß der Befehl ja eine OPTION fĂŒr die gewĂŒnschte Latenz hat und sich schon freut, daß die dann ja als Ziel eingehalten wird .. Ă€hm ja, also wie soll ich das Schreiben ohne verklagt zu werden??? Lieber nicht, hier ein Beispiel: 500ms angegeben, Latenz beginnt bei 320ms und wandert pö-Ăą-pö so Richtung 500ms, durchbricht den Median, und verschwindet alsbald jenseits von Gut und Böse im Sekundenbereich.

Wenn man auf die glorreiche Idee kommt, da das anzugeben, was der Algo vorher selbst ausgerechnet hat, dann bekommt man nicht 1,9s , nö, mehr so 1s+- und dann kommt das gleiche Spiel wie vorher bei 500ms.
Ja, man könnte jetzt die PAPLAY-Routine kapern, den anderen GerĂ€ten die Latenzen mitteilen und denen somit zu einem Sync verhelfen. ABER.. die Latenz wird ja immer grĂ¶ĂŸer, was bedeutet, daß bei jedem neuen Sync mehr Zeit vergeht, bis man was hört. Also auch mal 5 Sekunden schwarzes nichts. Das ist hochgradig Inakzeptabel.

Bugreports sind raus, werden nicht helfen, weil (C) endet 2006 . Sieht nicht so aus, als wenn da wer dran arbeitet.

Kommen wir zu ALSA

APLAY kann ALSA-Devices direkt ansprechen. Warum nutzen wir dann nicht APLAY, statt PAPLAY ? Gesagt, getan. Versuchts mal, viel GlĂŒck dabei. Das geht mit etwas GlĂŒck genau einmal und auch nur auf einem Device, aus das PA grade nichts ausgibt. Ist auch klar, weil PA ja ALSA als Unterbau hat. Wir erinnern uns, daß PAPLAY 1,9s Latenz hatte. APLAY, wenn man ein Device findet, das geht, hat 0ms und das Startdelay ist nicht ganz so funktional, wie sich APLAY das wĂŒnscht aka. auch buggy. ABER, 0ms sind cool, weil Android auch 0ms haben kann, ohne dabei drauf zu gehen. Der Lesezugriff fĂŒr Netzwerkdaten fĂŒr „16 Bit Stereo 48k“ auf einem Android liegt bei 1ms. d.b. nimmt man ALSA als Player und bekommt das Device frei, hat man eine echt geile Latenz von 1-2ms und das hört man nicht!

Der Resync

Jetzt gibt es allerlei HĂŒrden, die man umschiffen muß. Androids fliegt das eigene Multitasking um die Ohren, da fĂ€ngt der Ton dann an zu stottern. Vorwarnung : keine. Gegenmaßnahmen: derzeit unbekannt.Das funktioniert auf dem Desktop etwas besser.

Bei 0ms Latenz ist der Resync instant, da könnte man versucht sein, einfach pauschal alle paar Sekunden mal helfend durch einen Socket.close();Socket.connect() einzugreifen. Könnte klappen, muß nicht.Ist aber eine Option, wenn der Wiedergabetask das nicht merkt. Geheimtip: Vorsicht vor doppelten Daten im AudioBuffer. Vergleicht mal, ob Ihr nach dem connect()+read() einen Teil davon schon habt und schmeißt den raus.

LAHA

Unser ControllCenter steuert jetzt bereits beliebig viele Devices, kann Audiostreams von laufenden Apps kapern, z.b. MPV, FireFox etc. , hat diverse Backends zum Abspielen auf dem Desktop, könnte verschiedene Musikplayer als Quelle nutzen und damit auch Last.FM, Spotify etc. realisieren. Er verschiebt Metadaten, findet neue GerĂ€te im Netz, erlaubt EndgerĂ€ten mit Screen ihn fernzusteuern und hat bereits erfolgreich ein Handy als Drahtloskopfhörer fĂŒr Videos laufen gehabt. Dank MPVs negativer Latenz und der frei einstellbaren EndgerĂ€te Latenz, kann man alles perfekt ausrichten 🙂

Wir sind also auf dem richtigen Weg. Ob das allerdings vor Weihnachten 100% zuverlĂ€ssig lĂ€uft, kann ich nicht garantieren. Trotz des ganzen Frustes mit den Bugs der Anderen, hat das Projekt endlich mal wieder Spaß beim Programmieren beschert. Und das ist doch, weswegen man es tut, oder nicht 😀

Wie man in Java die lokale IP ermittelt

Da das Ermitteln der lokalen IPs ĂŒber alle Interface angeblich Voodoo ist, hier mal eine Lösung ohne Voodoo 🙂

import java.net.InetAddress;
import java.net.NetworkInterface;

                try {
 			Enumeration networkInterfaces = NetworkInterface.getNetworkInterfaces();
 			while (networkInterfaces.hasMoreElements()) {
 		    	     NetworkInterface networkInterface = (NetworkInterface)networkInterfaces.nextElement();
 		    	     Enumeration ips = networkInterface.getInetAddresses();
 		    	     while ( ips.hasMoreElements() ) {
 		    		// InetAddress ipa = (InetAddress)ips.nextElement();
 		    		String ip = ((InetAddress)ips.nextElement()).toString();
 		    		ip = ip.replaceAll("/", "").replaceAll("%.*$","");
 		    		... HIER mit der IP was machen ... 
 		    	      }
 			}
 		} catch (Exception e) {
 			e.printStackTrace();
		}

Eine kleine Anmerkung dazu. Das ist ja der Cast auf InetAddress, es werden an der Stelle aber IPv4 und IPv6 Objekte zurĂŒck gegeben, die sich eben ohne Cast-Fehlermeldung nur als InetAddress verarbeiten lassen. Wenn Ihr wissen wollt, was es ist, ohne eine RegEx ĂŒber das Ergebnis zu legen, lest einfach die Klasse des Objekts aus:

InetAddress ipa = (InetAddress)ips.nextElement();
log( ipa.getClass().getName() );
String ip = ipa.toString().replaceAll("/", "").replaceAll("%.*$","");

Anstatt getName() kann man auch getSimpleName() oder getType() benutzen, ganz wie es Euch gefÀllt.

Alternative:

		Enumeration<NetworkInterface> networkInterfaces = NetworkInterface.getNetworkInterfaces();
		while (networkInterfaces.hasMoreElements()) {
		   	NetworkInterface networkInterface = (NetworkInterface)networkInterfaces.nextElement();
		   	
		   	for (InterfaceAddress address : networkInterface.getInterfaceAddresses()) {
		   	    String ip = address.getAddress().toString();
	   		    int netmask = address.getNetworkPrefixLength();
	   		    log( netmask + ip );
		   	    ip = ip.replaceAll("/", "").replaceAll("%.*$","");
	   		}
		}

Da bekommt man auch gleich die Netzwerkmaske mit, ist wohl der bessere Weg 🙂

Signieren von npm Paketen

Zur Einleitung eine kleine Geschichte zu einem Projekt, daß ich mit einem unserer Kunden umgesetzt habe. Da das Projekt mangels Benutzer jĂŒngst eingestellt wurde, ist wohl die Floskel „Es war einmal…“ angebracht 🙂

Die Geschichte von Lord Uglify

Also.. Es war einmal .. ein tolles webbasiertes Firmenspiel fĂŒr das jede Menge Javascriptcode erzeugt wurde, weil es ja im Browser zu spielen war. Nun sollte das ellenlange Javascript eingedampft werden mit „Uglify“ einem node.js Tool zum Schrumpfen und Verschleiern von Javascriptcode.

Nun sollte jemand Uglify irgendwo installieren und es dafĂŒr benutzen. Das war der erste Fehler. Nachdem Node.Js aus dem Repository installiert wurde, tat es natĂŒrlich nichts sinnvolles, denn Uglify hat wie so viele andere Node.js Programme, einen AbhĂ€ngkeitsbaum, der milde betrachtet, bis zum Mond reicht. Mit NPM, dem Node.Js Paketmanager, kann man die AbhĂ€ngkeiten befriedigen, glaubten wir zumindest. Das war Fehler Nummer 2. Denn die AbhĂ€ngigkeiten von den AbhĂ€ngigkeiten der AbhĂ€ngigkeiten von den AbhĂ€ngigkeiten der AbhĂ€ngigkeiten von den AbhĂ€ngigkeiten die keine Ende nehmen wollten, brauchten geschlagene 30 Minuten sich zu installieren. Na gut, jetzt wird es ja wohl endlich starten. Das war der dritte Fehler.. allerdings dann auch der letzte, weil ich keinen Bock mehr hatte mich von so einem Witzprogramm verarschen zu lassen.

Ich habe dann einfach „jsmin“ genommen: klein,schnell,effektiv,lĂ€uft ĂŒberall, keine AbhĂ€ngigkeiten und einfachst zu bedienen. Kurzum, ein Programm wies sein sollte.

Was hat das jetzt mit dem Signieren von Paketen zu tun ?

Tja, wie man oben lesen kann, sind Node.js Programm extrem modularisiert, sprich, mal eben selbst was schreiben ist praktisch nicht, weil man erst mal jede Menge an Paketen installieren muß. Im Gegensatz zu Java, wo eine FĂŒlle von Klassen mitgeliefert werden, kommen die Pakete per NPM ins Projekt rein.

Diese Pakete sind nicht signiert, die von Java zwar auch nicht, aber die kommen ja auch aus einer definierten Quelle gleich mit. Signieren ist im NPM auch nicht vorgesehen. Daher hat jemand in Australien ( Details bei Heise ) gemeint, er mĂŒĂŸte das Ă€ndern und hat ein Signaturtool fĂŒr Node.js Pakete gebaut.

Die BegrĂŒndung war, das neulich diverse Pakete aus dem NPM Repo auf merkwĂŒrdige Art verschwunden sind, zwischenzeitlich durch gleichnamige Pakete ersetzt wurden, um dann funktional mit den frĂŒheren Paket  zu kollidieren, sprich, was anderes zu machen, als das Original.

Da jeder Pakete in das NPM Repo laden kann, wĂŒrde das Signieren also den Prozess mit den Paket-AbhĂ€ngigkeiten sicherer machen, weil wenn sich so ein Vorgang wie eben beschrieben passiert, wĂŒrde ja die Signatur nicht mehr passen und dem Entwickler wĂŒrde dann auffallen, daß da gerade was schief lĂ€uft. Nun, das mag sein.

Das eigentliche Problem

Das eigentliche Problem löst das natĂŒrlich nicht: 100 AbhĂ€ngigkeiten im Projekt, und den von den Entwicklern hat noch nie einer gehört. Ob die da Schadcode einbauen oder nicht, kann man nicht an der Tatsache einer gĂŒltigen Signatur erkennen.
Alles was dieses Signaturen bieten, ist ein Verwechslungsschutz, das aber auch nur, wenn der lange verschollene Author doch nochmal gefunden wird 🙂

Ich halte das fĂŒr nichts, was man an die große Glocke hĂ€ngen sollte, denn das hier kann man damit nicht vermeiden:

https://hackernoon.com/im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5

Es lohnt sich bis zum Ende zu lesen, weil Ihr sonst einen falschen Eindruck von der Sache bekommt. Wenn Ihr damit fertig sein, hier ein Zitat von „blog.fefe.org“ unser aller Weltverschwörungsguru 😉 passend zum Thema :

[l] Ein Einsender kommentiert die Webfrontend-Warnung:

  • lass‘ uns als kleine Veranschaulichung, wie breit und tief die GĂŒllegrube npm sein kann, eine Webanwendung anfangen. NatĂŒrlich mit Angular und dem aktuellen Standard-Build-System @angular/cli:

    $ npm i @angular/cli
    $ node_modules/.bin/ng new webkid --directory=.

    Das Ergebnis ist ein Skeleton mit einer Hello-World-Seite und:
    31 direkten AbhÀngigkeiten
    974 AbhÀngigkeiten insgesamt
    305 MB in node_modules

    Davon sind 158 Pakete Duplikate von bereits installierten Paketen mit einer anderen Versionsnummer. Bei so vielen AbhĂ€ngigkeiten Ă€ndern sich die Zahlen natĂŒrlich schnell, also am besten sofort anfangen mit dem Audit!“

    “ [Ende des Zitats]  Aufgrund der Struktur von Fefes Webseite, mĂŒĂŸt Ihr selbst den „Wed Jan 10 2018“ suchen 😉

 

Dem Kommentar kann man sich nur anschließen. Keine Signatur der Welt macht das irgendwie sicherer!

Davon ab, keine Ahnung wie jemand auf die Idee kommt, dafĂŒr zu Entwickeln. Da braucht man ja Stunden um anzufangen. Leute nehmt was vernĂŒnftiges, nehmt Java. Eclipse auf. Neues Javaprojekt aufmachen und einfach losschreiben 😉

Java kommt ĂŒbrigens leer mit knapp 105 MBye aus 😉 und das wĂ€re dann auch fĂŒr alle Projekte und nicht PRO Projekt 😀

Quelle: heise.de – Open Source Tool zum Signieren von npm Paketen veroeffentlicht

Linux – Fedora – Spectre & Meltdown Kernels nicht fehlerlos

Seit einigen Tagen sind ja die „gepatchten“ Fedora Kernel zu den Specture & Meltdown Schwachstellen verfĂŒgbar. Leider kommt es bei 32 und 64 Bit zu diversen Bugs, die ganze Serverfarmen inoperabel machen.

Der Kernel OOPS

so sieht so ein Kernel Fehler aus :

Jan 8 15:15:43 xx kernel: BUG: unable to handle kernel NULL pointer dereference at 00000008
Jan 8 15:15:43 xx kernel: IP: __radix_tree_lookup+0xe/0xa0
Jan 8 15:15:43 xx kernel: *pdpt = 0000000019977027 *pde = 0000000000000000 
Jan 8 15:15:43 xx kernel: Oops: 0000 [#1] SMP
Jan 8 15:15:43 xx kernel: Modules linked in: nfsv3 nfs_acl nfs lockd grace sunrpc fscache rmd160 ip_vti ip_tunnel af_key ah6 ah4 esp6 esp4 xfrm4_mode_beet xfrm4_tunnel tunnel4 xfrm4_mode_tunnel xfrm4_mode_transport xfrm6_mode_transport xfrm6_mode_ro xfrm6_mode_beet xfrm6
_mode_tunnel ipcomp ipcomp6 xfrm6_tunnel tunnel6 xfrm_ipcomp chacha20poly1305 cmac camellia_generic cast6_generic cast5_generic cast_common deflate ccm serpent_sse2_i586 serpent_generic glue_helper ablk_helper blowfish_generic cls_u32 blowfish_common twofish_generic sch_h
tb twofish_i586 twofish_common xcbc sha512_generic des_generic geode_aes xt_owner xt_multiport ip6table_filter ip6_tables xenfs xen_privcmd coretemp xen_netfront nf_conntrack_pptp nf_conntrack_proto_gre nf_conntrack libcrc32c crc32c_intel xen_blkfront
Jan 8 15:15:43 xx kernel: CPU: 0 PID: 1740 Comm: java Not tainted 4.14.11-200.fc26.i686+PAE #1
Jan 8 15:15:43 xx kernel: task: d750c500 task.stack: d7f96000
Jan 8 15:15:43 xx kernel: EIP: __radix_tree_lookup+0xe/0xa0
Jan 8 15:15:43 xx kernel: EFLAGS: 00010282 CPU: 0
Jan 8 15:15:43 xx kernel: EAX: 00000004 EBX: 0de6d000 ECX: 00000000 EDX: 00000000
Jan 8 15:15:43 xx kernel: ESI: 00000000 EDI: 00000004 EBP: d7f97da8 ESP: d7f97d98
Jan 8 15:15:43 xx kernel: DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0069
Jan 8 15:15:43 xx kernel: CR0: 80050033 CR2: 00000008 CR3: 01ee4000 CR4: 00002660
Jan 8 15:15:43 xx kernel: Call Trace:
Jan 8 15:15:43 xx kernel: radix_tree_lookup_slot+0x1d/0x40
Jan 8 15:15:43 xx kernel: find_get_entry+0x20/0x160
Jan 8 15:15:43 xx kernel: pagecache_get_page+0x24/0x290
Jan 8 15:15:43 xx kernel: lookup_swap_cache+0x3a/0x100
Jan 8 15:15:43 xx kernel: swap_readahead_detect+0x55/0x280
Jan 8 15:15:43 xx kernel: ? xen_set_pte_at+0x81/0x140
Jan 8 15:15:43 xx kernel: do_swap_page+0x22a/0x990
Jan 8 15:15:43 xx kernel: ? wp_page_copy+0x361/0x6f0
Jan 8 15:15:43 xx kernel: ? kmap_atomic_prot+0x3e/0x130
Jan 8 15:15:43 xx kernel: handle_mm_fault+0x498/0xc90
Jan 8 15:15:43 xx kernel: ? xen_timer_interrupt+0x17/0x30
Jan 8 15:15:43 xx kernel: __do_page_fault+0x202/0x4d0
Jan 8 15:15:43 xx kernel: ? __do_page_fault+0x4d0/0x4d0
Jan 8 15:15:43 xx kernel: do_page_fault+0x27/0xd0
Jan 8 15:15:43 xx kernel: ? __do_page_fault+0x4d0/0x4d0
Jan 8 15:15:43 xx kernel: common_exception+0x6f/0x76
Jan 8 15:15:43 xx kernel: EIP: 0x1f51b404
Jan 8 15:15:43 xx kernel: EFLAGS: 00010202 CPU: 0
Jan 8 15:15:43 xx kernel: EAX: 00000000 EBX: 0de6df60 ECX: 00000000 EDX: 40000000
Jan 8 15:15:43 xx kernel: ESI: 00000001 EDI: 40000000 EBP: 0f1f40b8 ESP: 0f1f409c
Jan 8 15:15:43 xx kernel: DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b
Jan 8 15:15:43 xx kernel: Code: b6 00 00 00 00 0f 0b 8d b6 00 00 00 00 b8 ef ff ff ff eb a4 e8 34 73 8b ff 8d 74 26 00 55 89 e5 57 56 53 89 c7 83 ec 04 89 4d f0 <8b> 5f 04 89 d8 83 e0 03 83 f8 01 75 6d 89 d8 83 e0 fe 0f b6 08
Jan 8 15:15:43 xx kernel: EIP: __radix_tree_lookup+0xe/0xa0 SS:ESP: 0069:d7f97d98
Jan 8 15:15:43 xx kernel: CR2: 0000000000000008
Jan 8 15:15:43 xx kernel: ---[ end trace 91253bf32b64ee98 ]---

Wie man sieht ist hier ein Java Prozess der gestorben ist. Das Problem dabei ist allerdings, daß die Prozesse gar nicht sterben, sondern einfach nicht mehr reagieren. Das ist besonders blöd, weil so ProzessĂŒberwachungstools, die Prozesse nicht einfach neu starten können.

Im Fall oben war es ein Tomcat Webserver der hÀngen blieb und damit keine Webseiten mehr auslieferte.

VerschÀrfung

Problematisch an der Sache ist, daß auch kerneleigene Prozesse betroffen sind z..b der „swapper/0“ crasht mal einfach beim Hochfahren des Rechners weg. Ob sich das negativ auswirkt oder die Server einfach nicht mehr swappen, weiß man noch nicht.

Abhilfe ?

Da habt Ihr leider Pech. Redhat ist dran, aber das kann dauern. Bis zu einer Lösung könnte Ihr hÀngende Prozesse nur neustarten.

 

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.