WLAN-Probleme seit 10.8.3 mit rMBP

[Marc Stibane]

Seit dem Update auf 10.8.3 fällt ca. 2-3mal am Tag kurz mein WLAN aus.
Soll heißen, es gibt keinen Internetzugang mehr und der gemountete
Fileserver schmeißt eine Fehlermeldung, wo man zum Glück auf
"Ignorieren" klicken kann. Da es meist weniger als 1 Minute dauert bis
die Verbindung wieder steht, wird das Servervolume auch nicht
dismountet, sondern funktioniert danach wieder. Nur wenn gerade ein
Finder-Kopiervorgang läuft wird der abgebrochen (und es bleibt eine
kaputte Datei auf dem Server liegen).

Ich hatte vorher ein halbes Jahr lang keine solchen Probleme mit meinem
rMBP, das fing direkt nach dem Update auf 10.8.3 an. Der WLAN-Router
(Airport Extreme) wurde nicht angefasst/upgedatet, und mit einem anderen
MacBookPro (das allerdings per Ethernet-Kabel angeschlossen ist) gibt es
keine Ausfälle.

Kennt jemand das Problem, und hat evtl sogar eine Lösung?

[Patrick Kormann]

Post by Marc Stibane
Kennt jemand das Problem, und hat evtl sogar eine Lösung?

Bei mir fing es schon früher an... Frag mich nicht bei welcher Version
genau. bei der einen 10.8.4 Beta war das Problem anscheinend weg, mit
einer anderen wieder eher schlimmer.
Zusätzlich hab ich immer noch den gelegentlich flimmernden Bildschirm -
der fing ungefähr gleichzeitig an und ist mir auch bei einer der betas
nicht mehr aufgefallen...
mal sehen was noch kommt.
Was bei mir bez. WLAN helfen würde wäre, das 2.4 GHz Netz zu nehmen und
nicht das 5 GHz. Aber das ist halt langsamer.

[Klaus Behrendt]

Post by Marc Stibane
Kennt jemand das Problem, und hat evtl sogar eine Lösung?

Verwendest Du neben der Airport Extreme noch einen weiteren
(WLAN-)Router, der als DSL-Modem dient und dessen Funkschnittstelle
ebenfalls aktiv ist?

Mit einer ähnlichen Konfiguration (Time Capsule und so ein
Telekom-Speedport) habe ich mir neulich selbst ein Bein gestellt.
Idiotischweise hatte ich beiden Funknetzen denselben Namen verpasst.
Meine Macs kamen damit halbwegs klar, ein frisches iPad aber gar nicht.

Ein WiFi-Scanner brachte mich dann auf die richtige Spur...


Grüße
Klaus

[Marc Stibane]

Post by Klaus Behrendt
Verwendest Du neben der Airport Extreme noch einen weiteren
(WLAN-)Router, der als DSL-Modem dient und dessen Funkschnittstelle
ebenfalls aktiv ist?

Nein. Nur die AE. Da hängen noch 2 iPads (5GHz) und 2 iPhones (2.4GHz)
mit dran, sowie ein NAS und mein altes MBP via Ethernet. Probleme hat
einzig mein rMBP (5GHz) und das auch erst seit 10.8.3, alles andere
flutscht wie geschmiert.

[Thomas Kaiser]

Post by Marc Stibane
Seit dem Update auf 10.8.3 fällt ca. 2-3mal am Tag kurz mein WLAN aus.

Und was meint

/System/Library/CoreServices/Wi-Fi\ Diagnostics.app

dazu?

Gruss,

Thomas

[Marc Stibane]

Marc Stibane schrieb am 22.04.2013

Post by Marc Stibane
Seit dem Update auf 10.8.3 fällt ca. 2-3mal am Tag kurz mein WLAN aus.

Gestern nachmittag und heute war es eher so 1mal pro Stunde.

Und was meint
/System/Library/CoreServices/Wi-Fi\ Diagnostics.app
dazu?

Mannomann, hat das Ding ein besch...es UI. Man schaltet Debug-Protokoll
'ein', klickt auf Fortfahren, und es fragt ob es abbrechen soll...

Also, wenn das WLAN läuft, ist alles grün. Irgendwie logisch.
Ich habe mal "Benachrichtigen, wenn WLAN-Anschluss Vom Netzwerk trennen"
(die könnten auch Native-Speaker zum Test der Übersetzungen nehmen)
angeklickt. Sowie die Debug-Basisprotokolle aktiviert.
.
.
.
.
.
.
.
.
Na toll. Gerade kam wieder die Finder-Warnung (*) hoch. Also zur
WLAN-Diagnose gewechselt: nix. Steht da und macht gar nix. Sobald man
auf Fortfahren klickt, fragt er ob die Protokollierung beendet werden
soll. Das blöde Ding sollte stattdessen *jetzt* die Protokollierung
starten. Na gut, es landet ein Report auf dem Desktop.
WiFiDiagnosticReport-20130423-1101.tgz, 472kB groß
Auspacken. Drin sind 7 system.log-Dateien (als .bz2 mit den logs vom
15.4. bis heute früh 0:30 Uhr), zwei leere IPConfigurations (0 byte),
opendirectoryd.log (2KB, nix auffälliges drin) sowie ein Syslog.asl
(1.4MByte). Mit der Konsole öffnen. Ich hänge mal die letzten paar
Zeilen hier an...


(*) gemountetes NAS-Volume lost: OK, Ignore. Ich klicke immer auf
Ignore, dann versucht er es nochmal und da das WLAN ja irgendwann wieder
funktioniert bleibt das Volume auch gemountet.


Apr 23 11:00:42 rMBP.local KernelEventAgent[73] <Notice>: tid 00000000
received event(s) VQ_NOTRESP (1)
Apr 23 11:00:42 rMBP.local KernelEventAgent[73] <Notice>: tid 00000000
type 'afpfs', mounted on '/Volumes/media', from
'//***@Serverchen._afpovertcp._tcp.local/media', not responding
Apr 23 11:00:42 rMBP kernel[0] <Debug>: ASP_TCP Disconnect: triggering
reconnect by bumping reconnTrigger from curr value 48 on so
0xffffff80355d1260
Apr 23 11:00:42 rMBP kernel[0] <Debug>: ASP_TCP asp_tcp_usr_control:
invalid kernelUseCount 0
Apr 23 11:00:42 rMBP kernel[0] <Debug>: AFP_VFS afpfs_DoReconnect
started /Volumes/media prevTrigger 48 currTrigger 49
Apr 23 11:00:42 rMBP kernel[0] <Debug>: AFP_VFS afpfs_DoReconnect:
doing reconnect on /Volumes/media
Apr 23 11:00:42 rMBP kernel[0] <Debug>: AFP_VFS afpfs_DoReconnect:
posting to KEA EINPROGRESS for /Volumes/media
Apr 23 11:00:42 rMBP kernel[0] <Debug>: AFP_VFS afpfs_DoReconnect: Max
reconnect time: 600 secs, Connect timeout: 15 secs for /Volumes/media
Apr 23 11:00:42 rMBP kernel[0] <Debug>: AFP_VFS afpfs_DoReconnect:
connect to the server /Volumes/media
Apr 23 11:00:42 rMBP.local KernelEventAgent[73] <Notice>: tid 00000000
found 1 filesystem(s) with problem(s)
Apr 23 11:00:58 rMBP kernel[0] <Debug>: AFP_VFS afpfs_DoReconnect:
connect on /Volumes/media failed 60.
Apr 23 11:00:58 rMBP kernel[0] <Debug>: AFP_VFS afpfs_DoReconnect:
connect to the server /Volumes/media
Apr 23 11:01:13 rMBP kernel[0] <Debug>: AFP_VFS afpfs_DoReconnect:
connect on /Volumes/media failed 60.
Apr 23 11:01:13 rMBP kernel[0] <Debug>: AFP_VFS afpfs_DoReconnect:
connect to the server /Volumes/media
Apr 23 11:01:28 rMBP kernel[0] <Debug>: AFP_VFS afpfs_DoReconnect:
connect on /Volumes/media failed 60.
Apr 23 11:01:28 rMBP kernel[0] <Debug>: AFP_VFS afpfs_DoReconnect:
connect to the server /Volumes/media
Apr 23 11:01:30 rMBP.local Wi-Fi Diagnostics[40042] <Warning>:
APDWorkflowController changeViewController: APDComplete
Apr 23 11:01:33 rMBP.local auditd[40553] <Notice>: Auditing enabled
Apr 23 11:01:33 rMBP.local auditd[40553] <Notice>: Got low space trigger
Apr 23 11:01:33 rMBP.local auditd[40553] <Error>: auditd_read_dirs():
all audit log directories over soft limit
Apr 23 11:01:33 rMBP.local auditd[40553] <Notice>: renamed
/var/audit/20130423084754.not_terminated to
/var/audit/20130423084754.20130423090133
Apr 23 11:01:33 rMBP.local auditd[40553] <Notice>: New audit file is
/var/audit/20130423090133.not_terminated
Apr 23 11:01:33 rMBP.local _securityagent[40559] <Warning>: audit
warning: soft /var/audit
Apr 23 11:01:33 rMBP.local _securityagent[40558] <Warning>: audit
warning: allsoft
Apr 23 11:01:33 rMBP.local _securityagent[40560] <Warning>: audit
warning: closefile /var/audit/20130423084754.20130423090133
Apr 23 11:01:33 rMBP.local authexec[40550] <Notice>: executing
/usr/sbin/ipconfig
Apr 23 11:01:33 rMBP.local Wi-Fi Diagnostics[40042] <Warning>: creating
report path: /private/tmp/WiFiDiagnosticReport-20130423-1101
Apr 23 11:01:33 rMBP.local configd[17] <Notice>: IPConfiguration:
verbose mode enabled
Apr 23 11:01:33 rMBP.local coreservicesd[31] <Error>: Application
App:"WLAN-Diagnose" [ 0x0/0x9e79e70] @ 0x0x7fa0c4225f70 tried to be
brought forward, but isn't in fPermittedFrontASNs ( (
ASN:0x0-0x9eacea3:) ), so denying.
Apr 23 11:01:33 rMBP.local WindowServer[98] <Warning>: [cps/setfront]
Failed setting the front application to WLAN-Diagnose, psn
0x0-0x9e79e70, securitySessionID=0x186a6, err=-13066
Apr 23 11:01:33 rMBP.local authexec[40561] <Notice>: executing /bin/sh

[Thomas Kaiser]

Post by Marc Stibane

Marc Stibane schrieb am 22.04.2013

Post by Marc Stibane
Seit dem Update auf 10.8.3 fällt ca. 2-3mal am Tag kurz mein WLAN aus.

Gestern nachmittag und heute war es eher so 1mal pro Stunde.

Ist doch prima, dann lohnt sich ja ein

tail -f /var/log/system.log

richtig (in 10.7 IIRC "tail -f /var/log/wifid.log").

Post by Marc Stibane

Und was meint
/System/Library/CoreServices/Wi-Fi\ Diagnostics.app
dazu?

Mannomann, hat das Ding ein besch...es UI. Man schaltet Debug-Protokoll
'ein', klickt auf Fortfahren, und es fragt ob es abbrechen soll...

Das Ding ist dafür gedacht, daß man den Apple-Support am Ohr hat und der
einem dann den Trick mit der [alt]-Taste erklärt und dem User am anderen
Ende der Leitung einschärft, daß besagtes WLAN-Diagnose-Tool gefälligst
die nächste Zeit offen zu sein hat. Und wenn der User es beendet oder
der Support ihn bittet, mal die Debug-Daten rüberzuschubsen, dann
beendet sich damit auch der verbose-Modus der Protokollierung. Alles
andere wäre für die angepeilte Zielgruppe (die typischen Mac-DAUs der
Woche) auch langfristig katastrophal, weil die Logs so geschwätzig
ausfallen, daß alle paar Monate 'ne doppelt so große Platte fällig wäre.

Aus der Perspektive der Zielgruppe also alles richtig gemacht: sobald Du
auf "Fortfahren" klickst, wird das Logging wieder auf normal umgestellt,
wird der ganze Log-Quatsch auf dem Schreibtisch gesammelt und sogar der
User direkt mit der Nase drauf gestoßen, was er nun ggf. dem Support
schicken soll.

Post by Marc Stibane
Also, wenn das WLAN läuft, ist alles grün. Irgendwie logisch.
Ich habe mal "Benachrichtigen, wenn WLAN-Anschluss Vom Netzwerk trennen"
(die könnten auch Native-Speaker zum Test der Übersetzungen nehmen)
angeklickt. Sowie die Debug-Basisprotokolle aktiviert.

Und das war der springende Punkt. Live und in Farbe bist Du mit "tail"
dabei (oder Konsole.app, falls das auch live mitscrollt)

Post by Marc Stibane
Apr 23 11:00:42 rMBP.local KernelEventAgent[73] <Notice>: tid 00000000
received event(s) VQ_NOTRESP (1)
[...]

Alles völlig uninteressant. Du mußt das Tool laufen lassen und parallel
in system.log gucken.

Gruss,

Thomas

[Marc Stibane]

Post by Thomas Kaiser

Post by Marc Stibane

Marc Stibane schrieb am 22.04.2013

Post by Marc Stibane
Seit dem Update auf 10.8.3 fällt ca. 2-3mal am Tag kurz mein WLAN aus.

Gestern nachmittag und heute war es eher so 1mal pro Stunde.

Ist doch prima, dann lohnt sich ja ein
tail -f /var/log/system.log
richtig

bin nicht dazu gekommen - gestern habe ich nur einen einzigen Ausfall
registriert und da auch verpennt direkt nachzusehen.

Post by Thomas Kaiser
(in 10.7 IIRC "tail -f /var/log/wifid.log").

wifid.log ist vom 28.12.2012 - da steht nix aktuelles drin.

Post by Thomas Kaiser

Post by Marc Stibane

Und was meint
/System/Library/CoreServices/Wi-Fi\ Diagnostics.app
dazu?

Mannomann, hat das Ding ein besch...es UI. Man schaltet
Debug-Protokoll 'ein', klickt auf Fortfahren, und es fragt ob es
abbrechen soll...

Das Ding ist dafür gedacht, daß man den Apple-Support am Ohr hat...

OK. Aber eine Rückmeldung dass die Debug-Protokolle jetzt aktiv sind und
das Logging gestartet wurde wäre auch für ONUs nicht schlecht.

Post by Thomas Kaiser
Aus der Perspektive der Zielgruppe also alles richtig gemacht: sobald Du
auf "Fortfahren" klickst, wird das Logging wieder auf normal umgestellt,
wird der ganze Log-Quatsch auf dem Schreibtisch gesammelt und sogar der
User direkt mit der Nase drauf gestoßen, was er nun ggf. dem Support
schicken soll.

Wenn der Button nicht "Fortfahren" sondern "Log beenden" hieße wäre das
auch sinnvoll.

Post by Thomas Kaiser

Post by Marc Stibane
Ich habe mal "Benachrichtigen, wenn WLAN-Anschluss Vom Netzwerk
trennen" angeklickt.

Ich habe in 3 Tagen nur ein einzigesmal kurz eine solche
Benachrichtigung gesehen (leider Screenshot vergessen).
Bei den anderen Ausfällen kam eine Benachrichtigung dass das gemountete
NAS-Volume nicht mehr erreichbar sei.

Post by Thomas Kaiser

Post by Marc Stibane
Sowie die Debug-Basisprotokolle aktiviert.

Und das war der springende Punkt. Live und in Farbe bist Du mit "tail"
dabei (oder Konsole.app, falls das auch live mitscrollt)

Post by Marc Stibane
Apr 23 11:00:42 rMBP.local KernelEventAgent[73] <Notice>: tid 00000000
received event(s) VQ_NOTRESP (1)
[...]

Alles völlig uninteressant. Du mußt das Tool laufen lassen und parallel
in system.log gucken.

Naja, VQ_NOTRESP heißt wohl dass da irgendwas nicht antwortet, dann
kommen AFP reconnect Versuche. Ein Teil des Systems weiß also schon dass
das Netz nicht erreichbar ist. Nur sieht man keinen Log-Eintrag vom
wifid o.ä.


Hatte 2 Tage keine Zeit mich drum zu kümmern. Aber das Tool läuft
seitdem mit Debug-Protokoll (nur Basis-, keine erweiterten Protokolle).
Heute hätte ich Zeit, aber seit vorgestern ist nur 1 Ausfall passiert
(irgendwann gestern mittag).

[Thomas Kaiser]

Post by Marc Stibane

Post by Thomas Kaiser

