Okt 26

[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:

Oct 24 14:03:30 macpro2 kernel[0]: 0x1face000, 0x00000000  Intel82574L::setLinkStatus - not active
Oct 24 14:03:30 macpro2 kernel[0]: 0x1face001, 0x00000000  Intel82574L::setLinkStatus - not active
Oct 24 14:03:32 macpro2 kernel[0]: Ethernet [Intel82574L]: Link up on en1, 1-Gigabit, Full-duplex, Symmetric flow-control, Debug [796d,af08,0d01,0200,cde1,3c00]
Oct 24 14:03:32 macpro2 kernel[0]: 0x1face001, 0x0000000b  Intel82574L::setLinkStatus - active
									

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:

kextstat |grep -v apple
Index Refs Address            Size       Wired      Name (Version) <Linked Against>
   41    0 0xffffff7f81e1f000 0x19000    0x19000    net.osx86.kexts.GenericUSBXHCI (1.2.6) <38 12 7 5 4 3>
  130    3 0xffffff7f833c7000 0x57000    0x57000    org.virtualbox.kext.VBoxDrv (4.3.18) <7 5 4 3 1>
  131    0 0xffffff7f8341e000 0x8000     0x8000     org.virtualbox.kext.VBoxUSB (4.3.18) <130 79 38 7 5 4 3 1>
  132    0 0xffffff7f83426000 0x5000     0x5000     org.virtualbox.kext.VBoxNetFlt (4.3.18) <130 7 5 4 3 1>
  133    0 0xffffff7f8342b000 0x6000     0x6000     org.virtualbox.kext.VBoxNetAdp (4.3.18) <130 5 4 1>

									

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:

cd /System/Library/Extensions

									

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

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

sudo kextunload /System/Library/Extensions/NAME_OF_THE_KEXT_FILE.kext
sudo rm /System/Library/Extensions/NAME_OF_THE_KEXT_FILE.kext
									

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.

Tagged with:
Jun 23

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

function FindProxyForURL(url, host)
{
        if (isInNet(host, "10.0.0.0", "255.255.255.0")) { // ipv4 im LAN ? Dann direct
                return "DIRECT";
        }
        if (host.substring(0, 4) == "127.") { // Localhost ? dann DIRECT
                return "DIRECT";
        }
        if (host.substring(0,16) == "2001:999:999:8888") { // IPv6 Adresse in den Browser eingegeben, und die ist im LAN ? Dann DIRECT
                return "DIRECT";
        }
        try {
            var resolved_ip = dnsResolveEx(host);
            if (resolved_ip.indexOf("2001:999:999:8888")>-1 ) { // Hostname löst auf eine IPv6 auf, die im LAN ist ? Dann DIRECT
                    return "DIRECT";
            }
        } catch(e) { // Funktion "dnsResolveEx" nicht vorhanden ? Dann Fallback proxy
            return "PROXY 10.0.0.2:3128";
        } 
        return "PROXY 10.0.0.2:3128"; // Default: Proxy
}

									

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…

Tagged with:
preload preload preload