Autor: Raptor 2101

Bird: strange next-hop

Raptor 2101Leave a comment

Nach meinem Umzug auf OpenWRT kam ich in den Genuss, das bei einem Reconnect nicht jeder Dienst neu gestartet wird. Leider hatte dieses „normale“ verhalten dazu geführt, das BIRD nicht mehr alle Routen propagiert hat. Das Problem: Es tauchten unvermittelt meldungen in folgendem Format im Syslog auf:

KRT: Received route 192.168.100.128/25 with strange next-hop 192.168.100.130

Zu Meldungen dieser Art kommt es wenn eine Routing-Regel aus der Kernel-Routing Tabelle gelernt wird, die ein direkt angeschlossenes Netz über einen entfernten Gateway schleifen will. Typisch für P-T-P und P-T-MP Verbindung wie OpenVPN oder PPPD. Interessanterweise stört BIRD das nur bei neu erlernten Routen. Ist die Route beim Dienst-Start schon in der Routing-Tabelle gibt es keine Probleme. Die Meldung kann man Unterdrücken, was jedoch stört ist die Tatsache, dass die entsprechende Routing-Rule nicht an die anderen Protokolle übertragen wird. Die möglichen Lösungen:

  • Eine statische Route über das Interface definieren und via Filter verhindern, dass diese Route zurück in den Kernel geschrieben wird.
  • BIRD nach einem Reconnect neu starten.
  • Diverse Protokolle bieten es an Netzwerke zu propagieren, die sie eigentlich nicht kennen. Unter OSPF kann man z.B. ein stubnet Konfigurieren. Dies hat den Charme, dass man der Route gleich entsprechende Kosten auferlegen kann. Die Route wird nur an die OSPF-Neighbors weitergereicht nicht an irgendein ein anderes Protokoll in der BIRD Instanz.

Welche der Lösungen man wählt hängt wohl vom Einsatzgebiet ab, ich hab mich für letztere entscheiden.

IPSec/L2TP VPN mit OpenWRT

Raptor 21014 Comments

Da ich mehrere Android Geräte in Benutzung habe die ich nicht „rooten“ darf und dennoch einen VPN Tunnel in mein Heimnetzwerk brauche, hatte ich das „Vergnügen“ mich mit IPSec/L2TP – Tunneln auseinander zu setzten. Android bietet native aktuell vier VPN-Varianten an: PPP, L2TP, IPSec/L2TP (PSK), IPSec/L2TP (Certificate)

PPTP fällt aus, da der Android-Client nur primitive Authentifizierungen anbietet, welche als leicht angreifbar gelten. L2TP ist nur ein Layer2-Tunnel-Protokoll um darüber wiederum ein PPP-Tunnel aufzubauen. Da L2TP selber nicht Verschlüsselt ist das ganze nur so sicher wie der PPP Tunnel. Bei welchem wieder nur primitive Authentifizierungen angeboten wird. Bleibt als letzte Alternative nur den L2TP-Tunnel via eines IPSec Tunnel zu sichern. Sowohl die PSK (PreSharedKey) als auch zertifikatsbasierte Lösung sollten hinreichend sicher sein.

Damit beginnt aber auch schon der Ärger.  IPSec-Gateways findet man nur in wenigen SOHO Geräten vorkonfiguriert (z.b. einigen Fritzboxen) und das aus gutem Grund. Das Zusammenspiel Clients, Netze, Netzanbieter und IPSec läuft nicht so reibungslos wie es sollte. Dazu gleich mehr.

OpenWRT bietet gleich mehrere IPSec und L2TP Dienste an. Ich hab mich für den StrongSwan4 – Daemon als IPSec Dienst entschieden. Da dieser auch IKEv2 anbietet, in der Hoffnung dass dies vom auf Android eingesetzten Racoon-Daemon auch mal genutzt wird.

Des weiteren komm der xl2tp-Daemon oder der standardmäßig installierte ppp-Daemon zum Einsatz.

