Hi,<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">

</div>Thanks, I've cherry-picked all I could right now.<br>
<br>
I'll have to test the software activation related changes with my nanoBTS's and<br>
with the BS-11.  I expect to do this later today.<br></blockquote><div><br>Great !<br><br>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 :)<br>
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

As for the ebab9a9e (Differentiate paging success), I think this code<br>
needs to update 04_11.c and silent_call.c as well, i.e. all locations<br>
where PAGING_SUCCEEDED is is currently used.<br></blockquote><div><br>Mmm, I don't understand what you mean here.<br><br>in 04_11 & silent call, it's not the signal dispatch that's used but the call back specified when making the paging request.<br>
The advantage of the call back is that you can give contextual information and it's only called for that specific<br><br>It's true that for sms, we could just check every time a paging succeed if there are pending SMS ...<br>
But for silent_call & 04_08 MT calls I think the call back need to stay.<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">
> sylvain/encryption: The current state of my encryption support work. I<br>
> rebased it and used the db structure you pushed for encryption. Everything<br>
> but the last 3 patches are pre-work / preparation / fixes and are imho OK.<br>
> The last 3 patches are the real implementation and I also think they're in<br>
> pretty good shape. Tested and working here :) Limitations includes : No Kc<br>
> re-use & No MT encryption yet.<br>
<br>
</div>I disagree with removing the 'id' primary key for AuthTuples and AuthKeys.<br>
<br>
Without that id we have it very hard to remove a single authtuple from the<br>
database manually, since we would have to provide the subscriber_id and some<br>
BLOB to select only a single entry.  This is why I did not merge this particular<br>
commit.<br></blockquote><div><br>?<br>In both table, you have :<br><br>  subscriber_id NUMERIC UNIQUE NOT NULL,<br><br>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.<br>
 <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
All the others (minus the last three) inside the encryption branch should<br>
have been merged now.<br>
<br>
It would be great if you can rebase those last three commits and your<br>
encryption_testing branch on current master and continue testing.<br></blockquote><div><br>Sure.<br><br>Cheers,<br><br>    Sylvain<br><br></div></div>