Post by Marc Stibane
Apr 23 11:00:42 rMBP.local KernelEventAgent[73] <Notice>: tid 00000000
received event(s) VQ_NOTRESP (1)
[...]

Alles völlig uninteressant. Du mußt das Tool laufen lassen und parallel
in system.log gucken.

Naja, VQ_NOTRESP heißt wohl dass da irgendwas nicht antwortet, dann
kommen AFP reconnect Versuche. Ein Teil des Systems weiß also schon
dass das Netz nicht erreichbar ist. Nur sieht man keinen Log-Eintrag
vom wifid o.ä.

Was evtl. heißt, daß es eigentlich keine Probleme mit dem WLAN "an sich"
gibt sondern ab und an der Durchsatz oberhalb Layer 1/2 so mau ist, daß
kein DSI-Tickle mehr durchgeht und deshalb der Client anfängt,
Reconnect-Versuche zu starten. In so einem Fall würde ich mal einen
endlos-Ping zwischen den Maschinen mitlaufen lassen (ping -i3 ...)

Gruss,

Thomas

[Marc Stibane]

Post by Thomas Kaiser

Post by Marc Stibane

Post by Thomas Kaiser

Post by Marc Stibane
Apr 23 11:00:42 rMBP.local KernelEventAgent[73] <Notice>: tid 00000000
received event(s) VQ_NOTRESP (1)

Alles völlig uninteressant. Du mußt das Tool laufen lassen und
parallel in system.log gucken.

Naja, VQ_NOTRESP heißt wohl dass da irgendwas nicht antwortet, dann
kommen AFP reconnect Versuche. Ein Teil des Systems weiß also schon
dass das Netz nicht erreichbar ist. Nur sieht man keinen Log-Eintrag
vom wifid o.ä.

Was evtl. heißt, daß es eigentlich keine Probleme mit dem WLAN "an sich"
gibt

Doch. Die Benachrichtigung (des Finders?) "Volume nicht mehr da" ist
immer nur eines der ersten Symptome, wenn ich dann Mail pollen will oder
eine Webseite aufrufen geht das auch nicht. Nur das WLAN-Symbol bleibt
unverändert bei allen 'Balken' (Viertelkreisen).
Einfach nur abwarten reicht, meistens dauert es keine Minute und alles
geht wieder.

Post by Thomas Kaiser
sondern ab und an der Durchsatz oberhalb Layer 1/2 so mau ist, daß
kein DSI-Tickle mehr durchgeht und deshalb der Client anfängt,
Reconnect-Versuche zu starten. In so einem Fall würde ich mal einen
endlos-Ping zwischen den Maschinen mitlaufen lassen (ping -i3 ...)

Mache ich wenn das Problem überhaupt mal wieder auftaucht - wie gesagt
seit gestern mittag nicht mehr passiert.

[Thomas Kaiser]

Post by Marc Stibane
Doch. Die Benachrichtigung (des Finders?) "Volume nicht mehr da" ist
immer nur eines der ersten Symptome, wenn ich dann Mail pollen will oder
eine Webseite aufrufen geht das auch nicht. Nur das WLAN-Symbol bleibt
unverändert bei allen 'Balken' (Viertelkreisen).
Einfach nur abwarten reicht, meistens dauert es keine Minute und alles
geht wieder.

Naja, sag ich doch. Mit dem WLAN paßt alles, es geht halt einfach nichts
mehr durch ;-)

Ist halt "shared medium", wenn andere das Medium komplett belegen
(andere Macs, die Mikrowelle des Nachbarn), dann geht halt nix mehr.

Laß mal ping durchlaufen. Und vergleich mal, auf welchen Kanälen Deine
Devices alle unterwegs sind (am Mac mit gedrückter [alt]-Taste aufs
Airport-Menüleistensymbol klicksen oder iStumbler&Co nutzen.

Post by Marc Stibane

Post by Thomas Kaiser
sondern ab und an der Durchsatz oberhalb Layer 1/2 so mau ist, daß
kein DSI-Tickle mehr durchgeht und deshalb der Client anfängt,
Reconnect-Versuche zu starten. In so einem Fall würde ich mal einen
endlos-Ping zwischen den Maschinen mitlaufen lassen (ping -i3 ...)

Mache ich wenn das Problem überhaupt mal wieder auftaucht

Das ist Blödsinn bzw. dann ist es zu spät. Der ping soll permanent
mitlaufen, denn dann hast Du Material, wenn Du im nachhinein Phänomene
untersuchen willst. Wobei das 3-Sekunden-Intervall vor dem Hintergrund
blöd ist, daß sich dann Zeitstempel umständlicher errechnen lassen. 6
Sekunden sind evtl. besser, denn dann entsprechen 10 Zeilen ping-Ausgabe
einer Minute. Oder so...

Gruss,

Thomas

[Marc Stibane]

Post by Thomas Kaiser

Post by Marc Stibane
Doch. Die Benachrichtigung (des Finders?) "Volume nicht mehr da" ist
immer nur eines der ersten Symptome, wenn ich dann Mail pollen will
oder eine Webseite aufrufen geht das auch nicht. Nur das WLAN-Symbol
bleibt unverändert bei allen 'Balken' (Viertelkreisen). Einfach nur
abwarten reicht, meistens dauert es keine Minute und alles geht
wieder.

Naja, sag ich doch. Mit dem WLAN paßt alles, es geht halt einfach nichts
mehr durch ;-)
Ist halt "shared medium", wenn andere das Medium komplett belegen
(andere Macs, die Mikrowelle des Nachbarn), dann geht halt nix mehr.

Mein anderer Mac hängt via Ethernet an der Airport Extreme. In der
Umgebung ist nur noch 1 weiteres 5GHz WLAN, aber 13 2.4GHz WLANs. Die
Mikrowelle ist auch auf 2.4GHz...

Wenn dieser Ausfall auftritt, kann ich mir mein iPad schnappen (was
genauso wie mein rMBP mit 5GHz funkt) und das geht problemlos. Oder mein
iPhone 4S (2.4GHz) und das geht auch.

Nein, das liegt nicht am WLAN. Sonst hätte zumindest das iPad dann auch
Probleme. Das liegt wirklich am MBP.

Post by Thomas Kaiser
Laß mal ping durchlaufen. Und vergleich mal, auf welchen Kanälen Deine
Devices alle unterwegs sind (am Mac mit gedrückter [alt]-Taste aufs
Airport-Menüleistensymbol klicksen oder iStumbler&Co nutzen.

Ich habe mein 5GHz-WLAN anders benannt als mein 2.4GHz, also sehe ich
bereits am Namen welches Netz verwendet wird.

Post by Thomas Kaiser

Post by Marc Stibane

Post by Thomas Kaiser
sondern ab und an der Durchsatz oberhalb Layer 1/2 so mau ist, daß
kein DSI-Tickle mehr durchgeht und deshalb der Client anfängt,
Reconnect-Versuche zu starten. In so einem Fall würde ich mal einen
endlos-Ping zwischen den Maschinen mitlaufen lassen (ping -i3 ...)

Mache ich wenn das Problem überhaupt mal wieder auftaucht

Das ist Blödsinn bzw. dann ist es zu spät. Der ping soll permanent
mitlaufen, denn dann hast Du Material, wenn Du im nachhinein Phänomene
untersuchen willst. Wobei das 3-Sekunden-Intervall vor dem Hintergrund
blöd ist, daß sich dann Zeitstempel umständlicher errechnen lassen. 6
Sekunden sind evtl. besser, denn dann entsprechen 10 Zeilen ping-Ausgabe
einer Minute. Oder so...

Gut, mache ich mal. Gerade war wieder ein Ausfall, der erste heute. Ich
schaue mir jetzt mal das Logfile an...

[Thomas Kaiser]

Post by Marc Stibane

Post by Thomas Kaiser

Post by Marc Stibane
Doch. Die Benachrichtigung (des Finders?) "Volume nicht mehr da" ist
immer nur eines der ersten Symptome, wenn ich dann Mail pollen will
oder eine Webseite aufrufen geht das auch nicht. Nur das WLAN-Symbol
bleibt unverändert bei allen 'Balken' (Viertelkreisen). Einfach nur
abwarten reicht, meistens dauert es keine Minute und alles geht
wieder.

Naja, sag ich doch. Mit dem WLAN paßt alles, es geht halt einfach
nichts mehr durch ;-)
Ist halt "shared medium", wenn andere das Medium komplett belegen
(andere Macs, die Mikrowelle des Nachbarn), dann geht halt nix mehr.

Mein anderer Mac hängt via Ethernet an der Airport Extreme.

Naja, dann ist dessen WLAN-Anbindung völlig irrelevant. ;-)

Post by Marc Stibane
In der Umgebung ist nur noch 1 weiteres 5GHz WLAN, aber 13 2.4GHz
WLANs. Die Mikrowelle ist auch auf 2.4GHz...

Die Nachbarn hier im Umfeld kaufen sich jetzt alle moderne, die auf 5
GHz funken ;-)

Post by Marc Stibane
Wenn dieser Ausfall auftritt, kann ich mir mein iPad schnappen (was
genauso wie mein rMBP mit 5GHz funkt) und das geht problemlos. Oder
mein iPhone 4S (2.4GHz) und das geht auch.

Dann laß das iPhone aus dem Spiel und leg Dir fürs iPad so 'ne
Gratis-ping-App zu, die Du mitlaufen läßt. Und wenn die beiden Geräte
nebeneinander liegen und das iPad normale Latenzen aufweist und das rMBP
Seltsamkeiten, dann ist klar, daß es nicht am WLAN liegt (so doof das
jetzt klingt) sondern _im_ rMBP zu verorten ist. Und die WLAN-Logs nix
bringen werden.

Wenn Du es schaffst, dann führe doch bitte mal die drei Kommandos aus,
_während_ ein Ausfall auftritt (also vorbereiten in 3 separaten Terminal-
Fenstern, so daß Du nur noch auf return hämmern mußt)

ifconfig
netstat -rn
netstat -r

Gruss,

Thomas

[Marc Stibane]

Marc Stibane schrieb am 26.04.2013

Post by Marc Stibane

Post by Thomas Kaiser
Naja, sag ich doch. Mit dem WLAN paßt alles, es geht halt einfach
nichts mehr durch ;-)

...

Post by Marc Stibane
Wenn dieser Ausfall auftritt, kann ich mir mein iPad schnappen (was
genauso wie mein rMBP mit 5GHz funkt) und das geht problemlos. Oder
mein iPhone 4S (2.4GHz) und das geht auch.

Dann laß das iPhone aus dem Spiel und leg Dir fürs iPad so 'ne
Gratis-ping-App zu, die Du mitlaufen läßt.

Mache ich.

Und wenn die beiden Geräte nebeneinander liegen und das iPad normale
Latenzen aufweist und das rMBP Seltsamkeiten, dann ist klar, daß es nicht
am WLAN liegt (so doof das jetzt klingt) sondern _im_ rMBP zu verorten
ist.

Ist doch mein Reden seit anno tobak. Es passiert nur _im_ rMBP und nur
seit dem Update auf 10.8.3. Andere Geräte sind nicht betroffen, und das
rMBP funktionierte bis incl. 10.8.2 auch einwandfrei.

Und die WLAN-Logs nix bringen werden.

Ich habe in den Logs auch nix gesehen, was nach wifid riecht.

Wenn Du es schaffst, dann führe doch bitte mal die drei Kommandos aus,
_während_ ein Ausfall auftritt (also vorbereiten in 3 separaten Terminal-
Fenstern, so daß Du nur noch auf return hämmern mußt)
ifconfig
netstat -rn
netstat -r

done.

ms$ ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
options=3<RXCSUM,TXCSUM>
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ether b8:f6:b1:1a:3b:2d
inet 10.0.4.18 netmask 0xffffff00 broadcast 10.0.4.255
media: autoselect
status: active
p2p0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 2304
ether 0a:f6:b1:1a:3b:2d
media: autoselect
status: inactive
en2: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ether e6:05:cb:d4:48:29
inet6 fe80::e405:cbff:fed4:4829%en2 prefixlen 64 scopeid 0x6
inet 192.168.16.50 netmask 0xffffff00 broadcast 192.168.16.255
media: autoselect (10baseT/UTP <full-duplex>)
status: active

war sofort fertig.

ms$ netstat -rn
Routing tables

Internet:
Destination Gateway Flags Refs Use Netif
Expire
default 10.0.4.1 UGSc 21 0 en0
default link#6 UCSI 1 0 en2
10.0.4/24 link#4 UCS 4 0 en0
10.0.4.1 link#4 UHRLWIir 22 3853 en0
18
10.0.4.2 e0:46:9a:a0:5d:f4 UHLWIi 1 1408 en0
1183
10.0.4.11 b4:f0:ab:c3:89:76 UHLWIi 0 14 en0
10.0.4.17 4:f7:e4:3b:1a:aa UHLWIi 1 19 en0
570
10.0.4.18 127.0.0.1 UHS 0 0 lo0
88.198.180.55 link#6 UHLWIi 1 1 en2
127 127.0.0.1 UCS 0 0 lo0
127.0.0.1 127.0.0.1 UH 1 283618 lo0
169.254 link#4 UCS 0 0 en0
192.168.16 link#6 UCS 1 0 en2
192.168.16.30 0:f:68:8:94:ee UHLWIi 4 249374 en2
351
192.168.16.50 127.0.0.1 UHS 0 0 lo0

Internet6:
Destination Gateway
Flags Netif Expire
::1 link#1
UHL lo0
fe80::%lo0/64 fe80::1%lo0
UcI lo0
fe80::1%lo0 link#1
UHLI lo0
fe80::%en2/64 link#6
UCI en2
fe80::e405:cbff:fed4:4829%en2 e6:5:cb:d4:48:29
UHLI lo0
ff01::%lo0/32 fe80::1%lo0
UmCI lo0
ff01::%en2/32 link#6
UmCI en2
ff02::%lo0/32 fe80::1%lo0
UmCI lo0
ff02::%en2/32 link#6
UmCI en2

war ebenfalls sofort fertig.

ms$ netstat -r
Routing tables

Internet:
Destination Gateway Flags Refs Use Netif
Expire
default 10.0.4.1 UGSc 21 0 en0
default link#6 UCSI 1 0 en2
10.0.4/24 link#4 UCS 4 0 en0
10.0.4.1 link#4 UHRLWIir 22 3854 en0
10.0.4.2 e0:46:9a:a0:5d:f4 UHLWIi 1 1415 en0
1105
10.0.4.11 b4:f0:ab:c3:89:76 UHLWIi 0 14 en0
10.0.4.17 4:f7:e4:3b:1a:aa UHLWIi 1 19 en0
411
10.0.4.18 localhost UHS 0 0 lo0
88.198.180.55 link#6 UHLWIi 1 1 en2
127 localhost UCS 0 0 lo0
localhost localhost UH 1 283618 lo0
169.254 link#4 UCS 0 0 en0
192.168.16 link#6 UCS 1 0 en2
192.168.16.30 0:f:68:8:94:ee UHLWIi 5 249556 en2
129
192.168.16.50 localhost UHS 0 0 lo0

Internet6:
Destination Gateway Flags Netif Expire
localhost link#1 UHL lo0
fe80::%lo0 localhost UcI lo0
localhost link#1 UHLI lo0
fe80::%en2 link#6 UCI en2
rmbp.local e6:5:cb:d4:48:29 UHLI lo0
ff01::%lo0 localhost UmCI lo0
ff01::%en2 link#6 UmCI en2
ff02::%lo0 localhost UmCI lo0
ff02::%en2 link#6 UmCI en2

brauchte mind. 15 Sekunden bevor überhaupt die erste Zeile ausgegeben
wurde, und ca. 60 Sekunden bis es fertig war.

[Marc Stibane]

Post by Marc Stibane

Post by Thomas Kaiser
Wenn Du es schaffst, dann führe doch bitte mal die drei Kommandos
aus, _während_ ein Ausfall auftritt
ifconfig
netstat -rn
netstat -r

