OpenWRT WIFI Channel 12 und 13

Wenn iw list in der Konsole von OpenWRT

                        ...
                        * 2467 MHz [12] (disabled)
                        * 2472 MHz [13] (disabled)
                        * 2484 MHz [14] (disabled)
                        ...

zurück liefert, gibt es dank ~jow einen Binary patch für OpenWRT.

Finden kann man den Patch in seinem Userdir http://luci.subsignal.org/~jow/reghack/old/.

Für den Fall das jow’s Seite einmal offline geht, gibt es hier eine Kopie der Dateien in einem 7z-Archiv.

Gefunden habe ich den Link im Bugtracker von Openwrt.org

Ausgabe während des Patchens auf meinem TP-Link TL-WR1043ND,

 cd /tmp/
root@OpenWrt:/tmp# wget http://luci.subsignal.org/~jow/reghack/reghack.mips.elf
Connecting to luci.subsignal.org (188.40.166.7:80)
reghack.mips.elf     100% |*******************************| 46156   0:00:00 ETA
root@OpenWrt:/tmp# chmod +x reghack.mips.elf
root@OpenWrt:/tmp# ./reghack.mips.elf /lib/modules/*/ath.ko
mmap(): Invalid argument
Memory mapping failed (missing fs support?), retrying from tmpfs
Patching @ 0x000002f0: ath_is_radar_freq() MIPS opcode in ath/regd.o
Patching @ 0x000003fc: ath_is_radar_freq() MIPS opcode in ath/regd.o
Patching @ 0x0000342c: ath world regdomain with 5 rules in ath/regd.o
Patching @ 0x000034cc: ath world regdomain with 4 rules in ath/regd.o
Patching @ 0x00003550: ath world regdomain with 4 rules in ath/regd.o
Patching @ 0x000035d4: ath world regdomain with 5 rules in ath/regd.o
root@OpenWrt:/tmp# ./reghack.mips.elf /lib/modules/*/cfg80211.koreboot
stat(): No such file or directory
root@OpenWrt:/tmp# ./reghack.mips.elf /lib/modules/*/cfg80211.ko
mmap(): Invalid argument
Memory mapping failed (missing fs support?), retrying from tmpfs
Patching @ 0x0002589c: core world6 regdomain in cfg80211/reg.o
Patching @ 0x000267ac: embedded US regdomain in cfg80211/regdb.o
Patching @ 0x0002ae30: embedded 00 regdomain in cfg80211/regdb.o

Ergebnis des Patchens:

                        * 2467 MHz [12] (30.0 dBm)
                        * 2472 MHz [13] (30.0 dBm)
                        * 2484 MHz [14] (disabled)

Wie man sieht habe ich die Binaries genutzt, der Aufwand die Module selbst zu bauen wäre mir zu groß. Danke an ~jow.

UPDATE:
OpenWRT Chaos Calmer 15.05-rc1 wurde veröffentlicht. Das OpenWRT Team hat sich dazu entschieden das ganze zu fixen. Sie haben wohl die letzten Jahre auf einen Fix vom Hersteller gewartet, da weiterhin nichts kommt und es immer mehr Bug reports werden, kann man nun die eingestellte eeprom Zone per

