Dear All,
I've been using the GTP-U kernel module to communicate with a P-GW.
Running Fedora 29, kernel 4.18.16-300.fc29.x86_64.
At high traffic levels through the GTP-U tunnel I see the performance
degrade as 100% CPU is consumed by a single ksoftirqd process.
It is running on a multi-cpu machine and as far as I can tell the load is
evenly spread across the cpus (ie either manually via smp_affinity, or even
irqbalance, checking /proc/interrupts so forth.).
Has anyone else experienced this?
Is there any particular area you could recommend I investigate to find the
root cause of this bottleneck, as i'm starting to scratch my head where to
look next...
Thanks in advance
Tony
---- FYI
modinfo gtp
filename:
/lib/modules/4.18.16-300.fc29.x86_64/kernel/drivers/net/gtp.ko.xz
alias: net-pf-16-proto-16-family-gtp
alias: rtnl-link-gtp
description: Interface driver for GTP encapsulated traffic
author: Harald Welte <hwelte(a)sysmocom.de>
license: GPL
depends: udp_tunnel
retpoline: Y
intree: Y
name: gtp
vermagic: 4.18.16-300.fc29.x86_64 SMP mod_unload
modinfo udp_tunnel
filename:
/lib/modules/4.18.16-300.fc29.x86_64/kernel/net/ipv4/udp_tunnel.ko.xz
license: GPL
depends:
retpoline: Y
intree: Y
name: udp_tunnel
vermagic: 4.18.16-300.fc29.x86_64 SMP mod_unload
Hi
Now I'm trying osmo-pcu on octasic-phy.
GPRS worked, but I want to get EGPRS.
I set 'gprs mode none' in openbsc.cfg and 'egprs only' in osmo-pcu.cfg.
And got next error: "Not accepting non-EGPRS phone in EGPRS-only mode".
As I found, it is like bug #3499.
What does this error depend on and how can it be fixed?
How can I test EGPRS?
Thanks,
Andrey Lavrukhin
Dear all
I am facting the following problems and hope you can help me:
- At present, I have two GGSN nodes(such as A and B), I also hava a sgsnemu node which is connected to GGSN-A and hold a PDP context, now I want to connect this PDP context to GGSN-B to simulate the handover of mobile devices between different base stations. How can I do it?
- And I I wonder if sgsnemu can generate “Update PDP Context Request” message.
Thanks and regards
Arthur
Hi!
Just in case not every subscriber here is following the osmocom.org RSS
feed: At http://osmocom.org/news/104 we have just announced a bunch of
new tagged versions of the Osmocom CNI (cellular network infrastructure)
software stack.
See the link above for all related details, and links to changelogs.
The "network:osmocom:latest" feed already contains builds for Debian 8 and 9,
as well as Ubuntu 16.04, 16.10, 17.04, 17.10 and 18.04. Raspbian 9 + Ubuntu 18.10
are currently building, see
https://build.opensuse.org/project/monitor/network:osmocom:latest
I'd like to thank everyone who has contributed in some way to those new
versions. That's primarily the great team of developers, but also everyone
helping with testing, bug reports, bug squashing, documentation, etc.
Happy hacking,
Harald
--
- Harald Welte <hwelte(a)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
Dear fellow Osmocom developers,
I'm a bit surprised to notice that not more people have signed up for
OsmoDevCon 2019. I guess it was mostly an oversight when the date was
originally announced, and not a lack of interest? ;)
All details about the event are available at the related wiki page at:
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2019
Please enter your name at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2019#Requested
in case you would like to attend. Registering early allows proper
planning. Thanks!
Looking forward to meeting old and new Osmocom developers in April 2019.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi,
I'm trying to build a simple node that would encap/decap between IP and GTP
in the user plane. For this I have been using gtp-link and gtp-tunnel tools
of the libgtpnl, but with no luck so far. Could anyone please review my
setup and let me know what I'm doing wrong?
Topology:
node1 - DUT, I would like to be able to send a ping from this node such
that it is encapsulated into GTP tunnel towards node2.
2 interfaces:
- ens6 - represents interface towards MS, has address 20.1.1.1/24
- ens7 - represents interface towards GGSN, has address 10.1.1.1/24
node2
Just a single interface towards node1, address 10.1.1.2/24
Test:
On node2, I'm following these steps:
- creating a GTP device:
# ./gtp-link add gtp-u
- adding a GTP tunnel:
# ./gtp-tunnel add gtp-u v1 20 10 20.1.1.1 10.1.1.2
# ./gtp-tunnel list
version 1 tei 20/10 ms_addr 20.1.1.1 sgsn_addr 10.1.1.2
- adding a route to an address representing APN to use the GTP device:
# ip route add 8.8.8.8 src 20.1.1.1 dev gtp-u
- Trying to ping 8.8.8.8
Result:
I was expecting to see ECMP packets to 8.8.8.8 to be sent out via ens7
towards node2 and encapsulated in GTP. However, I can only see that these
packets appear on the gtp-u interface, but are not forwarded. Looking at
interface stats on gtp-u, I can see that the ping hits "tx_error" counter.
Is there anything I'm missing here? Are any parameters wrong? Or am I
misunderstanding the function of the GTP-U kernel support entirely?
Any help would be appreciated.
Thanks,
Michael
hello,Please forgive my childishness,Can you tell me how to compile and install libgtpnl?thanks
I saw that you wrote the libgtpnl project on github, but there is no readme above.