CC::Blog

Schlagwort: lan

  • OSX Yosemite verliert nach dem Wakeup das Netz

    [Update 01.11.2014:] Klang alles vielversprechend, hat aber gerade mal 3 Tage WakeUp gehalten Lösung also leider noch nicht gefunden

    Nach dem ich meinen Mac auf Windows8 OSX Yosemite geupdated habe, ging nach einem WakeUp, netzwekmässig, überhaupt nichts mehr.

    War schon so gefrustet, dass ich dachte ich müsste Clean-Install machen, oder aber auf ein anderes OS wechseln. Das ganze hat sich im system.log und Allgemein so geäussert, dass die NIC nach einem WakeUp für ein paar Millisekunden da war, und dann wieder weg (was die Funktionalität angeht). In den Systemeinstellungen sah die ganze Zeit über alles fein aus: IP, Interface war up, etc. Aber halt so gar keine Connectivity. Auszug syslog:

    [codebox 1]

    Nach ein paar Anfragen bei stackoverflow kam ich auch nicht wirklich weiter. Irgendwann bin ich dann auf einen Beitrag gestossen, wo jemand über das Problem berichtete, dass sein Mac immer dann abstürzte, wenn er in die Soundeinstellungen ging. Das Problem wurde dadurch gelöst, dass er die Kernel-Extension (kext) von Soundflower deinstalliert hatte. Hab ich dann hier (obwohl ganz anderes Problem) auch mal gemacht. Zusätzlich hab ich noch alles andere an kexts deinstalliert, was nicht notwendig war. Vendorfremde kexts neigen bei ’nem Major-Update zum Amoklauf. Eine Liste, welche kexts bei Euch NICHT von Apple kommen gibts es wie folgt:

    [codebox 2]

    Die oberste kext benötige ich für USB3.0 (funktioniert auch unter Yosemite noch), die anderen 4 sind von Oracles VirtualBox. Mit denen funktioniert nun wieder alles. Vorher war noch Soundflower und noch irgendein Kram dabei. Idealerweise deinstalliert man die Dinger mit dem – der Soft hoffentlich beiliegenden – Uninstaller. Ist der nicht vorhanden kann man die Dinger auch per Hand töten. Seit OSX Lion muss man dafür nicht mal den Kernel-Extension-Cache neu aufbauen. Funktioniert wie folgt:

    [codebox 3]

    Mit ls die passende Extension, die man löschen will, suchen.

    Anschliessend kext „unloaden“ (d.h. aus dem RAM entfernen) und löschen:

    [codebox 4]

    War ’ne harte Nuss, zumal so gar kein Hinweis auf die (amoklaufenden) Extensions im Syslog oder Kernel-Ring-Buffer (dmesg) auftauchten. Nu tut der Mac wieder wie er soll. Nichts desto trotz denke ich, dass es langsam Zeit wird, sich nach einem anderen OS umzusehen. Die Schmerzen (und die Ähnlichkeit zu Windows) werden immer grösser.

  • IPv6 mit Safari und einer wpad.dat

    Die Konfig hier zu Haus sagt, gehe über den Proxy – egal was passiert. Per iptables ist es den Workstations verboten, direkte HTTP-Requests nach draussen abzusetzen. Die werden einfach gedroppt. Damit man jedoch nicht bei jedem neuen Client erst den Proxy eintragen muss, gibt es so schöne Erfindungen wie wpad.dat (aka proxy.pac).

    Der DHCP Server im Netz announced also, bei Vergabe einer ip, gleich die URL fuer die Proxy-Autoconf mit. In der Regel klappt das auch alles super. Hätte nicht jeder Browserhersteller wieder seinen eigenen Kram gebastelt. So interpretiert der Safari auf dem Mac diverse Dinge anders als der Chrome oder der IE. Eine schöne Matrix, mit dem was geht, und was nicht geht, gibt es bspw. bei pacwpad.com.

    Die Herausforderung bestand/besteht am Ende darin, den Browsern zu sagen: Hey, du willst was im LAN, dann brauchst Du den Proxy nicht zu fragen. Ansonsten bitte Proxy nehmen. Mit ipv4 kein Thema. Bei ipv6 verschluckt sich der Safari jedoch massivst.

    In der folgenden Config bin ich nun soweit, dass Chrome brav das macht was er soll, Safari jedoch bei jeglichen (auch LAN) ipv6-only Websites immer über den Proxy geht. Das liegt daran, dass der Safari scheinbar die javascript-Funktion „dnsResolveEx“ nicht kennt. Ohne try/exception macht der immer einen auf „direct“ bei ipv6. Mit diesem Konstrukt geht er zumindest immer auf den Proxy. Bin mal gespannt, wie lange es dauert bis sich die Browserhersteller da geeinigt haben…

    Hier also die Config:

    • LANv4 ist 10.0.0.0/24
    • LANv6 ist 2001:999:999:8888/64

    [codebox 1]

    Update: Es empfiehlt sich anstelle der IP (10.0.0.2:3128) den FQDN des Proxies einzutragen. Einige Geräte machen scheinbar einen lookup bevor sie den Proxy fragen. Wenn beim lookup eine V6 Adresse herauskommt, dann läuft die wpad.dat ins leere, da kein V6-Proxy gefunden wird. Wichtig: der FQDN des Proxies sollte sowohl über einen V4-Eintrag (A), als auch über einen V6-Eintrag (AAAA) verfügen, und auch zusätzlich auf dem V6-Port lauschen…