Thanks, I've cherry-picked all I could right now.
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.
Great !
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 :)
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.
in 04_11 & silent call, it's not the signal dispatch that's used but the call back specified when making the paging request.
The advantage of the call back is that you can give contextual information and it's only called for that specific
It's true that for sms, we could just check every time a paging succeed if there are pending SMS ...
But for silent_call & 04_08 MT calls I think the call back need to stay.
> sylvain/encryption: The current state of my encryption support work. I
> rebased it and used the db structure you pushed for encryption. Everything
> but the last 3 patches are pre-work / preparation / fixes and are imho OK.
> The last 3 patches are the real implementation and I also think they're in
> pretty good shape. Tested and working here :) Limitations includes : No Kc
> re-use & No MT encryption yet.
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.
All the others (minus the last three) inside the encryption branch should
have been merged now.
It would be great if you can rebase those last three commits and your
encryption_testing branch on current master and continue testing.
Sure.
Cheers,
Sylvain