wie wir ja alle wissen, ist nicht alles gold, was glaenzt. wie schon geschrieben, habe ich auf meinem weissen macbook ein update auf osx snow leopard gemacht.
die original cd die ich hatte, war natuerlich nur die version 10.6, welche wie zu erwarten mit fehlern behaftet war. nicht umsonst habe ich ein paar wochen gewartet, bis die fehler bereinigt sind. aktuell ist die 10.6.2, welche ich jetzt auch drauf habe. das problem war, dass ich erstmal ein ethernet kabel dranstoepseln musste, um mir das update auf 10.6.2 zu ziehen, da das wlan nicht mehr funktionierte.
auf den ersten blick scheint fast alles zu funktionieren. nur mein launch2net fuer den mobilen internetzugang per umts verweigerte den dienst.
nach eingabe des kennworts passierte nichts. die loesung des problems war schnell gefunden. anchliessende tests mit umts deckten ein anderes verhalten z.b. von ping unter snow leopard auf:
64 bytes from 80.xx.xx.xx: icmp_seq=7 ttl=48 time=162.567 ms
Request timeout for icmp_seq 8
Request timeout for icmp_seq 9
Request timeout for icmp_seq 10
Request timeout for icmp_seq 11
Request timeout for icmp_seq 12
64 bytes from 80.xx.xx.xx: icmp_seq=9 ttl=48 time=4373.707 ms
64 bytes from 80.xx.xx.xx: icmp_seq=10 ttl=48 time=3475.756 ms
64 bytes from 80.xx.xx.xx: icmp_seq=11 ttl=48 time=2476.617 ms
64 bytes from 80.xx.xx.xx: icmp_seq=12 ttl=48 time=1528.739 ms
64 bytes from 80.xx.xx.xx: icmp_seq=13 ttl=48 time=531.465 ms
frueher waren verlorene pakete nur anhand fehlender nummern in der icmp sequenz zu entdecken. jetzt werden die verlorenen pakete als timeout angezeigt. merkwuerdig nur, dass doch eine antwort kommt, wenn vorher ein timeout ausgegeben wurde (in dem oben gezeigten beispiel die sequenznummern 9 bis 12). kann man sicherlich mit einer der unzaehligen kommandozeilen parameter ausbuegeln, ist aber fuer ein “standard verhalten” unschoen.
viel weiter kam ich bis jetzt noch nicht. aber ich kann mir schon vorstellen, dass ich das ein oder anderen noch zu der integrierten exchange anbindung zu berichten habe 😉
