gengetopt by default picks the program name from PACKAGE (autotools),
which is osmo-ggsn and is obviously wrong in case of sgsnemu.
After this patch, "sgsnemu --help" no longer shows "osmo-ggsn" but
"sgsnemu" at the top of the help text.
Change-Id: Ifabc2435a503ef71aa5a002ca46833f329068b37
This will replace the manual additions to cmdline.[ch] with
auto-generated code from gengetopt. We need to fix-up the RAT Type in
sgsnemu.c as the manually-added code diverged from what gengetopt
generates.
Change-Id: Ia687e13d5cec1655a57078a767d2123aa022842c
In commit 3a4c67b4bf we introduced the
--norecovery command line option, but this was apparently done by
manually editing the C source code rather than adding it to the .ggo
and letting gengetopt do its magic. Let's fix this up.
Change-Id: I1698280a699b17cea65651c3736ef149aba7e432
In commit 41af5691ef we introduced the
--rai command line options, but this was apparently done by
manually editing the C source code rather than adding it to the .ggo
and letting gengetopt do its magic. Let's fix this up.
Change-Id: Iaab404c3bcfc0c3943764f6616763f4f407d5644
In commit 944dce3e66 we introduced various
command line options, but this was apparently done by manually editing
the C source code rather than adding it to the .ggo and letting
gengetopt do its magic. Let's fix this up.
Change-Id: Ib8e7ef1cad5fc4423a1a4af628950aa93a4e073a
In commit 11a398fbc3 we introduced the
--qose{1,2,3,4} command line options, but this was apparently done by
manually editing the C source code rather than adding it to the .ggo
and letting gengetopt do its magic. Let's fix this up.
Change-Id: I4cd827a96ac17f6eb9f824342f195727426d0e20
It seems like modern gengetopt no longer supports 'unsigned int'
argument types, and we need to use 'int' instead. tested with 2.22.6
Change-Id: I34ca86cb3cc482400a7c4b3bf77c8668aaef562e
In case the GGSN is behind some kind of DNAT, the public GTP-C and
GTP-U IP addresses as exposed inside the GTP payload information
elements are different from the (internal, behind-nat) IP address
to which it listens/binds.
Change-Id: I548c9011c9abd66d46f963b1def61575f3dabb89
in Change-Id I68ae49a765828fa681054c68bf7f5e74dbe48ad2 we introduced
a new struct member that breks ABI and API.
Change-Id: Ie631880155513b1b78d1e9dd473dc5dc50e05943
Osmocom has maintained this program since about 7 years now, while
the original author / copyright holder has completely disappeared.
With the introduction of Osmocom-style CTRL and VTY interfaces,
the way how the program is used and configured has substantially
changed. In order to avoid confusion in terms of configuration file
format etc, let's rename it to OsmoGGSN.
Change-Id: I2da30f7d4828e185bfac1a4e2d8414b01cbe4f9d
* README.Solaris is obsolete and related code has been removed
* NEWS file was unmaintained for more than a decade, remove it
* Remove "Performance" chapter about 550MHz Athlon
* gengetopt is no longer needed for ggsn
* remove compilation/installation instructions horribly out of date
* command line syntax of 'ggsn' program has changed
Change-Id: I45d627911503c7b733cae6a1396ca4d69a9994db
We haven nobody maintaining this platform, let's remove it.
In fact, only Linux and FreeBSD are part of the jenkins build tests,
so even Apple/MacOS is up for disposal. However, as it's more
popular, let's keep the code.
Change-Id: Id6b8179259bacade52c39f96e688f828eff164ac
This is required once one wants to support multiple GSNs in a single
application.
WARNING: This breaks ABI compatibility, LIBVERSION must be adjusted
Change-Id: I68ae49a765828fa681054c68bf7f5e74dbe48ad2
The control interface handle never belonged into libgtp in the first
place. Commit 727417dd28 should not
have added this to the shared library (used by sgsnemu, osmo-sgsn, ...),
but to some private state of the GGSN.
Introducing a private context pointer at the same location will keep
ABI compatibilty.
Change-Id: I4f17516dae3e04114564828a3e5f6e2ea54212a5
This allows the application to attach some private state to the tun
device, such as the context from which it was created/allocated
Change-Id: Ief43b9b5fab5830fa8e28362c795f88f0b4d353b
During IPv6 support implementation, helper function pco_contains_proto
was added which contains an error: It is only capable of finding first
protocol correctly, and as a consequence, in my setup DNS servers where not
sent back to the SGSN/MS, resulting in phone being able to connect to
IPs but not to domain names which required DNS resolution.
The condition in the while loop is also changed to match the increment
of the variable inside the loop to make it easier to understand at first
glance.
Fixes: 1ae98777d9
Change-Id: Icc2e6716c33d78d3c3e000f529806228d8aa155e
This updates the debian changelog to 0.94 and adds some logic
to debian/rulres which fixes the version of the libgtp.pc file
built as part of our OBS builds (used to be UNKNOWN since
commit 23eea1d132)
Change-Id: I883feaef35ff5ffd1b22fb255b7c36112b4a8f3b
When a peer GSN receives a GPDU for an unknown PDP context, it sends
a GTP Error Indication. This Error Indication should be used to
delete the offending PDP context locally.
In GTPv1, the Error Indication contains some mandatory IEs using
which we can look up the PDP context and delete it.
The existing code only dealt with GTPv0 Error Indications which lack
those IEs and use the TEI in the header instead.
Change-Id: I3e843f9ef1d6fd7868cc992e083c0891d16b6da9
Closes: OS#2426
For some reason Max' commits introducing the CTRL/trap interface
about one year ago didn't convert the IMSI to its actual textual
representation before usign it in the CTRL interface.
Let's clean that up by properly interpreting the IMSI.
Change-Id: I8b20d2e47a29de266d93a7ddd5e6877f7e346a63
As we can now have PDP contexts with IPv6 user IP payload,
it is useful to extend the TUN related code to be able to
configure the tun device IPv6 address + prefix length
Change-Id: I899d21e52d02e0b8384af29ddd489ff19c8f2cf6
There's a bit of trickery with the ip_pool and it's "lengty=8" IPv6
prefix handling, let's make sure we don't accidentially call any
support functions with addresses of wrong length.
Change-Id: I444c190bdcd18780344e1f0dad4faf3bcf9da5a5
In IPv6, DNS server information is not passed along as IPCP6 like
in IPv5 with IPCP. The reason is that IPCP6 (for PPP) doesn't
support passing DNS server information. Rather, the relevant RFCs
indicate DHCPv6 should be used even over point-to-point links.
3GPP decided to avoid DHCPv6 dependency for stateless autoconfiguration
(the only mandatory IPv6 configuration mechanism) and added some new
non-PPP-style PCO information elements ("containers") which can among
other things inform a MS about IPV6 DNS servers.
That same mechanism can also be used to inform the MS about IPv4 DNS
servers, so for IPv4 there are now two competing mechanisms: IPCP and
the new "native" PCO container. With this patch, we support both
for IPv4.
Change-Id: I21499afd61def8c925f7838bde76f34d28214b56
The 3GPP specs are quite strange when it comes to how an IPv6 address
or rather prefix is assigned to an IPv6 PDP context. The designated
method for allocating the IPv6 address via the PDP EUA (End User
Address) Information Element in the GTP signalling plane is *not*
used to allocate the address/prefix. Instead, the EUA is used to
allocate an "interface identifier" to the MS, which it the uses
to derive its link-local source address to send a router solicitation.
The GGSN subsequently answers witha router advertisement, advertising
a single/64 prefix, whihcthe MS then uses to generate it's real IPv6
source address for subsequent communication.
Change-Id: Icddf7d30e01d76a4784bcef5787b36f52f703a9f
Harald Welte
Max
Pau Espin