sgsn: Don't assign a new P-TMSI if one is pending
Currently every time an RA Update Req or an Attach Req is processed, a
new P-TMSI is allocated. When an MS issues another of these messages
before it has completed the first procedure, old_ptmsi is replaced by
ptmsi (and thus lost) and ptmsi is replaced by the newly allocated
P-TMSI. This can confuse the gbproxy, which can loose track of the
logical link then. At least a Blackberry emits a double set of RA Upd
Req messages from time to time which may be just 20ms apart.
This patch adds a check whether mm->ptmsi or mm->old_ptmsi are set.
If both are set, the P-TMSI is not re-allocated. This is only the
case, when the Complete message has not been received yet, since that
message will reset old_ptmsi.
Sponsored-by: On-Waves ehf
diff --git a/openbsc/tests/sgsn/sgsn_test.ok b/openbsc/tests/sgsn/sgsn_test.ok
index d3b333f..6f6204f 100644
--- a/openbsc/tests/sgsn/sgsn_test.ok
+++ b/openbsc/tests/sgsn/sgsn_test.ok
@@ -10,4 +10,8 @@
- Routing Area Update Request (valid)
- Routing Area Update Request (invalid type)
- Routing Area Update Request (invalid CAP length)
+Testing P-TMSI allocation
+ - sgsn_alloc_ptmsi
+ - Repeated Attach Request
+ - Repeated RA Update Request
Done