Monat: Oktober 2013

Die Pipeliningfunktion vom Firefox ist ein alter Hut, ja. Es ist ein so alter Hut dass man es schon fast wieder vergessen hat. Einmal im Firefox aktiviert schiebt es die Webseiteninhalte „gleichzeitig“ auf den Computer und somit gefühlt etwas schneller. Jetzt sind die Meisten ja irgendwann mal beim Google Chrome hängen geblieben und man muss einfach neidlos anerkennen: Das Teil ist rattenschnell….
Google…. Google ist toll aber wer ist bei Google die Ware? Genau wir! Nun blocken einige Benutzer ganz freudig Cookies im Browser um zumindest ein klein bisschen etwas gegen die Datensammelwut und das einblenden der „personalisierten“ Werbung zu tun. Da kommt Google und baut (ganz schlau) einen Weg ein den Benutzer denn noch zu packen: http://bits.blogs.nytimes.com/2013/09/19/google-is-exploring-an-alternative-to-cookies-for-ad-tracking/

Also doch wieder Firefox oder Midori oder oder?!?!? Japp :-/ Dann aber bitte mit Pipelining, damit es etwas flotter geht. Ach ja, so geht es an:

In der Adresszeile vom Firefox die Seite: about: config aufrufen und die Meldung mit: „Ja ja, ich bin vorsichtig“ abnicken (nein, nicht das Reh). Nun in der Suche einfach folgenden Begriff einwerfen: „pipelining“. Nun Sollten sich in der Anzeige nur noch ca. 11 Einträge befinden. Hier bei den unten stehenden Einträgen durch einen Doppelklick dafür sorgen das aus false ein true wird. Firefox schließen und fertig ist.

network.http.pipelining – true
network.http.proxy.pipelining – true
network.http.pipelining.ssl – true

Wenn man jetzt noch möchte kann man unter: Bearbeiten Einstellungen Erweitert Allgemein den Sanften Bildlauf / smooth scrolling deaktivieren. Viel Erfolg!

Ok ok, dass die Zeitumstellung sinnfrei ist, habe ich vor Jahren schon verstanden und ist wohl inzwischen auch bei den meisten anderen „Betroffenen“ angekommen. Wie nervig es sein kann ist mir erst als Vater klar geworden. Ich habe zwar lange versucht meiner 14 Monate alten Tochter das Thema näher zu bringen… Es wurde aber ignoriert. 5:30 Uhr ist nun Action in der Bude!

Können wir das Thema Zeitumstellung bitte abschaffen? Also jetzt? Bitte? Es nervt!

Nur damit ich es bei der nächsten Anfrage zu diesem Thema schön verlinken kann, denn es scheint ein Standardproblem zu sein….

Wenn jemandem also auffällt dass in seinem Kernel oder Syslog Meldungen aufschlagen wie:

Oct 24 16:34:12 hostname kernel: [786717.368688] rt6_redirect: source isn't a valid nexthop for redirect target
Oct 24 16:35:30 hostname kernel: [786795.230542] rt6_redirect: source isn't a valid nexthop for redirect target
Oct 24 16:36:11 hostname kernel: [786836.309684] rt6_redirect: source isn't a valid nexthop for redirect target
Oct 24 16:36:45 hostname kernel: [786870.407123] rt6_redirect: source isn't a valid nexthop for redirect target
Oct 24 16:36:45 hostname kernel: [786870.628257] rt6_redirect: source isn't a valid nexthop for redirect target
Oct 24 16:39:09 hostname kernel: [787014.210067] rt6_redirect: source isn't a valid nexthop for redirect target
Oct 24 16:40:15 hostname kernel: [787080.322571] rt6_redirect: source isn't a valid nexthop for redirect target
Oct 24 16:41:41 hostname kernel: [787166.667404] rt6_redirect: source isn't a valid nexthop for redirect target
Oct 24 16:43:30 hostname kernel: [787275.473179] rt6_redirect: source isn't a valid nexthop for redirect target
Oct 24 16:43:32 hostname kernel: [787277.498606] rt6_redirect: source isn't a valid nexthop for redirect target
Oct 24 16:43:32 hostname kernel: [787277.498613] rt6_redirect: source isn't a valid nexthop for redirect target
Oct 24 16:43:32 hostname kernel: [787277.584353] rt6_redirect: source isn't a valid nexthop for redirect target
Oct 24 16:43:39 hostname kernel: [787284.396245] rt6_redirect: source isn't a valid nexthop for redirect target