Bevor man die Sache angeht sollte man folgendes beachten um sich viel Zeit und Ärger zu ersparen: Das fehleranfälligste an einem IPSec/L2TP-VPN ist der IPSec-Anteil. Man sollte diesen also getrennt testen. Als sinnvoll hat es sich gezeigt, den Zielrouter mal vom Netz ab zu klemmen, die Firewall abzuschalten und plain den xl2tp-Daemon im Zusammenspiel mit dem PPP-Daemon zu testen. Das ganze geht einfach von der Hand und ist robust und stressfrei.

Danach kann man den IPSec Tunnel via PSK hochziehen und im internen Netz testen. Anschließend kann man ggf noch Zertifikate zur Authorisierung nutzen. Erst wenn das alles im internen Netz klappt sollte man Versuchen von „Außen“ auf das VPN zuzugreifen. Es empfiehlt sich an dieser Stelle für die Mobilen Devices einen LogReader zu installieren. Für Android ist das die App aLogcat. Leider gibt der racoon-Daemon nur in die Logfiles aus warum er einen Tunnel wieder zu macht oder warum er erst gar keinen aufbauen will.

Wie eingangs erwähnt gibt es mehrere Stolpersteine. Es war mir z.b. nicht möglich eines meiner Geräte dazu zu bewegen, den IPSec Tunnel aufzubauen. Das lies sich aber zweifelsfrei auf das Netzsegment zurückführen. Eine SIM-Karte des gleichen Netzanbieters aus einem anderen Gerät (anderes Netzsegment) eingewechselt und schon konnte der Tunnel aufgebaut werden. Es scheint Probleme beim Zusammenspiel Racoon – open/strong-Swan zu geben wenn mehrfaches „NAT“ing zum Einsatz kommt.[1. Quelle: http://www.mail-archive.com/users@lists.strongswan.org/msg02787.html]

Diesen Widrigkeiten zum Trotz kann man das ganze relativ leicht auf OpenWRT oder Ubuntu wie folgt einrichten:

Man benötigt  als Pakete den PPP-Daemon, XL2TP-Daemon und StrongSwan.

Configuration – /etc/ppp/options.xl2tpd

#Das wird nur gebraucht für radius-anbindung
plugin radius.so 
radius-config-file /etc/ppp/radius.conf
avpair NAS-Identifier=l2tp-vpn 
avpair NAS-Port=1

auth
#ggf für testzwecke noauth
#für debugging dump

lock
noccp
novj
novjccomp
nopcomp
noaccomp

ms-dns DNS-Server-IP

refuse-chap
require-pap

Hinweis ich erzwinge das unsichere PAP weil der IPSec-Tunnel via Zertifikaten gesichert ist (sehr schwer zu brechen, eigene CA) und FreeRadius für alles andere Klartextpasswörter im Zugriff braucht. Das muss man ggf. an seine Anforderungen anpassen!

Configuration xl2tp – Achtung hier verwende ich keine Authentifizierung. Das überlasse ich IPSec und PPPd
/etc/xl2tpd/xl2tpd.conf

[global]
port = 1701
;auth file = /etc/xl2tpd/xl2tp-secrets
access control = no
ipsec saref = no ;wichtig SAREF funktioniert nicht mit StrongSwan
;folgende zielen für debuggin einkommentieren
;debug avp = yes
;debug network = yes
;debug packet = yes
;debug state = yes
;debug tunnel = yes

[lns default]
exclusive = yes
ip range = 10.0.100.5-10.0.100.50
hidden bit = no
local ip = 10.0.100.1
length bit = yes
refuse authentication = yes
name = IpSec-Tunnel
ppp debug = no
pppoptfile = /etc/ppp/options.xl2tpd

Nun zu IPSec

config setup
        strictcrlpolicy=no #Für ein kleines Setup wird keine RevokationList verwaltet...
        plutodebug=none
        nat_traversal=yes #anschalten wenn man mit NAT(ted) Clients rechnet.
        virtual_private=%v4:10.0.0.0/8,%v4:192.168.99.0/24,%v4:!192.168.100.0/24
        charonstart=no #noch brauchen wir kein IKEv2
        #protostack=netkey
conn NAT-Tunnel
    authby=rsasig #Authentisierung via Zertifikaten
    pfs=no
    compress=no
    rekey=no 
    keyingtries=3
    type=transport
    auto=add
    left=%defaultroute
    leftcert=mycert.pem
    leftid=@mydomain
    leftrsasigkey=%cert
    leftsendcert=always
    leftprotoport=17/1701
    right=%any
    rightsubnet=vhost:%no,%priv
    rightprotoport=17/%any 
    rightrsasigkey=%cert
    rightca=%same #Wichtig das sorgt dafür dass alle Zertifikate die von der gleichen CA unterschrieben wurden wie das LeftCert angenommen wurden.
    keyexchange=ikev1 #ikev2 ist Standard auf ikev1 downgraden, da Android mit ikev1 reinkommt.

Anschließend sollte man sich noch vor der Dummheit der Nutzer und Clients schützen. Wenn der Racoon unter Andoid die Verbindung abbricht, versucht es der L2TP-Daemon dennoch aufzubauen. Die Verbindungsverwaltung bemerkt das zwar und beendet die Verbindung sofort, dummerweise wurden schon die Authentisierungs-Daten im Klartext gesendet. (Nein auch MS-Chap-v2 zählt als Klartext). Ein Angreifer kann so gezielt (über NAT) ein kurzes Downgrade erzwingen, die Daten abgreifen und dann selber ohne IPSec einen L2TP-Tunnel aufbauen.
Um das zu verhindern muss man IPTables dazu bringen Verbindungen für Port 1701(L2TP) nur dann anzunehmen, wenn diese über IPSec reingekommen sind. Früher war das einfach, da gab es ein ipsec-Device, heute muss man über die mangle-Table rann. Das ganze sieht dann wie folgt aus 

iptables -A INPUT -p udp --dport 500 -j ACCEPT #IPSec kommt immer über port 500 rein
iptables -A INPUT -p esp             -j ACCEPT # Encapsulated Security Payload - IPSec Protokoll
iptables -A INPUT -p ah              -j ACCEPT #Authentication Header - IPSec Protokoll

iptables -t mangle -A PREROUTING -p esp -j MARK --set-mark 1 # Der eigendliche Paylod kommt über das ESP protokol, alle Pakete markieren.
iptables -A INPUT -m mark --mark 1 -p udp --dport 1701 -j ACCEPT #alle Pakete die markiert wurden und an 1701 gehen werden akzeptiert.

Mittels dieser Regel lehnt der Gateway alle L2TP Pakete ab, die nicht über IPSec gesichert wurden.

Linux Bandbreiten-Monitor/Traffic-Accounting

Raptor 2101Leave a comment

Wenn man unter Linux einen Rechner betreibt findet man einen Haufen an Möglichkeiten den Bandbreitenverbrauch zu ermitteln. Betreibt man hingegen einen Router und will nicht nur den eigenen Verbrauch, sondern den Transfer-Traffic aufgeschlüsselt nach gewissen Attributen, wird es dünn im Lösungsumfeld. Soll das ganze dann noch auf einem handelsüblichen SOHO-Router laufen, wird es richtig kniffelig.

Das erste Problem ist, dass man wissen muss nach,nach was man sucht. Unter „Bandbreiten-Monitor“ verstehen die meisten Lösungsvorschläge das Monitoring des eigenen Verbrauchs/Traffic oder nur das „Gesamtaufkommen“ an einem Interface. Kurzum: Werte die sich leicht ermitteln lassen. Das aufschlüsseln des Transfertraffics bezeichnet man häufig als IP-Accounting. Danach teilt sich das Feld in folgende Lösungen auf:

  • Promiscuous Mode Basiert: Hierbei wird ein Interface in den Promiscuous-Mode geschaltet und der komplette Netzwerktraffic mitgeschnitten. Die Lösungen unterscheiden sich dann darin, wo und wie die Daten ausgewertet werden. Im einfachsten Fall werden die Pakete vorverarbeitet und an eine Sammelstelle weiter geleitet. Bekannteste Vertreter sind NTop, NProbe und bandwidthd.
  • IPTables/NetFilter Basiert: Hierbei wird ausgenutzt, dass IPTables mit protokolliert wie viele Pakete/Bytes über eine Filter-Regel gelaufen sind. Dies kann man dann asyncron über Bash-Befehle auslesen.

Der Promiscuous Mode basierten Lösungen sind die allumfassenden Lösungen. Sie schneiden alles mit und können die detailliertesten Auswertungen bieten. Sie haben jedoch immer zwei massive Nachteile. Erstens ist die benötigte CPU-Leistung enorm. Selbst die schlanke NPrope schaffte bei einem 600MHz Prozessor nicht mal Ansatzweise den zu erwartenden Transfertraffic (100Mbit/s). Auch wird das Analyseziel stark belastet. Sowohl was die Bandbreite als auch die CPU-Last betrifft. Das ist für eine einfache Bandbreitenanalyse ein wenig übertrieben. Des weiteren ist es mehr als fraglich ob das ganze rechtlich überhaupt zulässig ist. Immerhin handelt es sich hierbei um eine DPI,  jeh nach Ausführung sogar mit ungesicherter Ausleitung.

Die IPTables -Variante hat den Vorteil, dass die Pakete sowieso durch IPTables verarbeitet werden müssen. Der Overhead für das zusätzliche Monitoring hält sich in Grenzen. Auf besagtem 600 MHz Prozessor war keine Leistungsabfall durch Zu- oder Abschalten der Filter-Regeln zu messen, noch gab es eine nennenswerte CPU-Last. Der Nachteil ist jedoch, dass man wissen muss was man Monitoren will. Wenn man nur wissen will, wie viel Traffic auf ein Netzsegment entfällt, ist das einfach umsetzbar. Will man jedoch wissen auf welchen Client im Netzsegment der Traffic aufgelaufen ist, wird es schwierig. Besonders wenn es sich um ein Netzsegment mit ständig wechselnden Clients handelt wird es nahezu unmöglich das mit IPTables alleine zu bewerkstelligen.

Abhilfe schafft ein die NFLog Schnittstelle und ein Daemon aus dem pmacct.net-Project. IPTables führt das Decoding und Vorfilterung durch und leitet das Paket dann an den uacctd weiter. Dieser filtert, aggregiert und verarbeitet die Daten oder leitet sie an ein Sammelstelle weiter.

Das Ganze ist denkbar einfach zu konfigurieren. Als erstes braucht es nur IPTables-Regeln die die interessanten Pakete ausleiten.

iptables -I FORWARD -d 192.168.0.0/16 -j NFLOG --nflog-nlgroup 1
iptables -I FORWARD -s 192.168.0.0/16 -j NFLOG --nflog-nlgroup 1

Durch diese Regeln werden alle Pakete die das 192.168-Netz betreffen an die ULog-Schnittstelle weitergeleitet. Die weiteren Parameter bewirken, dass immer gewartet wird bis sich 50 Pakete gesammelt haben und nur die ersten 48 Bytes weitergeleitet werden. Die Group-Angabe ist später für die Auswertung wichtig.

Der entsprechende uacctd ist wie folgt konfiguriert:

daemonize: true
pidfile: /var/run/uacctd.pid
syslog: daemon

uacctd_group : 1
plugins: memory[host_in], memory[host_out]

aggregate[host_in]: dst_host
aggregate[host_out]: src_host

aggregate_filter[host_in]: dst net 192.168.0.0/16
aggregate_filter[host_out]: src net 192.168.0.0/16

imt_path[host_in]: /tmp/pmacct_host_in.pipe
imt_path[host_out]: /tmp/pmacct_host_out.pipe

Durch diese Konfiguration werden zwei Endpunkte angelegt, jeweils einen für ein- und ausgehendem Traffic und nach internem Client aggregiert. Der Speicherverbrauch und die Prozessorlast ist in meinem Einsatzgebiet zu vernachlässigen (selten mehr als 20 Clients gleichzeitig) kann jedoch je nach Einsatzart stark ansteigen. Ob das ganze bei 10k Clients und „portgenauem“ Monitoring noch skaliert habe ich nicht ausprobiert.

Auswerten kann man das ganze wie folgt:

pmactt -s -p /tmp/pmacct_host_in.pipe

Mit der eigenen Wunsch-Skriptsprache kann man nun die wildesten Skriptes zum überwachen des Traffics basteln.
Hier mein Beispiel für einen Perl-Skript/Munin-Plugin: munin-bandwidth.perl

Squeezebox und Radius

Raptor 2101Leave a comment

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

Raptor 2101Leave a comment

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

Raptor 21012 Comments

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

Raptor 2101Leave a comment

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.

Kerberos und NFS einrichten.

Raptor 2101Leave a comment

Ich kämpfe schon eine weile mit CIFS/Samba her rum. Bisher hab ich es leider nicht geschafft die Transferraten über mehr als 40MByte/s zu bekommen. Was bei Gigabit-Ethernet unbefriedigend ist. Vor einem Wechsel auf NFS habe ich mich aber immer gedrückt. Zum Einen weil dann immer die „Böse“ LDAP-Konfiguration im Raum stand, zum Anderen, weil ich der Meinung war Kerberos nicht zu brauchen.

Nun hat sich in den letzten Tagen herausgestellt, dass ich ein paar mehr Dienste brauche, die alle eine eigenen Authentisierung mit sich bringen. Darauf hatte ich keine Lust, ergo Kerberos musste her. Zweitens hat sich gezeigt, dass man LDAP nicht braucht. Das Maping von Usernamen/Groups funktioniert auch so Prima.

Es gibt ein gutes Tutorial, mit dem man innerhalb von einer Stunde einen NFS-Share mit Kerberos Unterstützung einrichten kann: NFSv4-Howto

Das Tutorial hat nur zwei Schönheitsfehler:

  • Der wichtigste Hinweis wird nicht hervorgehoben. Wer es ums verrecken nicht hinbekommt, dass sich NFS über Kerberos Authentifiziert sollte  seine /etc/krb.conf checken. Dort muss unter [libdefaults] der Eintrag „allow_weak_crypto = true“ gemacht werden.

  • Die Angaben für die /etc/exports Datei sind veraltet. Es wird noch die „gss/krb5“ verwendet. Aussehen sollten die exports aber so.

    /export       10.0.0.0/24(sec=krb5,rw,fsid=0, secure, no_subtree_check,async,no_all_squash)
/export/Share1 10.0.0.0/24(sec=krb5:krb5i:krb5p,rw,fsid=0, secure, no_subtree_check,async,no_all_squash)

    So kann man auch gleich dem Benutzer überlassen welche „Absicherung“ er gerade benötigt.

Des bin ich beim Einrichten des NFS-Shares noch über eine Stolperstein gefallen:

Aus irgendeinem Grund war der NFS-Server im all_squash Modus. Soll heißen alle User wurden auf „Nobody/Nogroup“ gemapt. Was zur folge hatte, dass ich zwar den Share mounten konnte aber keine Berechtigung hatte. Mit der Option „no_all_sqash“ war das behoben.

Anschließend hab ich mal Bonnie++ auf den Share los rennen lassen. Das Ergebnis waren 95.1MByte/s Read/Write. Kein Vergleich zu CIFS. Einzig wenn ich die höchste Sicherheitsstufe (krb5p – Transportverschlüsselung) ging die Performance in Knie (20 MByte/s).

XBMC – FullHD – Micro-Ruckler

Raptor 21012 Comments

Wenn man durch die Foren schaut, stolpert man immer mal wieder über das Problem, dass einige Nutzer Micro-Ruckler bekommen wenn sie 720p oder 1080p Quellen abspielen. Ich gehörte auch zu dieser Problemgruppe und will hier kurz beschreiben wie man das Problem angehen kann.

Als erstes muss man die Mikro-Ruckler erst mal eindeutig einer „Quelle“ zuordnen. Es gibt sehr viele Möglichkeiten, wie Mikro-Ruckler zu Stande kommen können:

  • Kodierfehler – die Ruckler z.B. tretet nur bei einem Film auf.
  • Frame-Drops – Das passiert wenn ein Bildwiederholfrequenz der Quelle höher ist als die Abspielfrequenz.
  • Falsche Timings bei der Ansteuerung des Bildschirms.
  • „andere Störenfriede“…

In meinem Fall konnte ich Kodierfehler ausschließen. Alle Filme wiesen sporadisches extrem kurzes Ruckeln auf. Einige Leute haben es nicht mal war genommen, mich hat es hingegen schon genervt (besonders wenn man weiß auf was man achten muss).

Um der Fehlerquelle einzugrenzen hab ich mir einige Naturaufnahmen mit langen ruhigen Schwenks in FullHD ausgesucht, dazu noch Batman – The Dark Knight wegen den starken Hell-Dunkel Kontrasten.

Als erstes hab ich die Timings wie in diesem Beitrag beschrieben korrigiert: Fixing the 24p issue.

Das hat die Ruckler zwar reduziert, aber sie waren immer noch vorhanden, das hat mich jedoch auf eine zweite Fährte gelockt. In dem Beitrag wird beschrieben wie man die Timings korrigiert und XBMC auf die Wiederholfrequenz der Quelle anpasst (Option). Durch test wurde mit ziemlich schnell klar, dass in meinen Fall nicht die Wiederholfrequenz das Problem darstellten, sondern die Timings. Eine Änderung von 60Hz auf 50Hz oder gar 24Hz hatte faktisch keinen Einfluss. Was jedoch auffällig war: sobald ich VSync abgeschaltet hatte, waren die Ruckler weg, aber die Bildfehler beim abspielen einer Testsequenz enorm. VSync musste also aktiviert bleiben. Ein kurze Suche im Internet hat mich auf die Composite-Extension aufmerksam gemacht.

Ich hab die automatische Anpassung abgeschaltet und in der xorg.conf nur einen Bild-Modus hinterlegt. Zusätzlich habe ich die Composite-Extension abgeschaltet.

Section "Extensions"
 Option "Composite" "disable"
EndSection

Nach einem Neustart kommt es nun zu keinen Mikrorucklern mehr.

BIRD manuel auf DD-WRT einrichten

Raptor 2101Leave a comment

Wenn man die Buffalo DD-WRT Version einsetzt und Routing (RIP, OSPF, BGP) aktiviert und sich danach nichts tut, sollte man mal mittels SSH Kontrollieren ob überhaupt ein Routing-Dienst läuft. Dazu muss man erst mal raus finden welcher dienst überhaupt laufen sollte. Das geht ganz einfach. In der Konsole versuchen „zebrad“ oder „bird“ aufrufen. Schlägt letzterer an muss man wie folgt vorgehen um den BIRD „manuell“ einzurichten.

Als erstet den Router-Modus zurückstellen auf „Gateway“, nicht das einem die Einstellungen aus der WebGUI in die Suppe spucken. Anschließend erstellt man das Verzeichnis /tmp/bird und die Datei /tmp/bird/bird.conf. Diese Datei gestaltet man nach seinen Wünschen und startet dann den BIRD.

mkdir /tmp/bird
vi /tmp/bird/bird.conf
bird

Eine Beispiel-Config findet man hier: Routing unter Ubuntu

Um das ganze zu automatisieren, muss die Config-Datei im NVRam hinterlegen.

nvram set zebra_conf="$(cat /tmp/bird/bird.conf)"
nvram commit

Beim Systemstart muss mittels des Startup-Skriptes das Verzeichnis und die Config-Datei angelegt werden.

mkdir /tmp/bird
nvram get zebra_conf > /tmp/bird/bird.conf

Den BIRD nicht beim Systemstart starten. Leider schießt die ServiceKontrolle/ProcessMonitor den BIRD automatisch ab wenn er da ist und ein Interface hochfährt (oder sich allgemein was ändert). Da die Speichervariablen (die ich noch nicht ermitteln konnte) keinen BIRD-Start vorsehen, wird er leider nicht nach gestartet.
Der richtige „Ort“ zum startet den BIRD ist daher das Firewall-Scriptes. Das wird immer ausgeführt, sobald sich an den Interfaces was ändern und ganz wichtig, es ist das letzte Skript.

if [ -ne $(pidof bird) ]; then
bird
fi

Das IF-Statement verhindert nur, dass der BIRD nochmal gestartet wird, wenn er schon existiert.