Adapter Worx Landroid v3.x.x

[Neuschwansteini]

@lucky_esa sagte in Adapter Worx Landroid v3.x.x:

@neuschwansteini Eigentlich sollt ihr eure APP ausprobieren und nicht den Adapter. Wenn alles funktioniert dann dringend erst in der Instanz Einstellung den roten Button drücken damit eure allte Session geköscht wird und dann noch den Adapter auf debug stellen.

Nochmal von der Logik her.. wenn der Adapter gestoppt ist, funktioniert der rote Button doch garnicht, oder doch???
Und wenn ich den Adapter laufen lasse, werde ich immer geblockt..

Daher meine Frage.. wie soll das denn funktionieren?
Wenn ich den Adapter starte, startet er mit der alten Session, die wird gleich wieder geblockt, bis ich den roten Button gedrueckt habe und der Adapter einen neuen Sessionkey holt.. so war's ja jetzt..

Da ist meiner meinung nach n dicker Logikfehler drin!

[eve11]

Vielleicht wäre es am besten den Adapter zu deinstallieren und von Vorne anzufangen.

[Neuschwansteini]

@eve11 sagte in Adapter Worx Landroid v3.x.x:

Vielleicht wäre es am besten den Adapter zu deinstallieren und von Vorne anzufangen.

ja, richtig, bevor noch mehr user sich ihren Account damit sperren...

[EvilEls]

@bananajoe sagte in Adapter Worx Landroid v3.x.x:

@armilar das passt zu der Annahme das nicht Worx sperrt sondern zuvor schon Cloudflare als Sicherheitsdienstleister
Bei mir wäre das schlecht - ich habe eine feste IP-Adresse ...

