Hi Sylvain,
On Sun, Jan 03, 2010 at 11:22:25AM +0100, Sylvain Munaut wrote:
> I'll have to test the software activation
related changes with my nanoBTS's
> and with the BS-11. I expect to do this later today.
this still hasn't happened, I suppose I'll get around doing it today.
What about the rrlp branch ? They are only changes to
rrlp-ephemeris and the
.gitignore patch is especially useful to ignore the output of asn1c (without
that git detects thousands of new files if you have built it :)
I have merged it right now. Feel free to commit directly to the master branch
as long as you only touch rrlp-ephemeris code. After all, it's your code!
I just didn't want direct commit's to openbsc in the master branch. Thanks.
As for the
ebab9a9e (Differentiate paging success), I think this code
needs to update 04_11.c and silent_call.c as well, i.e. all locations
where PAGING_SUCCEEDED is is currently used.
Mmm, I don't understand what you mean here.
It was my misunderstanding, sorry. I've applied it now.
I disagree
with removing the 'id' primary key for AuthTuples and AuthKeys.
Without that id we have it very hard to remove a single authtuple from the
database manually, since we would have to provide the subscriber_id and
some BLOB to select only a single entry. This is why I did not merge this
particular commit.
?
In both table, you have :
subscriber_id NUMERIC UNIQUE NOT NULL,
since there is a UNIQUE, there can't be two entries for the same subscriber
and so you can just delete by specifying the subscriber_id.
That's wrong then. subscriber_id should be unique for AuthInfo, but not for
AuthTuples. We can (and should!) have multiple auth tuples for a subscriber
and also think of a way how we can cycle through them (or randomly select one
of them each time we need one)
Also, if subscriber_id is UNIQUE in AuthInfo, then we can remove the id there,
like you proposed.
--
- Harald Welte <laforge(a)gnumonks.org>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)