programmier-noob sucht python wissenden zum pseudo reverse engineering *g*

Zitat von the ratman

Invoke-WebRequest : Es wurde kein Positionsparameter gefunden, der das Argument "--request" akzeptiert.

Dieser Fehler kommt daher, dass Du offenbar die PowerShell (unter Windows?) benutzt. Da ist "curl" nur ein Alias auf "Invoke-WebRequest". Und das ist wenig direkt kompatibel zu dem Original "curl".

Aber für sowas gibt es Konverter, z.B. https://curlconverter.com/powershell-webrequest/ und der spuckt folgendes aus:

Invoke-WebRequest -Uri "http://<printer_ip>/command" `
    -Method Post `
    -ContentType "application/x-www-form-urlencoded" `
    -Body "~M105"

Alternativ kannst Du in der WSL unter Windows mit den echten Linux-Tools arbeiten.

Zitat von Ingo-FP-Angel

Alternativ kannst Du in der WSL unter Windows mit den echten Linux-Tools arbeiten.

curl ist normalerweise unter Windows auch verfügbar ohne WSL ganz einfach in der Kommandozeile. Jedenfalls ist das bei allen meinen Windows-Installationen so. Also einfach cmd.exe ausführen statt powershell, z.B.: Windows-Taste+R cmd ENTER. Dort deinen curl-Befehl eintippen/rein pasten. Eventuell noch die Apostrophe durch Gänsefüßchen ersetzen (sollte aber hier nicht wirklich notwendig sein. Ist aber schon eine typische Falle beim Abschreiben von Unix-Curl Beispielen, weil Quoting und Escapes unter Unix Shells im Detail etwas anders funktionieren als unter cmd).

Ansonsten, vielleicht mal mit anderem Browser als Firefox probieren oder Fehlermeldung in Google eintippen. Ich bin da jetzt kein Firefox Experte. Jedenfalls sind Browser heute oft so voreingestellt, dass sie standardmäßig http-Verbindungen verweigern, wenn nicht https genommen wird. Dein Drucker kann aber wohl kaum https mit vollständiger Zertifikatskette.

Zitat von buers

curl ist normalerweise unter Windows auch verfügbar ohne WSL ganz einfach in der Kommandozeile.

Das war ja nicht die Aussage von Ingo-FP-Angel - er sagte das man dann mit den Original CURL arbeiten kann. Die Aussage ist soweit korrekt.

Zitat von buers

dass sie standardmäßig http-Verbindungen verweigern, wenn nicht https genommen wird

Auch nicht ganz korrekt, der Versuch der Verbindungsaufnahme wird mit https versucht und führt zu fehlern wenn man nicht explizit http:// hinschreibt.

Verweigern tun die Browser die Verbindungsaufnahme also nicht. Sie versuchen es nur gar nicht unaufgefordert ungesichert. Hab ich bei vielen meiner IOT Geräte (Tasmota).

Zitat von SkyBird1980

er sagte das man dann mit den Original CURL arbeiten kann

Ich wollte ja auch nicht widersprechen, nur ergänzen, dass man curl auch unter Windows ohne WSL bequem nutzen kann. Ich hatte übrigens immer das Verständnis, dass das irgendwie genauso ein Original curl ist, wie Unix, da aus den selben Quellen kompiliert. Jedenfalls lässt sich GitHub - curl/curl: A command line tool and library for transferring data with URL syntax, supporting DICT, FILE, FTP, FTPS, GOPHER, GOPHERS, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, MQTT, POP3, POP3S, RTMP, RTMPS, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET, TFTP, WS and WSS. libcurl offers a myriad of powerful features für WIndows genauso wie für Linux übersetzen. libcurl daraus wird in vielen Projekten für Linux und Unix und Windows und MacOS genutzt (auch von mir).

Egal, praktisch funktionierte für mich Windows-mitgeliefertes curl seit Langem sehr zuverlässig.

Zum Verweigern der Browser. Ich meinte, das hing durchaus von Browser/Standard-Einstellungen/evt. Firmenpolicies ab und auch ob und wie man https-Wunsch des Browser umgehen kann, und ob oder ob nicht es sich um eine lokale Adresse handelt. Die Firefox-Fehlermeldung deutet doch schon darauf hin - oder nicht? Klar, selbst nutze ich auch viele IoT-Geräte ohne https.

Wieder was gelernt, dass es eine `curl.exe` auch unter Windows gibt, war mir nicht bewusst. Würde ja bedeuten, die Beispiele, die man so im Netz findet, sollten in der PowerShell auch funktionieren, wenn man `curl` durch `curl.exe` ersetzt, so dass eben nicht der Alias genutzt wird (ich hab verstanden, dass es am Ende mit anderen Tools umgesetzt werden soll; nur fürs Gesamtverständnis).

Und ja, fhem kenne ich nicht und würde ich mich jetzt auch nicht einarbeiten wollen.

Mit Firefox würde ich das ganze definitiv nicht ausprobieren, wenn man da was in die URL Zeile packt, wird da ja immer ein GET Request ohne Request Body draus. Nachdem, was ich hier so gelesen habe, braucht es aber POST plus Body. Damit ist FF m.E. raus (ja, man kann natürlich auch per JavaScript und fetch in der Browser Konsole arbeiten, wenn man das will).

Zur Lösungsfindung fände ich es hilfreich, sich auf einen Weg zu einigen.

Ich würde denken, folgendes sollte funktionieren:

curl.exe --location --request POST 'http://192.168.178.9:8899/command' --header 'Content-Type: application/x-www-form-urlencoded' --data-urlencode '~M105'

Zumindest sollte es dann sinnvollere Ausgaben geben, weil die Syntax korrekt ist.

Das schickt dann per POST das Temperatur-Kommando "~M105" an den allgemeinen "command" Endpunkt.

Wobei ich natürlich nicht sagen und mangels Hardware nicht testen kann, ob "--location" (zum Folgen eventueller Redirects) und das URL-Encoding überhaupt nötig ist, d.h. ob nicht auch schon das hier reicht:

curl.exe --request POST 'http://192.168.178.9:8899/command' --header 'Content-Type: text/plain' --data '~M105'

Zitat von the ratman

curl: (1) Received HTTP/0.9 when not allowed

Ok, das sieht insofern "gut" aus, als dass es eine echte Antwort vom Drucker gegeben hat. Die "gefällt" curl mit Standardeinstellungen nur nicht.

Der Drucker spricht offenbar eine veraltete Version des HTTP Protokoll, das kann man aber explizit mit `--http0.9` erlauben:

curl.exe --http0.9 --location --request POST 'http://192.168.178.9:8899/command' --header 'Content-Type: application/x-www-form-urlencoded' --data-urlencode '~M105'

Die Fehlermeldungen aus der cmd deuten für mich darauf hin, dass die cmd das Kommando anders parst und deshalb nicht mit genau dieser Syntax klar kommt. "URL rejected: Port number was not a decimal number between 0 and 65535" heisst ja, dass es die cmd nicht hinbekommen hat, die "8899" als Portnummer zu erkennen bzw. das "Could not resolve host: application" deutet drauf hin, dass die cmd das 'Content-Type: application/x-www-form-urlencoded' für die URL hält. Damit würde ich mich nicht weiter auseinandersetzen, sondern bei der PowerShell bleiben.

Cool, dass das jetzt geklappt hat

Kannst Du gerne so weitergeben. Brauchst mich dabei auch nicht zu erwähnen.

Dann drück ich mal die Daumen, dass sich das auch mit dem httmod-modul von fhem irgendwie ausdrücken lässt. Da müsste dann aber ggf. jemand anderes einspringen, wenn das da nicht auf Anhieb klappt.

Zitat von Ingo-FP-Angel

Die Fehlermeldungen aus der cmd deuten für mich darauf hin, dass die cmd das Kommando anders parst und deshalb nicht mit genau dieser Syntax klar kommt.

ja

Zitat von buers

die Apostrophe [="Hochkomma" = "einache Quotes"] durch Gänsefüßchen ersetzen

War mir oben zwar nicht sicher, ob man das braucht. Laut Fehlermeldung wohl schon (und auch nach genauerem Nachdenken wurde mir das klar). Oft reicht das allein leider nicht beim Übersetzen von Unix-Kommandozeilen nach Windows, beispielsweise benötigen curl posts an Kodi oft json Argumente mit Gänsefüßchen (die curl sehen muss, nicht der Parser der Kommandozeile). Bei Unix-Shells kann man " innerhalb von ' einfach benutzen. Bei Windows cmd braucht man in solchen Situationen \".

In dem Kommando in deinem Post kann man auch einige Quotes weglassen und es sollte (ungetestet)

curl.exe --http0.9 --location --request POST http://192.168.178.9:8899/command --header "Content-Type: application/x-www-form-urlencoded" --data-urlencode ~M105

funktionieren, jedenfalls unter cmd.exe. Wobei ich jetzt nicht auf die Argumente geachtet habe, sondern nur auf korrektes Quoting.