[PATCH net-next] gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Sipos Csaba sipos.csaba at kvk.uni-obuda.hu
Tue May 10 21:30:19 UTC 2016


> We don't handle this from the kernel, this GTP-U echo request is
> passed up to userspace. The idea is to support any signaling message
> from userspace, only G-PDU messages are handled from the kernel
> itself. Openggsn has code to generate the Echo response for this.

I am not completely sure whats the reason behind it. A similar example would be to move the handling of SCTP heartbeat messages from the SCTP stack to lets say the MME entity.

Maybe I am misunderstanding something, but I really don't see what is the reason behind handling the echo requests in the GGSN instead of the gtp-u stack itself. Can someone please shed some light on this one?

Regards,
Csaba

----- Eredeti üzenet -----
Feladó: "Pablo Neira Ayuso" <pablo at netfilter.org>
Címzett: "Sipos Csaba" <sipos.csaba at kvk.uni-obuda.hu>
Másolatot kap: "Harald Welte" <laforge at gnumonks.org>, openbsc at lists.osmocom.org
Elküldött üzenetek: Kedd, 2016. Május 10. 22:11:11
Tárgy: Re: [PATCH net-next] gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)

On Tue, May 10, 2016 at 09:31:53PM +0200, Sipos Csaba wrote:
> Hi Pablo,
> 
> Thanks for the info!
> 
> Just went through the code, and wanted to ask if I am right that
> this implementation does not support GTP-U echo request/reply yet?
> 
> I am asking because according to the specs. this is an optional
> feature, but in practice there are quite a lot of ENB products that
> require a response to the GTP-U Echo Req. they send, otherwise they
> are not going to start forwarding any data on the GTP-U path. The
> reason for this is that in practice the ENB is always connected to
> more than one MME, and the only way for the ENB to know which SGW is
> available is to send GTP-U echo requests to check the availability
> of the service.

We don't handle this from the kernel, this GTP-U echo request is
passed up to userspace. The idea is to support any signaling message
from userspace, only G-PDU messages are handled from the kernel
itself. Openggsn has code to generate the Echo response for this.

> Just noticed that the link for libgtpnl is not working yet.

cgit is not working properly for some reason, but the repo can be
cloned via:

git clone git://git.osmocom.org/libgtpnl



More information about the OpenBSC mailing list