done.
ms$ netstat -r
Routing tables
Destination Gateway Flags Refs Use Netif
Expire
default 10.0.4.1 UGSc 21 0 en0
default link#6 UCSI 1 0 en2
10.0.4/24 link#4 UCS 4 0 en0
10.0.4.1 link#4 UHRLWIir 22 3854 en0
10.0.4.2 e0:46:9a:a0:5d:f4 UHLWIi 1 1415 en0
1105
10.0.4.11 b4:f0:ab:c3:89:76 UHLWIi 0 14 en0
10.0.4.17 4:f7:e4:3b:1a:aa UHLWIi 1 19 en0
411
10.0.4.18 localhost UHS 0 0 lo0
88.198.180.55 link#6 UHLWIi 1 1 en2
127 localhost UCS 0 0 lo0
localhost localhost UH 1 283618 lo0
169.254 link#4 UCS 0 0 en0
192.168.16 link#6 UCS 1 0 en2
192.168.16.30 0:f:68:8:94:ee UHLWIi 5 249556 en2
129
192.168.16.50 localhost UHS 0 0 lo0
Destination Gateway Flags Netif Expire
localhost link#1 UHL lo0
fe80::%lo0 localhost UcI lo0
localhost link#1 UHLI lo0
fe80::%en2 link#6 UCI en2
rmbp.local e6:5:cb:d4:48:29 UHLI lo0
ff01::%lo0 localhost UmCI lo0
ff01::%en2 link#6 UmCI en2
ff02::%lo0 localhost UmCI lo0
ff02::%en2 link#6 UmCI en2
brauchte mind. 15 Sekunden bevor überhaupt die erste Zeile ausgegeben
wurde, und ca. 60 Sekunden bis es fertig war.

Hab's gerade wieder probiert (mit funktionierendem WLAN), da kam die
Ausgabe wieder instantan:

ms$ netstat -r
Routing tables

Internet:
Destination Gateway Flags Refs Use Netif
Expire
default 10.0.4.1 UGSc 14 0 en0
default link#6 UCSI 1 0 en2
10.0.4/24 link#4 UCS 3 0 en0
10.0.4.1 b8:c7:5d:c6:c5:b2 UHLWIir 16 4506 en0
508
10.0.4.2 e0:46:9a:a0:5d:f4 UHLWIi 1 1552 en0
1038
10.0.4.17 4:f7:e4:3b:1a:aa UHLWIi 0 55 en0
957
10.0.4.18 localhost UHS 0 0 lo0
static.88-198-180- link#6 UHLWIi 1 1 en2
127 localhost UCS 0 0 lo0
localhost localhost UH 1 283618 lo0
169.254 link#4 UCS 0 0 en0
192.168.16 link#6 UCS 1 0 en2
192.168.16.30 0:f:68:8:94:ee UHLWIi 7 267127 en2
637
192.168.16.50 localhost UHS 0 0 lo0

Internet6:
Destination Gateway Flags Netif Expire
localhost link#1 UHL lo0
fe80::%lo0 localhost UcI lo0
localhost link#1 UHLI lo0
fe80::%en2 link#6 UCI en2
rmbp.local e6:5:cb:d4:48:29 UHLI lo0
ff01::%lo0 localhost UmCI lo0
ff01::%en2 link#6 UmCI en2
ff02::%lo0 localhost UmCI lo0
ff02::%en2 link#6 UmCI en2

[Juergen P. Meier]

Post by Marc Stibane

Post by Marc Stibane

Post by Thomas Kaiser
Wenn Du es schaffst, dann führe doch bitte mal die drei Kommandos
aus, _während_ ein Ausfall auftritt
ifconfig
netstat -rn
netstat -r

done.
ms$ netstat -r
Routing tables
Destination Gateway Flags Refs Use Netif
Expire
default 10.0.4.1 UGSc 21 0 en0
brauchte mind. 15 Sekunden bevor überhaupt die erste Zeile ausgegeben
wurde, und ca. 60 Sekunden bis es fertig war.

Genau 15 sekunden sprechen fuer DNS Timeouts (drei versuche von je 5
Sekunden timeout).

Post by Marc Stibane
Hab's gerade wieder probiert (mit funktionierendem WLAN), da kam die

Dann funktioniert DNS dort.

Bleiben noch "cat /etc/resolv.conf" sowie "cat /etc/hosts".

Deine lokale Domain heist nicht zufaellig .local?
Falls ja: wer die reservierte TLD .local fuer irgendwas anderes
ausser das wofuer sie Reserviert ist verwendet, verdient den langsamen
und qualvollen Tod seines kaputten Netzes. Vorallem wenn die Loesung
so einfach ist: Keine reservierten funktoinalen Domains fuer etwas
misbrauchen, wofuer sie nicht vorgesehen sind.

Juergen

[Marc Stibane]

Post by Juergen P. Meier
Bleiben noch "cat /etc/resolv.conf" sowie "cat /etc/hosts".

ms$ cat /etc/resolv.conf
#
# Mac OS X Notice
#
# This file is not used by the host name and address resolution
# or the DNS query routing mechanisms used by most processes on
# this Mac OS X system.
#
# This file is automatically generated.
#
domain chello.at
nameserver 10.0.4.1



ms$ cat /etc/hosts
##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting. Do not change this entry.
##
127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 localhost
fe80::1%lo0 localhost

184.72.115.86 search.yahoo.com
#74.208.10.249 gs.apple.com


Der falsche Yahoo-Entry ist damit man DuckDuckGo in Safari benutzen
kann, und der auskommentierte Apple-Entry ist von TinyUmbrella.

Post by Juergen P. Meier
Deine lokale Domain heist nicht zufaellig .local?

Dass sich .local mit Bonjour beisst war ja schon vor 10 Jahren ein
Thema:
http://hints.macworld.com/article.php?story=20021212074234953

Was ist eigentlich der "offizielle" Weg um eine lokale Domain für MacOS
zu setzen?

Post by Juergen P. Meier
Falls ja: wer die reservierte TLD .local fuer irgendwas anderes
ausser das wofuer sie Reserviert ist verwendet, verdient den langsamen
und qualvollen Tod seines kaputten Netzes. Vorallem wenn die Loesung
so einfach ist: Keine reservierten funktoinalen Domains fuer etwas
misbrauchen, wofuer sie nicht vorgesehen sind.

Ja aber. ".local" war lange in Benutzung bevor Apple es für Rendevous/
Bonjour reserviert hat.

[Juergen P. Meier]

Post by Marc Stibane
ms$ cat /etc/hosts
##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting. Do not change this entry.
##
127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 localhost
fe80::1%lo0 localhost
184.72.115.86 search.yahoo.com

Da hat dir jemand eine gefaelschte Suchmaschine untergejubelt.

Diese IP gehoert zu einem EC2 Miet-server.

Post by Marc Stibane
#74.208.10.249 gs.apple.com

Diese IP gehoert einem DSL-Anschluss im US-Amerikanischen 1&1 Netz
(wusste garnicht, dass die auch im US-Markt mitspielen).

Post by Marc Stibane
Der falsche Yahoo-Entry ist damit man DuckDuckGo in Safari benutzen
kann, und der auskommentierte Apple-Entry ist von TinyUmbrella.

Ahso, immerhin weist du woher sie kommen und kannst sie zuordnen.
Hast du noch weitere Netzwerk-verbiegungen anderer Art installiert?

Post by Marc Stibane

Post by Juergen P. Meier
Deine lokale Domain heist nicht zufaellig .local?

Dass sich .local mit Bonjour beisst war ja schon vor 10 Jahren ein
http://hints.macworld.com/article.php?story=20021212074234953

ach.

Post by Marc Stibane
Was ist eigentlich der "offizielle" Weg um eine lokale Domain für MacOS
zu setzen?

Wenn man eine offizielle Domain wie z.B. "meine.tld" hat, nimmt man
z.B. local.meine.tld.

Ansonsten gibt es im IETF Standard track seit Februar diesen Jahres
einen Standard-Vorschlag (PROPOSED STANDARD) fuer special-purpose
Domains http://www.rfc-editor.org/info/rfc6761
Leider fehlt ein Vorschlag fuer eine site-local Domain.

Ich empfehle dass du dir eine offizielle Domain (auch Subdomain geht,
z.B. wenn du "blah.fasel.tld" hast, kannst du z.B. lokal.blah.fasel.tld
als Lokale Domain verwenden) zu besorgen und eine subdomain davon zu verwenden.

Denn gerade generische Begriffe sind schon fast alle als gTLD
beantragt worden (die liste der aktuell beantragten TLDs sind u.A. auf
http://newgtlds.icann.org/sites/default/files/reveal/strings-1200utc-13jun12-en.csv
einzusehen).

Gerade wegen der gTLDs sollte man es sein lassen sich was eigenes
auszudenken.

Post by Marc Stibane

Post by Juergen P. Meier
Falls ja: wer die reservierte TLD .local fuer irgendwas anderes
ausser das wofuer sie Reserviert ist verwendet, verdient den langsamen
und qualvollen Tod seines kaputten Netzes. Vorallem wenn die Loesung
so einfach ist: Keine reservierten funktoinalen Domains fuer etwas
misbrauchen, wofuer sie nicht vorgesehen sind.

Ja aber. ".local" war lange in Benutzung bevor Apple es für Rendevous/
Bonjour reserviert hat.

Fuer genau das.

Denn schon immer galt im DNS Standard: Verwende nur Domains fuer die
du auch die Autoritaet hast (also offiziell dir zugewiesene).

Haette sich jeder dran gehalten, gaebe es nicht so viele verkackte
Installationen mit ".local".

Juergen

[Marc Stibane]

Post by Juergen P. Meier

Post by Marc Stibane
ms$ cat /etc/hosts
127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 localhost
fe80::1%lo0 localhost
184.72.115.86 search.yahoo.com

Da hat dir jemand eine gefaelschte Suchmaschine untergejubelt.

Das war ich selber.

Post by Juergen P. Meier

Post by Marc Stibane
#74.208.10.249 gs.apple.com

Diese IP gehoert einem DSL-Anschluss im US-Amerikanischen 1&1 Netz
(wusste garnicht, dass die auch im US-Markt mitspielen).

Post by Marc Stibane
Der falsche Yahoo-Entry ist damit man DuckDuckGo in Safari benutzen
kann, und der auskommentierte Apple-Entry ist von TinyUmbrella.

Ahso, immerhin weist du woher sie kommen und kannst sie zuordnen.
Hast du noch weitere Netzwerk-verbiegungen anderer Art installiert?

Nein, sonst nix.

Post by Juergen P. Meier

Post by Marc Stibane

Post by Juergen P. Meier
Deine lokale Domain heist nicht zufaellig .local?

Dass sich .local mit Bonjour beisst war ja schon vor 10 Jahren ein
http://hints.macworld.com/article.php?story=20021212074234953

ach.

Hat damals viele Firmen hart getroffen.

Post by Juergen P. Meier

Post by Marc Stibane
Was ist eigentlich der "offizielle" Weg um eine lokale Domain für
MacOS zu setzen?

Wenn man eine offizielle Domain wie z.B. "meine.tld" hat, nimmt man
z.B. local.meine.tld.

Ich meinte nicht die Auswahl eines geeigneten Domainnamens, sondern
wie/wo man den MacOS bekanntgibt.

Kontrollfeld->Netzwerk/Weitere Optionen/DNS?
Oder im DNS-Server der Airport Extreme setzen? Da habe ich derzeit nix
eingetragen, also holt sich die AE ihre Infos vom Kabel-Provider
(chello.at).

Post by Juergen P. Meier
Ansonsten gibt es im IETF Standard track seit Februar diesen Jahres
einen Standard-Vorschlag (PROPOSED STANDARD) fuer special-purpose
Domains http://www.rfc-editor.org/info/rfc6761
Leider fehlt ein Vorschlag fuer eine site-local Domain.
Ich empfehle dass du dir eine offizielle Domain (auch Subdomain geht,
z.B. wenn du "blah.fasel.tld" hast, kannst du z.B. lokal.blah.fasel.tld
als Lokale Domain verwenden) zu besorgen und eine subdomain davon zu verwenden.
Denn gerade generische Begriffe sind schon fast alle als gTLD
beantragt worden (die liste der aktuell beantragten TLDs sind u.A. auf
http://newgtlds.icann.org/sites/default/files/reveal/strings-1200utc-13

jun12-en.csv

Post by Juergen P. Meier
einzusehen).
Gerade wegen der gTLDs sollte man es sein lassen sich was eigenes
auszudenken.

OK. Bisher komme ich gut ohne aus - mein NAS meldet sich via Bonjour und
mehr interne Vernetzung brauche ich eh nicht.

Post by Juergen P. Meier

Post by Marc Stibane

Post by Juergen P. Meier
Falls ja: wer die reservierte TLD .local fuer irgendwas anderes
ausser das wofuer sie Reserviert ist verwendet, verdient den
langsamen und qualvollen Tod seines kaputten Netzes. Vorallem wenn
die Loesung so einfach ist: Keine reservierten funktoinalen Domains
fuer etwas misbrauchen, wofuer sie nicht vorgesehen sind.

Ja aber. ".local" war lange in Benutzung bevor Apple es für
Rendevous/Bonjour reserviert hat.

Fuer genau das.
Denn schon immer galt im DNS Standard: Verwende nur Domains fuer die
du auch die Autoritaet hast (also offiziell dir zugewiesene).
Haette sich jeder dran gehalten, gaebe es nicht so viele verkackte
Installationen mit ".local".

Es ist halt einfacher, wenn was eh nicht rausgeroutet werden soll, dafür
.local zu tippen als lokal.blah.fasel.tld...
Und Menschen sind nunmal faul.


Egal, zurück zum Thema. Mein Hosts-file sowie resolv.conf sollten
jedenfalls nicht für die WLAN-Probleme verantwortlich sein. Zumal ich
beide seit Ewigkeiten nicht verändert habe, und die Probleme direkt nach
dem Update meines rMBP auf 10.8.3 anfingen.

[Thomas Kaiser]

Post by Marc Stibane

Post by Juergen P. Meier

Post by Marc Stibane
Was ist eigentlich der "offizielle" Weg um eine lokale Domain für
MacOS zu setzen?

Wenn man eine offizielle Domain wie z.B. "meine.tld" hat, nimmt man
z.B. local.meine.tld.

Ich meinte nicht die Auswahl eines geeigneten Domainnamens, sondern
wie/wo man den MacOS bekanntgibt.
Kontrollfeld->Netzwerk/Weitere Optionen/DNS?

Das würde dann _zentrale_ Mechanismen wie DNS ein wenig karikieren bzw.
den Sinn der "search domain" (daß man nicht immer volle Namen sondern
Name ohne Domain eingeben kann) zunichte machen.

Post by Marc Stibane
Oder im DNS-Server der Airport Extreme setzen?

In der Dir zur verfügung stehenden DHCP-/DNS-Server-Kombi, so die das
überhaupt unterstützt. Keine Ahnung, ob das Apple-Zeugs das kann. Daß
sie die Domain vom Provider (chello.at) als "search domain" durchreicht,
ist jedenfalls etwas dämlich. Idealerweise geschieht Folgendes: DHCP-
ind DNS-Server existieren in Personalunion. Admin (Du) gibt dem DNS-
Server eine Search-Domain vor. Client bzw. User (wieder Du) konfiguriert
auf seinem Device einen Rechnernamen (Systemeinstellung --> Sharing, das
ist dann aber (noch) _nicht_ der sog. hostname sondern der ComputerName:
"scutil --get ComputerName"). Der User (Du) hängt das Device ins Netz,
das Device redet mit dem DHCP-Server und teilt seinen ComputerName mit,
der DHCP-Server teilt das seinem Kumpel, dem DNS-Server mit, der jetzt
dynamisch einen Eintrag: $ComputerName.$SearchDomain erstellt und die
Millisekunden später eintreffende Anfrage des Clients (denn der DHCP-
Server hat dem Client ja auch die Adresse des DNS-Servers mitgeteilt)
dann entsprechend beantwortet. Und ab dem Moment hat der Client auch
offiziell einen passenden Hostnamen, der -- und jetzt kommt das
eigentlich interessante -- (W)Lan-weit gilt. D.h. Du kannst von anderen
Devices auf Deinen Rechner jetzt einfach per "ping $ComputerName"
zugreifen, weil der ComputerName durch DHCP/DNS-Server zum Hostname
wurde und alle Devices die indentische "search domain" nutzen.

Und was bringt das Ganze in reinen Mac-Umgebungen? Fast nix, weil Bonjour
existiert und man sich ergo nur den Zusatz ".local" spart beim Tippen:

macbookpro-tk:~ tk$ ping keksdose
PING keksdose.fritz.box (192.168.83.38): 56 data bytes
64 bytes from 192.168.83.38: icmp_seq=0 ttl=64 time=1.480 ms

vs.

macbookpro-tk:~ tk$ ping keksdose.local
PING keksdose.local (192.168.83.38): 56 data bytes
64 bytes from 192.168.83.38: icmp_seq=0 ttl=64 time=1.598 ms

Gruss,

Thomas

