[Gelöst] VPN Tunel zwischen Fritzbox 7490 und iPhone (iOS9) funktioniert nicht mehr
- Ersteller Gabriel Burns
- Erstellt am
1. Die Pakete werden "einfach so" vom UM mit 0x03 versehen, also es gibt da bestimmt irgendwas, das nicht sein soll
2. Nicht-VPN Pakete, die mit ECN 0x03 versehen worden sind, die am iPhone ankommen, werden richtig bearbeitet, nur die VPN Pakete nicht
3. 0x03 ist völlig Valid, und bedeutet nicht, dass sie von der Gegenstelle nicht bearbeitet werden sollen.
4. Die Pakete, die von meinem UM Anschluss geschickt worden sind, sind alle in der richtige Reihenfolge angekommen, schnell und heil. Ein Kapazitätsproblem bei UM gibt es also nicht.
5. Wenn Apple ein Bug in deren Netzwerkcode haben, ja, ich erwarte, dass Apple irgendwas damit macht. Sie haben jetzt mit 9.0.1 "Kleinigkeiten" gefixed, warum nicht so was?
2. Nicht-VPN Pakete, die mit ECN 0x03 versehen worden sind, die am iPhone ankommen, werden richtig bearbeitet, nur die VPN Pakete nicht
3. 0x03 ist völlig Valid, und bedeutet nicht, dass sie von der Gegenstelle nicht bearbeitet werden sollen.
4. Die Pakete, die von meinem UM Anschluss geschickt worden sind, sind alle in der richtige Reihenfolge angekommen, schnell und heil. Ein Kapazitätsproblem bei UM gibt es also nicht.
5. Wenn Apple ein Bug in deren Netzwerkcode haben, ja, ich erwarte, dass Apple irgendwas damit macht. Sie haben jetzt mit 9.0.1 "Kleinigkeiten" gefixed, warum nicht so was?
amatör
Mitglied
- Mitglied seit
- 15 Feb 2014
- Beiträge
- 408
- Punkte für Reaktionen
- 10
- Punkte
- 18
Was verstehst du nicht? 0x03 soll keine Problemen verursachen. iOS 9 soll damit umgehen können. Tut es nicht, dann soll es gefixt werden. ECN ist Standardkram. 0x03 ist valid. Vielleicht nicht nötig, aber völlig valid. Niemals habe ich behauptet, dass Apple zu UM hingehen soll, um das 0x03 zu entfernen.
Das scheint in der Tat das Problem zu sein und ist wohl auch schon älter: http://serverfault.com/questions/35...ts-from-the-ip-tos-header-considered-harmfull
Ohne das jetzt von hier aus näher analysieren zu können, gehe ich doch davon aus, dass das in iOS9 korrekt gehandhabt wird. Wenn eine Netzwerkverstopfung signalisiert wird, soll das sendende Ende die Übertragungsrate vermindern, damit es nicht mehr zu einer Verstopfung kommt. Wikipedia: At the receiving endpoint, this congestion indication is handled by the upper layer protocol (transport layer protocol) and needs to be echoed back to the transmitting node in order to signal it to reduce its transmission rate.
Wenn jedoch unitymedia trotzdem immer und ewig "einfach so" Congestion Encountered, CE 0x03 zurückschickt, wie salamihawk in seiner Untersuchung festgestellt hat (und wofür er meine ausdrückliche Hochachtung verdient), kann es natürlich nie zu einer erfolgreichen Verbindung kommen.
Wenn jedoch unitymedia trotzdem immer und ewig "einfach so" Congestion Encountered, CE 0x03 zurückschickt, wie salamihawk in seiner Untersuchung festgestellt hat (und wofür er meine ausdrückliche Hochachtung verdient), kann es natürlich nie zu einer erfolgreichen Verbindung kommen.
Zuletzt bearbeitet:
Nicht unbedingt. iOS 9 handelt das unterschiedlich: ganz normale Pakete mit ECN 0x03 (direkte FTP zu mein Server nach Hause ohne VPN, z.B.) funktionieren trotz ECN 0x03 tadellos. VPN Pakete aber nicht. Ist auch vor lange dokumentiert worden, dass ESP (VPN Data Payloadpakete) manche VPN Endstellen stören. (siehe oben)
Also beide haben mist gebaut. UM ist schuld, weil sie alles mit ECN 0x03 ins Internet rausblasen, und Apple ist schuld, weil sie die Implementierung von ECN irgendwie verbockt haben...
Also beide haben mist gebaut. UM ist schuld, weil sie alles mit ECN 0x03 ins Internet rausblasen, und Apple ist schuld, weil sie die Implementierung von ECN irgendwie verbockt haben...
Also kannst du schon fast davon ausgehen, dass bei der nächsten Korrekturversion von iOS9 das FTP zu deinem Server auch nicht mehr gehen wird.
Sag das bitte bloß nicht zu laut, sonst werden die Apple Devs das verwircklichen!
Da möchte ich mich einfach mal anschließen und mich für die ausgezeichnete Arbeit bedanken!
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,156
- Punkte für Reaktionen
- 1,706
- Punkte
- 113
Da ECN nun mal nur ein Mechanismus zur "Regelung des Verkehrs" ist und bei IP auf die Hilfe eines darüber angesiedelten Protokolls angewiesen ist, damit eine Drosselung überhaupt möglich wird, macht es bei UDP-Paketen nur bedingt Sinn überhaupt zu taggen, nämlich dann, wenn eine Schicht darüber damit etwas anfangen kann (das kann so ein Router ja aber nicht entscheiden/wissen).
In RFC 3168 wurde mal explizit die Forderung aufgestellt (S. 7, letzter Absatz), daß ein Paket mit gesetzter CE-Kennzeichnung so zu behandeln wäre, wie ein von einem Router auf dem Transportweg verworfenes Paket und der "congestion avoidance"-Mechanismus des darüberliegenden Protokolls zu aktivieren wäre. Bei TCP wäre das eben die Annahme "congestion" und das Wiederholen des verworfenen Pakets (inkl. "slow start" von vorne), bei UDP an sich gibt es da gar keine Festlegungen.
Nachdem es so etwas bei einer "UDP-Verbindung" (auch das ist schon fast ein Euphemismus) nicht gibt und schon die Erkennung von Paketverlusten bei UDP nur durch eine entsprechende Nummerierung und/oder Absicherung auf einer höheren Ebene erfolgen kann (die darunter bieten weder Wiederholung noch Sortierung nach Reihenfolge), ist es auch nicht ganz so simpel. Die ganze Problematik wird für UDP in RFC 5404 in Punkt 3.1 (S. 6) ausführlich abgehandelt.
Auch RFC 3168 beschäftigt sich in Punkt 9.2 (Seite 29) explizit mit der Problematik bei der Verwendung von ECN in Kombination mit IPSec - das sollte aber bei ESP und NAT-T (also UDP-Kapselung), wo die Transportheader ohnehin keine Rolle spielen, nur sehr bedingt zu berücksichtigen sein, falls da irgendjemand (m.E. fälschlicherweise) die ECN-Konditionen aus den äußeren Paketen in die inneren kopieren würde.
Was jetzt Apple davon wie umsetzt bei den Änderungen in iOS9 (und wo UM ggf. noch dazwischenfunkt), sollte sich ja irgendwie an diesem Standard orientieren (oder ggf. an einem anderen, dann wäre die Frage an welchem).
Selbst mit Linux und "iptables" ist jedenfalls das Manipulieren der ECN-Bits eines Paketes nur für TCP-Pakete (und auch nur für die entsprechenden Bits im TCP-Header) möglich ... auch eine Linux-basierte Firewall kann (m.W., um das zu betonen, ich lasse mich gerne korrigieren) mit normalen Werkzeugen keine Manipulation an den ECN-Bits im IP-Header vornehmen (man kann sie nur bei einem recvmsg()-Aufruf mit auslesen als Empfänger). Selbst das Setzen der ECN-Bits im IP-Header irgendeiner Antwort (das wäre Aufgabe des Programms bei ECN für UDP) ist für ein Programm auf einer Schicht oberhalb der Netzwerkschicht (OSI 3) nicht trivial ... wie so ein IP-Stack für sich selbst an dieser Stelle reagieren müßte, ist m.W. nirgendwo festgelegt (anders als bei TCP).
Da eigentlich ECN-Bits per Definition zu ignorieren wären, wenn eine der beiden Seiten damit nichts anfangen kann (dann greift eben irgendwann bei echtem Stau ein Paketverlust regulierend ein), würde ich - dabei bleibe ich - das Problem tatsächlich eher bei Apple verorten. Wenn die UDP-Pakete mit gesetztem "ECN capable" verschicken und auf ständig gesetzte "congestion occured"-Bedingungen unglücklich reagieren, sehe ich - nur meine eigene Meinung - eben die Verantwortung für die korrekte Behandlung eines "Dauerstaus" (auch macht es eben nach RFC 3168 einen Unterschied, ob ein einzelnes Paket oder mehrere mit CE-Signalisierung eintreffen) bei Apple. Das generelles Taggen durch UM ist zwar sicherlich auch "fragwürdig" (wenn es wirklich immer erfolgt), aber wenn Apple die Unterstützung/Auswertung von ECN auf andere Protokolle ausdehnt, dann muß man wohl auch damit zurecht kommen, ohne daß gleich alles zusammenbricht. Während eben bei TCP-Verbindungen das Ganze damit zwar stark (und hoffentlich in der Regel unnötigerweise) gedrosselt würde (deshalb juckt das auch die prinzipielle Funktion einer FTP-Verbindung nicht, allerdings dürfte es sie erheblich verlangsamen) und auch bei bestimmten RTP-Verbindungen (RFC 6679) noch standardisiert ist, ist es bei IPSec-Implementierungen eine Frage der höheren Schichten, ob und wie das ausgewertet und behandelt wird. Diese Behandlung der Pakete bei UM ist ja sicherlich auch nichts wirklich Neues und andere Systeme kommen damit ja offenbar auch klar. Wenn also Apple der Meinung ist, sie machten es richtig und alle anderen falsch, sollten sie das ja mit einem entsprechenden Statement und dem Verweis auf den als Basis der Implementierung verwendeten Standard leicht klarstellen können.
Der Unterschied zwischen einem verworfenen Paket (dafür gibt es normalerweise gar keine Benachrichtigung, vielleicht noch ein "source quench", obwohl das seit RFC 6633 auch "deprecated" ist und das käme normalerweise auch von einem Endpoint und nicht von einem Router) und einem mit CE-Warnung ist es eben, daß ersteres den Empfänger gar nicht erreicht und zweiteres ihn eigentlich dazu veranlassen sollte, auf einer höheren Ebene (so es eine solche überhaupt gibt, siehe oben) dem Sender mit einer Quittung (oder dem nächsten eigenen Paket, wenn es wie bei UDP keine Quittungen gibt) diesen Umstand seinerseits mitzuteilen und ihn dazu aufzufordern, etwas langsamer zu machen (bis zu einem minimalen Niveau > 0).
Während also im ersteren Fall unbedingt ein Paket wiederholt werden müßte (wurde ja schließlich "discarded", bei IPSec kann auch nicht einfach eines ausfallen wie bei irgendwelchen RTP-Verbindungen), muß/soll das im zweiten Falle angekommene Paket eben noch verarbeitet werden. Das ist ein Widerspruch zum RFC 3168, wenn man es flüchtig liest ... aber das bezieht sich dort eben auf ein einzelnes Paket (single packet) mit gesetztem CE.
Insofern stimme ich KunterBunter auch nur bedingt zu, denn bei IPSec hat der Empfänger (der kriegt so ein "CE" als erster zu sehen, wenn das der Router am EP ist) gar keine Möglichkeit, dem Sender über irgendeine Flußsteuerung das "mach mal langsamer" zu signalisieren. Diese Signalisierung per ECN geht eben an den Empfänger eines IP-Paketes und der Sender erfährt davon nur dann, wenn es der Empfänger ihm irgendwie (ooB oder mit der nächsten regulären Meldung) mitteilen kann.
Also sollte/müßte Apple bei IP-Verbindungen, bei denen nicht bekanntermaßen auf einer höheren Schicht eine Flußkontrolle möglich ist, im IP-Stack an sich einfach mal gar nichts unternehmen und nur die Bits entsprechend auf Anforderung bereitstellen. Wenn hingegen der IPSec-Stack im iOS (nicht mit dem IP-Stack zu verwechseln) irgendwie diese ECN-Bits seit neuestem setzt und/oder auswertet, sollte ja irgendwo eine Dokumentation existieren, wie er mit welchen Konditionen umgeht.
Wenn der neue IP-Stack von OS X dasselbe Problem haben sollte, kann man dort aber wenigstens mit einem Packetdump noch feststellen, wie Apple mit solchen UDP-Paketen mit gesetztem CE überhaupt umgeht. Wenn es sie einfach verwirft, sollte ja in einem Packetdump kein "decapsulated packet" mit dem Payload zu sehen sein. Mit einem simplen "ping" (give me a ping, Vassili ... one ping only please) zwischen den Endpoints (ohne zusätzlichen Traffic) sollte sich das sogar wieder anhand der Anzahl der Pakete verifizieren lassen, ob so ein "echo request" über die IPSec-Strecke auch zu einem "echo reply" des Apple-Devices führt und dann nur dieses nicht richtig verarbeitet wird.
Interessant wäre es u.U. noch (damit kann man auch weitere Schlüsse ziehen, wo der Fehler nun eigentlich sitzen könnte, im IP- oder im IPSec-Stack), wie iOS 9 auf andere UDP-Pakete mit CE-Signalisierung reagiert (DNS gehörte da ja auch dazu) bzw. ob UM diese "ECN=3"-Tags tatsächlich vollkommen wahllos und für jeden Traffic setzt. Zwischen zwei UM-Anschlüssen könnte man dann ggf. sogar noch ermitteln, ob dieses Tagging nur für Traffic gilt, der das UM-Netz verläßt oder auch innerhalb des UM-Netzes ständig stattfindet.
Dem "chapeau" für salamihawk schließe ich mich an ... das war und ist genau das, was ich meinte und mir vorgestellt habe, als ich auf die Notwendigkeit einer Analyse des Traffics verwiesen habe.
PS: Interessant fand ich noch den Schlußsatz einer Studie u.a. zur Verwendung von ECN mit UDP im heutigen Internet:
In RFC 3168 wurde mal explizit die Forderung aufgestellt (S. 7, letzter Absatz), daß ein Paket mit gesetzter CE-Kennzeichnung so zu behandeln wäre, wie ein von einem Router auf dem Transportweg verworfenes Paket und der "congestion avoidance"-Mechanismus des darüberliegenden Protokolls zu aktivieren wäre. Bei TCP wäre das eben die Annahme "congestion" und das Wiederholen des verworfenen Pakets (inkl. "slow start" von vorne), bei UDP an sich gibt es da gar keine Festlegungen.
Nachdem es so etwas bei einer "UDP-Verbindung" (auch das ist schon fast ein Euphemismus) nicht gibt und schon die Erkennung von Paketverlusten bei UDP nur durch eine entsprechende Nummerierung und/oder Absicherung auf einer höheren Ebene erfolgen kann (die darunter bieten weder Wiederholung noch Sortierung nach Reihenfolge), ist es auch nicht ganz so simpel. Die ganze Problematik wird für UDP in RFC 5404 in Punkt 3.1 (S. 6) ausführlich abgehandelt.
Auch RFC 3168 beschäftigt sich in Punkt 9.2 (Seite 29) explizit mit der Problematik bei der Verwendung von ECN in Kombination mit IPSec - das sollte aber bei ESP und NAT-T (also UDP-Kapselung), wo die Transportheader ohnehin keine Rolle spielen, nur sehr bedingt zu berücksichtigen sein, falls da irgendjemand (m.E. fälschlicherweise) die ECN-Konditionen aus den äußeren Paketen in die inneren kopieren würde.
Was jetzt Apple davon wie umsetzt bei den Änderungen in iOS9 (und wo UM ggf. noch dazwischenfunkt), sollte sich ja irgendwie an diesem Standard orientieren (oder ggf. an einem anderen, dann wäre die Frage an welchem).
Selbst mit Linux und "iptables" ist jedenfalls das Manipulieren der ECN-Bits eines Paketes nur für TCP-Pakete (und auch nur für die entsprechenden Bits im TCP-Header) möglich ... auch eine Linux-basierte Firewall kann (m.W., um das zu betonen, ich lasse mich gerne korrigieren) mit normalen Werkzeugen keine Manipulation an den ECN-Bits im IP-Header vornehmen (man kann sie nur bei einem recvmsg()-Aufruf mit auslesen als Empfänger). Selbst das Setzen der ECN-Bits im IP-Header irgendeiner Antwort (das wäre Aufgabe des Programms bei ECN für UDP) ist für ein Programm auf einer Schicht oberhalb der Netzwerkschicht (OSI 3) nicht trivial ... wie so ein IP-Stack für sich selbst an dieser Stelle reagieren müßte, ist m.W. nirgendwo festgelegt (anders als bei TCP).
Da eigentlich ECN-Bits per Definition zu ignorieren wären, wenn eine der beiden Seiten damit nichts anfangen kann (dann greift eben irgendwann bei echtem Stau ein Paketverlust regulierend ein), würde ich - dabei bleibe ich - das Problem tatsächlich eher bei Apple verorten. Wenn die UDP-Pakete mit gesetztem "ECN capable" verschicken und auf ständig gesetzte "congestion occured"-Bedingungen unglücklich reagieren, sehe ich - nur meine eigene Meinung - eben die Verantwortung für die korrekte Behandlung eines "Dauerstaus" (auch macht es eben nach RFC 3168 einen Unterschied, ob ein einzelnes Paket oder mehrere mit CE-Signalisierung eintreffen) bei Apple. Das generelles Taggen durch UM ist zwar sicherlich auch "fragwürdig" (wenn es wirklich immer erfolgt), aber wenn Apple die Unterstützung/Auswertung von ECN auf andere Protokolle ausdehnt, dann muß man wohl auch damit zurecht kommen, ohne daß gleich alles zusammenbricht. Während eben bei TCP-Verbindungen das Ganze damit zwar stark (und hoffentlich in der Regel unnötigerweise) gedrosselt würde (deshalb juckt das auch die prinzipielle Funktion einer FTP-Verbindung nicht, allerdings dürfte es sie erheblich verlangsamen) und auch bei bestimmten RTP-Verbindungen (RFC 6679) noch standardisiert ist, ist es bei IPSec-Implementierungen eine Frage der höheren Schichten, ob und wie das ausgewertet und behandelt wird. Diese Behandlung der Pakete bei UM ist ja sicherlich auch nichts wirklich Neues und andere Systeme kommen damit ja offenbar auch klar. Wenn also Apple der Meinung ist, sie machten es richtig und alle anderen falsch, sollten sie das ja mit einem entsprechenden Statement und dem Verweis auf den als Basis der Implementierung verwendeten Standard leicht klarstellen können.
Der Unterschied zwischen einem verworfenen Paket (dafür gibt es normalerweise gar keine Benachrichtigung, vielleicht noch ein "source quench", obwohl das seit RFC 6633 auch "deprecated" ist und das käme normalerweise auch von einem Endpoint und nicht von einem Router) und einem mit CE-Warnung ist es eben, daß ersteres den Empfänger gar nicht erreicht und zweiteres ihn eigentlich dazu veranlassen sollte, auf einer höheren Ebene (so es eine solche überhaupt gibt, siehe oben) dem Sender mit einer Quittung (oder dem nächsten eigenen Paket, wenn es wie bei UDP keine Quittungen gibt) diesen Umstand seinerseits mitzuteilen und ihn dazu aufzufordern, etwas langsamer zu machen (bis zu einem minimalen Niveau > 0).
Während also im ersteren Fall unbedingt ein Paket wiederholt werden müßte (wurde ja schließlich "discarded", bei IPSec kann auch nicht einfach eines ausfallen wie bei irgendwelchen RTP-Verbindungen), muß/soll das im zweiten Falle angekommene Paket eben noch verarbeitet werden. Das ist ein Widerspruch zum RFC 3168, wenn man es flüchtig liest ... aber das bezieht sich dort eben auf ein einzelnes Paket (single packet) mit gesetztem CE.
Insofern stimme ich KunterBunter auch nur bedingt zu, denn bei IPSec hat der Empfänger (der kriegt so ein "CE" als erster zu sehen, wenn das der Router am EP ist) gar keine Möglichkeit, dem Sender über irgendeine Flußsteuerung das "mach mal langsamer" zu signalisieren. Diese Signalisierung per ECN geht eben an den Empfänger eines IP-Paketes und der Sender erfährt davon nur dann, wenn es der Empfänger ihm irgendwie (ooB oder mit der nächsten regulären Meldung) mitteilen kann.
Also sollte/müßte Apple bei IP-Verbindungen, bei denen nicht bekanntermaßen auf einer höheren Schicht eine Flußkontrolle möglich ist, im IP-Stack an sich einfach mal gar nichts unternehmen und nur die Bits entsprechend auf Anforderung bereitstellen. Wenn hingegen der IPSec-Stack im iOS (nicht mit dem IP-Stack zu verwechseln) irgendwie diese ECN-Bits seit neuestem setzt und/oder auswertet, sollte ja irgendwo eine Dokumentation existieren, wie er mit welchen Konditionen umgeht.
Wenn der neue IP-Stack von OS X dasselbe Problem haben sollte, kann man dort aber wenigstens mit einem Packetdump noch feststellen, wie Apple mit solchen UDP-Paketen mit gesetztem CE überhaupt umgeht. Wenn es sie einfach verwirft, sollte ja in einem Packetdump kein "decapsulated packet" mit dem Payload zu sehen sein. Mit einem simplen "ping" (give me a ping, Vassili ... one ping only please) zwischen den Endpoints (ohne zusätzlichen Traffic) sollte sich das sogar wieder anhand der Anzahl der Pakete verifizieren lassen, ob so ein "echo request" über die IPSec-Strecke auch zu einem "echo reply" des Apple-Devices führt und dann nur dieses nicht richtig verarbeitet wird.
Interessant wäre es u.U. noch (damit kann man auch weitere Schlüsse ziehen, wo der Fehler nun eigentlich sitzen könnte, im IP- oder im IPSec-Stack), wie iOS 9 auf andere UDP-Pakete mit CE-Signalisierung reagiert (DNS gehörte da ja auch dazu) bzw. ob UM diese "ECN=3"-Tags tatsächlich vollkommen wahllos und für jeden Traffic setzt. Zwischen zwei UM-Anschlüssen könnte man dann ggf. sogar noch ermitteln, ob dieses Tagging nur für Traffic gilt, der das UM-Netz verläßt oder auch innerhalb des UM-Netzes ständig stattfindet.
Dem "chapeau" für salamihawk schließe ich mich an ... das war und ist genau das, was ich meinte und mir vorgestellt habe, als ich auf die Notwendigkeit einer Analyse des Traffics verwiesen habe.
PS: Interessant fand ich noch den Schlußsatz einer Studie u.a. zur Verwendung von ECN mit UDP im heutigen Internet:
Wobei es darin wohlgemerkt nur um die Verwendung von ECN an sich geht und nicht um die (eher fragwürdige - in meinen Augen) Verwendung durch UM.
Zuletzt bearbeitet:
Absolut großartige Arbeit salamihawk!!!
Ich habe soeben auf die iOS 9.1 Public Beta2 aktualisiert und das Von Problem besteht weiterhin...Ich bin echt gespannt, wann das gefixxt wird, von welcher Seite auch immer.
Gruß und danke für die bisherigen Analysen!
Ich habe soeben auf die iOS 9.1 Public Beta2 aktualisiert und das Von Problem besteht weiterhin...Ich bin echt gespannt, wann das gefixxt wird, von welcher Seite auch immer.
Gruß und danke für die bisherigen Analysen!
Ich habe die Befürchtung dass das ewig dauern kann, nicht zuletzt wegen dem schlechten Support bei Unitymedia.
Ansonsten großartige Arbeit hier, Hut ab.
Ansonsten großartige Arbeit hier, Hut ab.
Naja zumindest wissen Apple und UM nun bescheid - auch an was es liegt - und ich bin doch guter Dinge und Hoffnung, dass sich einer von den beiden der Sache annimmt.
Ich bin mir ziemlich sicher, dass mindestens einer von den beiden sich überhaupt nicht dran stört.
amatör
Mitglied
- Mitglied seit
- 15 Feb 2014
- Beiträge
- 408
- Punkte für Reaktionen
- 10
- Punkte
- 18
Wer hat es Apple gemeldet bzw. sind denen auch die von salamihawk* gefundenen Details bekannt?
* dem ich hiermit ebenfalls meinen Respekt bezeuge und herzlich danke!
Ja, es gibt einen aktuellen Thread im Apple Dev Forum als auch einen Bug mit Case-Nummer:
https://forums.developer.apple.com/message/60922