Squeezebox und Radius

Betreibt man privat einen Radius-Server und will seine Squeezebox mittels EAP-TLS ins Netzwerk einbinden, wird man vom der geführten Konfiguration darauf hingewiesen, dass dieser Modus nicht unterstützt wird. Das ist gelinde gesagt Bullshit. Die Entwickler waren sich nur zu fein ein entsprechenden Konfigurationstool anzubieten.

Bevor es losgeht, braucht man erst mal die entsprechenden Client-Certs. Leider unterstützt der wpa_supplicant nicht alle Formattypen, explizit müssen die Client-Certs im DER-Format sein. Beim Root-CA-Cert ist es egal.

Wer zb aus dem PEM Format ein DER machen will, kann das wie folgt machen

openssl x509 -in newcert.pem -inform PEM -out newcert.der -outform DER #Konvertiert das Signierte ClientCert
openssl rsa -in newkey.pem -inform PEM -out newkey.der -outform DER #Konvertiert den Client-Key

Ist das erledigt muss man die Squeezebox erst mal mittels Kabel anschließen und per SSH auf die Box zugreifen. Am besten unter /etc/certs die erzeugten certs (inklusive root-ca) per scp ablegen.

Anschließend nimmt man sich die /etc/wpa_supplicant.conf vor und legt wie folgt ein Netzwerk an (oder modifiziert es):

network={
    ssid="SSID"
    scan_ssid=1
    #proto=RSN  #WPA2
    key_mgmt=WPA-EAP
    pairwise=CCMP
    group=CCMP
    eap=TLS
    identity="frei zu wählen"
    ca_cert="/etc/cert/root.ca.pem"
    client_cert="/etc/cert/client-cert.der"
    private_key="/etc/cert/client-key.der"
    private_key_passwd="password"
}

Das ist aber nur die halbe Miete, leider muss man die Netzwerkfähig auch noch manuell vornehmen. Die GUI ist nicht nicht der Lage von einem Halb-Vorkonfigurierten WLAN eine DHCP Request zu machen.

Also noch schnell in die /etc/network/interfaces und das Netzwerk hinterlegt/angepasst

auto lo
iface lo inet loopback

mapping eth1
        script /etc/network/if_mapping

iface eth0 inet dhcp
        script /etc/network/udhcpc_action
auto eth1=SSID
iface SSID inet dhcp
        script /etc/network/udhcpc_action

Nach einem Neustart der Box sollte sich das Gerät ordnungsgemäß am Radius-Server anmelden.

Update:
Squeezeboxen unterstützen nur eine KeyLength von 2048bit

HDMI Output und Ruckler in HD

So nun hoffentlich der finale Artikel zum Thema „Ruckler während des HD Playbacks“. Nachdem ich mir sogar ein neues Board (AMD Fusion) zum Test geholt hatte , musste ich leider feststellen, dass das Thema alles andere als einfach zu Debuggen ist.

Nach nunmehr mehreren Monaten des Suchens hab ich den letzten Verursacher von Bildrucklern gefunden. Am Ende liefen nicht mal H264 Videos im Baseline-Profile ordentlich ruckelfrei. Da hab ich in meiner Verzweifelung (und Hoffnung) mal das HDMI Kabel getauscht. Zum Glück hatte ich kein Ersatz und fand den Input-Converter DVI-HDMI meines TVs nicht. Folglich musste ich auf das „gute alte“ VGA-Kabel ausweichen. Sowohl Board als auch TV hatten den Anschluss noch. Und siehe da, ruckelfreies H264 in allen Lebenslagen! Kein störendes Bildstottern oder Fragmente. Alles so wie es sein soll.

Da ich nicht glauben wollte, dass das Kabel defekt war oder gar ein genereles Problem mit HDMI vorliegt, hab ich mich mal auf die Suche nach „Bildverbesserern“ auf Seitens des TVs gemacht. Ich wurde fündig. Ein bisschen vergraben wendet mein TV allerhand Algorithmen auf das Eingangssignal an. Allerdings nur auf das HDMI Signal. Standardmäßig waren die Einstellung wohl zu viel für die kleine CPU des TVs. So dass es statt zu Verbesserungen zu Fragmenten und Stottern kam. Sehr brauchbar.

