Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
41 changes: 23 additions & 18 deletions src/server/meshtasticManager.ts
Original file line number Diff line number Diff line change
Expand Up @@ -4358,33 +4358,38 @@ class MeshtasticManager {
}
}

// Existing block — only runs for PKI-error-based mismatches, NOT our proactive detection
// Clear mismatch flag when keys now match (post-purge resolution)
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 Excellent improvement to the comment clarity. This clearly explains both resolution scenarios that the code now handles.

// or when a new key arrives (PKI-error-based resolution)
if (!newMismatchDetected) {
if (existingNode && existingNode.keyMismatchDetected) {
const oldKey = existingNode.publicKey;
const newKey = nodeData.publicKey;

if (oldKey !== newKey) {
// Key has changed - the mismatch is fixed!
// Key has changed - the mismatch is fixed via new key
logger.info(`🔐 Key mismatch RESOLVED for node ${nodeId} (${user.longName}) - received new key`);
nodeData.keyMismatchDetected = false;
nodeData.lastMeshReceivedKey = undefined;
// Don't clear keySecurityIssueDetails if there's a low-entropy issue
if (!isLowEntropy) {
nodeData.keySecurityIssueDetails = undefined;
}

// Clear the repair state and log success
databaseService.clearKeyRepairStateAsync(fromNum);
const nodeName = user.longName || user.shortName || nodeId;
databaseService.logKeyRepairAttemptAsync(fromNum, nodeName, 'fixed', true);
} else {
// Keys now match - the mismatch was fixed (e.g., device re-synced after purge)
logger.info(`🔐 Key mismatch RESOLVED for node ${nodeId} (${user.longName}) - keys now match`);
}

Comment on lines 4368 to 4375
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎯 Perfect fix for the core issue

This is the critical change that resolves #2349. The previous logic had a gap:

Before: Only cleared keyMismatchDetected when oldKey !== newKey (new key scenario)
After: Clears the flag for both scenarios - when a new key arrives AND when keys already match

The else branch handling oldKey === newKey is exactly what was missing. After a successful immediate purge + NodeInfo exchange, the device re-syncs and the keys match, but the old logic would skip clearing the flag entirely.

The solution correctly handles both resolution paths while maintaining appropriate logging for each case.

// Emit update to UI
dataEventEmitter.emitNodeUpdate(fromNum, {
keyMismatchDetected: false,
keySecurityIssueDetails: isLowEntropy ? nodeData.keySecurityIssueDetails : undefined
});
nodeData.keyMismatchDetected = false;
nodeData.lastMeshReceivedKey = undefined;
// Don't clear keySecurityIssueDetails if there's a low-entropy issue
if (!isLowEntropy) {
nodeData.keySecurityIssueDetails = undefined;
}

// Clear the repair state and log success
databaseService.clearKeyRepairStateAsync(fromNum);
const nodeName = user.longName || user.shortName || nodeId;
databaseService.logKeyRepairAttemptAsync(fromNum, nodeName, 'fixed', true);

// Emit update to UI
dataEventEmitter.emitNodeUpdate(fromNum, {
keyMismatchDetected: false,
keySecurityIssueDetails: isLowEntropy ? nodeData.keySecurityIssueDetails : undefined
});
}
Comment on lines +4376 to 4393
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good refactoring: Moving the common cleanup code outside the conditional ensures it runs for both resolution scenarios. This eliminates the duplication that would have been needed and ensures consistent state cleanup regardless of how the mismatch was resolved.

}
}
Expand Down
Loading