[Marc Stibane]

Marc Stibane schrieb

Post by Marc Stibane

Post by Juergen P. Meier

Post by Marc Stibane
Was ist eigentlich der "offizielle" Weg um eine lokale Domain für
MacOS zu setzen?

Wenn man eine offizielle Domain wie z.B. "meine.tld" hat, nimmt man
z.B. local.meine.tld.

Ich meinte nicht die Auswahl eines geeigneten Domainnamens, sondern
wie/wo man den MacOS bekanntgibt.
Kontrollfeld->Netzwerk/Weitere Optionen/DNS?

Das würde dann _zentrale_ Mechanismen wie DNS ein wenig karikieren bzw.
den Sinn der "search domain" (daß man nicht immer volle Namen sondern
Name ohne Domain eingeben kann) zunichte machen.

Naja, man könnte dort ja genau die "search domain" manuell eintragen
(da steht ja jetzt die vom Router bezogene drin, z.B. "chello.at").
Z.B. "meine.tld", und dann sollte ja ein "ping meinServer" bei
"meinServer.meine.tld" anklopfen, oder?

Man müsste natürlich auf jedem Device im (W)LAN dasselbe eintragen...

Post by Marc Stibane
Oder im DNS-Server der Airport Extreme setzen?

In der Dir zur verfügung stehenden DHCP-/DNS-Server-Kombi, so die das
überhaupt unterstützt. Keine Ahnung, ob das Apple-Zeugs das kann.

Kann es. Habe gerade im Airport-Dienstprogramm an der AE im Tab
"Internet" unter Domain-Name "local.$meine.$tld" eingetragen, und nach
dem Restart der AE sehe ich jetzt am Mac im Kontrollfeld->Netzwerk->
Weitere Optionen/DNS nicht mehr chello.at sondern eben local.…

Daß sie die Domain vom Provider (chello.at) als "search domain"
durchreicht, ist jedenfalls etwas dämlich.

Jupp. Jetzt ist's besser ;-)

Idealerweise geschieht Folgendes: DHCP- ind DNS-Server existieren in
Personalunion. Admin (Du) gibt dem DNS- Server eine Search-Domain vor.

done

Client bzw. User (wieder Du) konfiguriert auf seinem Device einen
Rechnernamen (Systemeinstellung --> Sharing, das ist dann aber (noch)
_nicht_ der sog. hostname sondern der ComputerName: "scutil --get
ComputerName").

schon ewig.

Der User (Du) hängt das Device ins Netz, das Device redet mit dem
DHCP-Server und teilt seinen ComputerName mit, der DHCP-Server teilt das
$ComputerName.$SearchDomain erstellt und die Millisekunden später
eintreffende Anfrage des Clients (denn der DHCP- Server hat dem Client ja
auch die Adresse des DNS-Servers mitgeteilt) dann entsprechend
beantwortet. Und ab dem Moment hat der Client auch offiziell einen
passenden Hostnamen, der -- und jetzt kommt das eigentlich interessante --
(W)Lan-weit gilt. D.h. Du kannst von anderen Devices auf Deinen Rechner
jetzt einfach per "ping $ComputerName" zugreifen, weil der ComputerName
durch DHCP/DNS-Server zum Hostname wurde und alle Devices die indentische
"search domain" nutzen.

funktioniert. Ich kann jetzt auf dem iPad "ping rMBP" machen...

Und was bringt das Ganze in reinen Mac-Umgebungen? Fast nix, weil Bonjour
macbookpro-tk:~ tk$ ping keksdose
PING keksdose.fritz.box (192.168.83.38): 56 data bytes
64 bytes from 192.168.83.38: icmp_seq=0 ttl=64 time=1.480 ms
vs.
macbookpro-tk:~ tk$ ping keksdose.local
PING keksdose.local (192.168.83.38): 56 data bytes
64 bytes from 192.168.83.38: icmp_seq=0 ttl=64 time=1.598 ms

...und es pingt bei rmbp.local.$meine.$tld an, also meinem rMacBookPro.
Fein. Braucht man nur eigentlich nie...

Danke für die Aufklärung.


@Juergen: Ist eigentlich die local domain "fritz.box" geeignet?

Wahrscheinlich sogar sinnvoller als die Providerdomain ("chello.at"),
was wohl die meisten Router als search domain verwenden.

[Thomas Kaiser]

Post by Marc Stibane

Marc Stibane schrieb

Post by Marc Stibane

Post by Juergen P. Meier

Post by Marc Stibane
Was ist eigentlich der "offizielle" Weg um eine lokale Domain für
MacOS zu setzen?

Wenn man eine offizielle Domain wie z.B. "meine.tld" hat, nimmt man
z.B. local.meine.tld.

Ich meinte nicht die Auswahl eines geeigneten Domainnamens, sondern
wie/wo man den MacOS bekanntgibt.
Kontrollfeld->Netzwerk/Weitere Optionen/DNS?

Das würde dann _zentrale_ Mechanismen wie DNS ein wenig karikieren bzw.
den Sinn der "search domain" (daß man nicht immer volle Namen sondern
Name ohne Domain eingeben kann) zunichte machen.

Naja, man könnte dort ja genau die "search domain" manuell eintragen

Also am Mac kann man viel in die /etc/resolv.conf eintragen. Das
interessiert dort allenfalls Steinzeit-Unix-Software, die blöd genug
ist, da reinzuschauen (und genau deshalb schreibt der configd auch die
gültige Konfiguration da rein). Quelle ist SystemConfiguration.framework
und dort eintragen kann man's per Systemeinstellungen oder zu Fuß (bzw.
besser per defaults(1) unterhalb /Library/Preferences/SystemConfiguration/)

DNS-Konfig klebt an "Umgebungen". Und dementsprechen werden sie dort
konfiguriert, vom configd über die entsprechenden APIs verteilt und für
Altlasten noch zur Sicherheit in die resolv.conf geschrieben.

Post by Marc Stibane
Kann es. Habe gerade im Airport-Dienstprogramm an der AE im Tab
"Internet" unter Domain-Name "local.$meine.$tld" eingetragen,

Warum so kompliziert. Nimm halt ".intern"...

Post by Marc Stibane
und nach dem Restart der AE sehe ich jetzt am Mac im
Kontrollfeld->Netzwerk-> Weitere Optionen/DNS nicht mehr chello.at
sondern eben local.…

Und prüfen, wie's genau aussieht, kann man am Besten per

scutil --dns

Post by Marc Stibane
@Juergen: Ist eigentlich die local domain "fritz.box" geeignet?

Solange .box noch keine offizielle TLD ist, wunderbar. Und wenn sie's
mal wird, und Amazon wirklich so doof ist, dann irgendwas Relevantes
unterhalb .fritz.box anzusiedeln (und sich damit alle Fritzbox-User
aussperrt), dann wird's vielleicht mal zum Problem.

Aber Du hast ja Jürgen gefragt. Und der wird Dir gleich die volle
Wahrheit erzählen *g*.

Post by Marc Stibane
Wahrscheinlich sogar sinnvoller als die Providerdomain ("chello.at"),
was wohl die meisten Router als search domain verwenden.

Das ist in jedem Fall Mist, die vom upstream-DNS-Server gelieferte
Search Domain in ein privates Netz durchzureichen. Merkst Du im Falle
chello.at spätestens dann, wenn Du einen Deiner Rechner "members",
"business" oder "web" nennst.

Gruss,

Thomas

[Gerald E:scher]

Post by Marc Stibane
Es ist halt einfacher, wenn was eh nicht rausgeroutet werden soll, dafür
.local zu tippen als lokal.blah.fasel.tld...

Noch einfacher ist, in die /etc/resolv.conf
"domain lokal.blah.fasel.tld"[1] einzutragen bzw. unter OS X
Netzwerkeinstellungen->Weitere Optionen...->DNS->Such-Domains und sich
die Tipperei von allem ab dem ersten Punkt zu sparen.
Ein ordentlich konfigurierter DHCP-Server teilt dem Host neben
u.A. seiner IP-Adresse auch die lokale Domain mit, d.h. die Fummelei in
/etc/resolv.conf bzw. Netzwerkeinstellungen entfällt ebenfalls.


[1] Oder "search lokal.blah.fasel.tld" oder beides. Den Unterschied in
der Wirkungsweise von search und domain habe ich noch nicht ganz
verstanden.

[Thomas Kaiser]

Post by Gerald E:scher

Post by Marc Stibane
Es ist halt einfacher, wenn was eh nicht rausgeroutet werden soll,
dafür .local zu tippen als lokal.blah.fasel.tld...

Noch einfacher ist, in die /etc/resolv.conf
"domain lokal.blah.fasel.tld"[1] einzutragen bzw. unter OS X
Netzwerkeinstellungen->Weitere Optionen...->DNS->Such-Domains und sich
die Tipperei von allem ab dem ersten Punkt zu sparen.

Unter OS X sollte man _nur_ Letzteres machen, da die resolv.conf
dynamisch überschrieben wird.

Post by Gerald E:scher
Ein ordentlich konfigurierter DHCP-Server teilt dem Host neben u.A.
seiner IP-Adresse auch die lokale Domain mit, d.h. die Fummelei in
/etc/resolv.conf bzw. Netzwerkeinstellungen entfällt ebenfalls.

Yep. Und unterläßt es, einfach die Domain vom upstream-DNS-Server als
lokale Domain durchzureichen (wie bei Marc bzw. seinem Apple-DHCP-Zeugs)

Post by Gerald E:scher
[1] Oder "search lokal.blah.fasel.tld" oder beides. Den Unterschied in
der Wirkungsweise von search und domain habe ich noch nicht ganz
verstanden.

"domain" ist einfach die lokale Domain. Alle Hostname bekommen diesen
Zusatz drangepappt und fertig.

Bei "search" könntest Du mehrere Domains eintragen (IIRC max. 6), die
dann der Resolver der Reihe nach abklappert (dabei ggf. externe DNS-
Server befragend), validiert und erst im Falle einer Gültigkeit als FQDN
nimmt. Dauert also -- ggf. deutlich -- länger.

Gruss,

Thomas

[Thomas Kaiser]

Post by Marc Stibane

Marc Stibane schrieb am 26.04.2013

Post by Marc Stibane

Post by Thomas Kaiser
Naja, sag ich doch. Mit dem WLAN paßt alles, es geht halt einfach
nichts mehr durch ;-)

...

Post by Marc Stibane
Wenn dieser Ausfall auftritt, kann ich mir mein iPad schnappen (was
genauso wie mein rMBP mit 5GHz funkt) und das geht problemlos. Oder
mein iPhone 4S (2.4GHz) und das geht auch.

Dann laß das iPhone aus dem Spiel und leg Dir fürs iPad so 'ne
Gratis-ping-App zu, die Du mitlaufen läßt.

Mache ich.

Und wenn die beiden Geräte nebeneinander liegen und das iPad normale
Latenzen aufweist und das rMBP Seltsamkeiten, dann ist klar, daß es
nicht am WLAN liegt (so doof das jetzt klingt) sondern _im_ rMBP zu
verorten ist.

Ist doch mein Reden seit anno tobak.

Ja und? Sinn der Übung war doch, daß andere mal mit drüberschauen, die
neu an die Sache rangehen, oder?

Post by Marc Stibane
Es passiert nur _im_ rMBP und nur seit dem Update auf 10.8.3. Andere
Geräte sind nicht betroffen, und das rMBP funktionierte bis incl.
10.8.2 auch einwandfrei.

Und die WLAN-Logs nix bringen werden.

Ich habe in den Logs auch nix gesehen, was nach wifid riecht.

Also: Dein MacBook Pro hängt sowohl im WLAN als am Ethernet (der
Anschluß ist aktiv, die default route geht übers Ethernet) und wenn's
hängt, ist definitiv DNS betroffen, siehe die Timeouts. Was jetzt
gefehlt hat, war 'ne Aussage bzgl. des Dauer-Pings. Hast Du einen
mitlaufen lassen?

Bitte mal die Ausgabe von

cat /etc/resolv.conf

Bzw. nee, kürzen wir es gleich ab. Mach einfach ein

killall -INFO mDNSResponder
sudo grep mDNSResponder /var/log/system.log | open -f

Das erste Kommando nötigt den für m(DNS) zuständigen Dienst, sich mit
Debug-Meldungen ins syslog zu erbrechen, das zweite filtert die
relevanten Zeilen raus und öffnet den Kram in TextEdit. Bitte
durchsehen, ob da netzwerk-intern zu Vertrauliches drinsteht und dann
entweder online stellen und URL hierher oder meinetwegen auch schnell
'ne Mail.

Da DNS jetzt schon exklusiv in den Kreis der Verdächtigen aufgenommen
wurde (außer ein Dauer-ping bzw. deren zwei, einer zu 88.198.180.55 und
einer zu 10.0.4.1, stocken parallel auch -- drum ja die Bitte, das
einfach mitlaufen zu lassen), kannst Du auch gleich ein

sudo killall -USR1 mDNSResponder

präventiv absetzen, das dann für debug-Logging des mDNSResponder sorgt
und Dir jetzt ggf. Hinweise aufs Problem im Liveticker (system.log)
kredenzt.

BTW: Was noch seltsam ist: Default route zeigt via Ethernet ins Internet
aber zu irgendso 'nem Hetzner-Server bzw. 88.198.180.55 geht's über
WLAN. Warum? VPN-Verbindung aufgerissen? Statisch an Routen rumgespielt?

Gruss,

Thomas

[Thomas Kaiser]

Post by Thomas Kaiser
Also: Dein MacBook Pro hängt sowohl im WLAN als am Ethernet (der
Anschluß ist aktiv, die default route geht übers Ethernet)

Nachsatz: "en0" ist normalerweise Ethernet. Um sicherzugehen, bitte noch
die Ausgabe von

system_profiler SPNetworkDataType

hierher.

Grüssle,

Ingrid

[Marc Stibane]

Post by Thomas Kaiser

Post by Thomas Kaiser
Also: Dein MacBook Pro hängt sowohl im WLAN als am Ethernet (der
Anschluß ist aktiv, die default route geht übers Ethernet)

Nachsatz: "en0" ist normalerweise Ethernet. Um sicherzugehen, bitte noch
die Ausgabe von
system_profiler SPNetworkDataType
hierher.

Beim rMBP ist en0 WLAN.



ms$ system_profiler SPNetworkDataType
Network:

USBSerial:

Type: PPP (PPPSerial)
Hardware: Modem
BSD Device Name: usbmodemLPCBOAR1
Has IP Assigned: No
IPv4:
Configuration Method: PPP
IPv6:
Configuration Method: Automatic
Proxies:
FTP Passive Mode: Yes
Service Order: 0

HUAWEIMobile-Modem:

Type: PPP (PPPSerial)
Hardware: Modem
BSD Device Name: HUAWEIMobile-Modem
Has IP Assigned: No
IPv4:
Configuration Method: PPP
IPv6:
Configuration Method: Automatic
Proxies:
FTP Passive Mode: Yes
Service Order: 1

HUAWEIMobile-Modem 3:

Type: PPP (PPPSerial)
Hardware: Modem
BSD Device Name: HUAWEIMobile-28
Has IP Assigned: No
IPv4:
Configuration Method: PPP
IPv6:
Configuration Method: Automatic
Proxies:
FTP Passive Mode: Yes
Service Order: 2

HUAWEIMobile-Modem2:

Type: PPP (PPPSerial)
Hardware: Modem
BSD Device Name: HUAWEIMobile-Modem
Has IP Assigned: No
IPv4:
Configuration Method: PPP
IPv6:
Configuration Method: Automatic
Proxies:
FTP Passive Mode: Yes
Service Order: 3

Bluetooth:

Type: PPP (PPPSerial)
Hardware: Modem
BSD Device Name: Bluetooth-Modem
Has IP Assigned: No
IPv4:
Configuration Method: PPP
IPv6:
Configuration Method: Automatic
Proxies:
FTP Passive Mode: Yes
Service Order: 4

Ethernet:

Type: Ethernet
Hardware: Ethernet
BSD Device Name: en1
Has IP Assigned: No
IPv4:
Configuration Method: DHCP
IPv6:
Configuration Method: Automatic
Proxies:
Exceptions List: *.local, 169.254/16
FTP Passive Mode: Yes
Service Order: 5

AirPort:

