mirror of
https://github.com/MarekZegare4/MeshCore-Solo.git
synced 2026-09-14 23:26:38 +00:00
meshcore-solo-site's new cross-visitor relay bridge (Phase 3) needs a way
to read a sim instance's live freq/bw/sf/cr so a WebSocket relay server
can fan traffic out only to other visitors tuned to the same params,
mirroring real LoRa channel isolation. Added sim_radio_get_params()
(examples/companion_radio/main.cpp), reading NodePrefs directly -- the
real live source of truth, since SimRadio::setParams() has always been a
complete no-op (accepts and discards its arguments). Out-params via
pointer, same buffer-pointer idiom sim_radio_poll_tx() already uses;
build_wasm.sh needed HEAPF32/HEAP32 added to EXPORTED_RUNTIME_METHODS so
JS can read them back.
While testing the relay bridge with two independent browser contexts, hit
a real bug: sim_instance_salt() (SimInstance.h) is a pure function of the
simInstanceTag STRING ('hero'/'B'/'R'), so it's only useful for telling
apart same-tab instances -- it's identical for two genuinely different
visitors who both boot a 'hero' instance. Combined with SimRNG::begin()'s
other seed ingredients -- time(NULL) (1-second resolution) and a WASM
heap pointer (no ASLR inside the sandbox, so it's fully deterministic
across independent boots of the same binary) -- two different visitors
landing on the same wall-clock second reliably generated byte-identical
Ed25519 identities (confirmed: two fresh browser contexts launched
together produced provably identical advert packets end to end).
Fixed by mixing in real crypto.getRandomValues()-sourced entropy from the
host page (new sim_instance_entropy(), read the same way simInstanceTag
already is) into both SimRNG::begin() and the twin seeding pattern in
SimRadio::getRngSeed(). Applies to every sim instance uniformly (hero/B/R
all get proper per-session entropy now), not just the new relay path --
strictly an improvement with no compatibility concern, since identity
generation only ever runs once per fresh/empty IDBFS.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018iubftDmKNWmkNnhJRz8UH
33 lines
1.4 KiB
C++
33 lines
1.4 KiB
C++
#pragma once
|
|
|
|
#include <Utils.h>
|
|
#include <cstdlib>
|
|
#include <ctime>
|
|
#include "SimInstance.h"
|
|
|
|
// mesh::RNG implementation for the native sim build. Not cryptographically
|
|
// strong (rand() under the hood) -- fine for a terminal demo. Phase 3 mixes
|
|
// in sim_instance_salt() so that two module instances of the SAME compiled
|
|
// binary (the browser's two companion_radio instances) can't end up with
|
|
// the same seed -- see SimInstance.h for why that's a real risk here, not
|
|
// a hypothetical one. sim_instance_entropy() (also SimInstance.h) mixes in
|
|
// real crypto.getRandomValues()-sourced entropy from the host page on top
|
|
// of that -- salt alone is a pure function of the tag string ('hero'/'B'/
|
|
// 'R'), so it's identical across two genuinely different browser tabs that
|
|
// both boot a 'hero' instance; combined with time(NULL)'s 1-second
|
|
// resolution and a WASM heap pointer that's fully deterministic (no ASLR
|
|
// inside the sandbox) across independent boots, two different real visitors
|
|
// landing on the same wall-clock second used to get byte-identical
|
|
// generated identities without this.
|
|
class SimRNG : public mesh::RNG {
|
|
public:
|
|
SimRNG() { }
|
|
void begin() {
|
|
unsigned seed = (unsigned)time(NULL) ^ (unsigned)(uintptr_t)this ^ sim_instance_salt() ^ sim_instance_entropy();
|
|
srand(seed);
|
|
}
|
|
void random(uint8_t* dest, size_t sz) override {
|
|
for (size_t i = 0; i < sz; i++) dest[i] = (uint8_t)rand();
|
|
}
|
|
};
|