Hi Jiannan,

----- On Mar 27, 2017, at 7:16 AM, Jiannan Ouyang ouyangj@fb.com wrote:

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 | 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#L7... | https://github.com/RoadRunnr/osmo-ggsn/blob/master/libgtnl/src/gtp-genl.c#L7... ] , 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/398199135a6009dcbd421d7a330a5a...

You are welcome to forward port, fix, test, and submit that to the kernel.

Regards Andreas

Regards,

-Jiannan

Hi Jiannan,

On Mon, Mar 27, 2017 at 05:16:10AM +0000, Jiannan Ouyang wrote:

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#L7..., the NLM_F_EXCL flag is used to prevent updating an existing tunnel. I’m is wondering what is the reason of preventing updating?

As a minor side note: Please note the authoritative source for libgtpnl is at git.osmocom.org http://git.osmocom.org/libgtpnl/tree/src/gtp-genl.c

To me it's quite obvious that a function called "gtp_add_tunnel()" should only add a new tunnel and hence I think the current behavior is correct.

However, I guess you could simply submit a patch with "gtp_update_tunnel()" or "gtp_modify_tunnel()" which can modify an existing tunnel. The latter might probably be required anyway in other cases?