From 6d7ef3ff1f39960dc2428aee6ec76262ac5ddfdc Mon Sep 17 00:00:00 2001 From: Kaj Schittecat Date: Wed, 19 Aug 2026 16:11:28 +0200 Subject: [PATCH] fix: a login that times out now names multi-byte path hashing (#278, #280) Two reports of remote management, telemetry and ping all failing against a repeater or room server while the same operations work from other MeshCore clients, with no error anywhere: "Logging in..." disappears and nothing happens. Multi-byte path hashing fails exactly like that. sendFloodScoped() stamps path_hash_mode + 1 bytes of repeater hash onto unicast floods, which is the login / status / telemetry / ack path specifically, while channel traffic takes a different overload. A repeater that predates the feature, or does not implement it, drops 2- and 3-byte-hash packets SILENTLY, so the request never arrives and nothing on either side reports a failure. randelreiss said outright he is running 3-byte hashes (#280). It defaults to 1 byte and is opt-in, so this is behaving as designed. What is not reasonable is that someone who turned it on has no way to connect that choice to "remote management stopped working" weeks later. The timeout already had the operator's attention and was spending it on password, server and clock; it now names the path-hash setting and where to change it when the setting is not on its default. Does not change any send behaviour. This is diagnosis, not a fix for the drop itself, and it is deliberately worded as a thing to try rather than a verdict: neither reporter has confirmed the cause yet. All 8 S3 boards build. Co-Authored-By: Claude Opus 5 --- src/ui-touch/UITask.cpp | 20 +++++++++++++++++--- 1 file changed, 17 insertions(+), 3 deletions(-) diff --git a/src/ui-touch/UITask.cpp b/src/ui-touch/UITask.cpp index 61dbf7e..058bb0f 100644 --- a/src/ui-touch/UITask.cpp +++ b/src/ui-touch/UITask.cpp @@ -15449,9 +15449,23 @@ static void loginWaitTimeoutCb(lv_timer_t* t) { time_t tt = (time_t)the_mesh.getRTCClock()->getCurrentTime(); struct tm tmv; if (localtime_r(&tt, &tmv)) strftime(when, sizeof when, "%H:%M %d %b", &tmv); - char msg[120]; - snprintf(msg, sizeof msg, TR("No reply. Check password, server,\nor device clock (device: %s)"), when); - g_lv.task->showAlert(msg, 4500); + char msg[160]; + // Multi-byte path hashing is the one setting that makes a login fail EXACTLY like + // this: a repeater that predates it, or does not implement it, silently drops 2- and + // 3-byte-hash packets, so the request never arrives and no error is ever generated + // anywhere. It is opt-in and defaults to 1 byte, but someone who turned it on has no + // way to connect that choice to "remote management stopped working" — reported twice + // (#278, #280), once explicitly while running 3-byte hashes. Name it here, where the + // operator is already looking, rather than leaving them to find it in Settings. + const uint8_t phm = the_mesh.getNodePrefs() ? the_mesh.getNodePrefs()->path_hash_mode : 0; + if (phm > 0) { + snprintf(msg, sizeof msg, + TR("No reply. Path hash is %u bytes;\nolder repeaters drop those.\nTry 1 byte (Settings > Radio & Mesh)"), + (unsigned)(phm + 1)); + } else { + snprintf(msg, sizeof msg, TR("No reply. Check password, server,\nor device clock (device: %s)"), when); + } + g_lv.task->showAlert(msg, 5000); } static void loginWaitArm(LoginWaitKind kind) { loginWaitCancel();