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.

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.

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'

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.

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).

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.

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.

Als erstes erstellt man eine Datei unter /tmp/connection_tracker.sh

#!/bin/sh
 
if [ $(ping -c 1 $(nvram get wan_ipaddr)|grep -c from) -lt 1 ]; then 
  logger -t connectiontracker `nvram get wan_ipaddr` unreachable
  killall redial; 
  killall pppd; 
  sleep 5 
  pppd file /tmp/ppp/options.pppoe >/dev/null; 
  logger -t connectiontracker reconnect wan `nvram get wan_ipaddr` successfully 
fi

Was macht das Script? Es versucht die IP des WAN-Interfaces zu pingen. Ist das Down gibt es keinen Treffer. “grep” wertet die Rückgabe des ping Befehls aus und zählt die Zeilen. Gibt es weniger als einen Treffer (also Null) wird der redial und pppd gestoppt und neu gestartet.

Anschließend fügt man eine NVRAM-Variable hinzu. Gibt es die Variable wird sie überschieben, Ansonsten wird sie angelegt.

nvram set rc_custom="$(cat /tmp/connection_tracker.sh)"
nvram commit

Über den Startup-Script/Command muss diese Datei nun immer angelegt werden.

nvram get rc_custom>/tmp/connection_tracker.sh

Über einen zusätzlichen Cron-Job die Überprüfung alle 15-Minuten durchführen.

*/15 * * * * root /tmp/connection_tracker.sh

Will man unter Ubuntu einen “echten” Router betreiben, also dynamisch auf die Netzwerkumgebung reagieren, stehen zwei Routing-Suites zur Verfügung: BIRD und Quagga. Beide unterstützen die wichtigsten Routing-Protokolle: BGP, RIP, OSPF

Die Quagga-Suite ist schon seit einiger Zeit am Markt. Sie bietet ein Config-Interface das einem CISCO Router gleicht. Man kann sowohl Config Files hinterlegen als auch “on the fly” Config Befehle geben und die entsprechende Config dann raus schreiben (ganz wie bei CISCO Routern). Im Hintergrund werden bei Quagga für jedes Routing-Prokoll ein eigener Dienst gestartet und jeder dieser Dienste macht einen TELNET Port auf. Diesen kann man auf den Localhost beschränken oder so konfigurieren, dass er jede Anfrage ablehnt (kein Password angeben).

Bird befindet sich aktuell noch in der (Weiter-)Entwicklung. Zudem wirkt es auf mich schlanker. Es wird nur ein Dienst gestartet, die Config befindet sich in einer Datei und wirkt übersichtlicher. Neben diesen “Geschmacksfragen” soll BIRD leistungsschonender sein.¹ Laut Wiki kommt er vor allem deswegen in den großen “Verteilerknoten” zum Einsatz. ² Dafür spricht auf jeden Fall, dass bei DD-WRT Firmwares für wenig Speicher der BIRD zum Einsatz kommt und bei viel Speicher die Quagga-Suite.

Ich habe beide Implementierungen gezwungenermaßen durch meine Routern im Einsatz. Beim Ubuntu-Router hatte ich die Wahl und mich nach einem kleinen Quagga Test für BIRD entschieden.

Wichtig: Die meisten Routing-Protokolle nutzten MultiCast-Addressen für ihre Kommunikation. Damit das funktioniert muss man eine entsprechende Route hinterlegen.

route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0

Beispiel – Konfiguration BIRD

Einfach über apt-get oder aptitude bird installieren und schon kann es losgehen.

aptitude install bird

Danach kann man die /etc/bird.conf bearbeiten.

log syslog all;
router id 10.1.0.1;
 
protocol kernel {
        export all;
        learn;
}
 
protocol device {
        scan time 60;
}
 
protocol ospf {
        debug { states, routes, interfaces };
        area 0 {
                interface "eth0" 10.1.0.0/16 {
                        cost 10;
                        stub;
                        check link;
                };
                interface "eth1" 10.2.0.0/16 {
                        priority 10;
                        cost 100;
                        type broadcast;
                        hello 30; retransmit 5; wait 10; dead 120;
                        authentication none;
                        check link;
                };
                interface "eth2" 10.3.0.0/16 {
                        priority 10;
                        cost 10;
                        type broadcast;
                        hello 30; retransmit 5; wait 10; dead 120;
                        authentication none;
                        check link;
                };
        };
}

Die Config dürfte selbsterklärend sein. Ein paar Hinweise zum Umgang mit BIRD:

