Second call on encrypted connection
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
participants (2)
-
Andreas Eversberg -
Holger Hans Peter Freyther