Amazon AWS S3 / Github downloads sehr langsam, nicht nutzbar

[#1]

Hallo,

seit ca. einer Woche habe ich starke Probleme beim Zugriff auf Inhalte von Github / Amazon AWS S3. Es ist nahezu unmöglich größere Dateien herunterzuladen. Ich erreiche lediglich Geschwindigkeiten im einstelligen kb/s Bereich. Aufgefallen ist es mir nach der Neu-Installation meines Desktop Rechners und ich hatte erst vermutet es sei ein lokales Problem mit dem Rechner. Ich habe jedoch heute auch mit 3 weiteren Geräten im lokalen Netz das gleich Problem gehabt. Da das Problem nun an min 3 Tagen in der letzten Woche aufgetreten ist, und ich über z.B. LTE ordentliche Bandbreiten erreiche habe ich nun ein Problem mit dem Anschluss in Verdacht.

Die Generelle Bandbreite des Anschlusses ist i.O., lediglich mit S3 habe ich Probleme. Ich habe in älteren Posts von Problemen mit dem Peering gelesen, konnte dazu allerdings nichts aktuelles finden. Wie kann ich mein Problem lösen?

[#2 · Accepted solution]

---

@Thomas_Herrmann  schrieb:

Bei mir auch Wirespeed, 11MB/s.

Danke Telekom/AWS/wer auch immer - auch wenn's lange gedauert hat.

---

---

@viper.de  schrieb:

Bei mir ca. 9 MB/s an einem VDSL100, IP Adresse 91.23.xxx.yyy

---

---

@rtel  schrieb:

Auf einmal 12.1Mb/sec anstatt zuvor 1-2 Kb. Kann bestätigen, dass es wieder schnell ist. Keine Ahnung, wer was genau gemacht hat, aber auf jeden Fall vielen Dank!

---

---

@soupdiver  schrieb:

Ich kann von 84.161.x.x auch bestätigen, dass wieder >10MB/s durch die Leitung gehen.

Top!!... danke an die vielen sinnvollen Beiträge hier... und das ganze Gemecker vergessen wir mal

---

---

@tm_107  schrieb:

Hier auch wieder ordentliche Downloadgeschwindigkeiten ...

---

---

@Jaffi  schrieb:

ES FUNZT WIEDER!!! FULLSPEED, DANKE!!! 🚀

---

---

@luddinho  schrieb:

Auch ich kann von meiner Seite berichten, dass seit heute Nachmittag ca. 16:45 Uhr die Downloadgeschwindigkeit enorm zugenommen hat.

---

@Thomas_Herrmann @viper.de @rtel @soupdiver @tm_107 @Jaffi @luddinho Danke für die positiven Rückmeldungen und es freut uns, dass die von euch genutzten Dienste, die von Amazon gehostet werden, nun wieder in der gewünschten Geschwindigkeit zur Verfügung stehen. 👍 😊

@luddinho  schrieb:

Interessieren würde mich dennoch was im Hintergrund geschehen ist was zur Besserung beigetragen hat.

---

Wie zuvor erwähnt: Von unserer Seite gibt es keine Engpässe bezüglich der Verkehre mit Amazon. Unsere mit Amazon vereinbarten Schnittstellen sind für den Datenverkehr ausreichend ausgestattet. Die Verkehrssteuerung obliegt am Ende aber Amazon selbst. Seit Anfang der Woche sehen wir wieder eine optimalere Verkehrsverteilung und sind guter Dinge, das damit die Probleme für unsere Kunden gelöst sind. Auch stehen wir mit Amazon in direktem Kontakt, um solche Vorfälle in Zukunft hoffentlich vermeiden zu können.

Liebe Grüße

Waldemar H.

[#3 · Accepted solution]

Telekom/AWS update

eine kleine Zusammenfassung für Neuankömmlinge als Living-Post (ich bin kein Experte nur Zusammenfassender):

Das Problem ist noch nicht gelöst!
Der Thread ist nur als "Gelöst" markiert, weil das die einzige Möglichkeit ist, Beiträge anzupinnen.

Es betrifft offenbar AWS-Server an der Ostküste der USA und Dienste wie github die dort gehostet werden.
Das aber nur bei Kunden der Telekom und bei Wiederverkäufern, wahrscheinlich auch bei Providern die Infrastruktur der Telekom nutzen.

Die grundsätzliche Ursache liegt wohl in der Route auf dem Rückweg.
(Posts mit Traceroutes in Hinrichtung nützen deswegen übrigens nichts)

Zur Stellungnahme des Telekom-Teams siehe anderer angepinnter Beitrag.
Außerdem fand ich diesen Beitrag in einem anderen Thread recht klar:
"von unserer Seite gibt es keine Engpässe in Richtung Amazon. Unsere mit Amazon vereinbarten Schnittstellen sind für den Datenverkehr ausreichend ausgestattet. Warum Amazon seinen Datenverkehr von der Ostküste darüber hinaus auch über andere Verkehrswege verschickt, können wir nicht sagen und ist die Entscheidung von Amazon.
Selbstverständlich befinden wir uns mit dem Anbieter in Gesprächen, um eine bessere Lösung für unsere Kunden zu schaffen."

Die Rückroute geht im langsamen Fall z.B. über Cogent an die Telekom.
Die Anbindung ist wohl suboptimal um es nett zu sagen.
Warum dabei die Geschwindigkeit auf 1/100 bis 1/1000 sinkt ist [für mich] rätselhaft.

Eine Frage ist, ob die Ursachen in firmenpolitischen Zusammenhängen liegen, siehe interessante Links ganz unten.

Workarounds:

Von der IP die man zugewiesen bekommt, hängt offenbar das Routing ab.
Man kann versuchen, durch z.B. "Neu Verbinden" in der Fritzbox oder entsprechendes bei anderen Routern (ohne Trennen des DSL) einen anderen IP-Bereich zu bekommen.
Aber nicht jeder bekommt IPs aus mehreren Bereichen.

Bekannte kritische Bereiche:
79.192.0.0/10 (79.192.0.1 - 79.255.255.254)

80.128.0.0/11 (80.128.0.1 - 80.159.255.254)

84.128.0.0/10 (84.128.0.1 - 84.191.255.254)

87.128.0.0/10 (87.128.0.1 - 87.191.255.254)

91.0.0.0/10 (91.0.0.1 - 91.63.255.254)

93.192.0.0/10 (93.192.0.1 - 93.255.255.254)

...

scheint wieder zu funktionieren:
84.136.0.0 bis 84.191.255.255 (siehe Link unter Entwicklungen)
darunter 84.166.*.* aus eigener Erfahrung

anscheinend unkritisch:
93.* (ausgenommen obiger Teilbereiche)
217.*
...

(weitere bitte posten...wird ergänzt, wenn Zeit ist)

Durch einen Proxy oder ein VPN kann man ebenfalls einen anderen IP-Bereich bekommen und damit auch ein anderes Routing.
(ich denke, der Proxy/VPN darf dann selbst nicht bei der Telekom und in einem schlechten Bereich liegen, z.B. bei einem eigenen VPN-Server und auch nicht auf AWS us-east für die Verbindung zu Dir)

Kleine Zusammenfassung der "Lösungen" in einem älteren Post:
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Amazon-AWS-S3-Github-downloads-sehr-langsam-ni...

zusätzlich für einzelne Dateien auch:
"der einfachste Workaround ist
diese URL aufrufen
https://hide.me/en/proxy
und da die eigentliche URL zu github einfügen.
Braucht kein VPN und kostet nichts -
für einzelne Dateien ist das nicht mal ein nennenswerter Mehraufwand - was an dem Problem nichts ändert"
(von Stefan)

Der obige Proxy scheint auch nicht immer zu funktionieren, stattdessen aber dieser:
https://www.hidemyass.com/de-de/proxy


Test der Rückroute:
https://mtr.sh
AWS US-OH Ohio für us-east
AWS US-OR Oregon für us-west zum Vergleich
oben eigene externe IP eintragen und "mtr" wählen
(interessanterweise ist US-VA, das ja auch an der Ostküste liegt mit kurzer Route)

weitere interessante Links/Posts:

Entwicklungen:
84.136.0.0 bis 84.191.255.255
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Amazon-AWS-S3-Github-downloads-sehr-langsam-ni...

Messung:
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Amazon-AWS-S3-Github-downloads-sehr-langsam-ni...
(sehr interessant, mag etwas über die Ursachen aussagen)

bzgl. Route:
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Amazon-AWS-S3-Github-downloads-sehr-langsam-ni...

bzgl. älterer Peering-Verwicklungen der Telekom:
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Amazon-AWS-S3-Github-downloads-sehr-langsam-ni...

eventuelle Gegenargumente:
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Amazon-AWS-S3-Github-downloads-sehr-langsam-ni...

zu Rückmeldungen von Amazon:
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Amazon-AWS-S3-Github-downloads-sehr-langsam-ni...
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Amazon-AWS-S3-Github-downloads-sehr-langsam-ni...

Abhandlung der Telekom über Peering-Probleme:
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Peeringprobleme-Probleme-bei-Datenuebertragung...

[#4 · Accepted solution]

der einfachste Workarround für das herunterladen einzelner Dateien ist diese URL aufrufen

https://hide.me/en/proxy 

oder falls es da Probleme gibt: 

https://www.hidemyass.com/de-de/proxy

und da  die eigentliche URL zu github einfügen.

Braucht kein VPN und kostet nichts - 

Für einzelne Dateien ist das nicht mal ein nennenswerter Mehraufwand - was an dem Problem nichts ändert

[#5]

So ich konnte mal ein paar Daten von meinem Kumpel klauen.

Der hat ne AWS Instanz und ping täglich seine eigene Heim-IP. Da kann man dann deutlich sehen ab wann das Peering dicht macht, jeden Tag ab 18-19Uhr. Er wohnt im Westen, kann im Osten oder Süden dementsprechend anders sein, aber ein Problem scheint es da definitiv zu geben.

[#6]

Auch heute am frühen Nachmittag waren meist nur <40 kB/s zu bekommen. Da scheint die Aussagefähigkeit der Pings an ihre Grenzen zu stoßen.

Ich habe das von mir verlinkte Archiv (Link) jetzt im Zeitraum 20-21 Uhr nochmal an diversen Anschlüssen unseres Firmennetzwerks versucht herunterzuladen:

(nach Downloadrate sortiert)

Berlin - Telekom LTE -> 5-20 kB/s

Berlin - Telekom 16 MBit/s DSL -> 8-25 kB/s

Bernau (bei Berlin) - Telekom 50 MBit/s VDSL -> 10-25 kB/s

Chemnitz - Telekom 6 MBit/s DSL -> 10-30 kB/s

Köln - Telekom 100 MBit/s VDSL -> 10-30 kB/s

Potsdam - 1&1 100 MBit/s VDSL -> 10-30 kB/s

Köln - O² LTE -> 14 MB/s

Berlin - Vodafone 250 MBit/s Kabel -> 20 MB/s

Chemnitz - Vodafone 250 MBit/s Kabel -> 20 MB/s

Berlin -> Vodafone LTE -> 21 MB/s

Köln - NetCologne 250 MBit/s Kabel -> 23 MB/s

Stuttgart - Versatel 600 MBit/s Glasfaser -> ca. 50 MB/s

Ein Kollege hat über seinen Sohn das Ganze im Netz der TU Augsburg probiert ... >50 MB/s

Es fällt schon auf, dass (zumindest stichprobenartig) in ganz Deutschland anscheinend nur Telekom-Anschlüsse betroffen sind, während andere Netzbetreiber scheinbar keine Probleme haben.

Immerhin unterscheiden sich die erreichbaren Datenraten um den Faktor 1000 !!!

[#7]

@tm_107 

Wenn 1&1 auch betroffen ist (die mieten nur die Leitung, Peering und Einwahl geht komplett über 1&1) gibt es irgendwo nen Engpass der außerhalb des Telekomnetzes liegt, da es auch 1&1 betrifft.

Jetzt müsste man wissen wo und dann könnte man das bestimmt irgendwie abändern.

[#8]

wie gesagt, bei mir am Telekom Abschluss mit genau dem Peering - Der Übersichtlichkeit gekürzt.

]C:\tools>wget https://github.com/win-acme/win-acme/releases/download/v2.1.13.1/win-acme.v2.1.13.978.x64.pluggable....

2020-12-17 21:34:52-- https://github.com/win-acme/win-acme/releases/download/v2.1.13.1/win-acme.v2.1.13.978.x64.pluggable.... Resolving github.com (github.com)...

HTTP request sent, awaiting response...

200 OK Length: 31697304 (30M) [application/octet-stream]

Saving to: 'win-acme.v2.1.13.978.x64.pluggable.zip.1'

[=======================================================>] 30.23M 7.46MB/s in 4.0s 

[#9]

@FelixKruemel 

Sorry, da bin ich in der Zeile verrutscht. 1&1 hatte 13 MBit/s, kann ich aber leider nicht mehr editieren.

Die Zeile müsste korrekt lauten:

Potsdam - 1&1 100 MBit/s VDSL -> 13 MB/s

Falls ein Admin das liest, kann er es bitte gerne korrigieren.

Wobei ich der Meinung bin, dass mein früherer 1&1-VDSL-Anschluss komplett Telekom war. Also definitiv Einwahl und IP.

Jetzt läuft das aber wohl über Versatel.

[#10]

Ich habe es heute Vormittag nochmal probiert. Keine Veränderung in der erreichten Bandbreite:

 wget https://github.com/win-acme/win-acme/releases/download/v2.1.13.1/win-acme.v2.1.13.978.x64.pluggable.zip
--2020-12-18 10:56:19--  https://github.com/win-acme/win-acme/releases/download/v2.1.13.1/win-acme.v2.1.13.978.x64.pluggable.zip
Resolving github.com (github.com)... 140.82.121.3
Connecting to github.com (github.com)|140.82.121.3|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://github-production-release-asset-2e65be.s3.amazonaws.com/46080325/a3281780-3868-11eb-8e96-a0525feb625e?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credentmz-Date=20201218T095619Z&X-Amz-Expires=300&X-Amz-Signature=27c5808b4b93ec267007b1cd4bdedc21866e11ea7c0d8097c14641fea38f530e&X-Amz-SignedHeaders=host&actor_id=0&key_idme%3Dwin-acme.v2.1.13.978.x64.pluggable.zip&response-content-type=application%2Foctet-stream [following]
--2020-12-18 10:56:19--  https://github-production-release-asset-2e65be.s3.amazonaws.com/46080325/a3281780-3868-11eb-8e96-a0525feb625e?X-Amz-Algorithm=AWS4-HMAC-SHA25ws4_request&X-Amz-Date=20201218T095619Z&X-Amz-Expires=300&X-Amz-Signature=27c5808b4b93ec267007b1cd4bdedc21866e11ea7c0d8097c14641fea38f530e&X-Amz-SignedHeaders=host&acent%3B%20filename%3Dwin-acme.v2.1.13.978.x64.pluggable.zip&response-content-type=application%2Foctet-stream
Resolving github-production-release-asset-2e65be.s3.amazonaws.com (github-production-release-asset-2e65be.s3.amazonaws.com)... 52.216.178.147
Connecting to github-production-release-asset-2e65be.s3.amazonaws.com (github-production-release-asset-2e65be.s3.amazonaws.com)|52.216.178.147|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 31697304 (30M) [application/octet-stream]
Saving to: ‘win-acme.v2.1.13.978.x64.pluggable.zip’

win-acme.v2.1.13.978.x64.pluggable.zip                        0%[                                                                                                                                                                                                                                                                           win-acme.v2.1.13.978.x64.pluggable.zip      2%[=>                                                                                  ] 857.55K  8.08KB/s    eta 54m 45s

Ich habe dann nochmal einen MTR laufen lassen, diesmal auf github-production-release-asset-2e65be.s3.amazonaws.com. Dabei ist dann dies hier passiert:

So wie ich das verstehe hat plötzlich meine FB angefangen die Pakete zu verwerfen.... gibt es dafür eine Sinnvolle Erklärung?

Ich habe dann MTR abgebrochen und einfach nochmal neu laufen lassen, dann ergibt sich folgendes Bild:

Wie lässt sich das merkwürdige Verhalten der FB / MTR erklären?

[#11]

Das merkwürdige Verhalten kann ich leider auch nicht erklären, zumal ich aus den merkwürdigen Screenshots nicht schlau werde.

Fest steht nur, dass das Problem allgemein wohl nicht an der Fritzbox liegen wird. Hier im Büro habe ich die Downloadprobleme ja auch, und zwar über eine "Digitalisierungsbox Premium" (also ein bintec-elmeg be.ip-ähnlicher Router).

Und eine Fritzbox ist meines Wissens nach bei uns nur an dem Anschluss in Bernau in Betrieb (von dem ich gestern auch die Traceroute-Screenshots gemacht habe).

Aktuell:

[#12]

Selber Hier, versuche den ganzen Tag 20.3mb von Github runterzuladen ..... mit kb geschwindigkeiten bis dann einen Netzwerk Fehler auftritt.... auch beim oculus install kann ich nicht die Dateien runterladen (b/s ???)

[#13]

Meine Screenshots zeigen eine alternative Ausgabe von MTR. Jede Spalte der bunten Symbole ist ein Datenpunkt und zeigt so wie ich das verstehe die gemessene Latenz bzw. den verlorene Pakete an (rote Fragezeichen). Mit jedem Paket wird eine neue Spalte rechts gezeichnet und die Ausgabe wird nach links verschoben. Es zeigt also den Package loss / Latenz über Zeit. Man kann beim ersten screenshot sehen, dass package loss zuerst nura außerhalb meines Anschlusses passiert, und plötzlich verwirft meine FB alles. Erst nach dem "Neustart" sehen die Daten in meinem LAN wieder i.O. aus.

[#14]

Der Download läuft noch immer ...

Man könnte 😂 ... wenn es nicht so traurig wäre.

[#15]

Seih froh das er überhaupt läuft, bei mir bricht er dann irgendwann einfach mit nem Fehler ab -_-

[#16]

Auch heute -- 6.2 Sekunden - nach vie vor ist die Router unfassbar lang 

C:\tools>wget https://github.com/win-acme/win-acme/releases/download/v2.1.13.1/win-acme.v2.1.13.978.x64.pluggable.zip
--2020-12-18 16:37:52--  https://github.com/win-acme/win-acme/releases/download/v2.1.13.1/win-acme.v2.1.13.978.x64.pluggable.zip
Resolving github.com (github.com)... 140.82.121.4
Connecting to github.com (github.com)|140.82.121.4|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://github-production-release-asset-2e65be.s3.amazonaws.com/46080325/a3281780-3868-11eb-8e96-a0525feb625e?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20201218%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20201218T153740Z&X-Amz-Expires=300&X-Amz-Signature=6c62098167e81fa171bbc99461a6951e5471418d3961a1cfb6604786fd6a233d&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=46080325&response-content-disposition=attachment%3B%20filename%3Dwin-acme.v2.1.13.978.x64.pluggable.zip&response-content-type=application%2Foctet-stream [following]
--2020-12-18 16:37:52--  https://github-production-release-asset-2e65be.s3.amazonaws.com/46080325/a3281780-3868-11eb-8e96-a0525feb625e?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20201218%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20201218T153740Z&X-Amz-Expires=300&X-Amz-Signature=6c62098167e81fa171bbc99461a6951e5471418d3961a1cfb6604786fd6a233d&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=46080325&response-content-disposition=attachment%3B%20filename%3Dwin-acme.v2.1.13.978.x64.pluggable.zip&response-content-type=application%2Foctet-stream
Resolving github-production-release-asset-2e65be.s3.amazonaws.com (github-production-release-asset-2e65be.s3.amazonaws.com)... 52.216.28.132
Connecting to github-production-release-asset-2e65be.s3.amazonaws.com (github-production-release-asset-2e65be.s3.amazonaws.com)|52.216.28.132|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 31697304 (30M) [application/octet-stream]
Saving to: 'win-acme.v2.1.13.978.x64.pluggable.zip'

win-acme.v2.1.13.978.x64.plug 100%[=================================================>]  30,23M  7,45MB/s    in 6,2s

2020-12-18 16:37:59 (4,88 MB/s) - 'win-acme.v2.1.13.978.x64.pluggable.zip' saved [31697304/31697304]

[#17]

ich habe mal den Hostmaster von TATA Communications angeschrieben, erwarte allerdings nicht, dass der sich jemals meldet.

Schaden kann es aber auch nicht.

[#18]

Still running ...

Jetzt breche ich das Ganze aber ab, das wird ja lächerlich. Außerdem wollte ich nicht so lange auf Arbeit bleiben 🤔

[#19]

Das gleiche Problem hier. Generell scheint die us-east Region von AWS betroffen zu sein. 

[#20]

Hier besteht das gleiche Problem.. Github/AWS alles nicht nutzbar. 

[#21]

@Stefan: Mir ist aufgefallen, dass in deinem wget in den redirected URLs die Region zu sehen ist (hier us-east). Bei mir sehe ich diese Angabe nicht. Kann man bei S3 irgendwie Einfluss auf die genutzte Region nehmen? Kann ich feststellen welche Region bei mir Verwendung findet?

[#22]

das entscheidet der Loadbalancer der AWS das kannst du nicht beeinflussen.

Wüsste jedenfalls nicht wie.

[#23]

Habe dasselbe Problem. Downloads über AWS (schon seit ein paar Tagen) praktisch nicht möglich

[#24]

Über @telekom_hilft bei Twitter hat ich es auch (erfolglos) versucht.

Seit Tagen geht nichts mehr über den Telekom Anschluss

[#25]

So ich hab den Thread jetzt mal eskaliert nachdem sich seit Tagen kein Teami gemeldet hat.

Ob man jedoch da was machen kann weiß ich nicht, aber ein Versuch ist es denke ich wert.

[#26]

Super vielen dank, ich drücke die Daumen. Das ist echt kein Zustand mehr :(.

[#27]

Hallo zusammen,

ich kann da im Moment noch nicht wirklich etwas zu sagen, werde aber zusehen, was ich dazu herausfinden kann.

Grüße
Peter

[#28]

Hallo in die Runde,

es tut mir leid, dass es auf der Route gerade Probleme gibt. Wir stehen mit Amazon bereits in Kontakt um die Kapazitäten zu erweitern. Bis dahin kann ich leider nur um Eure Geduld bitten.

Viele Grüße
Henning H.

[#29]

Ich möchte mich der Beschwerde anschließen! 

Ich nutze z.B. den Dienst WorkFlowy.com - langsam bis kurz vor die Unbenutzbarkeit.

Ich versuche einen Download von iZotope.com - da kommen ein paar kb/s wenn es nicht fast stillsteht

GitHub-Downloads hatte ich ähnliche Probleme

speedtests, diese Telekom-Seite und div. anders läuft problemlos

Wie ich hier sehe, scheint das Problem ja bekannt zu sein. Es hält aber schon einige Tage / Wochen an! 

Dejavú - Das gab es schon mal mit Apple, als die Streams nicht mehr liefen und Downloads aus den Stores so langsam wurden, dass sie abbrachen.

Ich frage mich, warum das den Nutzern nicht nur auffallen muss sondern warum wir dies über Wochen aushalten müssen? Es gibt auch Arbeit zu tun, gerade in diesem Jahr mit großem Homeoffice Anteil. Das ist aktuell wirklich sehr niederschmetternd und Werbung, in der man mir günstig ein Upgrade auf 250mbit anbieten möchte, macht mich eher stinkig in diesem Kontext 😕 

Ich hoffe wirklich, dass das Problem jetzt  mal zeitnah behoben wird

Wenn jemand Workarounds kennt - bitte gerne her damit