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> 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