• Das Kernel-Protokoll wird gebraucht. Ohne die “export all;” Regel werden keine Routen an das OS bekanntgegeben.
• Hat man Default-Routen oder pflegt händisch welche über den “route”-Befehl nach, sollte die über das “learn”-Statement von BIRD ermittelt werden.
• Alle lokalen Netze, die den Nachbarn mitgeteilt werden sollen, benötigen ein interface-Statement. Das stub-Statement markiert Interfaces die nur “announced” werden sollen aber sonst keine Funktion haben.
• Wenn man einen PPPoE-DSL-Uplink als Default-Route verwendet, sollte man das PPPoE Interface nicht als Area-Interface hinterlegen.
• “check link” funktioniert nur, wenn man neuerere BIRD-Versionen benutzt. BIRD 1.1.5 meckert einen Syntax-Fehler an.

 Beispiel – Konfiguration Quagga

Installation:

aptitude install quagga

Quagga ist anfangs etwas komplizierter. Anfangs muss man erst mal die benötigten Dienste unter /etc/quagga/daemons freischalten. Will man, dass diese Dienste per TelNet auch Remote konfigurierbar sind muss man noch in der /etc/quagga/debian.conf Anpassungen vornehmen.

Auf jeden Fall benötigt man den zebra-Dienst. Dieser ist das “protocol kernel” Pendant. Zusätzlich muss man noch den Dienst für das gewünschte Protokoll aktivieren. Für den einfachen Einstieg findet man Beispiel-Konfigurationen unter /usr/share/doc/quagga/examples.

zebra.conf

hostname deadend-router
 
interface br0
  link-detect
interface ath1
   link-detect

in der zerba.conf werden die zu nutzenden interfaces angegeben.

ospf.conf

interface br0
  ip ospf cost 10
  ip ospf dead-interval 120
  ip ospf hello-interval 30
  ip ospf retransmit-interval 5
  ip ospf network broadcast
interface eth0
  ip ospf cost 10
  ip ospf dead-interval 120
  ip ospf hello-interval 30
  ip ospf retransmit-interval 5
  ip ospf network broadcast
 
router ospf
  ospf router-id 10.3.0.10
  network 10.3.0.0/16 area 0
  network 10.4.0.0/16 area 0
    redistribute kernel
    redistribute connected

In der ospf.conf wird diesen Interfaces erst Eigenschaften zugewiesen und anschließend das Protokoll zugeschaltet. Wichtig ist die Syntax. Das Einrücken dient nur zur Optik und hat kein Einfluss. Die Reihenfolge der Befehle hingegen hat Einfluss. Gewisse Befehle “öffnen” eine SubConfig-Ebene. Ein “ip ospf cost” ist nur gültig, wenn vorher eine interface-Direktive stand. Was bei den “interface”-Direktiven noch übersichtlich erscheint, kann bei den area-direktiven unübersichtlich werden, da diese ineinander geschachtelt sein können. Angenehm sind hingegen die redistribute -Direktiven. So muss man nur die Interfaces auflisten, auf den auch wirklich ein weiterer Router lauscht.

• WHR-HP-G300N (400 MHz/32MB Ram)
• WZR-HP-AG300H (680 MHz/128MB Ram)

Beide Geräte werden ab Werk mit DD-WRT ausgeliefert. Die Hardware-Ausstattung ist für meine Verhältnisse üppig und reicht für den Home und Medium-Office Bereich. Auch wenn beide “eigentlich” DD-WRTv24Sp2 einsetzten unterscheiden sich die tatsächlich eingesetzten Firmwares doch stark. Sie unterscheiden sich vor allem im Release-Date und den verfügbaren Features. Der kleinere G300N vermisst zum Beispiel CIFS Support, OpenVPN, beschreibbaren Speicher (JFFS2) usw.  Dazu kommen Unterschiede in den ausgelieferten Software-Versionen. Beim G300N kommt BIRD als Routing-Daemon zum Einsatz, beim AG300H wird Quagga angeboten. Man könnte beide Geräte auch auf die offizielle DD-WRT Version zurück flashen, diese hingt der “Buffalo” Version jedoch im Release hinterher (keine Ahnung was das für Auswirkungen hat). Leider bietet Buffalo die Sourcen der DD-WRT Software nicht zum download (oder ich hab den Link noch nicht gefunden) so muss man mit einigen “Eigenheiten” leben. Dazu gleich mehr. Neben einem Farbbranding und ein paar Funktionseinschränkungen entspricht die Buffalo Version von DD-WRT der frei verfügbaren DD-WRT-Version.