Type: AirPort
Hardware: AirPort
BSD Device Name: en0
Has IP Assigned: Yes
IPv4 Addresses: 10.0.4.18
IPv4:
Addresses: 10.0.4.18
ARPResolvedHardwareAddress: b8:c7:5d:c6:c5:b2
ARPResolvedIPAddress: 10.0.4.1
Configuration Method: DHCP
Interface Name: en0
Network Signature:
IPv4.Router=10.0.4.1;IPv4.RouterHardwareAddress=b8:c7:5d:c6:c5:b2
Router: 10.0.4.1
Subnet Masks: 255.255.255.0
DNS:
Domain Name: chello.at
Server Addresses: 10.0.4.1
DHCP Server Responses:
Domain Name: chello.at
Domain Name Servers: 10.0.4.1
Lease Duration (seconds): 0
DHCP Message Type: 0x05
Routers: 10.0.4.1
Server Identifier: 10.0.4.1
Subnet Mask: 255.255.255.0
Ethernet:
MAC Address: b8:f6:b1:1a:3b:2d
Media Options:
Media Subtype: Auto Select
Proxies:
Exceptions List: *.local, 169.254/16
FTP Passive Mode: Yes
Service Order: 7

Tivizen Mobile TV USB:

Type: Ethernet
Hardware: Ethernet
BSD Device Name: en2
Has IP Assigned: Yes
IPv4 Addresses: 192.168.16.50
IPv4:
Addresses: 192.168.16.50
Configuration Method: DHCP
Interface Name: en2
Subnet Masks: 255.255.255.0
IPv6:
Configuration Method: Automatic
DHCP Server Responses:
Domain Name: local
Lease Duration (seconds): 0
DHCP Message Type: 0x05
Server Identifier: 192.168.16.30
Subnet Mask: 255.255.255.0
Ethernet:
MAC Address: e6:05:cb:d4:48:29
Media Options: Full Duplex
Media Subtype: 10baseT/UTP
Proxies:
Exceptions List: *.local, 169.254/16
FTP Passive Mode: Yes
Service Order: 8

Thunderbolt FireWire:

Type: FireWire
Hardware: FireWire
BSD Device Name: fw0
Has IP Assigned: No
IPv4:
Configuration Method: DHCP
IPv6:
Configuration Method: Automatic
Proxies:
Exceptions List: *.local, 169.254/16
FTP Passive Mode: Yes
Service Order: 9

iPhone:

Type: Ethernet
Hardware: Ethernet
BSD Device Name: en3
Has IP Assigned: No
IPv4:
Configuration Method: DHCP
IPv6:
Configuration Method: Automatic
Proxies:
Exceptions List: *.local, 169.254/16
FTP Passive Mode: Yes
Service Order: 10

[Thomas Kaiser]

Post by Marc Stibane

Post by Thomas Kaiser

Post by Thomas Kaiser
Also: Dein MacBook Pro hängt sowohl im WLAN als am Ethernet (der
Anschluß ist aktiv, die default route geht übers Ethernet)

Nachsatz: "en0" ist normalerweise Ethernet. Um sicherzugehen, bitte noch
die Ausgabe von
system_profiler SPNetworkDataType
hierher.

Beim rMBP ist en0 WLAN.
ms$ system_profiler SPNetworkDataType
[...]
Type: AirPort
Hardware: AirPort
BSD Device Name: en0
Has IP Assigned: Yes
IPv4 Addresses: 10.0.4.18
[...]
Domain Name: chello.at
Server Addresses: 10.0.4.1
[...]
Service Order: 7

Irgendeinen spezifischen Grund, warum dieses Dein Haupt-Interface erst
abgeschlagen auf diesem Platz in der Reihenfolge der Interfaces
auftaucht? OS X bzw. dessen configd funktioniert so, daß die
Reihenfolge, in der Du die Interfaces in den Systemeinstellungen
festlegst, eine wichtige Rolle spielt in Abhängigkeit davon, welche
Interfaces gerade aktiv sind oder nicht. D.h. das erste Interface, das
einen physischen Link hat (Ethernet-Kabel gesteckt, Einbuchen in WLAN,
bei den USB-Varianten $irgendwas, das der Treiber gegenüber dem System
signalisiert), ist das, über das in Folge die default route gelegt wird
(Änderung der Routing Table).

Laß den ping mal Richtung 10.0.4.1 durchlaufen (und Ausgabe der
/etc/resolv.conf kannste Dir schenken). Und wenn das Problem das nächste
mal wieder auftritt, dann schauen wir uns a) die Ergebnisse an und b)
schiebst Du Dein Airport-Dings mal ans obere Ende der Liste, damit dort
"Service Order: 0" steht.

Post by Marc Stibane
Type: Ethernet
Hardware: Ethernet
BSD Device Name: en2
Has IP Assigned: Yes
IPv4 Addresses: 192.168.16.50
[...]

Interessant. Das Ding behauptet gegenüber dem System, es wäre ein
Ethernet-Adapter. Und dahinter steckt ein eigenes LAN. Über dieses
Interface zeigt seltsamerweise eine Route zu einem Server, der bei
Hetzner steht, bei dem viele Standard-Ports offen sind, auf dem ein eher
frisches Debian Squeeze läuft und dessen Webmin-SSL-Zertifikat zu
nierle.com gehört. Kannst Du damit was anfangen?

Gruss,

Thomas

[Marc Stibane]

Marc Stibane schrieb

Post by Marc Stibane
Beim rMBP ist en0 WLAN.
ms$ system_profiler SPNetworkDataType
[...]
Type: AirPort
Hardware: AirPort
BSD Device Name: en0
Has IP Assigned: Yes
IPv4 Addresses: 10.0.4.18
[...]
Domain Name: chello.at
Server Addresses: 10.0.4.1
[...]
Service Order: 7

Irgendeinen spezifischen Grund, warum dieses Dein Haupt-Interface erst
abgeschlagen auf diesem Platz in der Reihenfolge der Interfaces
auftaucht?

Keine Ahnung.

OS X bzw. dessen configd funktioniert so, daß die
Reihenfolge, in der Du die Interfaces in den Systemeinstellungen
festlegst, eine wichtige Rolle spielt in Abhängigkeit davon, welche
Interfaces gerade aktiv sind oder nicht. D.h. das erste Interface, das
einen physischen Link hat (Ethernet-Kabel gesteckt, Einbuchen in WLAN,
bei den USB-Varianten $irgendwas, das der Treiber gegenüber dem System
signalisiert), ist das, über das in Folge die default route gelegt wird
(Änderung der Routing Table).

Im Kontrollfeld Netzwerk ist aber das WLAN ganz oben.
Danach der Tivizen, und nur die beiden haben einen grünen Punkt.
Dann kommt USBserial (rot), die drei Huawei-Modems (gelb), Ethernet
(rot), Thunderbolt Firewire (rot), und schließlich iPhone USB (rot).

Laß den ping mal Richtung 10.0.4.1 durchlaufen

läuft...

Und wenn das Problem das nächste mal wieder auftritt, dann schauen wir uns
a) die Ergebnisse an und b) schiebst Du Dein Airport-Dings mal ans obere
Ende der Liste, damit dort "Service Order: 0" steht.

Die Reihenfolge kann man ja eh nicht mehr ändern. Früher konnte man die
nach Belieben rauf und runter draggen, jetzt wechselt nur die Selektion.
Auch nicht mit ctrl/alt/cmd...

Post by Marc Stibane
Type: Ethernet
Hardware: Ethernet
BSD Device Name: en2
Has IP Assigned: Yes
IPv4 Addresses: 192.168.16.50
[...]

Interessant. Das Ding behauptet gegenüber dem System, es wäre ein
Ethernet-Adapter. Und dahinter steckt ein eigenes LAN.

Oder eben WLAN - man kann es wahlweise in ein existierendes WLAN
einbuchen oder aber es spannt ein eigenes auf, in das sich dann Mac oder
iPad einbuchen können.
Stammt von ElGato, läuft mit EyeTV. Die waren bestimmt nur zu faul einen
USB-Treiber zu schreiben. Da sie eh für WLAN ein Netzwerk-Interface
brauchen, verwenden sie das auch für USB.

Aber das Teil besitze ich schon seit 'nem Dreivierteljahr und habe
monatelang nix mehr an der Konfiguration geändert.

Über dieses Interface zeigt seltsamerweise eine Route zu einem Server, der
bei Hetzner steht, bei dem viele Standard-Ports offen sind, auf dem ein
eher frisches Debian Squeeze läuft und dessen Webmin-SSL-Zertifikat zu
nierle.com gehört. Kannst Du damit was anfangen?

Nö. Ich betreibe das Ding per USB, weil es kein 5GHz WLAN kann, sondern
nur 2.4GHz, und da ist hier zuviel los. Führt zu Aussetzern beim
Aufnehmen.

[Bjoern Seegebarth]

Am 29.04.13 19:48, schrieb Marc Stibane:
[…]

Post by Marc Stibane
Die Reihenfolge kann man ja eh nicht mehr ändern. Früher konnte man die
nach Belieben rauf und runter draggen, jetzt wechselt nur die Selektion.
Auch nicht mit ctrl/alt/cmd...

[…]

Hi!

Klar kann man.
Klick mal auf das Zahnrad unten.

Grüße
Björn

[Marc Stibane]

Post by Bjoern Seegebarth

Die Reihenfolge kann man ja eh nicht mehr ändern. > […]

Klick mal auf das Zahnrad unten.

Ups. Ich nehme alles zurück und behaupte das Gegenteil.

Gut, jetzt ist WLAN an erster Stelle und Ethernet an zweiter. Tivizen an
letzter, da gibt es eh nie eine Route ins Netz, nur TV-Daten.

[Marc Stibane]

Post by Thomas Kaiser
Laß den ping mal Richtung 10.0.4.1 durchlaufen

Gerade wieder down am rMBP.

64 bytes from 10.0.4.1: icmp_seq=645 ttl=255 time=3.038 ms
64 bytes from 10.0.4.1: icmp_seq=646 ttl=255 time=3.030 ms
64 bytes from 10.0.4.1: icmp_seq=647 ttl=255 time=3.142 ms
Request timeout for icmp_seq 649
Request timeout for icmp_seq 650
Request timeout for icmp_seq 651
Request timeout for icmp_seq 652
Request timeout for icmp_seq 653
Request timeout for icmp_seq 654
Request timeout for icmp_seq 655
ping: sendto: Host is down
Request timeout for icmp_seq 656
ping: sendto: Host is down
Request timeout for icmp_seq 657
ping: sendto: Host is down
Request timeout for icmp_seq 658
ping: sendto: Host is down
Request timeout for icmp_seq 659
ping: sendto: Host is down
Request timeout for icmp_seq 660
ping: sendto: Host is down


Am iPad funktioniert der Ping problemlos. Braucht da zwar nicht 3ms
sondern meistens 23ms, aber das war auch vorher schon so (als es am rMBP
noch ging).

[Marc Stibane]

Post by Marc Stibane

Post by Thomas Kaiser
Laß den ping mal Richtung 10.0.4.1 durchlaufen

Gerade wieder down am rMBP.
64 bytes from 10.0.4.1: icmp_seq=645 ttl=255 time=3.038 ms
64 bytes from 10.0.4.1: icmp_seq=646 ttl=255 time=3.030 ms
64 bytes from 10.0.4.1: icmp_seq=647 ttl=255 time=3.142 ms
Request timeout for icmp_seq 649
Request timeout for icmp_seq 650
Request timeout for icmp_seq 651
Request timeout for icmp_seq 652
Request timeout for icmp_seq 653
Request timeout for icmp_seq 654
Request timeout for icmp_seq 655
ping: sendto: Host is down
Request timeout for icmp_seq 656
ping: sendto: Host is down
Request timeout for icmp_seq 657
ping: sendto: Host is down
Request timeout for icmp_seq 658
ping: sendto: Host is down
Request timeout for icmp_seq 659
ping: sendto: Host is down
Request timeout for icmp_seq 660
ping: sendto: Host is down
Am iPad funktioniert der Ping problemlos. Braucht da zwar nicht 3ms
sondern meistens 23ms, aber das war auch vorher schon so (als es am rMBP
noch ging).

Jetzt geht's wieder:

Request timeout for icmp_seq 729
ping: sendto: Host is down
Request timeout for icmp_seq 730
Request timeout for icmp_seq 731
64 bytes from 10.0.4.1: icmp_seq=732 ttl=255 time=1.291 ms
64 bytes from 10.0.4.1: icmp_seq=733 ttl=255 time=0.566 ms
64 bytes from 10.0.4.1: icmp_seq=734 ttl=255 time=0.572 ms
64 bytes from 10.0.4.1: icmp_seq=735 ttl=255 time=0.478 ms
64 bytes from 10.0.4.1: icmp_seq=736 ttl=255 time=0.645 ms
64 bytes from 10.0.4.1: icmp_seq=737 ttl=255 time=0.401 ms
64 bytes from 10.0.4.1: icmp_seq=738 ttl=255 time=0.627 ms
64 bytes from 10.0.4.1: icmp_seq=739 ttl=255 time=0.604 ms
64 bytes from 10.0.4.1: icmp_seq=740 ttl=255 time=0.556 ms
64 bytes from 10.0.4.1: icmp_seq=741 ttl=255 time=0.608 ms
64 bytes from 10.0.4.1: icmp_seq=742 ttl=255 time=0.968 ms
64 bytes from 10.0.4.1: icmp_seq=743 ttl=255 time=0.558 ms
64 bytes from 10.0.4.1: icmp_seq=744 ttl=255 time=0.541 ms
64 bytes from 10.0.4.1: icmp_seq=745 ttl=255 time=0.730 ms
64 bytes from 10.0.4.1: icmp_seq=746 ttl=255 time=0.637 ms
64 bytes from 10.0.4.1: icmp_seq=747 ttl=255 time=0.503 ms
64 bytes from 10.0.4.1: icmp_seq=748 ttl=255 time=0.562 ms
64 bytes from 10.0.4.1: icmp_seq=749 ttl=255 time=0.543 ms
64 bytes from 10.0.4.1: icmp_seq=750 ttl=255 time=0.528 ms
64 bytes from 10.0.4.1: icmp_seq=751 ttl=255 time=0.602 ms

Deutlich schneller als vor dem Ausfall.

[Marc Stibane]

Post by Marc Stibane

Post by Marc Stibane

Post by Thomas Kaiser
Laß den ping mal Richtung 10.0.4.1 durchlaufen

Gerade wieder down am rMBP.
64 bytes from 10.0.4.1: icmp_seq=647 ttl=255 time=3.142 ms
Request timeout for icmp_seq 649
Request timeout for icmp_seq 650
Request timeout for icmp_seq 651
Request timeout for icmp_seq 652
Request timeout for icmp_seq 653
Request timeout for icmp_seq 654
Request timeout for icmp_seq 655
ping: sendto: Host is down
Am iPad funktioniert der Ping problemlos. Braucht da zwar nicht 3ms
sondern meistens 23ms, aber das war auch vorher schon so (als es am
rMBP noch ging).

Request timeout for icmp_seq 729
ping: sendto: Host is down
Request timeout for icmp_seq 730
Request timeout for icmp_seq 731
64 bytes from 10.0.4.1: icmp_seq=732 ttl=255 time=1.291 ms
64 bytes from 10.0.4.1: icmp_seq=733 ttl=255 time=0.566 ms
64 bytes from 10.0.4.1: icmp_seq=734 ttl=255 time=0.572 ms
64 bytes from 10.0.4.1: icmp_seq=735 ttl=255 time=0.478 ms
Deutlich schneller als vor dem Ausfall.

Jetzt gab es mal ein paar Hickups vor einem Ausfall, der auch ziemlich
lange anhält:

64 bytes from 10.0.4.1: icmp_seq=1880 ttl=255 time=0.543 ms
64 bytes from 10.0.4.1: icmp_seq=1881 ttl=255 time=0.634 ms
64 bytes from 10.0.4.1: icmp_seq=1882 ttl=255 time=3.206 ms
64 bytes from 10.0.4.1: icmp_seq=1883 ttl=255 time=3.349 ms
64 bytes from 10.0.4.1: icmp_seq=1884 ttl=255 time=0.864 ms
64 bytes from 10.0.4.1: icmp_seq=1885 ttl=255 time=0.587 ms
64 bytes from 10.0.4.1: icmp_seq=1886 ttl=255 time=1.253 ms
64 bytes from 10.0.4.1: icmp_seq=1887 ttl=255 time=3.180 ms
64 bytes from 10.0.4.1: icmp_seq=1888 ttl=255 time=3.425 ms
Request timeout for icmp_seq 1889
64 bytes from 10.0.4.1: icmp_seq=1890 ttl=255 time=0.589 ms
64 bytes from 10.0.4.1: icmp_seq=1891 ttl=255 time=0.603 ms
Request timeout for icmp_seq 1892
64 bytes from 10.0.4.1: icmp_seq=1893 ttl=255 time=0.574 ms
64 bytes from 10.0.4.1: icmp_seq=1894 ttl=255 time=3.314 ms
Request timeout for icmp_seq 1895
Request timeout for icmp_seq 1896
64 bytes from 10.0.4.1: icmp_seq=1897 ttl=255 time=109.944 ms
64 bytes from 10.0.4.1: icmp_seq=1898 ttl=255 time=0.640 ms
Request timeout for icmp_seq 1899
64 bytes from 10.0.4.1: icmp_seq=1900 ttl=255 time=0.578 ms
64 bytes from 10.0.4.1: icmp_seq=1901 ttl=255 time=10.173 ms
64 bytes from 10.0.4.1: icmp_seq=1902 ttl=255 time=0.576 ms
64 bytes from 10.0.4.1: icmp_seq=1903 ttl=255 time=3.227 ms
64 bytes from 10.0.4.1: icmp_seq=1904 ttl=255 time=3.359 ms
64 bytes from 10.0.4.1: icmp_seq=1905 ttl=255 time=0.668 ms
64 bytes from 10.0.4.1: icmp_seq=1906 ttl=255 time=3.242 ms
64 bytes from 10.0.4.1: icmp_seq=1907 ttl=255 time=0.637 ms
64 bytes from 10.0.4.1: icmp_seq=1908 ttl=255 time=0.692 ms
64 bytes from 10.0.4.1: icmp_seq=1909 ttl=255 time=0.621 ms
Request timeout for icmp_seq 1910
64 bytes from 10.0.4.1: icmp_seq=1911 ttl=255 time=117.947 ms
64 bytes from 10.0.4.1: icmp_seq=1912 ttl=255 time=3.104 ms
64 bytes from 10.0.4.1: icmp_seq=1913 ttl=255 time=3.251 ms
64 bytes from 10.0.4.1: icmp_seq=1914 ttl=255 time=3.249 ms
64 bytes from 10.0.4.1: icmp_seq=1915 ttl=255 time=0.720 ms
64 bytes from 10.0.4.1: icmp_seq=1916 ttl=255 time=0.614 ms
64 bytes from 10.0.4.1: icmp_seq=1917 ttl=255 time=3.123 ms
64 bytes from 10.0.4.1: icmp_seq=1918 ttl=255 time=3.189 ms
Request timeout for icmp_seq 1919
64 bytes from 10.0.4.1: icmp_seq=1920 ttl=255 time=107.881 ms
64 bytes from 10.0.4.1: icmp_seq=1921 ttl=255 time=3.109 ms
64 bytes from 10.0.4.1: icmp_seq=1922 ttl=255 time=3.142 ms
64 bytes from 10.0.4.1: icmp_seq=1923 ttl=255 time=3.474 ms
64 bytes from 10.0.4.1: icmp_seq=1924 ttl=255 time=3.477 ms
64 bytes from 10.0.4.1: icmp_seq=1925 ttl=255 time=6.222 ms
64 bytes from 10.0.4.1: icmp_seq=1926 ttl=255 time=3.165 ms
Request timeout for icmp_seq 1927
64 bytes from 10.0.4.1: icmp_seq=1928 ttl=255 time=53.402 ms
64 bytes from 10.0.4.1: icmp_seq=1929 ttl=255 time=0.673 ms
64 bytes from 10.0.4.1: icmp_seq=1930 ttl=255 time=3.489 ms
Request timeout for icmp_seq 1931
64 bytes from 10.0.4.1: icmp_seq=1932 ttl=255 time=0.566 ms
64 bytes from 10.0.4.1: icmp_seq=1933 ttl=255 time=3.120 ms
64 bytes from 10.0.4.1: icmp_seq=1934 ttl=255 time=3.040 ms
64 bytes from 10.0.4.1: icmp_seq=1935 ttl=255 time=0.604 ms
64 bytes from 10.0.4.1: icmp_seq=1936 ttl=255 time=3.083 ms
64 bytes from 10.0.4.1: icmp_seq=1937 ttl=255 time=3.078 ms
64 bytes from 10.0.4.1: icmp_seq=1938 ttl=255 time=3.339 ms
64 bytes from 10.0.4.1: icmp_seq=1939 ttl=255 time=23.830 ms
64 bytes from 10.0.4.1: icmp_seq=1940 ttl=255 time=0.625 ms
Request timeout for icmp_seq 1941
64 bytes from 10.0.4.1: icmp_seq=1942 ttl=255 time=0.650 ms
Request timeout for icmp_seq 1943
Request timeout for icmp_seq 1944
Request timeout for icmp_seq 1945
Request timeout for icmp_seq 1946
Request timeout for icmp_seq 1947
Request timeout for icmp_seq 1948
ping: sendto: Host is down
Request timeout for icmp_seq 1949
ping: sendto: Host is down
Request timeout for icmp_seq 1950
ping: sendto: Host is down
...
Request timeout for icmp_seq 2045
ping: sendto: Host is down
Request timeout for icmp_seq 2046
Request timeout for icmp_seq 2047
64 bytes from 10.0.4.1: icmp_seq=2048 ttl=255 time=0.622 ms
64 bytes from 10.0.4.1: icmp_seq=2049 ttl=255 time=0.666 ms
64 bytes from 10.0.4.1: icmp_seq=2050 ttl=255 time=0.577 ms
64 bytes from 10.0.4.1: icmp_seq=2051 ttl=255 time=0.684 ms
64 bytes from 10.0.4.1: icmp_seq=2052 ttl=255 time=0.648 ms
64 bytes from 10.0.4.1: icmp_seq=2053 ttl=255 time=0.618 ms
64 bytes from 10.0.4.1: icmp_seq=2054 ttl=255 time=0.572 ms
64 bytes from 10.0.4.1: icmp_seq=2055 ttl=255 time=0.557 ms
64 bytes from 10.0.4.1: icmp_seq=2056 ttl=255 time=0.522 ms
64 bytes from 10.0.4.1: icmp_seq=2057 ttl=255 time=0.609 ms
64 bytes from 10.0.4.1: icmp_seq=2058 ttl=255 time=0.698 ms
64 bytes from 10.0.4.1: icmp_seq=2059 ttl=255 time=0.625 ms
64 bytes from 10.0.4.1: icmp_seq=2060 ttl=255 time=0.530 ms
64 bytes from 10.0.4.1: icmp_seq=2061 ttl=255 time=0.576 ms
64 bytes from 10.0.4.1: icmp_seq=2062 ttl=255 time=0.523 ms

104 * 3Sek = knapp über 5 Minuten Ausfall. So lange dauert es
"normalerweise" nicht...

[Marc Stibane]

Post by Marc Stibane
104 * 3Sek = knapp über 5 Minuten Ausfall. So lange dauert es
"normalerweise" nicht...

So, der ping ist die ganze Nacht durchgelaufen. Es gab keinen größeren
Ausfall, nur einzelne Pakete kamen nicht an. Und einmal gleich 4
nacheinander:

64 bytes from 10.0.4.1: icmp_seq=8287 ttl=255 time=3.370 ms
64 bytes from 10.0.4.1: icmp_seq=8288 ttl=255 time=3.225 ms
Request timeout for icmp_seq 8289
Request timeout for icmp_seq 8290
Request timeout for icmp_seq 8291
Request timeout for icmp_seq 8292
64 bytes from 10.0.4.1: icmp_seq=8293 ttl=255 time=3.115 ms
64 bytes from 10.0.4.1: icmp_seq=8294 ttl=255 time=0.581 ms

Mittlerweile ist er hier:

64 bytes from 10.0.4.1: icmp_seq=13519 ttl=255 time=3.480 ms
64 bytes from 10.0.4.1: icmp_seq=13520 ttl=255 time=0.611 ms
64 bytes from 10.0.4.1: icmp_seq=13521 ttl=255 time=3.689 ms
64 bytes from 10.0.4.1: icmp_seq=13522 ttl=255 time=3.456 ms
64 bytes from 10.0.4.1: icmp_seq=13523 ttl=255 time=3.331 ms
64 bytes from 10.0.4.1: icmp_seq=13524 ttl=255 time=0.788 ms
64 bytes from 10.0.4.1: icmp_seq=13525 ttl=255 time=3.193 ms
64 bytes from 10.0.4.1: icmp_seq=13526 ttl=255 time=0.750 ms
64 bytes from 10.0.4.1: icmp_seq=13527 ttl=255 time=3.164 ms

[Marc Stibane]

Post by Marc Stibane
64 bytes from 10.0.4.1: icmp_seq=13519 ttl=255 time=3.480 ms
64 bytes from 10.0.4.1: icmp_seq=13520 ttl=255 time=0.611 ms
64 bytes from 10.0.4.1: icmp_seq=13521 ttl=255 time=3.689 ms
64 bytes from 10.0.4.1: icmp_seq=13522 ttl=255 time=3.456 ms
64 bytes from 10.0.4.1: icmp_seq=13523 ttl=255 time=3.331 ms
64 bytes from 10.0.4.1: icmp_seq=13524 ttl=255 time=0.788 ms
64 bytes from 10.0.4.1: icmp_seq=13525 ttl=255 time=3.193 ms
64 bytes from 10.0.4.1: icmp_seq=13526 ttl=255 time=0.750 ms
64 bytes from 10.0.4.1: icmp_seq=13527 ttl=255 time=3.164 ms

Gerade der erste Ausfall seit gestern abend:

64 bytes from 10.0.4.1: icmp_seq=19571 ttl=255 time=3.203 ms
64 bytes from 10.0.4.1: icmp_seq=19572 ttl=255 time=3.259 ms
Request timeout for icmp_seq 19573
Request timeout for icmp_seq 19574
Request timeout for icmp_seq 19575
Request timeout for icmp_seq 19576
Request timeout for icmp_seq 19577
Request timeout for icmp_seq 19578
Request timeout for icmp_seq 19579
Request timeout for icmp_seq 19580
Request timeout for icmp_seq 19581
Request timeout for icmp_seq 19582
Request timeout for icmp_seq 19583
Request timeout for icmp_seq 19584
Request timeout for icmp_seq 19585
Request timeout for icmp_seq 19586
Request timeout for icmp_seq 19587
ping: sendto: Host is down
Request timeout for icmp_seq 19588
ping: sendto: Host is down
Request timeout for icmp_seq 19589
ping: sendto: Host is down
Request timeout for icmp_seq 19590
ping: sendto: Host is down
Request timeout for icmp_seq 19591
ping: sendto: Host is down
Request timeout for icmp_seq 19592
ping: sendto: Host is down
Request timeout for icmp_seq 19593
Request timeout for icmp_seq 19594
Request timeout for icmp_seq 19595
ping: sendto: Host is down
Request timeout for icmp_seq 19596
ping: sendto: Host is down
Request timeout for icmp_seq 19597
ping: sendto: Host is down
Request timeout for icmp_seq 19598
ping: sendto: Host is down
Request timeout for icmp_seq 19599
ping: sendto: Host is down
Request timeout for icmp_seq 19600
ping: sendto: Host is down
Request timeout for icmp_seq 19601
ping: sendto: Host is down
Request timeout for icmp_seq 19602
Request timeout for icmp_seq 19603
Request timeout for icmp_seq 19604
ping: sendto: Host is down
Request timeout for icmp_seq 19605
ping: sendto: Host is down
Request timeout for icmp_seq 19606
ping: sendto: Host is down
Request timeout for icmp_seq 19607
ping: sendto: Host is down
Request timeout for icmp_seq 19608
ping: sendto: Host is down
Request timeout for icmp_seq 19609
ping: sendto: Host is down
Request timeout for icmp_seq 19610
ping: sendto: Host is down
Request timeout for icmp_seq 19611
Request timeout for icmp_seq 19612
ping: sendto: Host is down
Request timeout for icmp_seq 19613
ping: sendto: Host is down
Request timeout for icmp_seq 19614
ping: sendto: Host is down
Request timeout for icmp_seq 19615
ping: sendto: Host is down
Request timeout for icmp_seq 19616
ping: sendto: Host is down
Request timeout for icmp_seq 19617
ping: sendto: Host is down
Request timeout for icmp_seq 19618
Request timeout for icmp_seq 19619
Request timeout for icmp_seq 19620
Request timeout for icmp_seq 19621
Request timeout for icmp_seq 19622
Request timeout for icmp_seq 19623
Request timeout for icmp_seq 19624
64 bytes from 10.0.4.1: icmp_seq=19625 ttl=255 time=1529.765 ms
64 bytes from 10.0.4.1: icmp_seq=19626 ttl=255 time=0.517 ms
64 bytes from 10.0.4.1: icmp_seq=19627 ttl=255 time=0.585 ms
64 bytes from 10.0.4.1: icmp_seq=19628 ttl=255 time=0.545 ms
64 bytes from 10.0.4.1: icmp_seq=19629 ttl=255 time=0.650 ms
64 bytes from 10.0.4.1: icmp_seq=19630 ttl=255 time=0.707 ms
64 bytes from 10.0.4.1: icmp_seq=19631 ttl=255 time=0.545 ms
64 bytes from 10.0.4.1: icmp_seq=19632 ttl=255 time=3.210 ms
64 bytes from 10.0.4.1: icmp_seq=19633 ttl=255 time=0.534 ms
64 bytes from 10.0.4.1: icmp_seq=19634 ttl=255 time=0.932 ms
64 bytes from 10.0.4.1: icmp_seq=19635 ttl=255 time=3.255 ms
64 bytes from 10.0.4.1: icmp_seq=19636 ttl=255 time=0.805 ms
64 bytes from 10.0.4.1: icmp_seq=19637 ttl=255 time=3.179 ms
64 bytes from 10.0.4.1: icmp_seq=19638 ttl=255 time=3.339 ms
64 bytes from 10.0.4.1: icmp_seq=19639 ttl=255 time=3.207 ms
64 bytes from 10.0.4.1: icmp_seq=19640 ttl=255 time=0.583 ms
64 bytes from 10.0.4.1: icmp_seq=19641 ttl=255 time=1.739 ms
64 bytes from 10.0.4.1: icmp_seq=19642 ttl=255 time=0.562 ms

[Marc Stibane]

Post by Thomas Kaiser
Ja und? Sinn der Übung war doch, daß andere mal mit drüberschauen, die
neu an die Sache rangehen, oder?

Hast ja recht.

Post by Thomas Kaiser
Also: Dein MacBook Pro hängt sowohl im WLAN als am Ethernet (der
Anschluß ist aktiv, die default route geht übers Ethernet)

Das ist ein rMBP ohne Ethernet-Chip. Und ich besitze gar keinen
Thunderbolt-Ethernet-Adapmich. Also kommen darüber bestimmt keine
Daten...

Post by Thomas Kaiser
und wenn's hängt, ist definitiv DNS betroffen, siehe die Timeouts. Was
jetzt gefehlt hat, war 'ne Aussage bzgl. des Dauer-Pings. Hast Du einen
mitlaufen lassen?

Noch nicht. War über's WE verreist (ohne Mac!), und habe nur heute früh
nach Lesen Deines Posts gleich mal die 3 Kommandos abgesetzt, als Safari
keine Seite mehr öffnen wollte (noch bevor die Volume-lost Meldung kam).

Post by Thomas Kaiser
Bitte mal die Ausgabe von

...

mache ich heute abend, muss jetzt nochmal weg.

Post by Thomas Kaiser
BTW: Was noch seltsam ist: Default route zeigt via Ethernet ins Internet
aber zu irgendso 'nem Hetzner-Server bzw. 88.198.180.55 geht's über
WLAN. Warum?

rMBP ohne Ethernet-Chip.

Post by Thomas Kaiser
VPN-Verbindung aufgerissen? Statisch an Routen rumgespielt?

nein und nein

[Marc Stibane]

Post by Thomas Kaiser
Bzw. nee, kürzen wir es gleich ab. Mach einfach ein
killall -INFO mDNSResponder

Ohne sudo kommt da nur
No matching processes belonging to you were found
also mit sudo...

Post by Thomas Kaiser
sudo grep mDNSResponder /var/log/system.log | open -f

Und das sind dann über 200KB Text, das will ich hier nicht abkippen.
Aber das Ergebnis von

Post by Thomas Kaiser
sudo killall -USR1 mDNSResponder