Fazit: Wer ein modernes Display mit HDMI Input betreibt, kann nicht davon ausgehen, dass sein Eingangssignal auch ohne Veränderung ausgegeben wird. Kommt es zu Rucklern, Fragmenten oder anderen sporadischen Bildfehlern, einfach mal nachschauen ob nicht irgendwo ein Bilderverbesserer wie „Rauschunterdrückung“,“Bewegungsglättung“ oder gar „Upscaler“ sein Unwesen treibt.

NVidia – HD-Video – MicroRuckler

Nach meinen ersten Maßnahmen gegen MicroRuckler hat es ein wenig gedauert bis ich den letzten Verursacher gefunden hatte. Das Problem war, dass die Ruckler nur sporadisch ab und zu auftraten. Mal 30 Minuten lang gar nicht, dann wieder im 5 Minuten Takt.

Als Verursacher hat sich das PerformanceManagement der NVidia-Karte herausgestellt. Die Taktet die Karte runter, sobald wenig Leistung gebraucht wird. Scheinbar dauert das Justieren zu lange, so dass es zu FrameDrops kommen kann.

Zur Behebung hab ich folgendes in die ‚/etc/X11/xorg.conf‘ eingepflegt:

Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    Option              "NoLogo"        "True"
    Option         "NvAGP" "1"
    Option      "RenderAccel"  "true"
    Option         "TripleBuffer" "True"
    Option         "RegistryDwords" "PowerMizerEnable=0x1; PerfLevelSrc=0x2222; PowerMizerDefault=0x1; PowerMizerDefaultAC=0x1"
EndSection

Die Vorletzte Zeile aktiviert den TripleBuffer, so werden 3 statt zwei Bilder vorgehalten. In 2D Anwendungen (Videodarstellung) ist der Performanceverlust und Speicherverbrauch verkraftbar gegenüber der ruckelfreiem Abspielen.

Der letzte Befehl erzwingt vom NVidia-Treiber, dass die Grafikkarte immer mit maximaler Leistung arbeitet.

Sollte es immer noch zu leichten Ruckler kommen, kann man den Treiber nochmals mittels nvidia-settings dazu zwingen, endlich in den PerformanceMode zu gehen…:

nvidia-settings -a '[gpu:0]/GPUPowerMizerMode=1'

Samba/CIFS und Kerberos Authentifizierung

Nachdem ich NFS und Kerberos installiert hatte, wollte ich auch Samba/CIFS an Kerberos anbinden. Das gestaltete sich schwerer als erwartet.

Das Einrichten auf Serverseite gestaltete relativ reibungslos. Einfach dem Samba-Dienst entsprechend Konfigurieren.

security = ADS
realm = AQUA
kerberos method = system keytab
encrypt passwords = true

Im Kerberos hinterlegt man einen entsprechenden Principal und fügt ihn dem CIFS-Server hinzu.

sudo kadmin -p kerberosadmin/admin
addprinc -randkey cifs/server.fqdn
ktadd cifs/server.fqdn

Nach einem Neustart des Dienstes werden die User-Credentials von Samba gegenüber Kerberos Authentiziert.

Auf Client-Seite war dem ganzen nicht so leicht bei zu kommen. Als erstes muss ein Client-Key am Kerberos erzeugt werden und in der Client Keytab hinterlegt werden.

sudo kadmin -p kerberosadmin/admin
addprinc -randkey cifs/client.fqdn
ktadd cifs/client.fqdn

Anschließend mounted man den Share wie folgt:

mount -t cifs //server.fqnd/Share /mnt/cifs-share -o sec=krb5,uid=1001

Bis dahin hat mich das „nur wenige“ Stunden gekostet. Der Parameter „uid“ wird scheinbar gebraucht wenn Winbind nicht so will, wie es soll. Ich hab es ums verrecken nicht hinbekommen, dass der Winbind mehr schmeißt als nur Fehler.

Daneben war es mit nicht möglich den krb5i-Modus zu aktivieren, also Schutz gegen Veränderung der einzelnen Daten-Pakete. Zudem scheint CIFS/Samba nur beim Mount die Usercredentials zu überprüfen und die Verbindung dann an den User zu knüpfen. Wenn ein anderer User (root) auf den Share zugrifft, erfolgt das unter der UID des Users der den Mount aufgemacht hat.