MTR v5 firmware upgrade scripting

[Satoshi Manabe]

I’ve been successful in scripting upgrades on MTR v4 software, which required a single “firmware-upgrade” command. But with MTR v5 mPower software, it appears there is a 3-step process of “firmware_pre_upgrade”, “firmware_check”, “firmware_upgrade” that’s required. I’ve copied the steps performed in the GUI (which works perfectly), but somehow I’m failing at the first step. I’ve had no success on both MTR-LNA7 and MTR-H5 devices. Can anybody spot where I’m going wrong?

# curl -v –insecure -b ‘token=E57352D2C3FABAD04FBDE961FED8FC’ https://192.168.2.1/api/command/firmware_pre_upgrade
* Expire in 0 ms for 6 (transfer 0x63e880)
* Trying 192.168.2.1…
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x63e880)
* Connected to 192.168.2.1 (192.168.2.1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: C=US; ST=Minnesota; L=Minneapolis; CN=ocg.example.com
* start date: Jan 27 19:54:22 2020 GMT
* expire date: Jan 24 19:54:23 2030 GMT
* issuer: C=US; ST=Minnesota; L=Minneapolis; CN=ocg.example.com
* SSL certificate verify result: self signed certificate (18), continuing anyway.
> GET /api/command/firmware_pre_upgrade HTTP/1.1
> Host: 192.168.2.1
> User-Agent: curl/7.64.0
> Accept: */*
> Cookie: token=E57352D2C3FABAD04FBDE961FED8FC
>
< HTTP/1.1 400 Bad Request
< Set-Cookie: token=E57352D2C3FABAD04FBDE961FED8FC; Path=/; Secure
< Cache-Control: no-cache
< Content-type: application/json
< Access-Control-Allow-Origin: *
< Content-Security-Policy: default-src ‘self’; script-src ‘unsafe-inline’ ‘unsafe-eval’ ‘self’; style-src ‘unsafe-inline’ https://fonts.googleapis.com ‘self’; font-src https://fonts.gstatic.com ‘self’; connect-src ‘self’; img-src ‘self’ data:
< X-Frame-Options: SAMEORIGIN
< X-XSS-Protection: 1; mode=block
< X-Content-Type-Options: nosniff
< Referrer-Policy: strict-origin-when-cross-origin
< Feature-Policy: accelerometer ‘none’; camera ‘none’; geolocation ‘none’; gyroscope ‘none’; payment ‘none’; usb ‘none’
< Strict-Transport-Security: max-age=31536000
< Content-Length: 74
< Date: Tue, 04 Feb 2020 11:16:00 GMT
<
{
“code” : 400,
“error” : “unknown command”,
“status” : “fail”
}
* Connection #0 to host 192.168.2.1 left intact

[Jeff Hatch]

Hello Satoshi,

By default curl does a GET. I believe that the commands are required to be a POST (ie. -X POST). Try a POST and see if that works.

Jeff

[Satoshi Manabe]

Ah, that was the problem. Though only the “firmware_check” command transfers the firmware file, all three commands must use POST.

Thanks for the help!

[Author]

Posts