You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
chore(protobufs): refresh pin to develop@6ceceae and honor rx_rssi explicit presence (#4466)
* chore(protobufs): refresh pin to develop@6ceceae and honor rx_rssi presence
Bumps the protobufs submodule from develop@ba16bfc to develop@6ceceae
(61 upstream commits). Still a develop preview: the newest upstream tag
is v2.7.26, no 2.8.x tag exists yet.
Protocol tables brought in line with the new pin:
- HardwareModel 141-143 (HELTEC_RC32 / RC52 / RCC6)
- PortNum.LORA_OTA_APP = 79, plus the normalize and name tables in
meshtasticProtobufService so a string-form portnum can't be dropped
- UA_868 labelled deprecated in the region picker (upstream marked the
enum value [deprecated = true]); still selectable so existing devices
round-trip
- DeviceMetadata.has_xeddsa surfaced through /api/admin/get-device-metadata
and the Admin Commands capabilities list. The route uses an explicit
allowlist, so the field would otherwise be silently dropped (#3923)
MeshPacket.rx_rssi gained explicit presence upstream (optional int32
rx_rssi = 12, firmware PR #11271). Verified against the new pin: an
absent field decodes to null, a genuine 0 dBm reading decodes to 0 and
is carried on the wire. Every `rxRssi !== 0` guard was therefore reading
a real 0 dBm reception as "no data".
The consequential site is hasRfReceptionMarkers(): a 2.8 node spoofing
our local node at point-blank range reports rx_rssi 0, no other RF
marker fires, and the packet was classified isGenuineLocalTx — rendered
as our own outgoing message. Now presence-based, with a regression test
for that case. Six node/telemetry RSSI sites and the {RSSI} announcement
token had the same pattern (cosmetic, not security).
rx_snr is deliberately unchanged: it keeps proto3 implicit presence, so 0
there is still indistinguishable from absent. The -128 sentinel handling
from #3590 stands. rx_time also became optional but needs no change —
plausibleRxTime()'s 2020-01-01 floor already subsumes presence.
No-op against 2.7 firmware, which never puts a 0 on the wire.
Refs #3548, #3923, #3854
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01L9NzRtqE8eSMS8tvAeodUB
* address review: null-guard script env RSSI, surface hasXeddsa for local node
Three items from the PR #4466 review, all verified against the code first.
1. scriptEnv.RSSI/SNR guarded only `undefined`. An absent rx_rssi decodes to
null under 2.8's explicit presence, so String(null) handed user scripts the
literal string "null" — truthy and non-empty — instead of omitting the var.
2. hasXeddsa was only surfaced for remote nodes. The original reasoning (that
the local-node branch has no real DeviceMetadata to read) was wrong: the
manager already captures hasWifi/hasEthernet/hasBluetooth from exactly that
message. hasXeddsa is now captured onto localNodeInfo alongside them and
returned by the local branch of /get-device-metadata, which is the common
case for a user checking their own device.
3. Added a {RSSI}/{SNR} presence test. The existing token tests in
meshtasticManager.autoack-templates.test.ts re-implement the logic inline
and would pass regardless of what production does, so this drives the real
replaceAcknowledgementTokens path instead. Verified non-vacuous: reverting
the guard to `!== 0` fails "renders a present rxRssi of 0 as 0, not N/A".
Full suite 13250 passed / 0 failed with PG+MySQL containers up. tsc clean,
lint:ci passes.
Refs #3548, #3923
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01L9NzRtqE8eSMS8tvAeodUB
---------
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
0 commit comments