Hallo Alfred,
euere Service hat mir diese Woche erklärt, dass der Problem an definitiv an Apple liegt und er das Ticket nicht weiter bearbeiten wird. Von Apple erhalte ich auf mein dort eröffnetes Ticket keine Antwort. Um die "Schwere" des Problems zu erklären, ich habe diese Woche ca. 1 Stunde benötigt um 60 Files (ca. 200 MB) mit HTTP Upload zum Sharepoint Server hochzuladen da die Verbindung immer wieder abgebrochen ist.
Das ist für uns nicht mehr tragbar und verbrennt jede Menge Zeit und damit Geld.
Es ist keine Besserung in Aussicht und ich habe weder die Möglichkeit Apple Airport Driver oder LANCOM LCOS zu debuggen oder upzudaten, das habe ich auch eueren Support erklärt, er wollte es aber nicht verstehen und hatte auch keine Lösung anzubieten.
Da ihr uns leider nicht helfen könnt habe ich einen CISCO AP bestellt um erst einmal wieder arbeiten zu können, bei unseren Kunden mit CISCO kenne ich solche Probleme nicht. Schade, ist momentan alles LANCOM hier....
Ich denke ihr bekommt heftige Probleme wenn euere Kunden in nächster Zeit von "G" auf "N" gehen, ich sehe seit ca. 1 Jahr fast bei jeden unser Kunden MacBooks.
Viele Grüße
Henri
L-322: WLAN hängt
Moderator: Lancom-Systems Moderatoren
Hallo Alfred,
das hatte ich auch zu diesem Zeitpunkt gedacht, dass Problem tritt extrem heftig auf wenn im Hintergrund eine Sicherung läuft (bei mir Timemachine (1* pro Stunde) und IBM TSM (1* pro Tag)). Bei mir werden pro Tag ca. 30 GB via TSM pro Tag und ca. 2 GB via Timemachine pro Stunde gesichert. Sobald dann noch ein HTTP Upload hinzukommt kommen die Aussetzer aller paar Minuten. Ich hatte beim Testen diesen Zusammenhang noch nicht verstanden, da lief im Hintergrund nichts weiter.
Mit vielen Grüßen
Henri
das hatte ich auch zu diesem Zeitpunkt gedacht, dass Problem tritt extrem heftig auf wenn im Hintergrund eine Sicherung läuft (bei mir Timemachine (1* pro Stunde) und IBM TSM (1* pro Tag)). Bei mir werden pro Tag ca. 30 GB via TSM pro Tag und ca. 2 GB via Timemachine pro Stunde gesichert. Sobald dann noch ein HTTP Upload hinzukommt kommen die Aussetzer aller paar Minuten. Ich hatte beim Testen diesen Zusammenhang noch nicht verstanden, da lief im Hintergrund nichts weiter.
Mit vielen Grüßen
Henri
-
marsbewohner
- Beiträge: 532
- Registriert: 27 Mär 2007, 13:17
Hallo Henri,
auf welchem Weg hast du das Ticket bei Apple platziert, habt ihr da ein Enterprise Agreement?
Ich bin geneigt eventuell den Weg hier noch zu probieren:
http://www.apple.com/de/support/product ... ident.html
Gruß,
auf welchem Weg hast du das Ticket bei Apple platziert, habt ihr da ein Enterprise Agreement?
Ich bin geneigt eventuell den Weg hier noch zu probieren:
http://www.apple.com/de/support/product ... ident.html
Gruß,
-
marsbewohner
- Beiträge: 532
- Registriert: 27 Mär 2007, 13:17
Danke für die Info.
Bei meinen Problemfällen ist das eigentlich relativ einfach, es hängt damit zusammen das der Apple dem AP
meldet das er in Powersave geht, und der AP solange die Pakete zwischenspeichert, bis der Client sich
wieder zurückmeldet und die Pakete rausschickt, zumindest lässt sich das so schön aus dem Trace lesen.
Hast du das mal so an Apple gepostet bzw ist das bei dir auch so, ob die vielleicht erklären können warum der
Client mitten in der Übertragung in den Powersave wechselt und das damit auslösen (kann)?
Wobei die Frage ja ist was andere APs da anders machen, senden die einfach weiter und der Client lässt sich die Pakete
die er damit verloren hat einfach nochmal zusenden, sind die schneller wieder da etc....?
Grüße,
Bei meinen Problemfällen ist das eigentlich relativ einfach, es hängt damit zusammen das der Apple dem AP
meldet das er in Powersave geht, und der AP solange die Pakete zwischenspeichert, bis der Client sich
wieder zurückmeldet und die Pakete rausschickt, zumindest lässt sich das so schön aus dem Trace lesen.
Hast du das mal so an Apple gepostet bzw ist das bei dir auch so, ob die vielleicht erklären können warum der
Client mitten in der Übertragung in den Powersave wechselt und das damit auslösen (kann)?
Wobei die Frage ja ist was andere APs da anders machen, senden die einfach weiter und der Client lässt sich die Pakete
die er damit verloren hat einfach nochmal zusenden, sind die schneller wieder da etc....?
Grüße,
Moin,
wieviel - einen Mechanismus zum 'nochmal anfordern'
gibt's nicht.
Die primäre Frage ist ja, wieso der Client das irgendwann
auf einmal tut, wenn's eine ganze Weile vorher funktioniert
hat.
Wenn man einmal in der Situation ist, gibt es diverse
Variablen im Verhalten des AP, die das Ergebnis beeinflussen
können:
(1) Wie groß ist die Pufferkapazität des APs, d.h. ab wieviel
aufgesammelten Paketen fägt er wegen Überlauf an,
wegzuwerfen?
(2) Wenn der Client wieder 'da' ist, mit welcher Priorität
schickt der AP die aufgesammelten Pakete raus? Es kann
ja passieren, daß der Client kurz aufwacht, der AP die
aufgesammelten Pakete zum Rausschicken vorbereitet, und
währenddessen der Client sich schon wieder schlafen legt.
Dann gehen die Pakete ins Leere...
(3) Wenn (2) passiert ist, und der AP feststellt, daß der
Client wieder schläft, steckt er die Pakete wieder zurück
in den Puffer oder verwirft er sie?
Gruß Alfred
Ein Client 'weiß' nur, daß Pakete für ihn anstehen, aber nichtWobei die Frage ja ist was andere APs da anders machen, senden die einfach weiter und der Client lässt sich die Pakete
die er damit verloren hat einfach nochmal zusenden, sind die schneller wieder da etc....? Shocked
wieviel - einen Mechanismus zum 'nochmal anfordern'
gibt's nicht.
Die primäre Frage ist ja, wieso der Client das irgendwann
auf einmal tut, wenn's eine ganze Weile vorher funktioniert
hat.
Wenn man einmal in der Situation ist, gibt es diverse
Variablen im Verhalten des AP, die das Ergebnis beeinflussen
können:
(1) Wie groß ist die Pufferkapazität des APs, d.h. ab wieviel
aufgesammelten Paketen fägt er wegen Überlauf an,
wegzuwerfen?
(2) Wenn der Client wieder 'da' ist, mit welcher Priorität
schickt der AP die aufgesammelten Pakete raus? Es kann
ja passieren, daß der Client kurz aufwacht, der AP die
aufgesammelten Pakete zum Rausschicken vorbereitet, und
währenddessen der Client sich schon wieder schlafen legt.
Dann gehen die Pakete ins Leere...
(3) Wenn (2) passiert ist, und der AP feststellt, daß der
Client wieder schläft, steckt er die Pakete wieder zurück
in den Puffer oder verwirft er sie?
Gruß Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
-- Edgar Froese, 1944 - 2015
Moin,
funktioniert wie bei anderen Firmen, kann man das sich
schenken - eine große amerikanische Firma ignoriert das
schlicht und ergreifend, wenn eine kleine europäische mit
Fragen 'anklopft'. Und auch Apple wird den WLAN-Treiber
kaum selber entwickeln, die nehmen das, was ihnen
der Chipsatz-Hersteller (in diesem Fall Broadcom) ihnen gibt.
Und Broadcom ist, was sein Verhalten gegenüber 'kleinen
Kunden' angeht, ohnehin die Unverschämtheit hoch drei
(wollten mit uns über ADSL-Chipsätze noch nicht mal reden).
Daß sich ein Supporter bei uns, der soundsoviele Calls pro
Tag abarbeiten muß, das nicht ans Bein binden will, kann ich
durchaus nachvollziehen...
Gruß Alfred
Wenn der Support bei Apple nur ansatzweise genausound der Lancom Support will keinen Kontakt zu Apple aufnehmen.
funktioniert wie bei anderen Firmen, kann man das sich
schenken - eine große amerikanische Firma ignoriert das
schlicht und ergreifend, wenn eine kleine europäische mit
Fragen 'anklopft'. Und auch Apple wird den WLAN-Treiber
kaum selber entwickeln, die nehmen das, was ihnen
der Chipsatz-Hersteller (in diesem Fall Broadcom) ihnen gibt.
Und Broadcom ist, was sein Verhalten gegenüber 'kleinen
Kunden' angeht, ohnehin die Unverschämtheit hoch drei
(wollten mit uns über ADSL-Chipsätze noch nicht mal reden).
Daß sich ein Supporter bei uns, der soundsoviele Calls pro
Tag abarbeiten muß, das nicht ans Bein binden will, kann ich
durchaus nachvollziehen...
Gruß Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
-- Edgar Froese, 1944 - 2015
-
marsbewohner
- Beiträge: 532
- Registriert: 27 Mär 2007, 13:17
Moin,
nur ist die Chance insgesamt nicht höher wenn man sich auf Hersteller zu Hersteller Ebene unterhält, als auf User zu Hersteller?
Ihr geht ja sehr offen mit user Feedback um, nur andere tun das ja nicht unbedingt...
Vorallendingen da es ja ein reproduzierbares & verbreiteteres Problem zu sein scheint.
Mein nächster Test ist ein Mac mit Windows, um mal einzukreisen ob es ein Treiber oder HW Problem ist....
Gruß,
nur ist die Chance insgesamt nicht höher wenn man sich auf Hersteller zu Hersteller Ebene unterhält, als auf User zu Hersteller?
Ihr geht ja sehr offen mit user Feedback um, nur andere tun das ja nicht unbedingt...
Vorallendingen da es ja ein reproduzierbares & verbreiteteres Problem zu sein scheint.
Mein nächster Test ist ein Mac mit Windows, um mal einzukreisen ob es ein Treiber oder HW Problem ist....
Gruß,
Moin,
Dreimol Null es Null bliev Null - wenn Du verstehst, was ich meine...
um ein iPad. Da ist aber mit ziemlicher Sicherheit das iPad schuld, weil auch andere im Internet vom
gleichen Problem mit anderen APs berichten: das iPad kriegt das Roaming wohl nicht richtig auf die
Reihe, wenn die gleiche SSID sowohl auf 2,4 als auch 5 GHz angeboten wird...
Gruß Alfred
Naja, es gibt so ein Lied von einer in dieser Gegend beliebten Gruppe:nur ist die Chance insgesamt nicht höher wenn man sich auf Hersteller zu Hersteller Ebene unterhält, als auf User zu Hersteller?
Dreimol Null es Null bliev Null - wenn Du verstehst, was ich meine...
Außer Euch beiden kenne ich im Augenblich nur ein weiteres 'Apple-Problem' , und da geht'sVorallendingen da es ja ein reproduzierbares & verbreiteteres Problem zu sein scheint.
um ein iPad. Da ist aber mit ziemlicher Sicherheit das iPad schuld, weil auch andere im Internet vom
gleichen Problem mit anderen APs berichten: das iPad kriegt das Roaming wohl nicht richtig auf die
Reihe, wenn die gleiche SSID sowohl auf 2,4 als auch 5 GHz angeboten wird...
Gruß Alfred
Hallo Alfred,
ich habe schon ein paar Mal einen Bug unter "http://bugreport.apple.com" gemeldet (die Userid gibt's kostenfrei) und bisher zu 90% auch eine qualifizierte Antwort vom Lab erhalten. Ihre könnt auch für 99US$ eine Developer Lizenz kaufen (dabei ist so weit ich mich erinnern) kann einen Anfrage an das Lab mit enthalten. Es gibt auch noch weitere Pakete. Allerdings ist es gut den Fehler so technisch ausführlich wie möglich zu beschreiben, das versteht dann sowieso keiner und der Record wird an den Entwickler weitergereicht. Insgesamt funktioniert das wesentlich besser als bei Microsoft. Es dauert halt nur ....
Ich habe hier jede Menge Macbook Pros/Powerbooks (seit 2005) unterschiedlichste Modelle und bis zum Modell 2010 hatte ich keine Probleme mit L-305s/ L-315s, auch im N Mode (Greenfield mit Kanalbündelung). Leider ist das Teil aber täglich mit einem Kernel Bug (CISCO Client, habe ich nach ein paar Monaten erst herausgefunden) abgestürzt und da ich nicht weiter wusste habe ich Anfang 2010 dieses 17" i7 Teil gekauft.
Seit dieser Zeit treten die Probleme auf. Ich habe zwischenzeitlich noch einen WLC 4006 eingebaut und einen L-322 angeschlossen, hat alles nicht geholfen.
P.S.:Der L-322 hatte sich mit 8.0 mit meinem Macbook überhaupt nicht vertragen.
Sorry aber habe mich schon zu sehr darüber geärgert.
Vielen Dank und viele Grüße
Henri
ich habe schon ein paar Mal einen Bug unter "http://bugreport.apple.com" gemeldet (die Userid gibt's kostenfrei) und bisher zu 90% auch eine qualifizierte Antwort vom Lab erhalten. Ihre könnt auch für 99US$ eine Developer Lizenz kaufen (dabei ist so weit ich mich erinnern) kann einen Anfrage an das Lab mit enthalten. Es gibt auch noch weitere Pakete. Allerdings ist es gut den Fehler so technisch ausführlich wie möglich zu beschreiben, das versteht dann sowieso keiner und der Record wird an den Entwickler weitergereicht. Insgesamt funktioniert das wesentlich besser als bei Microsoft. Es dauert halt nur ....
Ich habe hier jede Menge Macbook Pros/Powerbooks (seit 2005) unterschiedlichste Modelle und bis zum Modell 2010 hatte ich keine Probleme mit L-305s/ L-315s, auch im N Mode (Greenfield mit Kanalbündelung). Leider ist das Teil aber täglich mit einem Kernel Bug (CISCO Client, habe ich nach ein paar Monaten erst herausgefunden) abgestürzt und da ich nicht weiter wusste habe ich Anfang 2010 dieses 17" i7 Teil gekauft.
Seit dieser Zeit treten die Probleme auf. Ich habe zwischenzeitlich noch einen WLC 4006 eingebaut und einen L-322 angeschlossen, hat alles nicht geholfen.
P.S.:Der L-322 hatte sich mit 8.0 mit meinem Macbook überhaupt nicht vertragen.
Ich habe mich heftigst mit euerem Support gestritten, der sagt mir das dieses Problem bei euch mit einen LANCOM eigenen Macbook (welches Model auch immer) nachvollziehbar war und das Problem definitiv bei Apple liegt. Daher will er meinen Case nicht mehr bearbeiten. Ich verstehe nur überhaupt nicht, wieso Ihr in diesem Fall nicht direkt mit Apple sprecht und dort das Problem meldet. Ich habe Ihm auch gesagt das es nicht meine Aufgabe als Kunde ist zwischen Apple und Lancom zu vermitteln! Ich finde es auch nicht sinnvoll Kunden mit so einem Verhalten "sauerzufahren". Falls die Aussage des Supports richtig ist, ist dies ein GRUNDSÄTZLICHES Problem und betrifft nicht nur "uns beiden". Sonst ist es ein Support Problem!Außer Euch beiden kenne ich im Augenblich nur ein weiteres 'Apple-Problem' , und da geht's
um ein iPad. Da ist aber mit ziemlicher Sicherheit das iPad schuld, weil auch andere im Internet vom
gleichen Problem mit anderen APs berichten: das iPad kriegt das Roaming wohl nicht richtig auf die
Reihe, wenn die gleiche SSID sowohl auf 2,4 als auch 5 GHz angeboten wird...
Sorry aber habe mich schon zu sehr darüber geärgert.
Vielen Dank und viele Grüße
Henri
OK, das eskaliert hier jetzt, ich werde mich hier zu dem Thema
nicht weiter äußern. Ich werde unserem Management einen
Hinweis auf diesen Thread geben und die sollen dann entscheiden,
wie's weitergeht...
Gruß Alfred
nicht weiter äußern. Ich werde unserem Management einen
Hinweis auf diesen Thread geben und die sollen dann entscheiden,
wie's weitergeht...
Gruß Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
-- Edgar Froese, 1944 - 2015
-
marsbewohner
- Beiträge: 532
- Registriert: 27 Mär 2007, 13:17
Moin Alfred,
Ich habe gestern nochmal ein paar Tests gemacht, und bin der Meinung das dass Problem (mitunter) auf Apples Seite im Treiber liegt:
Testaufbau:
MacBook Air (2011) mit Windows XP SP3
MacBook Air (2011) mit Mac OS X 10.6.4
Macbook Pro aus 2008 mit Max OS X 10.6.7
Alle Geräte mit Stromanschluss, kein Akkubetrieb, 4m Luftlinie zum AP ohne Sichthindernisse.
Ergebnisse eines Pings ohne parallelem Traffic:
- MacBook Air 2011 mit Win XP
Die Zeiten von gestern mit MacBook Pro aus 2008 mit 10.6.7 habe ich jetzt leider nicht da, allerdings reden wir dabei von Werten welche im Durchschnitt mindestens 3-4 Stelling sind, als Max gern auch schon mal 5stellig, siehe Test von letzter Woche:
Da WLAN ja kein garantiertes Medium ist kann unser Kunde mit den Werten aus dem Test von Windows und OS X 10.6.4 ganz gut leben, da diese sich im Alltag nicht groß auswirken sollten. Problematisch wird es dann nur mit den neueren Versionen, 10.6.6 und 10.6.7.
Bleibt die Gretchenfrage, wie lösen andere Hersteller das Problem?
Sollte sich daher im Moment erstmal keine Lösung finden, sind wir angehalten worden neue APs vom einem anderen hersteller zu beschaffen.
Gruß,
Ja, das kenne ich....Naja, es gibt so ein Lied von einer in dieser Gegend beliebten Gruppe:
Dreimol Null es Null bliev Null - wenn Du verstehst, was ich meine...
Ich habe gestern nochmal ein paar Tests gemacht, und bin der Meinung das dass Problem (mitunter) auf Apples Seite im Treiber liegt:
Testaufbau:
MacBook Air (2011) mit Windows XP SP3
MacBook Air (2011) mit Mac OS X 10.6.4
Macbook Pro aus 2008 mit Max OS X 10.6.7
Alle Geräte mit Stromanschluss, kein Akkubetrieb, 4m Luftlinie zum AP ohne Sichthindernisse.
Ergebnisse eines Pings ohne parallelem Traffic:
- MacBook Air 2011 mit Win XP
- MacBook Air 2011 mit OS X 10.6.4:Ping-Statistik für 192.168.100.1:
Pakete: Gesendet = 216, Empfangen = 214, Verloren = 2 (0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 2ms, Maximum = 187ms, Mittelwert = 7ms
bzw--- 192.168.100.1 ping statistics ---
206 packets transmitted, 205 packets received, 0.5% packet loss
round-trip min/avg/max/stddev = 8.617/17.385/787.165/54.044 ms
Interessant finde ich dabei schon mal, dass unter Max OS die Zeiten generell höher sind als unter Windows.--- 192.168.100.1 ping statistics ---
293 packets transmitted, 293 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 8.614/22.885/1134.752/71.542 ms
Die Zeiten von gestern mit MacBook Pro aus 2008 mit 10.6.7 habe ich jetzt leider nicht da, allerdings reden wir dabei von Werten welche im Durchschnitt mindestens 3-4 Stelling sind, als Max gern auch schon mal 5stellig, siehe Test von letzter Woche:
Was sich als besonders problematisch herausgestellt hat ist der Wechsel von Netzbetrieb auf Akku, dabei haben wir teilweise schon mal 20 Pakete Loss gehabt und danach Werte welche unterirdisch 5 Stellig waren. Erst nach etwas um die 50 Pakete herum normalisiert sich das ganze, ob dabei allerdings der AP oder die Broadcom vom Mac aus dem Tritt kommt kann ich nicht sagen.--- 192.168.100.16 ping statistics ---
38 packets transmitted, 38 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 9.969/13442.344/31297.821/10218.813 ms
Da WLAN ja kein garantiertes Medium ist kann unser Kunde mit den Werten aus dem Test von Windows und OS X 10.6.4 ganz gut leben, da diese sich im Alltag nicht groß auswirken sollten. Problematisch wird es dann nur mit den neueren Versionen, 10.6.6 und 10.6.7.
Bleibt die Gretchenfrage, wie lösen andere Hersteller das Problem?
Sollte sich daher im Moment erstmal keine Lösung finden, sind wir angehalten worden neue APs vom einem anderen hersteller zu beschaffen.
Gruß,