Dann hast du das RFC nicht gelesen! Für das normale Next Hop Routing ist bei IPv6 IMMER die link-local Adresse des Routers zu benutzen und NICHT die Global Unicast IP.

Kontrolle Kontrolle….. Ganz einfach wenn euch folgender Befehl etwas anderes als die fe80 Adresse eures lokalen Router auswirft, dann ist es in 99% der Fällt falsch:

$ ip -6 route show default
default via fe80::20c:42ff:fe72:2ba6 dev eth0 proto static metric 1

Kennt man die Adresse des Routers nicht, hat man die Möglichkeit sie recht einfach zu erfragen, denn Router antworten auf einen ping einer bestimmten Adresse. Möchte ich als wissen, welcher Router hinter meinem eth0 steht:

$ ping6 -c 5 ff02::2%eth0
PING ff02::2%eth0(ff02::2) 56 data bytes
64 bytes from fe80::1: icmp_seq=1 ttl=64 time=40.8 ms
64 bytes from fe80::1: icmp_seq=2 ttl=64 time=24.1 ms
64 bytes from fe80::1: icmp_seq=3 ttl=64 time=0.602 ms
64 bytes from fe80::1: icmp_seq=4 ttl=64 time=0.542 ms
64 bytes from fe80::1: icmp_seq=5 ttl=64 time=0.578 ms

--- ff02::2%eth0 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4000ms
rtt min/avg/max/mdev = 0.542/13.344/40.848/16.508 ms

Um das eigentliche Problem besser zu verstehen hilft es den Redirect Punkt besser zu verstehen. Zuerst ICMP Redirect gab es auch bereits bei IPv4… Es ist nichts weiter als eine GAAANZZ alte Version eines Routing „Protokolls“. Über diesen Weg teilt einem der Router eine „bessere“ Route zu einem Ziel mit. Bei einem Router ist es verständlicherweise witzlos bei mehreren „kann“ es helfen. Ich denke aber sauber konfiguriert wäre besser. Wie kommt es nun zu diesem Logeintrag? Ganz einfach…. Ist die IPv6 default Route zum Next Hop nicht, wie vorgeschrieben, die fe80 Adresse des Routers (bei nicht Next Hop Routing natürlich nicht) erreicht der Client den Router und somit die gerouteten Netze (Internet)… Vorausgesetzt der Client hat bereits eine Adresse, welche es ihm ermöglicht den Router überhaupt zu erreichen. Eine fest eingestellt öffentliche IPv6 Adresse zum Beispiel (wenn man hier weiter denkt wird einem schnell klar, dass es schon falsch sein muss nicht die fe80 zu nehmen). ABER wenn der Client nun so seinen Weg über den Router nimmt und dieser dann versucht einem eine „bessere“ Router per ICMP Redirect zu übermitteln, wird der Router hier nicht die fe80 eintragen, sondern die Angesprochene öffentliche. Dieses ist falsch, wird vom Client erkannt und ins Logfile geschrieben!

