Hi All,
In current OAI implementation, we found that there are cases SPGW is out-of-sync with MME, because of the delete_session_request is not received by the SPGW because of some errors, however MME has cleared
the state of that session. Then when the UE re-attaches, a new create_session_request is sent to SPGW; and because we try to allocate the same IP for the same IMSI (local change), the SPGW will result out in trying to update an existing GTP tunnel.
According to
http://lxr.free-electrons.com/source/drivers/net/gtp.c#L937 and
https://github.com/RoadRunnr/osmo-ggsn/blob/master/libgtnl/src/gtp-genl.c#L73, the NLM_F_EXCL flag is used to prevent updating an existing tunnel. I’m is wondering what is the reason of preventing updating?
The correct repository for libgtnl is: http://git.osmocom.org/libgtpnl/, my github tree of osmo-ggsn is outdated and shouldn't be used.
While we are actively investigating sending delete_session_request properly, as temporary workaround, I’m thinking to recovery from the out-of-sync problem, we can allow the new GTP tunnel to overwrite the old one in libgtpnl. Your suggestions are welcomed.
Thanks.
It should be possible to update an existing PDP context as long as you don't change any of the hash keys. That would be GTP version, GTP socket, ms_addr, and i_tei.
The validation of those values for updating is a bit weak in the kernel. Currently, it would to possible change any of the hash keys without the hash being updated.
Adding gtp_update_tunnel to libgtpnl should be simple (but beware of the hash key changes).
A gtp_update_tunnel that supports changing any the hash keys would have to set the NLM_F_REPLACE flag. That is currently not supported by the kernel implementation and libgtnl is not setting that flag.
I found an old, untested, and most likely incomplete version of an update pdp implementation for the kernel in my repository at https://github.com/RoadRunnr/osmo-ggsn/commit/398199135a6009dcbd421d7a330a5af2d36dda8d
You are welcome to forward port, fix, test, and submit that to the kernel.
Regards
Andreas