Apr 30 06:56:39 rMBP.local sudo[91650]: ms : TTY=ttys001 ;
PWD=/Users/ms/Downloads/; USER=root ; COMMAND=/usr/bin/killall -USR1
mDNSResponder
Apr 30 06:56:39 rMBP.local mDNSResponder[34]: SIGUSR1: Logging Enabled
Apr 30 06:56:45 rMBP.local mDNSResponder[34]: 13:
DNSServiceGetAddrInfo(login.messaging.aol.com., Addr) RMV 4
login.messaging.aol.com. Addr 205.188.58.57
Apr 30 06:56:45 rMBP.local mDNSResponder[34]: 13:
DNSServiceGetAddrInfo(login.messaging.aol.com., Addr) ADD 4
login.messaging.aol.com. Addr 64.12.172.97
Apr 30 06:56:49 rMBP.local mDNSResponder[34]: 16:
DNSServiceBrowse(_apple-mobdev._tcp.local., PTR) RESULT Add 4: 69
_apple-mobdev._tcp.local. PTR
04:f7:e4:3b:1a:***@fe80::6f7:e4ff:fe3b:1aaa._apple-mobdev._tcp.local.
Apr 30 06:56:49 rMBP.local mDNSResponder[34]: 477: Adding FD for uid 213
Apr 30 06:56:49 rMBP.local mDNSResponder[34]: 477: DNSServiceResolve(0 4
04:f7:e4:3b:1a:***@fe80::6f7:e4ff:fe3b:1aaa._apple-mobdev._tcp.local.)
START PID[56](usbmuxd)
Apr 30 06:56:49 rMBP.local mDNSResponder[34]: 477:
DNSServiceResolve(04:f7:e4:3b:1a:***@fe80::6f7:e4ff:fe3b:1aaa._apple-mobd
ev._tcp.local.) ADD 29
04:f7:e4:3b:1a:***@fe80::6f7:e4ff:fe3b:1aaa._apple-mobdev._tcp.local. SRV
0 0 62078 marcstibanede-5.local.
Apr 30 06:56:49 rMBP.local mDNSResponder[34]: 477:
DNSServiceResolve(04:f7:e4:3b:1a:***@fe80::6f7:e4ff:fe3b:1aaa._apple-mobd
ev._tcp.local.) ADD 1
04:f7:e4:3b:1a:***@fe80::6f7:e4ff:fe3b:1aaa._apple-mobdev._tcp.local. TXT
Apr 30 06:56:49 rMBP.local mDNSResponder[34]: 477:
DNSServiceResolve(04:f7:e4:3b:1a:***@fe80::6f7:e4ff:fe3b:1aaa._apple-mobd
ev._tcp.local.) RESULT marcstibanede-5.local.:62078
Apr 30 06:56:49 rMBP.local mDNSResponder[34]: 480: Adding FD for uid 213
Apr 30 06:56:49 rMBP.local mDNSResponder[34]: 480:
DNSServiceQueryRecord(local., SOA) unicast
Apr 30 06:56:49 rMBP.local mDNSResponder[34]: 480:
DNSServiceGetAddrInfo(0, 4, 1, marcstibanede-5.local.) START
PID[56](usbmuxd)
Apr 30 06:56:49 rMBP.local mDNSResponder[34]: 480:
DNSServiceGetAddrInfo(marcstibanede-5.local., Addr) ADD 4
marcstibanede-5.local. Addr 10.0.4.17
Apr 30 06:56:49 rMBP.local mDNSResponder[34]: 477:
DNSServiceResolve(04:f7:e4:3b:1a:***@fe80::6f7:e4ff:fe3b:1aaa._apple-mobd
ev._tcp.local.) STOP PID[-1]()
Apr 30 06:56:49 rMBP.local mDNSResponder[34]: 477: Removing FD
Apr 30 06:56:49 rMBP.local mDNSResponder[34]: 480:
DNSServiceGetAddrInfo(marcstibanede-5.local.) STOP PID[-1]()
Apr 30 06:56:49 rMBP.local mDNSResponder[34]: 480: Removing FD
Apr 30 06:56:53 rMBP.local sudo[91654]: ms : TTY=ttys001 ;
PWD=/Users/ms/Downloads/ ; USER=root ; COMMAND=/usr/bin/grep
mDNSResponder /var/log/system.log

[Thomas Kaiser]

Post by Marc Stibane

Post by Thomas Kaiser
Bzw. nee, kürzen wir es gleich ab. Mach einfach ein
killall -INFO mDNSResponder

Ohne sudo kommt da nur
No matching processes belonging to you were found

Äh, ja klar. Ich hole mir bei solchen Sachen immer gleich eine root-
Shell per "sudo su -". Du nicht?

Post by Marc Stibane
also mit sudo...

Post by Thomas Kaiser
sudo grep mDNSResponder /var/log/system.log | open -f

Und das sind dann über 200KB Text, das will ich hier nicht abkippen.

Dann war vorherige Übung sinnlos. Von Abkippen hat ja auch niemand
geredet sondern von "online stellen" oder mailen. Aber egal, ist ja Dein
Problem :-)

Post by Marc Stibane
Aber das Ergebnis von

Post by Thomas Kaiser
sudo killall -USR1 mDNSResponder

Apr 30 06:56:39 rMBP.local sudo[91650]: ms : TTY=ttys001 ;
PWD=/Users/ms/Downloads/; USER=root ; COMMAND=/usr/bin/killall -USR1
mDNSResponder

Und damit bin ich raus. Logfiles, die umbrochen sind, erzeugen bei mir
Brechreiz, weil nicht mehr sinnvoll parsebar.

Zu der ping-Chose noch: Spannend wäre gewesen, den ping durchlaufen zu
lassen und *beim Auftreten des Problems* noch parallel

a) die Ausgaben von ifconfig und "netstat -rn"
b) das, was nach Geschwätzigschaltung des mDNSResponder parallel in
/var/log/system.log auftaucht (und zwar _alles_ und nicht nur das,
was der mDNSResponder von sich gibt)

abzufischen.

Alles, was wir anhand des pings bislang wissen, ist, daß es _kein_ DNS-
Problem ist (weil der ping auf die Adresse des DNS-Servers ausgeführt,
selbst nix mit DNS zu tun hat). DNS-Timeouts sind nur Symptom und nicht
Ursache. Nichtsdestoweniger können die Meldungen des mDNSResponder
aufschlußreich sein, weil der recht nah am configd agiert. Ich komme
grad nicht mehr drauf, wie man eben jenen configd(8) in den verbose-
Modus tritt (bis 10.6 war das über eine XML-Datei möglich, ab 10.7 steh
ich grad auf dem Schlauch).

Gruss,

Thomas

[Marc Stibane]

Marc Stibane schrieb

Post by Marc Stibane

Post by Thomas Kaiser
sudo grep mDNSResponder /var/log/system.log | open -f

Und das sind dann über 200KB Text, das will ich hier nicht abkippen.

Dann war vorherige Übung sinnlos. Von Abkippen hat ja auch niemand
geredet sondern von "online stellen" oder mailen.

Kommt per Mail.

Und damit bin ich raus. Logfiles, die umbrochen sind, erzeugen bei mir
Brechreiz, weil nicht mehr sinnvoll parsebar.

OK. Dann auch per Mail.

Zu der ping-Chose noch: Spannend wäre gewesen, den ping durchlaufen zu
lassen und *beim Auftreten des Problems* noch parallel
a) die Ausgaben von ifconfig und "netstat -rn"

Das hatte ich gestern bereits gepostet. Nochmal?

b) das, was nach Geschwätzigschaltung des mDNSResponder parallel in
/var/log/system.log auftaucht (und zwar _alles_ und nicht nur das,
was der mDNSResponder von sich gibt)
abzufischen.

OK, das mache ich noch.

Alles, was wir anhand des pings bislang wissen, ist, daß es _kein_ DNS-
Problem ist (weil der ping auf die Adresse des DNS-Servers ausgeführt,
selbst nix mit DNS zu tun hat).

Jupp. Außerdem gibt es immer auch eine Fehlermeldung Volume-lost, was ja
wohl auch nicht am DNS hängt, oder?

[Thomas Kaiser]

Post by Marc Stibane

Marc Stibane schrieb

Post by Marc Stibane

Post by Thomas Kaiser
sudo grep mDNSResponder /var/log/system.log | open -f

Und das sind dann über 200KB Text, das will ich hier nicht abkippen.

Dann war vorherige Übung sinnlos. Von Abkippen hat ja auch niemand
geredet sondern von "online stellen" oder mailen.

Kommt per Mail.

Danke, da stand nix Auffälliges drin.

Post by Marc Stibane

Und damit bin ich raus. Logfiles, die umbrochen sind, erzeugen bei mir
Brechreiz, weil nicht mehr sinnvoll parsebar.

OK. Dann auch per Mail.

Dito ;-)

Post by Marc Stibane

Zu der ping-Chose noch: Spannend wäre gewesen, den ping durchlaufen zu
lassen und *beim Auftreten des Problems* noch parallel
a) die Ausgaben von ifconfig und "netstat -rn"

Das hatte ich gestern bereits gepostet. Nochmal?

Naja, ich meinte _parallel_. Aber das meinte ich, weil zu dem Zeitpunkt
noch nicht klar war, ob "DNS geht nicht" nur Symptom oder doch Ursache
ist. Und das wäre ja geklärt.

Post by Marc Stibane

b) das, was nach Geschwätzigschaltung des mDNSResponder parallel in
/var/log/system.log auftaucht (und zwar _alles_ und nicht nur das,
was der mDNSResponder von sich gibt)
abzufischen.

OK, das mache ich noch.

Das ist dann auch das Letzte, was mir dazu aus der Ferne einfällt.
Gestrige Vermutung war, daß anhand der Reihenfolge der Interfaces aus
irgendeinem Grund sich eines der anderen höher priorisierten plötzlich
als "active" meldet, damit der configd unter anderem die default route
über dieses Device gehend umbiegt (und ggf. auch anderen DNS-Resolver
setzt) und daß es deshalb zum Abbruch kommt. Das sollte sich a) aus
system.log rauslesen lassen, b) jetzt nicht mehr vorkommen, wenn Du
die Reihenfolge geändert hast. Zur Sicherheit nochmal nachschauen (am
Besten abermals per "system_profiler SPNetworkDataType" und Blick auf
"Service Order"). Im normalen GUI wird immer das Interface ganz oben
angezeigt, das gerade in der hinterlegten Reihenfolge "active" ist.

Und c) ist die Idee wohl Blödsinn, den anhand "netstat -rn" ließ sich ja
ablesen, daß sich an den Routen während des Auftretens der Verbindungs-
abbruch nix geändert hat.

Naja, letzte Chance Blick in system.log. Wenn's das nicht bringt, mußt
Du das Ding halt wegwerfen. Ich biete Dir aber günstige Entsorgung an.
Deal? ;-)

Gruss,

Thomas

[Marc Stibane]

Marc Stibane schrieb

Post by Marc Stibane

Marc Stibane schrieb

Post by Thomas Kaiser
sudo grep mDNSResponder /var/log/system.log | open -f

Danke, da stand nix Auffälliges drin.

Post by Marc Stibane

Zu der ping-Chose noch: Spannend wäre gewesen, den ping durchlaufen
zu lassen und *beim Auftreten des Problems* noch parallel
a) die Ausgaben von ifconfig und "netstat -rn"

Das hatte ich gestern bereits gepostet. Nochmal?

Naja, ich meinte _parallel_.

Ich habe die schon gemacht, als gerade das Problem akut war

Aber das meinte ich, weil zu dem Zeitpunkt noch nicht klar war, ob "DNS
geht nicht" nur Symptom oder doch Ursache ist. Und das wäre ja geklärt.

Jupp. Symptom - weil einfach nix über's WLAN geht.

Post by Marc Stibane

b) das, was nach Geschwätzigschaltung des mDNSResponder parallel in
/var/log/system.log auftaucht (und zwar _alles_ und nicht nur
das, was der mDNSResponder von sich gibt) abzufischen.

OK, das mache ich noch.

Das ist dann auch das Letzte, was mir dazu aus der Ferne einfällt.

Derzeit fällt es gerade nicht aus...

Gestrige Vermutung war, daß anhand der Reihenfolge der Interfaces aus
irgendeinem Grund sich eines der anderen höher priorisierten plötzlich
als "active" meldet, damit der configd unter anderem die default route
über dieses Device gehend umbiegt (und ggf. auch anderen DNS-Resolver
setzt) und daß es deshalb zum Abbruch kommt. Das sollte sich a) aus
system.log rauslesen lassen, b) jetzt nicht mehr vorkommen, wenn Du
die Reihenfolge geändert hast. Zur Sicherheit nochmal nachschauen (am
Besten abermals per "system_profiler SPNetworkDataType" und Blick auf
"Service Order").

Das bestätigt die gestrige Aktion - WLAN jetzt als erstes, dann
Ethernet, USBSerial, die Huaweis...

Im normalen GUI wird immer das Interface ganz oben
angezeigt, das gerade in der hinterlegten Reihenfolge "active" ist.

Da wurde die letzten Monate immer WLAN ganz oben gezeigt (und mit grünem
Dot), weil die anderen Devices gar nicht angeschlossen wurden bzw.
(Tivizen) eh keine Internet-Daten lieferten.

Und c) ist die Idee wohl Blödsinn, den anhand "netstat -rn" ließ sich ja
ablesen, daß sich an den Routen während des Auftretens der Verbindungs-
abbruch nix geändert hat.
Naja, letzte Chance Blick in system.log. Wenn's das nicht bringt, mußt
Du das Ding halt wegwerfen.

oder den Aufwand auf mich nehmen, zurück auf 10.8.2 zu gehen. TM-Backup
ist ja vorhanden.

Ich biete Dir aber günstige Entsorgung an. Deal? ;-)

Hast Du denn selber noch kein rMBP?

Hmm, ich habe ja noch Garantie von Apple und kann mit dem Ping-Log ja
auch nachweisen dass da regelmäßig, wenn auch nichtt reproduzierbar was
nicht funktioniert. Werde wohl nächste Woche mal anrufen und
nachfragen...

[Thomas Kaiser]

Post by Marc Stibane

Post by Thomas Kaiser
Das ist dann auch das Letzte, was mir dazu aus der Ferne einfällt.

Derzeit fällt es gerade nicht aus...

Aber nachdem Du die Reihenfolge der Netzwerk-Schnittstellen geändert
hattest, kam es erneut zu einem oder mehreren Ausfällen? Oder nicht?

Post by Marc Stibane

Post by Thomas Kaiser
Im normalen GUI wird immer das Interface ganz oben angezeigt, das
gerade in der hinterlegten Reihenfolge "active" ist.

Da wurde die letzten Monate immer WLAN ganz oben gezeigt (und mit grünem
Dot)

Wie gesagt: Du kriegst in den Systemeinstellungen eine dynamische Sicht
kredenzt, die auch noch verzögert funktioniert. Die echte Reihenfolge
legst Du selbst manuell fest und die dynamische Reihenfolge ergibt sich
aus allen "aktiven" Interfaces (LAN --> Kabel steckt, WLAN --> in Netz
eingebucht, $sontiges --> irgendwas, was der Treiber meldet) anhand der
statischen. Grünen Punkt gibt's, wenn das Interface nicht nur "active"
ist (vgl. mit ifconfig) sondern auch noch eine gültige IP-Konfiguration
aufweisen (sei's manuell oder von einem DHCP-Server kredenzt -- vgl. mit
"system_profiler SPNetworkDataType"). Nur "active" und kein "Has IP
Assigned: Yes" --> oranger Punkt im GUI.

Post by Marc Stibane
weil die anderen Devices gar nicht angeschlossen wurden bzw. (Tivizen)
eh keine Internet-Daten lieferten.

Aber Du hast schon im Hinterkopf, daß dieses USB-Dingens im System als
Ethernet-Schnittstelle ankommt und daß Du zumindest gestern eine
statische Route zu irgendeinem gehosteten Server über dieses USB-Dingens
im System hattest?

Post by Marc Stibane

Post by Thomas Kaiser
Naja, letzte Chance Blick in system.log. Wenn's das nicht bringt,
mußt Du das Ding halt wegwerfen.

oder den Aufwand auf mich nehmen, zurück auf 10.8.2 zu gehen. TM-Backup
ist ja vorhanden.

Wenn's denn wirklich an 10.8.3 liegt. Letztlich nur -- vermutlich
geringere -- Verschwendung von Lebenszeit, das rauszufinden im Vergleich
zur Analyse.

Post by Marc Stibane

Post by Thomas Kaiser
Ich biete Dir aber günstige Entsorgung an. Deal? ;-)

Hast Du denn selber noch kein rMBP?