Nun lassen sich diese Logmeldungen natürlich abschalten, wenn man seinem Client mitteilt, dass er bitte alle ICMPv6 Redirect Messages ignorieren soll, korrekt konfiguriert ist das eigenen Next Hop Routing damit leider noch immer nicht 😀 OK ok… Angreifen könnten natürlich versuchen die ICMP Redirect Messages zu nutzen um einen Angriff zu fahren, denn jeder kann diese Meldungen senden. Damit dieser greift müsste dieser Angreifer im gleichen fe80 (denn nur diese würden vom Client ja genutzt) sitzen. Was bedeutet „am gleichen“ Switch. Ist der Angreifer dort hat er noch 10000 andere Möglichkeiten, gegen welche man sich absichern sollte. Dieses zur Vollständigkeit, da es gerade im speziellen um die Logmeldung geht, gibt es dazu ein anders mal genaueres 😀

Mehr zum Abschalten bis dahin hier:

http://askubuntu.com/questions/118273/what-are-icmp-redirects-and-should-they-be-blocked

So long….

Da versuche ich gerade mein Windows 8 auf Windows 8.1 in der VirtualBox zu heben, da springt mich unverhofft eine Meldung an. Ich könne Windows 8.1 nicht installieren da mein Prozessor CompareExchange128 nicht unterstützt.

CompareExchange 128? Das kommt mir im Zusammenhang mit C/C++ und dem Compiler irgendwie bekannt vor. Ich hatte da mal etwas mit einer Binary unter einem FreeBSD. Hing zusammen mit einer AMD64 CPU und noch irgendwas… Gott, warum kann ich mir so einen Mist nicht merken. Aber ich habe in meiner aktuellen Kiste eine Intel CPU. Wobei es wohl eher mit 64Bit als mit dem CPU Hersteller zu schaffen hat. Kann mich da bitte noch mal jemand schlau machen?

Öhm wie auch immer ich erinnere mich daran dass irgendeine recht kryptisch aussehender „Befehlssatz/Anweisung“ im Prozessor genutzt werden sollte. Das Programm auf dem FreeBSD war irgendwie sehr Hardwarenahe übersetzt worden….. 😛

Google brachte mich auf den richtigen Weg, nachdem ich es mit: FreeBSD Compareexchange 128 und AMD64 gefüttert hatte. Plöp: http://en.wikipedia.org/wiki/X86-64 und CMPXCHG16B instruction.

Meine CPU:

$ cat /proc/cpuinfo |grep "model name"|uniq
model name : Intel(R) Core(TM) i5-3450 CPU @ 3.10GHz

Kann diese instruction aber und ich wüsste jetzt nicht das mein Bios oder Hostkernel es abschaltet (warum auch?). AAABBBER vielleicht muss man es für VirtualBox einschalten?!? Ok also VBoxManage und öhm sicherlich VBoxInternal und ich würde es bei CPUM?/device? Vermuten… Ach noch mal Google fragen!

Google bringt mit den Worten: CMPXCHG16B und VirtualBox auch direkt ein passendes Ergebnis!

$ VBoxManage setextradata "Windows 8 " VBoxInternal/CPUM/CMPXCHG16B 1

Tja, was soll ich sagen? Geht 🙂 Gefühlt habe ich mich mit dem Thema schon wieder zu lange beschäftigt und vor allem zu oft Google fragen müssen (ich bin so schlecht). Also tippe ich mal CompareExchange128 CPU und Instruction hier hin. Dann erinnere ich mich sicher daran es mal hier hin geschrieben zu haben .o0(oder auch nicht).

Ja, es sollte Standard sein, es war aber bis heute nicht aktiviert. Jetzt werden meine Seiten erst mit gzip komprimiert und dann an euren Browser ausgeliefert. Euer Browser muss sie dann noch entpacken! Davon solltet ihr aber nichts merken….. Warum das alles? Da gibt es mehrere Gründe:

1. Komprimierte Daten verbrauchen weniger Platz auf der Leitung.

2. Komprimierte Daten sind kleiner uns damit schneller übertragen.

3. Weder der Server noch euer Rechner muss wirklich CPU-Zeit aufbringen um die Daten zu packen/entpacken.

4. Die Webseiten werden bei euch schneller angezeigt.