hi,
while trying to do a second call (hold the first, dial another number), i found out that there is no acknowledge for a CM service request, when encyption is enabled. the attached patch will fix it.
regards,
andreas
On Wed, Jul 10, 2013 at 09:18:19AM +0200, Andreas Eversberg wrote:
hi,
while trying to do a second call (hold the first, dial another number), i found out that there is no acknowledge for a CM service request, when encyption is enabled. the attached patch will fix it.
looks reasonable,
do you think it makes sense to add a case for GSM_SECURITY_ALREADY in _gsm0408_authorize_sec_cb? It certainly wouldn't hurt?
Holger Hans Peter Freyther wrote:
do you think it makes sense to add a case for GSM_SECURITY_ALREADY GSM_SECURITY_ALREADY in _gsm0408_authorize_sec_cb? It certainly wouldn't hurt?
i think not, because GSM_SECURITY_ALREADY cannot happen at location updating, where the security is performed the first time, because location updating is always the first request from a mobile. (if location area changed.) but if i am wrong, it would be mandatory.
On Wed, Jul 10, 2013 at 07:02:59PM +0200, Andreas Eversberg wrote:
i think not, because GSM_SECURITY_ALREADY cannot happen at location updating, where the security is performed the first time, because location updating is always the first request from a mobile. (if location area changed.) but if i am wrong, it would be mandatory.
Well,
it should not happen (as the periodic LU timer should be stopped), but imagine the 'unsigned int' would be an 'enum', we would now have a warning about unhandled cases (e.g. not building a partition over the enum) and it is good practice to avoid it.
a.) If it can happen support it b.) If it can not happen, use LOGL_ERROR so we potentially notice if it does happen and then we can re-consider.
cheers holger
Holger Hans Peter Freyther wrote:
it should not happen (as the periodic LU timer should be stopped), but imagine the 'unsigned int' would be an 'enum', we would now have a warning about unhandled cases (e.g. not building a partition over the enum) and it is good practice to avoid it.
there is a "default:", which will not cause any warning, since it handles all unhandled cases above.
a.) If it can happen support it b.) If it can not happen, use LOGL_ERROR so we potentially notice if it does happen and then we can re-consider.
LOGL_ERROR makes sense. maybe it tuns out that there is a call setup that caused a cell re-selection and a location updating is sent right afterwards.
Holger Hans Peter Freyther wrote:
b.) If it can not happen, use LOGL_ERROR so we potentially notice if it does happen and then we can re-consider.
hi holger,
the new patch will give an error message, if location updating is received after CM service request, but it finishes location updating in case of this unexpected behavior.
regards,
andreas