14 May
2024
14 May
'24
7:59 a.m.
On Tue, May 14, 2024 at 01:20:14AM +0200, Neels Hofmeyr wrote:
On Mon, May 13, 2024 at 09:05:26AM +0200, Harald Welte
wrote:
The idea was to have a named counter whose name doesn't get recycled, and thereby
there's
no chance of the race you described. A persistent one might also be an alternative, but
of course only in scenarios where the hNBs are a static set. I believe we have seen
cases
at other customerswhere the hNB comes back with a different identity every time it
connects,
so one would be leaking counters if they were persistent, as in reality every reconnect a
new
one would be allocated and all old ones would be stale.
--
- Harald Welte <laforge(a)gnumonks.org> https://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
IMHO yet another reason to give named counters a
try, as we discussed. They might have other problems,but if we don't try, we never
know.
Is your idea to use a named counter that remains persistent even if the hNodeB
disconnects, in order to avoid the race?