Similar to what we already have for struct sgsn_mme_ctx in
gtp_mme.{c,h}.
This is just the nth step of properly splitting different
protocol layers, data model, etc.
Change-Id: Iad1895f09e43e299df7bb126bf52fdb98268392e
Scenario:
1- For an unknwon reason, sgsn sends DeletePdpCtxReq on GTP towards GGSN.
2- GGSN answers with Error Indication to that pdp ctx which calls
gtp_freepdp()
3- gtp_freepdp() calls libgtp callback cb_delete_context() before freeing the
pointer, in osmo-sgsn callback points to cb_delete_context(), which
removes pctx->ggsn and tries to drop the pdp on the NS side by sending a
DeactPdpReq.
4- While waiting for DeactPdpAck, the MS/PCU sends a DeactPdpReq, and
code was unconditionalyl trying to release the gtp side without checking
if it was alreay released, using pctx->ggsn==NULL and crashing.
This is basically the same logic already in place in regular path
gsm48_rx_gsm_deact_pdp_ack.
Related: OS#4817
Change-Id: I02587a3dc812823d893fc00b904142b75fd190b9
It could happen that SGSN drops GTP side of a pdp ctx (pdp->lib=NULL)
while still maintaing the other side (to notify about the entire pdp ctx
being torn down). If a PdpActReq arrives during that time, we need to
account for that situation, otherwise osmo-sgsn crashes accessing
pdp->lib.
If no pdp->lib is found at that time, let's reject the request and
expect at some point later in time the entire pdp context will be
destroyed and reestablished.
Related: OS#4173
Change-Id: I6dd87557ebb26fdbd280504abde10d976acecf64
Pau Espin