Der a.nel.cloudflare.com aus dem Screenshot ( dieser Post: https://forum.iobroker.net/post/1278181) ist zumindest sowohl über IPv4 als auch IPv6 erreichbar

a.nel.cloudflare.com aus dem report-to header ist nur eine URL zu der der Browser anonymisierte Trackingdaten schickt. Das hat direkt nichts mit dem 429 zu tun. Habe es nur eingerahmt um zu zeigen, dass Cloudflare das Problem sieht.

Aber, account.worxlandroid.com sowie id.worx.com liegen bei Cloudflare. (Siehe server header)

Der 429 wird also nicht von worx sondern von Cloudflare geworfen. Dort wird sofort auf IP Ebene der 429 zurückgegeben, ohne überhaupt die Requests zu worx weiterzugeben.

Wenn ich mir bei der Telekom eine neue IP abhole, kann ich problemlos auf account.worxlandroid.com sowie id.worx.com zugreifen. Ohne Einschränkungen.

Unter id.worx.com habe ich alle verbundenen Apps gelöscht.

Dann Adapter gestartet:

worx.0
2025-06-22 11:48:52.573	warn	Serial number 202130267209007208FB was not found. Please delete the object tree worx.0.202130267209007208FB.
worx.0
2025-06-22 11:48:52.549	info	Start check devices object!
worx.0
2025-06-22 11:48:52.546	warn	No mower found to start mqtt
worx.0
2025-06-22 11:48:52.546	info	Start MQTT connection
worx.0
2025-06-22 11:48:52.531	error	{"message":"Too Many Attempts."}
worx.0
2025-06-22 11:48:52.531	error	AxiosError: Request failed with status code 429
worx.0
2025-06-22 11:48:52.265	info	Connected to worx server
worx.0
2025-06-22 11:48:51.723	info	Start login
worx.0
2025-06-22 11:48:51.718	error	{"error":"invalid_grant","error_description":"The refresh token is invalid.","hint":"Token has been revoked"}
worx.0
2025-06-22 11:48:51.718	error	AxiosError: Request failed with status code 400
worx.0
2025-06-22 11:48:51.202	info	Login to worx
worx.0
2025-06-22 11:48:51.200	info	Use new aws-iot-device-sdk-v2.
worx.0
2025-06-22 11:48:51.105	info	starting. Version 3.2.4 in /opt/iobroker/node_modules/iobroker.worx, node: v20.19.1, js-controller: 7.0.7

Danach account.worxlandroid.com sowie id.worx.com wieder 429. Alles dicht.

Also, neue IP geholt.

Wieder kann ich problemlos auf account.worxlandroid.com sowie id.worx.com zugreifen.
Interessanterweise sind wieder zwei Apps verbunden:

account. wird durch Zugriffe über die Webseite hinzugefügt.
app. durch den Adapter.

D.h., als ich den Adapter angeworfen habe, ist mindestens ein Login Versuch pro Applikation zu worx durchgekommen.

Nun ist die Frage, warum cloudflare danach alle Requests von meiner IP blockt.

Entweder:

• Cloudflare registriert das Login-Verhalten als „suspekt“ oder „botartig“ und blockiert die IP automatisch per WAF (Web Application Firewall) Rule, Bot Management oder Rate-Limit Rule.
• Worx hat auf seinem Origin-Backend ein Regelwerk, das bei verdächtigem Verhalten IPs an Cloudflare zurückmeldet (z. B. über Firewall API oder custom Access Rules via API). ZB, wenn App ungültigen Token 5× sendet → API erkennt Missbrauch → löst Blockierung via Cloudflare API aus. (halte ich aber für unwahrscheinlich)

Zu erstem Szenario würde auch passen, dass worx ein Problem mit mqtt DDOS eingeräumt (https://forum.iobroker.net/topic/74380/adapter-worx-landroid-v3-x-x/281?_=1750584154729) hat.

Also, mit neuer IP und funktionierenden Webseitzugriffen worx App installiert.
Diese ist seit gut 5 Tagen deinstalliert.

Login schlägt fehl. (Err: "Verbindung fehlgeschlagen")
Beim erneuten öffnen der App dann das bekannte, Langsamer.
Webseiten account.worxlandroid.com sowie id.worx.com wieder 429.

Mit neuer IP komme ich dann wieder auf die Webseiten und sehe wieder zwei Applications

play.google. offensichtlich die Android APp
account. wird durch Zugriffe über die Webseite hinzugefügt.

Also halten wir fest, es sieht alles danach aus, dass Cloudflare der Ausführende ist (429 zurückgibt), aber es ist nicht klar ob:
Cloudflare autonom durch die aktivierten Schutzfunktionen (Bot Detection, Rate Limits etc.) handelt
ODER
durch explizite Konfigurationen von Worx (z. B. Regeln wie „blockiere IP, wenn ...“)

DAS genau muss worx untersuchen.

[Homoran]

@evilels sagte in Adapter Worx Landroid v3.x.x:

Cloudflare autonom durch die aktivierten Schutzfunktionen (Bot Detection, Rate Limits etc.) handelt

wenn ich bei einer Website ein cloudflare popup erhalte, heisst es immer
"bitte bestätigen Sie, dass Sie ein Mensch sind"

Sollte der Fehler/ Block von cloudflare kommen, wird IMHO genau diese Überprüfung wohl eine Software (interpretiert als möglicherweise schädlicher Bot) ergeben

[Lucky_ESA]

@neuschwansteini sagte in Adapter Worx Landroid v3.x.x:

@lucky_esa sagte in Adapter Worx Landroid v3.x.x:

@neuschwansteini Eigentlich sollt ihr eure APP ausprobieren und nicht den Adapter. Wenn alles funktioniert dann dringend erst in der Instanz Einstellung den roten Button drücken damit eure allte Session geköscht wird und dann noch den Adapter auf debug stellen.

Nochmal von der Logik her.. wenn der Adapter gestoppt ist, funktioniert der rote Button doch garnicht, oder doch???
Und wenn ich den Adapter laufen lasse, werde ich immer geblockt..

Daher meine Frage.. wie soll das denn funktionieren?
Wenn ich den Adapter starte, startet er mit der alten Session, die wird gleich wieder geblockt, bis ich den roten Button gedrueckt habe und der Adapter einen neuen Sessionkey holt.. so war's ja jetzt..

Da ist meiner meinung nach n dicker Logikfehler drin!

Die Session ist in worx.0.session gespeichert welchen man auch manuell leeren kann. Der rote Button leert den State und das auch ohne das der Adapter eingeschaltet ist. Das refreshToken kann immer wieder verwendet werden es sei denn, ihr ändert PW, User und Application dann erfolgt ein neuer Login. Dieses Verhalten ist von Worx gewünscht und wird mir sogar als Example Code zur Verfügung gestellt.

Mir ist bewusst das ihr versucht eine Lösung zu finden und sucht den Fehler beim Adapter. Was ihr alle gemeinsam habt kann ich nicht sagen aber für mich sieht es nach einer Account Sperrung aus. Warum das so ist kann euch nur Worx sagen.

Ich werde mal den retry-after ausgeben lassen. Dieser sollte ja eigentlich die Zeit beinhalten, wie lange ihr gesperrt seit.

Eure Mails an Worx sollte nicht mehr 3-Party enthalten sondern das ihr mit der Worx APP immer sofort blockiert werdet.

Mittlerweile habe ich auch das Gefühl, dass es irgendwas mit der DDOS Attacke zu tun hat.

Gruß//Lucky

[Neuschwansteini]

@lucky_esa

Vielen Dank für die ausführlichen Erklärungen!

[EvilEls]

@homoran sagte in Adapter Worx Landroid v3.x.x:

@evilels sagte in Adapter Worx Landroid v3.x.x:

Cloudflare autonom durch die aktivierten Schutzfunktionen (Bot Detection, Rate Limits etc.) handelt

wenn ich bei einer Website ein cloudflare popup erhalte, heisst es immer
"bitte bestätigen Sie, dass Sie ein Mensch sind"

Sollte der Fehler/ Block von cloudflare kommen, wird IMHO genau diese Überprüfung wohl eine Software (interpretiert als möglicherweise schädlicher Bot) ergeben

Jein
Dein Gedankengang ist korrekt, aber es gibt mehrere Szenarien, in denen Cloudflare blockiert, ohne das typische "Bitte bestätigen Sie, dass Sie ein Mensch sind"-Popup (Challenge-Seite) anzuzeigen.

Die CAPTCHA / Managed Challenge (Mensch-Seite) - was du meinst - wird angezeigt, wenn Cloudflare dich verdächtigt, aber nicht sicher ist, dass du ein Bot sein könntest.
Diese Challenge erscheint nur bei HTML-Inhalten (nicht bei reinen API-Aufrufen, XHR oder App-Calls).
Sie ist aber nur im Browser sichtbar. Eine App oder ein Skript bekommt keine Möglichkeit, sie zu lösen und wird stattdessen geblockt.
Man sieht das Popup typischerweise bei „grenzwertigem“ Verhalten wird aber bei offensichtlichen Angriffen oder Skripttraffic nicht gezeigt

Cloudflare kann aber auch sofort blocken, ohne Popup, ohne Challenge, z. B. durch:
Rate Limiting Rules, wenn zu viele Anfragen von deiner IP in kurzer Zeit kommen. Ergibt dann Response: 429 Too Many Requests – wie in diesem Fall
Diese Request werden direkt durch Cloudflare beantwortet. Keine Chance zur Interaktion durch Popup.

Bot Management mit "hard block" könen ebenfalls einen direkten 429 verursachen. Wenn zB Cloudflare sicher ist, dass du ein Bot bist (z. B. durch Fingerprint, fehlenden User-Agent, automatisierte Muster). Würde dann zB Response: 403 Forbidden, 429, manchmal 503 zurückgeben. Kein Popup, keine Challenge, sofortiger Ausschluss.

Custom Firewall Rules (von Sitebetreiber - also worx) können über das Cloudflare Dashboard Regeln definiert werden. ZB:

Wenn IP-Anfrage > 100 in 60 Sekunden → blockiere sofort
Wenn Request-Header fehlt → sofort blockieren
Wenn Pfad enthält /api/login/ → max 5 Versuche pro Minute

Diese Regeln würde zB nie ein CAPTCHA zeigen, sondern führen direkt zu einem Block (403, 429, oder 5xx je nach Setup).

Dann sind da noch WAF Managed Rules (Automatische Angriffsabwehr)
Z. B. wenn:
SQL-Injection-Muster erkannt wird
bekannte Exploit-Versuche auftauchen
App-Request-Header verdächtig wirken

Diese führen ebenfalls zu sofortigem Block. Ohne sichtbare Challenge. Besonders bei API-Calls oder App-Verkehr.

Ich denke, Cloudflare kann hier nicht sinnvoll eine Challenge zeigen, weil die App/Adpter sie nicht lösen kann. Daher direkter Block mit 429.

Evtl liegt es ja auch am Token Management auf worx Seite, die sofort IP blocken wenn ein Fehler auftritt.

2025-06-22 11:48:51.718	error	{"error":"invalid_grant","error_description":"The refresh token is invalid.","hint":"Token has been revoked"}
worx.0
2025-06-22 11:48:51.718	error	AxiosError: Request failed with status code 400
worx.0
2025-06-22 11:48:51.202	info	Login to worx

Ich schließe mich der Meinung von @Lucky_ESA an, dass hier nicht der Adapter (oder die App) die Schuldigen sind.

[Neuschwansteini]

@evilels

gut analysiert!

Nur hoffe ich, dass der Worx-Support das kapiert, denn diese Bürokraten Maschinerie ist nicht die besonders hellste.. (zumindest meine Erfahrung..)

[eve11]

Die Frage wären nun, wie kann man den Sachverhalt Worx beibringen.
@Lucky_ESA: Hast du zufällig einen Ansprechpartner bei Worx ?

[hsteinme]

@eve11 sagte in Adapter Worx Landroid v3.x.x:

@Lucky_ESA: Hast du zufällig einen Ansprechpartner bei Worx ?

@Lucky_ESA In meinen Augen wäre es sinnvoll, die betrachtete Problematik als neues, eigenständiges Thema in https://github.com/PositecBeta/mower-connection-samples/issues einzutüten. Von einem Einbringen in den dortigen Issue #35 als Zusatz halte ich wenig.

Wenn Du diesen Weg gehst, wirst Du wohl aufgefordert werden, konkret Ross und Reiter zu nennen. Um hier schnell reagieren zu können, empfehle ich allen Betroffenen, ihre Seriennummern und die Zeitpunkte der Sperren per PN an @Lucky_ESA zu schicken - sobald er hier mitgeteilt hat, den genannten Weg eingeschlagen zu haben.

[ITCrowd]

@hsteinme
Selbst die Landroids kommen kaum noch an den Server.

Mit Wireshark mal in die Kommunikation des Landroid geschaut. Er bekommt nur selten eine Antwort.

Was meinst Du mit "ohne öffentliche IPv4"? Wievielte dieser gesperrten User gibt es Deines Wissens nach? Wo haben diese User von ihren Sperren berichtet? Sind dort nur ioBroker User betroffen?

Das ist der Fluch der ganz neuen Technik. Neue große Provider (zB. Glasfaser) haben nicht genug IPv4 Adressen vom großen Kuchen bekommen. Also nutzen theoretisch über 65000 Nutzer eine IPv4 Adresse Richtung Internet. DS-Lite-Tunnel, Mobilfunk und Breitband Kunden, haben dasselbe Problem.

Und ja, zehn meiner Nachbarn haben die orangen Flitzer im Garten. Alle haben Glasfaser und alle zehn haben das gleiche Problem.