fix: keep the full 5-byte OTA counter on increments (v3.6.23)

spNextCntr coerced the 40-bit replay counter with `>>> 0`, so any counter
above FFFFFFFF lost its top byte after an accepted send: the live
10000AAAC8 came back as 00000AAAC9, and spCntrSyncPreset then stored the
broken value in the card preset - the RAM/Explore flows (ramIncrementCntr,
which is correct) inherited it.

- spNextCntr: 40-bit arithmetic (`% 0x10000000000`, wrap at FFFFFFFFFF
  kept) instead of the 32-bit >>> 0 coercion plus slice(-10).
- spCntrAdjust (+/-): the same 40-bit wrap (an 11-digit value could be
  produced at the maximum).
- tests: 10000AAAC8 -> 10000AAAC9, separator handling, FFFFFFFFF7 ->
  FFFFFFFFF8, FFFFFFFFFFF -> 0000000000 wrap, out-of-range input clamps.

The server side (_increment_counter_hex, _ram_next_cntr, final_cntr) was
already exact.  653 frontend / 500 Python green; version 3.6.23;
sw simple-v296.

This commit is contained in:

Антон Трошин

2026-09-28 22:01:54 +03:00

parent 3c104f5685

commit 991be7353b

5 changed files with 17 additions and 7 deletions

									
										frontend/sw.js
									
		+1
		-1
	
												View File
												
				@@ -1,4 +1,4 @@

				const CACHE = 'simple-v295';

				const CACHE = 'simple-v296';

				const URLS = [

				  'index.html',

				  'help.html',