meshtastic
[Bug]: CLI duck-types all values for `--set` irrespective of the field's type
Category
Serial, WiFi
Hardware
T-Beam
Firmware Version
2.3.4.ea61808
Description
From the CLI, I set the psk to something with a leading zero. Reboot the device, the router does not get a DHCP request. Checking the psk, the leading zero has been dropped.
Disabling wifi, connecting via Bluetooth, then setting the psk is successful, and the CLI now reports the leading 0.
Relevant log output
pok@CENTCOMP:~/Downloads$ meshtastic --set network.wifi_psk 0123456789
Connected to radio
Set network.wifi_psk to 0123456789
Writing modified preferences to device
pok@CENTCOMP:~/Downloads$ meshtastic --get network.wifi_psk
Connected to radio
network.wifi_psk: 123456789
Completed getting preferences
Python is interpreting this value as a number. You probably need to quote to have it treat this is as a string
Do you mean simply adding quotes around the psk in the cli command? If so, I get the same result.
pok@CENTCOMP:~/Downloads$ meshtastic --set network.wifi_psk "0987654321"
Connected to radio
Set network.wifi_psk to 0987654321
Writing modified preferences to device
pok@CENTCOMP:~/Downloads$ meshtastic --get network.wifi_psk
Connected to radio
network.wifi_psk: 987654321
Completed getting preferences
Yeah, I see the issue here. We'll need to update the code to be aware of the type of the field it's setting; right now it just blindly tries to convert to bytes (with 0x or base64: prefix), boolean (with t, true, yes, f, false, no), int, or float.
I just experienced this issue when trying to set the bluetooth PIN via the CLI.
In the web client for meshtastic: https://github.com/meshtastic/web/issues/222
They seemingly enforce no leading zeroes as a solution. Perhaps a loud error like "PIN with leading zero will not work" to mirror that can be a fix.
The pin in the protobufs is a number, so you can't have leading zeros in any client.
To elaborate, what I experienced on version 2.5.4:
meshtastic --set bluetooth.enabled true --set bluetooth.fixed_pin 011111 --set bluetooth.mode FIXED_PIN
Connected to radio
Set bluetooth.enabled to true
Set bluetooth.fixed_pin to 011111
Set bluetooth.mode to FIXED_PIN
Writing modified preferences to device
If I log into the meshtastic node (I can do this because I don't need to re-pair), the pin shown in the GUI is 11111, leading zero is dropped. If I were to attempt pairing using 011111 on the smartphone, it would fail.
It is the case that the leading zero is dropped, but this makes setting a leading-zero pin quite confusing from the CLI. The CLI should probably make it more clear what is happening, right now there is no indication what is happening. It can alternatively print a warning or refuse to write the leading-zero pin. So you are right @garthvh that the protocol can't support leading zeroes, but that should be made more obvious to the end user by way of the client.
This is possibly fixed in a newer CLI, but if so the issue should be closed. I can check that later.
If it hasn't been fixed, I can probably come up with a PR myself.
Yeah, it does probably still fall partly under this issue for sure. For both the bluetooth PIN and the wifi PSK, the CLI should be trying to parse each value according to the type of the field it goes into. The bluetooth PIN part has an extra part that's separate from this, which is the request that it do some sort of warning or feedback to indicate the 0 has been dropped for the bluetooth PIN (or any other numeric field).
As far as I know, no work has started on either thing, since I haven't had time to sit down with it yet.