adam/meshview
1
0 Fork 0
mirror of https://github.com/pablorevilla-meshtastic/meshview.git synced 2026-10-30 18:51:57 +01:00
Code Issues 20 Packages Projects Releases Wiki Activity

Support Meshtastic one-byte PSK shorthand in mqtt.secondary_keys #65

New Issue
Closed
opened 2026-10-05 06:04:35 +02:00 by adam · 2 comments
adam commented 2026-10-05 06:04:35 +02:00
Owner
Copy link
Copy source

Meshview does not appear to support Meshtastic's standard one-byte PSK shorthand values, such as Ag==, when they are configured in mqtt.secondary_keys.

Meshtastic expands these shorthand PSKs internally to the corresponding 16-byte AES key. Meshview currently base64-decodes the configured value directly and uses the result as an AES key.

As a result:

[mqtt]
secondary_keys = Ag==

decodes to a single byte (0x02) instead of the expected AES-128 key.

Steps to reproduce

  1. Configure a Meshtastic channel with the PSK:

    Ag==

  2. Enable MQTT uplink for the channel.

  3. Configure Meshview with:

    [mqtt]
secondary_keys = Ag==

  4. Send a message on that channel.

  5. Observe that Meshview does not decode the packet.

  6. Replace the Meshview configuration with the expanded AES key:

    [mqtt]
secondary_keys = 1PG7OiApB1nwvP+rz05pAg==

  7. Restart Meshview and send another message.

  8. Observe that the packet is decoded successfully.

Expected behavior

Meshview should accept Meshtastic PSKs in their normal channel configuration representation.

For example:

secondary_keys = Ag==

should internally expand to:

1PG7OiApB1nwvP+rz05pAg==

before being passed to AES.

Existing AQ== behavior

The default AQ== PSK effectively works because Meshview already hardcodes its expanded AES key:

PRIMARY_KEY = base64.b64decode("1PG7OiApB1nwvP+rz05pAQ==")

This makes the behavior inconsistent: the default shorthand PSK works implicitly, while other Meshtastic shorthand PSKs do not work through secondary_keys.

Suggested fix

When parsing secondary_keys, detect Meshtastic one-byte PSKs and expand them using Meshtastic's standard PSK expansion logic before adding them to the decryption keyring.

It would also be useful to validate decoded key lengths and log a clear configuration error for invalid AES keys.

Meshview does not appear to support Meshtastic's standard one-byte PSK shorthand values, such as `Ag==`, when they are configured in `mqtt.secondary_keys`. Meshtastic expands these shorthand PSKs internally to the corresponding 16-byte AES key. Meshview currently base64-decodes the configured value directly and uses the result as an AES key. As a result: ```ini [mqtt] secondary_keys = Ag== ``` decodes to a single byte (`0x02`) instead of the expected AES-128 key. ## Steps to reproduce 1. Configure a Meshtastic channel with the PSK: ```text Ag== ``` 2. Enable MQTT uplink for the channel. 3. Configure Meshview with: ```ini [mqtt] secondary_keys = Ag== ``` 4. Send a message on that channel. 5. Observe that Meshview does not decode the packet. 6. Replace the Meshview configuration with the expanded AES key: ```ini [mqtt] secondary_keys = 1PG7OiApB1nwvP+rz05pAg== ``` 7. Restart Meshview and send another message. 8. Observe that the packet is decoded successfully. ## Expected behavior Meshview should accept Meshtastic PSKs in their normal channel configuration representation. For example: ```ini secondary_keys = Ag== ``` should internally expand to: ```text 1PG7OiApB1nwvP+rz05pAg== ``` before being passed to AES. ## Existing `AQ==` behavior The default `AQ==` PSK effectively works because Meshview already hardcodes its expanded AES key: ```python PRIMARY_KEY = base64.b64decode("1PG7OiApB1nwvP+rz05pAQ==") ``` This makes the behavior inconsistent: the default shorthand PSK works implicitly, while other Meshtastic shorthand PSKs do not work through `secondary_keys`. ## Suggested fix When parsing `secondary_keys`, detect Meshtastic one-byte PSKs and expand them using Meshtastic's standard PSK expansion logic before adding them to the decryption keyring. It would also be useful to validate decoded key lengths and log a clear configuration error for invalid AES keys. <!-- github-sync-id:5234333930 -->
adam closed this issue 2026-10-05 06:04:35 +02:00
adam commented 2026-10-05 06:04:36 +02:00
Author
Owner
Copy link
Copy source

Just released version 3.0.8 with all your fixes. Thank you!!

Just released version 3.0.8 with all your fixes. Thank you!! <!-- github-comment-id:5608024913 -->
adam commented 2026-10-05 06:04:36 +02:00
Author
Owner
Copy link
Copy source

Thank you! Just pulled it at Meshtastic Greece Network meshview! Looking good so far

Thank you! Just pulled it at [Meshtastic Greece Network meshview](https://meshview.m-powered.gr/)! Looking good so far <!-- github-comment-id:5608265664 -->
Sign in to join this conversation.
No Branch/Tag Specified
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
adam (Adam Wojcieszonek)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: adam/meshview#65