Repository navigation
Fix repeater login failure after companion reboot and enforce ACL login timestamp updates - #3631
Open
radek-sixi wants to merge 1 commit into
Open
radek-sixi wants to merge 1 commit into
radek-sixi wants to merge 1 commit into
Conversation
…in timestamp updates
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #3482
Problem
Users reported in #3482 that rebooting a companion node (such as Heltec V4) after logging into a repeater prevents subsequent logins or post-login admin/status commands until the repeater itself is physically rebooted:
BaseChatMesh::bootstrapRTCfromContacts()):On ESP32 boards (
ESP32RTCClock::begin(), which restores_rtc_backup_timefromRTC_NOINIT_ATTR) or boards with an external I2C RTC (AutoDiscoverRTCClock::begin()), the RTC clock already holds the current time on boot. However,MyMesh::begin()then callsbootstrapRTCfromContacts(), which unconditionally callsgetRTCClock()->setCurrentTime(latest + 1)without checking whetherlatest >= getRTCClock()->getCurrentTime(). Because logging into a repeater and sending admin/status requests does not modify persisted contacts on flash,latest + 1is older than the timestamps already sent to the repeater before the reboot, stepping the companion's RTC backwards (and overwriting_rtc_backup_time).handleLoginReq/onAnonDataRecv):sender_timestamp <= client->last_timestamprejects the login attempt (Failed to login).data[0] == 0),client = acl.getClient(...)is non-NULL, which previously skipped theif (client == NULL)block entirely. As a result,handleLoginReqneither checkedsender_timestamp <= client->last_timestampnor updatedclient->last_timestampandclient->last_activity(and on Room Server also skipped updatingsync_since,pending_ack, andpush_failures). It returnedRESP_SERVER_LOGIN_OK(so the UI reported being logged in as admin), whileclient->last_timestampremained stuck at the pre-reboot value and causedonPeerDataRecv()to silently drop all subsequent status/clock-sync/CLI requests as replay attacks.Fix
BaseChatMesh::bootstrapRTCfromContacts(), only advance the RTC clock tolatest + 1whenlatest >= getRTCClock()->getCurrentTime().simple_repeater,simple_room_server, andsimple_sensor, validatesender_timestamp > client->last_timestampand updateclient->last_timestampandclient->last_activity(plus room sync state onsimple_room_server) on both ACL (blank-password) and password login paths.