Nö, mein jetziges MBP ist 1,5 Jahre alt und abgesehen von Kirschsaft-
schaden, Displayschaden durch Kerze (in Cafés/Kneipen arbeiten ist
definitiv gefährlicher als im Büro ;-) und verzogenem Chassis, weil's
aus dem Bett geschleudert wurde, noch topfit!

Post by Marc Stibane
Hmm, ich habe ja noch Garantie von Apple und kann mit dem Ping-Log ja
auch nachweisen dass da regelmäßig, wenn auch nichtt reproduzierbar
was nicht funktioniert.

Naja, ich (als Apple) würde mich (wiederum als Apple) dann aber erstmal
fragen, ob das in 'ner anderen Umgebung auch auftritt. Hast Du da
Vergleichswerte? 24 Stunden in ein anderes 5 GHz WLAN umziehen und dort
dauerpingenderweise mitschneiden?

Gruss,

Thomas

[Marc Stibane]

Marc Stibane schrieb

Post by Marc Stibane

Post by Thomas Kaiser
Das ist dann auch das Letzte, was mir dazu aus der Ferne einfällt.

Derzeit fällt es gerade nicht aus...

Aber nachdem Du die Reihenfolge der Netzwerk-Schnittstellen geändert
hattest, kam es erneut zu einem oder mehreren Ausfällen? Oder nicht?

Ja, heute waren's schon 2.

Post by Marc Stibane
weil die anderen Devices gar nicht angeschlossen wurden bzw.
(Tivizen) eh keine Internet-Daten lieferten.

Aber Du hast schon im Hinterkopf, daß dieses USB-Dingens im System als
Ethernet-Schnittstelle ankommt und daß Du zumindest gestern eine
statische Route zu irgendeinem gehosteten Server über dieses USB-Dingens
im System hattest?

Gut, da werde ich nochmal nachsehen, was das soll.

Post by Marc Stibane

Post by Thomas Kaiser
Naja, letzte Chance Blick in system.log. Wenn's das nicht bringt,
mußt Du das Ding halt wegwerfen.

oder den Aufwand auf mich nehmen, zurück auf 10.8.2 zu gehen.
TM-Backup ist ja vorhanden.

Wenn's denn wirklich an 10.8.3 liegt. Letztlich nur -- vermutlich
geringere -- Verschwendung von Lebenszeit, das rauszufinden im Vergleich
zur Analyse.

Jupp. Ich werde aber erst nochmal 'ne weitere 3TB-Platte ordern, und da
einen Klon draufziehen.

Post by Marc Stibane
Hast Du denn selber noch kein rMBP?

Nö, mein jetziges MBP ist 1,5 Jahre alt und abgesehen von Kirschsaft-
schaden, Displayschaden durch Kerze (in Cafés/Kneipen arbeiten ist
definitiv gefährlicher als im Büro ;-) und verzogenem Chassis, weil's
aus dem Bett geschleudert wurde, noch topfit!

Ich habe ja auch 5 Jahre mit meinem 2.4GHz 17" MBP (pre-unibody)
ausgehalten - der Sprung zum rMBP war heftig. Mal sehen, wie lange das
jetzt durchhält (bzw. wie lange es mir ausreicht)...

Post by Marc Stibane
Hmm, ich habe ja noch Garantie von Apple und kann mit dem Ping-Log ja
auch nachweisen dass da regelmäßig, wenn auch nichtt reproduzierbar
was nicht funktioniert.

Naja, ich (als Apple) würde mich (wiederum als Apple) dann aber erstmal
fragen, ob das in 'ner anderen Umgebung auch auftritt. Hast Du da
Vergleichswerte? 24 Stunden in ein anderes 5 GHz WLAN umziehen und dort
dauerpingenderweise mitschneiden?

Könnte ich sogar machen - habe meiner Nachbarin ihre TimeCapsule
eingerichtet (sie hing vorher im überfüllten 2.4GHz-Spektrum mit ihrem
MacBook Air und klagte über die WLAN-Speed) und könnte auch darüber
surfen. Die TC steht nur eine Rigips-Wand weiter... Nur an mein NAS käme
ich dann nicht ran.

[Patrick Kormann]

Post by Marc Stibane
Könnte ich sogar machen - habe meiner Nachbarin ihre TimeCapsule
eingerichtet (sie hing vorher im überfüllten 2.4GHz-Spektrum mit ihrem
MacBook Air und klagte über die WLAN-Speed) und könnte auch darüber
surfen. Die TC steht nur eine Rigips-Wand weiter... Nur an mein NAS käme
ich dann nicht ran.

Jetzt wo ihr's sagt - meine Frau mit ihrem 2009er MBP hat das Problem
manchmal auch - viel seltener als ich, aber auch. Am Ende haben die
Airports ein faules Update gekriegt. Ach, mir fällt ein, gibt ja ne neue
10.8.4, gleich probieren.

[Marc Stibane]

Post by Patrick Kormann
Jetzt wo ihr's sagt - meine Frau mit ihrem 2009er MBP hat das Problem
manchmal auch - viel seltener als ich, aber auch.

Seit wann? Bei mir fing es definitiv nach dem Update auf 10.8.3 an.

Post by Patrick Kormann
Am Ende haben die Airports ein faules Update gekriegt.

Welche Airports? Die Basis oder diejenigen in den MacBooks? Und woher?
Die Basis habe ich nicht angefasst, und hatte mit meinem rMBP bei 10.8,
10.8.1 und 10.8.2 keine Probleme. Daran kann es nicht liegen.

Post by Patrick Kormann
Ach, mir fällt ein, gibt ja ne neue 10.8.4, gleich probieren.

Du meinst eine Entwickler-Beta?

[Patrick Kormann]

Post by Marc Stibane

Post by Patrick Kormann
Jetzt wo ihr's sagt - meine Frau mit ihrem 2009er MBP hat das Problem
manchmal auch - viel seltener als ich, aber auch.

Seit wann? Bei mir fing es definitiv nach dem Update auf 10.8.3 an.

Das kann ich nicht genau sagen. Bei ihr ist es selten, weniger als 1 mal
die Woche. Bei meinem Retina hat es jedenfalls viel früher angefangen
als 10.8.3.

Post by Marc Stibane
Welche Airports? Die Basis oder diejenigen in den MacBooks? Und woher?
Die Basis habe ich nicht angefasst, und hatte mit meinem rMBP bei 10.8,
10.8.1 und 10.8.2 keine Probleme. Daran kann es nicht liegen.

Die Basis... Aber ja hast recht, passt nicht. Ich erinnere mich nicht
mehr an jede Einzelheit des Threads, tritt das Problem bei dir auch nur
im 5 GHz Netz auf?

Post by Marc Stibane
Du meinst eine Entwickler-Beta?

Ja - immerhin adressiert die ja unter anderem genau WIFI-Probleme.

[Marc Stibane]

Post by Patrick Kormann

Post by Marc Stibane

Post by Patrick Kormann
Jetzt wo ihr's sagt - meine Frau mit ihrem 2009er MBP hat das
Problem manchmal auch - viel seltener als ich, aber auch.

Wie oft hast Du's denn?

Post by Patrick Kormann

Post by Marc Stibane
Seit wann? Bei mir fing es definitiv nach dem Update auf 10.8.3 an.

Das kann ich nicht genau sagen. Bei ihr ist es selten, weniger als 1 mal
die Woche. Bei meinem Retina hat es jedenfalls viel früher angefangen
als 10.8.3.

Und wie oft? Wenn es nur 1mal am Tag auftrat, habe ich's vielleicht auch
nur übersehen. Aber seit 10.8.3 tritt es hier eben mehrmals am Tag auf.

Post by Patrick Kormann

Post by Marc Stibane
Welche Airports? Die Basis oder diejenigen in den MacBooks? Und
woher? Die Basis habe ich nicht angefasst, und hatte mit meinem rMBP
bei 10.8, 10.8.1 und 10.8.2 keine Probleme. Daran kann es nicht
liegen.

Die Basis... Aber ja hast recht, passt nicht. Ich erinnere mich nicht
mehr an jede Einzelheit des Threads, tritt das Problem bei dir auch nur
im 5 GHz Netz auf?

Keine Ahnung. Ich mag mein rMBP nicht ins überfüllte und lahme 2.4GHz
stecken.

Post by Patrick Kormann

Post by Marc Stibane
Du meinst eine Entwickler-Beta?

Ja - immerhin adressiert die ja unter anderem genau WIFI-Probleme.

Hmmm, könnte ich mir dann evtl. auch holen...

[Patrick Kormann]

Post by Marc Stibane
Und wie oft? Wenn es nur 1mal am Tag auftrat, habe ich's vielleicht auch
nur übersehen. Aber seit 10.8.3 tritt es hier eben mehrmals am Tag auf.

Unregelmässig. Manchmal 3 mal Tag, dann vielleicht auch mal wieder ein
paar Tage nicht mehr. Dito mit den Flackerern, wobei ich die vielleicht
auch schon gelegentlich übersehe (Gewöhnung...)
Seit der neusten Beta habe ich noch keinen Unterbruch gehabt (also seit
gestern abend) und Flackern wohl auch nicht...
Aber ich dachte auch schon das Problem sei weg und plötzlich war's dann
wieder da.

Post by Marc Stibane
Keine Ahnung. Ich mag mein rMBP nicht ins überfüllte und lahme 2.4GHz
stecken.

Naja, ne Weile hatte ich das so, lieber lahmes 2.4GHz als im Dümmsten
Moment gar kein LAN.

Post by Marc Stibane
Hmmm, könnte ich mir dann evtl. auch holen...

Normalerweise schmeiss ich ja nicht so gern Betas auf die
'Produktivmaschine' aber wenn der 'Release' nicht sauber läuft...

[Marc Stibane]

Post by Patrick Kormann

Post by Marc Stibane
Hmmm, könnte ich mir dann evtl. auch holen...

Normalerweise schmeiss ich ja nicht so gern Betas auf die
'Produktivmaschine' aber wenn der 'Release' nicht sauber läuft...

Ich war eigentlich sehr zufrieden mit 10.8.2 und hatte extra 'ne Woche
gewartet ob es im Netz Wehklagen und Aufschreie gibt, bevor ich das
Update auf 10.8.3 gemacht habe.
Pech gehabt.

[Patrick Kormann]

Post by Marc Stibane
eine Webseite aufrufen geht das auch nicht. Nur das WLAN-Symbol bleibt
unverändert bei allen 'Balken' (Viertelkreisen).
Einfach nur abwarten reicht, meistens dauert es keine Minute und alles
geht wieder.

Ah, das ist bei mir dann aber anders, bei mir ist der Empfang plötzlich
komplett weg. Manchmal ist WLAN sogar ausgeschaltet.
Passiert wie gesagt nur im 5 GHz Band...

[Nils Hott]

Post by Marc Stibane
Kennt jemand das Problem, und hat evtl sogar eine Lösung?

Mein Mac hat zu 10.7-Zeiten plötzlich im WLAN gesponnen. Da hat nur
geholfen, das WLAN vom kombinierten g+n Betrieb auf g zu stellen.

Gruß, Nils

[Marc Stibane]

Post by Nils Hott

Post by Marc Stibane
Kennt jemand das Problem, und hat evtl sogar eine Lösung?

Mein Mac hat zu 10.7-Zeiten plötzlich im WLAN gesponnen. Da hat nur
geholfen, das WLAN vom kombinierten g+n Betrieb auf g zu stellen.

Das liegt nicht an der Basis. Habe 2 iPads im 5GHz-Netz, und 2 iPhones
natürlich bei 2.4GHz. Alle haben kein Problem mit dem WLAN, nur mein
rMBP (5GHz) seit 10.8.3.

[Thomas Kaiser]

Alle haben kein Problem mit dem WLAN, nur mein rMBP (5GHz) seit
10.8.3.

Das ist eine Interpretation. Die reine Feststellung wäre "seit ungefähr
dem Zeitpunkt, an dem das Update auf 10.8.3 durchgeführt wurde". Du
kennst das, daß man sich bei Problemeingrenzung retrospektiv gerne alles
Mögliche zusammenreimt, das plausibel erscheint? Und Du kennst die [alt]-
Taste, die man halten kann, während man auf das Airport-Menubar-Item
klickst (um dort seit 10.7 "Wi-Fi Diagnostics.app" starten zu können)?

Gruss,

Thomas

[Andre Igler]

Und Du kennst die [alt]- Taste, die man halten kann, während man auf
das Airport-Menubar-Item klickst (um dort seit 10.7 "Wi-Fi
Diagnostics.app" starten zu können)?

Nein, aber jetzt. :)

Danke, wieder was gelernt. Mit einem Mac wird einem nie fad ...

addio

[Thomas Kaiser]

Post by Andre Igler

Und Du kennst die [alt]- Taste, die man halten kann, während man auf
das Airport-Menubar-Item klickst (um dort seit 10.7 "Wi-Fi
Diagnostics.app" starten zu können)?

Nein, aber jetzt. :)
Danke, wieder was gelernt. Mit einem Mac wird einem nie fad ...

Mit der [alt]-Taste wird einem nie fad. Auch bei anderen Menüzeilen-
bewohnern wie TimeMachine, Ton, Bluetooth oder ab 10.8 "Mitteilungen".

Auf Menüs selbst, Dialoge und sogar Kontextmenüs trifft das aber meist
ebenfalls zu. Ich mach das fast schon reflexartig, wenn ich mit einem
neuen Programm zu tun habe: wild klicken und Modifier Keys reihum
drücken...

Gruss,

Thomas

[Klaus Behrendt]

Post by Marc Stibane

Post by Nils Hott

Post by Marc Stibane
Kennt jemand das Problem, und hat evtl sogar eine Lösung?

Mein Mac hat zu 10.7-Zeiten plötzlich im WLAN gesponnen. Da hat nur
geholfen, das WLAN vom kombinierten g+n Betrieb auf g zu stellen.

Das liegt nicht an der Basis. Habe 2 iPads im 5GHz-Netz, und 2 iPhones
natürlich bei 2.4GHz. Alle haben kein Problem mit dem WLAN, nur mein
rMBP (5GHz) seit 10.8.3.

Wieso "natürlich"? Sollen iPhones nicht in 5GHz-Netze?


Grüße
Klaus

[Marc Stibane]

Post by Klaus Behrendt

Post by Marc Stibane
Das liegt nicht an der Basis. Habe 2 iPads im 5GHz-Netz, und 2
iPhones natürlich bei 2.4GHz. Alle haben kein Problem mit dem WLAN,
nur mein rMBP (5GHz) seit 10.8.3.

Wieso "natürlich"? Sollen iPhones nicht in 5GHz-Netze?

Sie können nicht. Haben nur 2.4GHz verbaut. Deswegen braucht man einen
Dual-WLAN-Router wie eben die Airport Extreme, die in beiden Frequenzen
gleichzeitig funkt.

[Klaus Behrendt]

Post by Marc Stibane

Post by Klaus Behrendt

Post by Marc Stibane
Das liegt nicht an der Basis. Habe 2 iPads im 5GHz-Netz, und 2
iPhones natürlich bei 2.4GHz. Alle haben kein Problem mit dem WLAN,
nur mein rMBP (5GHz) seit 10.8.3.

Wieso "natürlich"? Sollen iPhones nicht in 5GHz-Netze?

Sie können nicht. Haben nur 2.4GHz verbaut. Deswegen braucht man einen
Dual-WLAN-Router wie eben die Airport Extreme, die in beiden Frequenzen
gleichzeitig funkt.

Dann sind sie schon älter. :-)

iPhone 5: Wi-Fi (802.11a/b/g/n; 802.11n bei
2,4 GHz und 5 GHz)


Grüße
Klaus

[Ingo Lembcke]

Hallo!

Post by Marc Stibane
Sie können nicht. Haben nur 2.4GHz verbaut.

Davon weiss mein iPhone nichts, ich erzähl ihm das auch nicht :-).
Du meinst: deine iPhone < 5 können keine 5 GHz.

Mfg,
Ingo Lembcke

[Patrick Kormann]

Vorhin war die Verbindung doch wieder weg.
Das log war so vollgemüllt dass ich nicht sicher bin ob ich das
Wesentliche gesehen habe. Wie es aussieht wurde plötzlich eine
Verbindung zu einer weiter entfernten Station aufgenommen. Zu der wurde
aber offensichtlich auch keine Verbindung aufgebaut, denn das Symbol war
ja grau. Die andere Station ist so viel schwächer, resp. die normale so
nah dran (und ich hab ne 450 MBit/s Verbindung) es gibt kein 'normales'
Szenario warum sie genommen werden sollte.