# iw reg get
country 00: DFS-UNSET
        (2402 - 2472 @ 40), (N/A, 20), (N/A)
        (2457 - 2482 @ 40), (N/A, 20), (N/A), PASSIVE-SCAN
        (2474 - 2494 @ 20), (N/A, 20), (N/A), NO-OFDM, PASSIVE-SCAN
        (5170 - 5250 @ 80), (N/A, 20), (N/A)
        (5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, PASSIVE-SCAN
        (5490 - 5730 @ 160), (N/A, 20), (0 ms), DFS, PASSIVE-SCAN
        (5735 - 5835 @ 80), (N/A, 20), (N/A), PASSIVE-SCAN
        (57240 - 63720 @ 2160), (N/A, 0), (N/A)

abfragen und über set, also

# iw reg set DE
# iw reg get
country DE: DFS-ETSI
        (2400 - 2483 @ 40), (N/A, 20), (N/A)
        (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR
        (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
        (5470 - 5725 @ 160), (N/A, 27), (0 ms), DFS
        (57000 - 66000 @ 2160), (N/A, 40), (N/A)

über die shell lösen.

IPv6 über DHCP an KVM Gäste verteilen

It’s magic.

# cat /etc/network/interfaces
### Hetzner Online AG - installimage
# Loopback device:
auto lo
iface lo inet loopback
 
# device: eth0
auto  eth0
iface eth0 inet static
  address   XXX.XXX.XXX.131
  broadcast XXX.XXX.XXX.191
  netmask   255.255.255.192
  gateway   XXX.XXX.XXX.129
  # default route to access subnet
  up route add -net XXX.XX.XXX.128 netmask 255.255.255.192 gw XXX.XXX.XXX.129 eth0
 
iface eth0 inet6 static
  address 2a01:AAA:AAA:AAA::1
  netmask 128
  gateway fe80::1
# Enable forwarding
    pre-up echo 1 > /proc/sys/net/ipv6/conf/default/forwarding
    pre-up echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
# But disable forwarding on THIS interface so we still get RAs
    pre-up echo 0 > /proc/sys/net/ipv6/conf/eth0/forwarding
    pre-up echo 1 > /proc/sys/net/ipv6/conf/eth0/accept_ra
    pre-up echo 1 > /proc/sys/net/ipv6/conf/all/accept_ra
    pre-up echo 1 > /proc/sys/net/ipv6/conf/default/accept_ra
 
auto br0
iface br0 inet6 static
  pre-up brctl addbr br0
  post-down brctl delbr br0
  bridge_stp off
  address 2a01:AAA:AAA:AAA::1
  netmask 64

Die pre-up echo’s sind ein workaround, da nur entweder accept_ra ODER forwarding funktioniert. Genaueres findet man hier.

Als DHCP habe ich den wide-dhcp6-server genommen.

#cat /etc/wide-dhcpv6/dhcp6s.conf
option domain-name-servers 2a01:4f8:0:a0a1::add:1010;
option domain-name-servers 2a01:4f8:0:a111::add:9898;
option domain-name-servers 2a01:4f8:0:a102::add:9999;
 
interface br0 {
        address-pool pool1 3600;
};
 
pool pool1 {
        range 2a01:AAA:AAA:AAAA::0000 to 2a01:AAA:AAA:AAAA::ffff;
};

Damit die auto_ra funktioniert, setzte ich radvd ein, mit dieser Konfig:

interface br0
{
        AdvManagedFlag on;
        MinRtrAdvInterval 3;
        MaxRtrAdvInterval 10;
        AdvSendAdvert on;
 
  prefix 2a01:AAA:AAA:AAA::/64
  {
                AdvOnLink on;
                AdvAutonomous on;
                AdvRouterAddr on;
  };
};

Bei der Umsetzung hat mir dieser Wiki Eintrag bei Hetzner geholfen.

Realtek Sound parallel auf Lautsprecher und Kopfhörer

Nachdem ich nun 2 Tage lang das Internet und den ASUS Support bemüht habe habe, um zu erfahren wie ich die parallele Wiedergabe auf Kopfhörern und Lautsprechern gleichzeitig einstellen kann, fand ich nach der folgenden Antwort des ASUS Supports:

Sehr geehrter Hr. Müller,

die simultane Ausgabe des Tonsignals über die Rückseitigen- und die Frontanschlüsse ist nicht möglich.

Mit freundlichen Grüßen

Technical Support Division ASUS Germany

selbst die Lösung. Offensichtlich ist ASUS selbst nicht bekannt, dass oben angesprochenes funktioniert.

Hier eine kleine Bebilderung.

Bild 1 zeigt den Realtek Soundmanager und die Abfolge der klicks, bei 3. muss nach einem Rechtsklick auf „Anschluss-Neuverteilung“ geklickt werden. Bild 2 zeigt, auf was der Front-Audio Anschluss eingestellt werden muss.
Dieses Spielchen kann man für alle Ausgänge wiederholen, auf denen man die Lautsprecherausgabe hören möchte.

Der Weg zu einem Stromsparwunder

Um den Strombedarf eines Mobilen Computers (Note-/Netbook) zu reduzieren hat man ja generell nur die Möglichkeit die Hintergrundprozesse zu reduzieren, um weniger Aktivität auf der CPU zu haben. Doch man kann noch viel viel mehr tun, um die Laufzeit seines mobilen Begleiters zu verlängern.

Ich bin derzeit dabei an meinem Notebook den Strombedarf meines Notebooks rigoros zu reduzieren. Angefangen habe ich bei 1h 55Min. Akkulaufzeit, der Akku verfügt über 58Wh Gesamtkapazität.

Ich will nun versuchen auf alle Facetten einzugehen, die ein möglichst effektives Stromsparen anhand meines Notebooks zu ermöglichen.
Aber Achtung: PCI-Express und SATA Controller haben zusätzliche Stromsparfunktionen, auf die ich aber mangels Existenz in meiner Hardware hier nicht weiter eingehen werde.

Bislang habe ich mit Hilfe von powertopProzesse identifiziert, die die CPU unnötig wecken(<C4). Dadurch bin ich nun bei aktiviertem WLAN bei 14-15 Wake-Ups pro Sekunde, bei deaktiviertem bei ~5Wake-Ups/Sek.

Auf dem Weg zum leisen,kühlen und stromsparenden Notebook, habe ich die /lib/hdparm/hdparm-functions dahingehend geändert, dass die HDD im AC- und im Akkubetrieb mit einem APM(Advanced Power Management) Wert von 192 laufen.
Um die Zeilen zu finden, kann man nach „-B254“, „-B128“ oder einfach „-B“ suchen. 192 nutze ich in meinem Fall, da meine HDD (eine Seagate Momentus 5400) den „193 Load_Cycle_Count“ extrem schnell erhöht (3-4 pro Minute).
Wer sich für die Hintergründe interessiert, kann gerne mittels google danach suchen.
Nach 25Sekunden Leerlaufzeit lasse ich die HDD in den Standby-Modus gehen. Das kann man umsetzen durch den Befehl hdparm -S5 /dev/sda, oder wie ich mit in die hdparm-functions vor dem zuvor genannten „-B“. Der Vorteil dabei ist, dass man den dort genutzten Wechsel zwischen Akku und Netzteilversorgung auch gleich nutzen kann um bei Netzspeisung die Festplattenabschaltung zu deaktivieren.

Um die Festplattenabschaltung zu komplett zu machen, habe ich unter /etc/pm/config.d/ eine Datei endend auf „.conf“ angelegt und folgendes eingefügt:

JOURNAL_COMMIT_TIME_BAT=600
JOURNAL_COMMIT_TIME_AC=20
LAPTOP_MODE=600
LAPTOP_DIRTY_RATIO=40
LAPTOP_DIRTY_BG_RATIO=80
LAPTOP_DIRTY_WRITEBACK=600000
DRIVE_READAHEAD_AC=256
DRIVE_READAHEAD_BAT=6144

Dadurch wird versucht die Schreibzyklen auf die Festplatte um bis zu 10Minuten hinaus zu zögern.
Nachteil: Alle Änderungen werden in den Speicher geschrieben, wodurch man natürlich auch einen Datenverlust von bis zu 10Minuten in Kauf nimmt. Jedesmal wenn man von der Festplatte lies springt die Festplatte natürlich auch an.

Als nächstes habe ich die Wärmeleitpaste der CPU ausgetauscht. Das Dell Notebook von mir hat seine CPU unter der Tastatur sitzen. Dementsprechend einfach kommt man daran. Der Kühler hatte ein Alupapier unter der alten Wärmeleitpaste. Das habe ich ebenfalls entfernt und dahinter den Kühlkörper von dieser alten Schicht Wärmeleitpaste ebenfalls gereinigt. Danach habe ich das Alupapier mittels Wärmeleitpaste wieder am Kühlkörper befestigt, anschliessend auf die CPU ebenfalls einen Klecks getan und das ganze wieder zusammen gebaut.

Geholfen hat es auch, die Temperatur im Leerlauf ging um 6°C (auf 31°C) zurück, die Temperatur bei Vollauslastung liegt nun bei 58°C anstelle von 70°C. Wenn man bedenkt, dass der Kühler vom Mainboard nur 3 Geschwindigkeitsstufen hat und dieser bei 50°C auf 1 und bei 70°C auf Stufe 2 läuft (0 = aus), ist von der Geräuschkulisse der Unterschied bereits jetzt immens.

Mittlerweile hält der Akku im Idle Betrieb 2h 35Min.

Im nächsten Beitrag werde ich auf die Zentrale Möglichkeit der Temperatursenkung, Geräuschreduzierung und Stromverbrauchreduzierung, genannt „CPU Undervolting“ eingehen.
Soviel sei schon gesagt, der Akku wird bei mir derzeit mit 4h 10Min Laufzeit angezeigt.

G-Data Antivirus 2011 vs. OpenWRT Backfire 10.03

Vor einigen Monaten (ich glaube im Juli) hab ich ja Kasperskys Internet Security Suite bedingt durch eine kostenfreie Lizenz in der Computerbild-Spiele angetestet. Nun habe ich mich vor, na ca. 2Wochen an GData Antivirus herangewagt. Diese Antivirenlösung fand ich früher richtig klasse. Irgendwann wurde sie aber immer mehr zur 1-Click-Destroys-All Lösung, die keine vernünftigen Auswahloptionen bot, aber dafür schön bunt war.
2 Wochen lang hatte ich nun keine Probleme mit G-Data Antivirus 2011. Bis heute… ja heute hat sich das schlagartig geändert.

Ich nutze hier seit ~1Jahr einen Gigabit Router von TP-Link, das Betriebssystem der Wahl ist dabei OpenWRT und OpenWRT widerum bringt ein sauberes und sehr mächtiges Webinterface mit.

Nun eben dieses Webinterface ist der Verusacher von einem Vormittag Fehlersuche. Nachdem ich mit den Dev’s von OpenWRT gesprochen und die Kommunikation zwischen Webserver und G-Data Antivirus transparent gemacht habe(strace/tcpdump), hat es den Anschein, das G-Data Antivirus mit dessen Serverpush nicht zurecht kommt. Ich werde mich mal mit dem Support von G-Data in Verbindung setzen.

Ich hatte mir zwischendurch günstig bei ebay eine 3-PC Lizenz für GData Antivirus 2011 gekauft. Ich denke da werde ich von meinem Widerrufsrecht gebrauch machen.

1 2