Symptom

Position packets received on a private secondary channel (encrypted with a 256-bit AES key) display as "channel N" — where N is a raw numeric hash value (e.g., 39) — instead of the correct channel slot name. Text messages on the exact same channel decrypt and display correctly with the proper channel label.

Root Cause (Code Analysis)

The channel resolution paths differ between packet types:

• Text messages (TEXT_MESSAGE_APP): The dispatch path passes the decryption context (decryptedBy / decryptedChannelId) through to the message handler, so the channel is resolved from the context established during decryption rather than from the raw packet field.

• Position packets (POSITION_APP): processPositionMessageProtobuf reads meshPacket.channel directly. This field contains the raw LoRa XOR hash of the channel name + PSK, not the channel slot index. The POSITION_APP dispatch case in meshtasticManager.ts drops the decryption context before calling the position handler, unlike TEXT_MESSAGE_APP which passes it through.

The fix should make position packet processing resolve the channel using the same decryption context (decryptedBy / decryptedChannelId) that text message processing uses, rather than reading the raw meshPacket.channel hash.

Expected Behavior

Position packets should display the correct channel slot/name, consistent with how text messages on the same channel are displayed.

Reproduction Steps

1. Base node: Linux/portduino, connected via TCP
2. Portable node(s): Position reporting disabled on channels 0/1; full-precision position enabled on a private secondary channel (custom AES-256 key)
3. Observe incoming position packets in MeshMonitor — channel label shows raw hash (e.g., "channel 39") instead of the correct channel slot

Workaround

None currently. Sharing position on channel 0 bypasses the issue but compromises privacy by broadcasting position to all nodes regardless of channel membership.

Authored by NodeZero 0️⃣