gprs: Fix typo in the comment
sgsn: Cancel pending timer in sgsn_mm_ctx_free

Currently the timer is not stopped before the MM context is freed
which can lead to failure if sgsn_mm_ctx_free is called while timer
protected procedures are active.

This patch add code to cancel the timer if necessary from within
sgsn_mm_ctx_free.

Ticket: OW#1322
Sponsored-by: On-Waves ehf
sgsn: Delete PDP contexts properly

Currently the PDP contexts are hard freed (via sgsn_pdp_ctx_free)
at some places in gprs_gmm.c on the reception of a Detach Req and on
re-use of an IMSI that is already associated with an MM context. This
can lead to segfaults when there is a pending request or a data
indication at libgtp.

This patch add a new function sgsn_pdp_ctx_terminate that de-associates
the PTP context from the MM context, deactivates SNDCP, sets pdp->mm
to NULL and then calls sgsn_delete_pdp_ctx. sgsn_libgtp is updated to
check for pdp->mm being non-NULL before dereferencing it. The
sgsn_pdp_ctx_terminate function will be called for each PDP context of
an MM context before this context is going to be deleted via
sgsn_mm_ctx_free. To ensure, that the ctx->llme (which is accessed
during the deactivation of SNDCP) remains valid, the call to
gprs_llgmm_assign is moved after the call to sgsn_mm_ctx_free. The
handling of re-used IMSIs is changed to mimic the processing of a
Detach Req.

Addresses:
<0002> gprs_gmm.c:654 MM(/f6b31ab0) Deleting old MM Context for same
    IMSI p_tmsi_old=0xc6f19134
<000f> gprs_sgsn.c:259 PDP freeing PDP context that still has a
    libgtp handle attached to it, this shouldn't happen!
[...]
SEGFAULT

Ticket: OW#1311
Sponsored-by: On-Waves ehf
sgsn: Send detach(re-attach) instead of gmm status if TLLI unknown

The osmo-sgsn sends Status messages (or nothing in case of non
GMM/GSM) when the TLLI is unknown. This prevents the MS from
reconnecting.

This patch adds the initiation of an MT detach procedure to force a
re-attach to set up a valid LLE context if an LLE or an MM context
cannot be found. Since this can also be triggered by non-GMM SAPI
messages, a GPRS application callback sgsn_force_reattach_oldmsg is
added which in turn calls the GMM layer to generate the GSM 04.08
specific messages.

Note that the MS can be left in REGISTERED state after initially
wanting to detach itself, since it will receive a Detach Req
(re-attach) when sending a DEACT PDP CTX REQ after the SGSN or
gbproxy (P-TMSI patching enabled) has been restarted. This same
behaviour has been observed with another SGSN.

Sponsored-by: On-Waves ehf
gbproxy/test: Add expect_msg checks to test_gbproxy_keep_info

This patch adds assertions to check the LLC/GMM message received from
the gbproxy by the test framework within the function
test_gbproxy_keep_info.

It also fixes the source address of the DETACH ACC messages.

Sponsored-by: On-Waves ehf
gbproxy/test: Add test case for repeated and otherwise bad messages

This adds a test case to check gbproxy's behaviour when processing
two subsequent but identical Attach Accept messages.

Ticket: OW#1322
Sponsored-by: On-Waves ehf
gbproxy: Fix P-TMSI generation for repeated Attach Accept messages

Currently, when P-TMSI patching is enabled, a new BSS P-TMSI is
generated for each Attach Accept. So two duplicated, subsequent
Attach Accept messages will be mapped to different BSS side P-TMSI.
Because the last one will replace former ones in the link_info
struct, the MS will fail to access the SGSN if it uses the former
P-TMSI to derive the new TLLI.

This patch checks the SGSN P-TMSI already assigned to the link_info
and only generates a new BSS P-TMSI on mismatch (or if the BSS P-TMSI
hasn't been set yet).

Ticket: OW#1322
Sponsored-by: On-Waves ehf
gbproxy: Patch BSSGP P-TMSI in PAGING PS messages

Currently the P-TMSI IE in PAGING_PS is not patched.

This commit adds code to patch BSSGP P-TMSI IE in
gbproxy_patch_bssgp independently from the P-TMSI patching at the LLC
layer. It also extends gbproxy_update_link_state_dl to use the IMSI
to find the link_info if the TLLI is not present in the message.

Note that the spec (GSM 08.18, 7.2) requires to use of the P-TMSI
instead of the IMSI to select the MS if that IE is available.
Nevertheless as long as the IMSI is always present in downlink BSSGP
messages and as long as the optional P-TMSI refers to the same MS
(which is the case currently), this is not an issue.

Sponsored-by: On-Waves ehf