Interface status info not sent if IMEI missing

[ghost]

Possible bug when monitoring modemmanager interfaces - When the IMEI is not found, because it is a required value, all attempts to send the rest of the monitoring data will fail. This results in the device not sending any charting status information about any interfaces, which is not the desired outcome. (Uptime, RTT and packet loss still come through).

The IMEI may not be readable at all times because ModemManager may be restarting, or the modem may be rebooting or crashed, or simply unused.

The error in response.txt is: "Invalid data in \"#/interfaces/0/mobile\", validator says:\n\n'imei' is a required property"

A workaround is to delete the queued logs that are missing IMEI from the /tmp/openwisp/monitoring directory, then restart openwisp-monitoring, but this results in lost data.

Opening it here rather than with the agent because the error looked to me like it came from the API.

Wed May  1 08:17:46 2024 daemon.err openwisp-monitoring[11960]: > POST //api/v1/monitoring/device/[redacted]/?key=[redacted]&time=23-01-2024_03:27:51.000000 HTTP/1.1
Wed May  1 08:17:46 2024 daemon.err openwisp-monitoring[11960]: > Host: mgmt.networkhoist.com
Wed May  1 08:17:46 2024 daemon.err openwisp-monitoring[11960]: > User-Agent: curl/7.83.1
Wed May  1 08:17:46 2024 daemon.err openwisp-monitoring[11960]: > Accept: */*
Wed May  1 08:17:46 2024 daemon.err openwisp-monitoring[11960]: > Content-Type: application/json
Wed May  1 08:17:46 2024 daemon.err openwisp-monitoring[11960]: > Content-Length: 13723
Wed May  1 08:17:46 2024 daemon.err openwisp-monitoring[11960]: >
Wed May  1 08:17:46 2024 daemon.err openwisp-monitoring[11960]: } [13723 bytes data]
Wed May  1 08:17:47 2024 daemon.err openwisp-monitoring[11960]: < HTTP/1.1 400 Bad Request
Wed May  1 08:17:47 2024 daemon.err openwisp-monitoring[11960]: < Server: nginx
Wed May  1 08:17:47 2024 daemon.err openwisp-monitoring[11960]: < Date: Tue, 30 Apr 2024 22:17:47 GMT
Wed May  1 08:17:47 2024 daemon.err openwisp-monitoring[11960]: < Content-Type: application/json
Wed May  1 08:17:47 2024 daemon.err openwisp-monitoring[11960]: < Content-Length: 93
Wed May  1 08:17:47 2024 daemon.err openwisp-monitoring[11960]: < Connection: keep-alive
Wed May  1 08:17:47 2024 daemon.err openwisp-monitoring[11960]: < Vary: Accept, Accept-Language, Cookie
Wed May  1 08:17:47 2024 daemon.err openwisp-monitoring[11960]: < Allow: GET, POST, HEAD, OPTIONS
Wed May  1 08:17:47 2024 daemon.err openwisp-monitoring[11960]: < X-Frame-Options: DENY
Wed May  1 08:17:47 2024 daemon.err openwisp-monitoring[11960]: < Content-Language: en-gb
Wed May  1 08:17:47 2024 daemon.err openwisp-monitoring[11960]: < X-Content-Type-Options: nosniff
Wed May  1 08:17:47 2024 daemon.err openwisp-monitoring[11960]: < Referrer-Policy: same-origin
Wed May  1 08:17:47 2024 daemon.err openwisp-monitoring[11960]: < X-XSS-Protection: 1; mode=block
Wed May  1 08:17:47 2024 daemon.err openwisp-monitoring[11960]: < X-Content-Type-Options: nosniff
Wed May  1 08:17:47 2024 daemon.err openwisp-monitoring[11960]: < Referrer-Policy: same-site
Wed May  1 08:17:47 2024 daemon.err openwisp-monitoring[11960]: < Content-Security-Policy: default-src http: https: data: blob: 'unsafe-inline'; script-src 'unsafe-eval' https: 'unsafe-inline' 'self'; frame-ancestors 'self'; connect-src https://mgmt.networkhoist.com wss: 'self'; worker-src https://mgmt.networkhoist.com blob: 'self';
Wed May  1 08:17:47 2024 daemon.err openwisp-monitoring[11960]: < Permissions-Policy: interest-cohort=()
Wed May  1 08:17:47 2024 daemon.err openwisp-monitoring[11960]: < Strict-Transport-Security: max-age=31536000
Wed May  1 08:17:47 2024 daemon.err openwisp-monitoring[11960]: <
Wed May  1 08:17:47 2024 daemon.err openwisp-monitoring[11960]: { [93 bytes data]
Wed May  1 08:17:47 2024 daemon.warn root: Data not sent successfully. Retrying in 32 seconds
Wed May  1 08:17:47 2024 daemon.err openwisp-monitoring[11960]: root: Data not sent successfully. Retrying in 32 seconds

[nemesifier]

@mips171 I've incurred recently in a case in which I needed to get the IMEI of a modem which didn't have a SIM inserted, I was getting it as the agent gets it, but it wasn't returning anything. So I figured out there's another way to get the IMEI from modem-manager even if the SIM is not present.

So in this case, why is the IMEI not present? Shouldn't the IMEI always be part of a mobile modem interface?

[ghost]

@nemesifier If there's no SIM inserted, ModemManager will put the modem into a failed state, and you lose a lot of basic functionality and information. A workaround may be to use qmicli (qmicli -p -d /dev/cdc-wdm0 --dms-get-ids), or mbimcli to query the modem directly. A couple drawbacks with that approach are 1) those utilities need to be installed (they're not included by default), 2) there's no structured output (json or key/value) so you have to parse raw output with regular expressions. There's a small risk that can break with each update.

Would it be possible to make IMEI optional?