Als erstes fällt beim Einsatz von DD-WRT auf, dass man nicht für einen Idioten gehalten wird. Man kann den Assistenten wegklicken! Nach der Änderung des Passwords  darf man auf Wunsch gleich loslegen ohne sich durch einen Nerf-Dialog zu klicken. Standardmäßig ist Telnet und HTTP als “Fernwartung” aktiviert. Das kann man aber einfach umkonfigurieren. SSH und HTTPS werden angeboten. Beide Varianten haben kleine Haken. HTTPS verwendet “fest” eingebrannte selbst signierte Zertifikate (und ich würde wetten, dass die priv Keys nur pro Version-Build unterschiedlich sind). Will man dieses austauschen muss man gleich eine eigene Firmware einspielen da der /etc Bereich read-only gemounted ist. SSH bietet hingegen die Möglichkeit die Zertifikate zu ändern. Standardmäßig logt man sich dort hingegen als root ein. Da ist Vorsicht bei den Passwörtern geboten!

Neben diesen beiden “Fehlern” fällt nur noch der Umstand auf, dass die Konfigurationsoberfläche stark auf den Betrieb eines Gateway-Routers ausgelegt ist. Hat man sich damit einmal abgefunden und verstanden, dass das br0-Interface (intern werden Birdges verschaltet) immer “das Interne”-Interface ist, entfaltet sich eine Konfiguationsvielfalt, die man sonst nur bei hochpreisigen Konkurrenten findet. Ein Beispiel: um auf den WAN – Port (eth1) zwei VLANs zu konfigurieren braucht es 3 Klicks. Will man WAN-VLAN1 ins br0-Netz bridgen ist das ein weiterer Klick. Will man nun das WLAN aus dem br0 nehmen und auf WAN-VLAN2 bridgen geht das mit unter 5 Klicks. Ohne auch nur ein mal das SSH-Terminal zu nutzen. Auf diesem Niveau geht es weiter. Statische Routen, sehr detaillierte Interface-Konfigurationen, fast alle Services und diverse Hilfseinstellungen lassen sich über das WebInterface bequem und umfangreich konfigurieren.

Ich hab den SSH-Zugang dennoch häufig genutzt. Das hat drei Gründe:

• Die Zeit die man zum Konfigurieren braucht: alle Einstellungen erfordern das Schreiben in den NVRam, das anschließende auslesen dieser Informationen und das durchstartet des betroffenen Dienstes. Da DD-WRT aber nicht “weiß” welcher Dienst betroffen ist, wird alles durchgestartet. Beispiel: ändert man an der PPPoE Einstellung etwas, werden mal ebend alle Dienste durchgestartet auch der Routing-Dienst (BIRD/ZEBRA). Der Router ist erst mal eine Weile beschäftigt. Wird ein Routing-Dienst eingesetzt und befindet man sich außerhalb der direkten Router-Netze muss man erst mal warten, bis  die Routing-Tabellen wieder stehen. Wenn man weiß was mach macht, kann man auf der Konsole in aller Ruhe an der Config-File rum fuschen. nur den betroffenen Dienst durchstartet und wenn alles wie gewünscht funktioniert, alles in den NVRam speichern.
• Einige exotische Einstellungen kann man “nur” über die Konsole machen. Das WebInterface bietet zwar die Möglichkeit 3 Skriptes zu hinterlegen (StartUp, FirewallUp,ShutDown) und direkt Konsolen-Befehle auszuführen, mir fehlt hier aber das Feedback. Ich hab die Skriptes immer erst im Terminal ausprobiert und dann als Skript hinterlegt.
• Einige Eingabemasken führen quasi eins zu eins auf ein Config-File für einen Dienst. Startet man dann durch und hat einen Syntax-Fehler bekommt man keine Rückmeldung. Auch hier gilt: erst auf der Konsole ausprobieren und dann hinterlegen.

Bei den ganzen Konfigurations-Möglichkeiten sollte noch erwähnt werden, dass alle Interfaces frei konfigurierbar sind. Selbst wenn das WebInterface dann ein wenig zickt. Es werden alle Ethernet und WLan Ports einzeln an das OS gemeldet. Im Falle des AG300H (DualBand) muss man den 2.4Ghz Adapter getrennt vom 5GHz konfigurieren (auch im WebInterface). Einzig die internen LAN-Ports werden durch eine nicht konfigurierbaren Hardware-Switch verschaltet. So muss man ein wenig aufpassen was man am eth0-Port macht.

Was bleibt abschließend zu sagen? Ich bin vom Funktionsumfang der Firmware sehr positiv überrascht. Es wird einem fast alles geboten, was man so braucht. Für alles andere gibt es das SSH-Terminal.  Der WNR3500 war wohl mein letzter nicht WRT Router gewesen sein.