OsmoGGSN succeeds OpenGGSN!
laforge at gnumonks.org
Wed Sep 6 10:04:28 UTC 2017
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,
* multiple GGSN instances bound to different GTP IP addresses
* multiple APNs within each GGSN, each with different Address Pools and
* 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?)
* 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
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
- Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
More information about the osmocom-net-gprs