Hello,
I was trying to clone git repository from http://git.osmocom.org/libgtpnl/but got an error :
remote: An error occurred while reading CGI reply (no response received)fatal: unable to access 'http://git.osmocom.org/libgtpnl/': The requested URL returned error: 502
I can't open http://git.osmocom.org/libgtpnl/ in browser either. It said 'An error occurred while reading CGI reply (no response received)'.
Is my url to git repository wrong ?
Thanks,
WangSS
Hi,
I want to ask two questions.
I dont know if you remember, but I have been trying to backport GTP to 3.18
kernel. I fixed all the errors, it works. However there is one issue that
I'm not sure how to implement it correctly.
--->There is one private flag called IFF_NO_QUEUE and it has no
implemetation in 3.18 kernel, I just set it to an unused bit in the private
flag field. I would like to get your opinion on this.
*include/linux/netdevice.h ->(*@IFF_NO_QUEUE: device can run without qdisc
attached*)
The other thing I would like to ask is that I cannot reach the git
repository for libgtpnl. Could you please check it?
Thanks,
Fırat
Hello,
I compiled osmo-ggsn and was trying to run it as per the instructions
present on https://osmocom.org/projects/openggsn/wiki/Kernel_GTP
But when I try to start osmo-ggsn *using -g or --gtp-linux*, it says
invalid option.
Please let me know how to start it using gtp kernel.
I have modprobed gtp.ko successfully.
[root@localhost osmo-ggsn]# lsmod |grep gtp
gtp 28672 0
ip6_udp_tunnel 16384 1 gtp
udp_tunnel 16384 1 gtp
[root@localhost examples]# osmo-ggsn --gtp-linux -c osmo-ggsn.cfg -d
*osmo-ggsn: unrecognized option '--gtp-linux'*
<0002> ggsn.c:159 APN(internet): Starting
<0002> ggsn.c:162 APN(internet): Opening TUN device tun4
<0002> ggsn.c:167 APN(internet): Opened TUN device tun4
<0002> ggsn.c:178 APN(internet): Setting tun IP address 176.16.222.0/24
<0002> ggsn.c:224 APN(internet): Creating IPv4 pool 176.16.222.0/24
<0002> ggsn.c:245 APN(internet): Successfully started
<0002> ggsn.c:159 APN(inet6): Starting
<0002> ggsn.c:162 APN(inet6): Opening TUN device tun6
<0002> ggsn.c:167 APN(inet6): Opened TUN device tun6
<0002> ggsn.c:190 APN(inet6): Setting tun IPv6 address 2001:780:44:2000::/56
<0002> ggsn.c:236 APN(inet6): Creating IPv6 pool 2001:780:44:2000::/56
<0002> ggsn.c:245 APN(inet6): Successfully started
<0002> ggsn.c:159 APN(inet46): Starting
<0002> ggsn.c:162 APN(inet46): Opening TUN device tun46
<0002> ggsn.c:167 APN(inet46): Opened TUN device tun46
<0002> ggsn.c:178 APN(inet46): Setting tun IP address 176.16.46.0/24
<0002> ggsn.c:190 APN(inet46): Setting tun IPv6 address
2001:780:44:2100::/56
<0002> ggsn.c:224 APN(inet46): Creating IPv4 pool 176.16.46.0/24
<0002> ggsn.c:236 APN(inet46): Creating IPv6 pool 2001:780:44:2100::/56
<0002> ggsn.c:245 APN(inet46): Successfully started
<0002> ggsn.c:687 GGSN(ggsn0): Starting GGSN
<000d> gtp.c:705 GTP: gtp_newgsn() started at 192.168.11.128
<0002> ggsn.c:724 GGSN(ggsn0): Successfully started
<0005> telnet_interface.c:102 telnet at 127.0.0.1 4260
<000c> control_if.c:788 CTRL at 127.0.0.1 4257
Also, I tried executing gtp-tunnel list but it gives empty output.
[root@localhost tools]# ./gtp-tunnel list
[root@localhost tools]#
Please help.
Thanks,
Ravi
<https://osmocom.org/projects/openggsn/wiki/Kernel_GTP>
Hi all,
12 years after OpenGGSN was seemingly abandoned by its original creators,
and 7 years after Osmocom adopted it, it is time for a significant change:
OpenGGSN is becoming a first-class Osmocom citizen called OsmoGGSN.
We had already taken some baby-steps in the past by introduction of a
CTRL interface as well as the use of libosmocore logging. However, my
recent patches introducing a VTY interface and changing the
configuration file format from the 'gengetopt' style to libosmovty based
change the look+feel of the program significantly that it is a good
point to rename.
After all, if command-line arguments and config file syntax are
changing, documentation will also need to change and it becomes
confusing to users to understand that depending on the version the
documentation is correct or incorrect.
So from today on,
* osmo-ggsn is available from http://git.osmocom.org/osmo-ggsn/
* osmocom:nightly packages will build both openggsn + osmo-ggsn
* osmocom:nitb-split:nightly packages will only build osmo-ggsn
* redmine still at http://osmocom.org/projects/openggsn due to
permanent redmine project naming...
The introduction of the VTY interface comes with many new possibilities,
such as
* multiple GGSN instances bound to different GTP IP addresses
* multiple APNs within each GGSN, each with different Address Pools and
tun-devices
* sophisticated logging configuration (syslog, file, stdout, telnet)
What's still missing:
* re-integrate kernel GTP-U support
* create OsmoGGSN user manual in osmo-gsm-manuals.git
* migrate TTCN-3 test execution on jenkins to osmo-ggsn
* perl/python script to convert old config file to new config file
format (any volunteers?)
Roadmap:
* IPv6 transport plane support (outer IP layer surrounding GTP/UDP)
* improved logging (ensure context is always included)
* libgtp: migration of kernel GTP-U support into libgtp (not just ggsn)
* libgtp: make PDP context hash table part of the 'gsn' structure
* once all expected ABI/API changes are done, rename libgtp to
libosmo-gtp
In terms of maintenance, I don't want to continue to maintain OpenGGSN
for much longer. We'll keep it around for some time and merge important
security and/or bug fixes, but I won't accept new feature patches into
OpenGGSN.
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)
Hello,
I am a newbie in this area so please pardon me if these are dumb or
covered questions!
I am looking for a GTP stack that implements GTP-C version 2. Is this
supported in open grps or is there a plan for that? If not, what stack
(preferably open source) is recommended?
Thanks,
Tom
Hi.
With the ongoing split of OpenBSC into per-project repository, I wonder if we could
do the same to OpenGGSN and split libgtp into separate repository?
Rationale:
* would simplify docs for newcomers (it's not obvious that openggsn have to be built
ahead of OsmoSGSN because of libgtp)
* simplify release process (we can release libgtp independently of OpenGGSN, makes it
easier to automate too)
While at it and considering recent IPv6 support (and related config changes) it might
be also good idea to rename it to OsmoGGSN (and libosmo-gtp?) to clearly mark the
breaking point.
What do you think?
--
Max Suraev <msuraev(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 Osmocom community,
from August 26th 06:54 UTC through August 31st 06:22 UTC our Osmocom.org
redmine could not send any e-mails. This was due to a configuration
file syntax error introduced by me, my apologies.
If you rely on redmine e-mail notifications to the issues you have
subscribed to, please double-check as related notifications during that
interval were unfortunately lost.
Best regards,
Harald
p.s.: The reason for the config change was to enable e-mail
notifications from jenkins.osmocom.org (which it now has, if you want to
configure e.g. post-build notification actions).
--
- 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)
Dear all,
I've been busy all day (and night) implementing IPv6 PDP context support
in OpenGGSN. The related code is currently in gerrit for review,
you can also use the 'laforge/ipv6' branch of openggsn.git
In terms of configuration, all you need to do is to specify IPv6 address
+ prefix as the 'net'. If you don't specify a 'dynip' config option,
it will automatically use the network/prefix specified in 'net'.
My minimalistic example config file for testing looks like this:
debug
fg
listen 127.0.0.6
net 2001:780:44:2000:0:0:0:0/120
Which means it is listening for GTP on IPv4 (no IPv6 on the GTP side
supported), and will create a tun device with the stated IPv6 address
and a /120 netmask. Your GGSN is 2001:780:44:2000::1, and UEs will get
addresses allocated from 2001:780:44:2000::2 onwards.
It's important to configure your UE to actually request and IPv6 PDP
context. If no v4/v6 is specified in the request, it will default to
IPv4. If IPv4 is requested while having a v6 pool configured, OpenGGSN
will reject the PDP Context Creation due to not being able to serve a v4
PDP context.
I don't have immediate plans for supporting IPv6 on the outer
(transport) layer for now. I also have no plans to support v4 and v6
from a single OpenGGSN at this time. It's quite easy to run two
different OpenGGSN instances in parallel, on two different IPv4
addresses for the GTP side, and then use OsmoSGSN's PDP context routing
to those different GGSNs. This way it is possible to have a v4 APN and
a v6 APN without having to do any additional development right now.
Architecturally, having multiple IP pools (and some for v4 and some for
v6) is definitely possible, and should actually be easy. We just need
to switch to a configuration mechanism that supports something like
this, such as libosmovty. Once we have a VTY based configuration, it
should be simple to operate multiple IP pools or multiple virtual APNs
on one OpenGGSN.
WARNING: The Linux Kernel GTP code does *not* support IPv6 user payload
at this point. So if you want IPv6, you will need to use regular,
old-fashioned userspace GTP-U in OpenGGSN for now. Controbutions are
always welcome, of course!
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)
This patch series augmented the existing GTP module to support flow
based GTP tunneling and modified the openvswitch datapath to support the
GTP vport type.
A flow based GTP net device enables that,
1) on the RX path, the outer (IP/UDP/GTP) header information could to be
stored in the metadata_dst struct, and embedded into the skb.
2) on the TX path, packets are encapsulated following instructions in
the metadata_dst field of the skb.
A flow based GTP net device can be integrated with Open vSwitch, which
allows SDN controllers to program GTP tunnels via Open vSwitch.
Open vSwitch changes are based on patch set
[PATCH] Add GTP vport based on upstream datapath
Example usage with OVS:
ovs-vsctl add-port br0 gtp-vport -- set interface gtp-vport \
ofport_request=2 type=gtp option:remote_ip=flow options:key=flow
ovs-ofctl add-flow br0
"in_port=2,tun_src=192.168.60.141,tun_id=123, \
actions=set_field:02:00:00:00:00:00->eth_src, \
set_field:ff:ff:ff:ff:ff:ff->eth_dst,LOCAL"
ovs-ofctl add-flow br0 \
"in_port=LOCAL,actions=set_tunnel:888, \
set_field:192.168.60.141->tun_dst,2"
arp -s 10.1.1.122 02:00:00:00:00:00
Jiannan Ouyang (3):
gtp: refactor to support flow-based gtp encap and decap
gtp: Support creating flow-based gtp net_device
openvswitch: Add GPRS Tunnel Protocol (GTP) vport support
drivers/net/gtp.c | 375 ++++++++++++++++++++++++++++++++-------
include/net/gtp.h | 8 +
include/uapi/linux/openvswitch.h | 1 +
net/openvswitch/Kconfig | 10 ++
net/openvswitch/Makefile | 1 +
net/openvswitch/vport-gtp.c | 144 +++++++++++++++
6 files changed, 475 insertions(+), 64 deletions(-)
create mode 100644 net/openvswitch/vport-gtp.c
--
2.9.3
