OsmoGGSN succeeds OpenGGSN!

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)