Dear Harald, Sorry to spam the openbsc list with this, but if you (or someone) can confirm if the Sgsn-emu part of Osmo-GGSN utilizing the kernel GTP module or not, that would be lovely. FYI, I was not able to pass more than 280Mbit and the sgsn-emu process was maxing out a single core. Based on this I suspect that it does not use the kernel GTP module. I have seen some commits that indicates preparation work for this feature, but it is unclear at least to me, if this was finished or not. In the Osmo-GGSN.cfg example config I can see the config option for kernel GTP, but not in the sgsn-emu.cfg example. Regards, Csaba
Hi Csaba, On 12/22/22 15:00, Sipos Csaba wrote:
Dear Harald,
Sorry to spam the openbsc list with this, but if you (or someone) can confirm if the Sgsn-emu part of Osmo-GGSN utilizing the kernel GTP module or not, that would be lovely.
sgsnemu is not using the kernel module, only osmo-ggsn has support for it so far. See osmo-ggsn.git/./sgsnemu/sgsnemu.c line 1905 calling: """ if (tun_new((struct tun_t **)&tun, options.tun_dev_name, false, -1, -1)) """ See tun_new() function used by both osmo-ggsn and sgsnemu: """ int tun_new(struct tun_t **tun, const char *dev_name, bool use_kernel, int fd0, int fd1u) { """ So sgsnemu is passing use_kernel=false, which makes the lib skip gtp-kernel functions like gtp_kernel_create().
FYI, I was not able to pass more than 280Mbit and the sgsn-emu process was maxing out a single core. Based on this I suspect that it does not use the kernel GTP module. I have seen some commits that indicates preparation work for this feature, but it is unclear at least to me, if this was finished or not. In the Osmo-GGSN.cfg example config I can see the config option for kernel GTP, but not in the sgsn-emu.cfg example.
You could try passing use_kernel=true to tun_new(), and see how far you can get. Patches welcome. Regards, Pau -- - Pau Espin Pedrol <pespin@sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte
Hi Csaba and Pau, On Fri, Dec 23, 2022 at 06:38:55PM +0100, Pau Espin Pedrol wrote:
You could try passing use_kernel=true to tun_new(), and see how far you can get. Patches welcome.
The GTP kernel module needs to be told if it operates in SGSN or GGSN mode. grep for GTP_ROLE_SGSN in libgtpnl. I don't know all of the related functions off my head, but on the SGSN side you need to make sure to initialize the kernel GTP with GTP_ROLE_SGSN instead of GTP_ROLE_GGSN. -- - Harald Welte <laforge@gnumonks.org> https://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Hi Harald and Pau, The GTP_ROLE_SGSN part is set in gtp_new(), for both the sgsn-emu.c and the ggsn.c code. What I cant figure out is what to change in order for that to be passed to the GTP kernel module... Spent some time modifying the sgsnemu.c but the only thing I achieved was a segmentation fault... I am not even sure how can I distinguish which part is using the kernel GTP headers and which part is using the internal GTP implementation... Modifying the tun_new() function to set the use_kernel parameter to true is definitely not enough: Line 1905 (sgsnemu.c): if (tun_new((struct tun_t **)&tun, options.tun_dev_name, true, -1, -1)) { Regards, Csaba
participants (3)
-
Harald Welte -
Pau Espin Pedrol -
Sipos Csaba