The subscriber cache would help in case:
* GPRS DETACH, GPRS ATTACH. In that case we might still
have some cached authentication tuples we avoid another
sendAuthenticationInfo request.
* After a detach the cache expiry would make sure to
eventually send a purgeMS to the HLR (which might be
ignored).
At the same time to make the cache work we will need to
make sure to start and stop timers. In case we don't
start we might accumulate subscribers. I am afraid that
the above two benefits do not outweight the complexity
of this implementation.
Currently old LLMEs and MM contexts that haven't been explicitly
detached or cancelled are not removed until another request with the
same IMSI is made. These stale entries may accumulate over time and
severely compromise the operation of the SGSN.
This patch implements age based LLME expiry, when the maximum age has
been reached, the corresponding MM context is cancelled. If such an MM
context doesn't exist, the LLME is unassigned directly.
The implementation works as follows.
- llme->age_timestamp is reset on each received PTP LLC message
- sgsn_llme_check_cb is invoked periodically (each 30s)
- sgsn_llme_check_cb sets the age_timestamp to the current time if
it has been reset
- sgsn_llme_check_cb computes the age and expires the LLME if
it exceeds gprs_max_time_to_idle()
Ticket: OW#1364
Sponsored-by: On-Waves ehf
[hfreyther: Fix typo in comment LMME -> LLME]
Set the expiry delay after the subscriber has been deleted (e.g. by
freeing the MM context). If cancelled, the subscriber will be deleted
immediately and no timeout will be set. If the expiry time is set to
SGSN_TIMEOUT_NEVER, no timer will be started and the subscriber entry
will be kept until it is cancelled.
The following VTY command is added to the sgsn node:
- subscriber-expiry-time <0-999999> set expiry time in seconds
- no subscriber-expiry-time set to SGSN_TIMEOUT_NEVER
The default is an expiry time of 0 seconds, which means that the
subscriber entries are wiped out immediately after an MM context is
destroyed.
Note that unused MM contexts are not expired yet. Therefore the
subscriber will only be expired after a successful MM detach.
Sponsored-by: On-Waves ehf
This flag is used to determine, whether the Update Location procedure
shall be invoked. This is currently only set, when the 'remote'
authorization policy is set. When the flag is set, sgsn_auth_update
will not never be called directly by sgsn_auth_request, if an Attach
Request procedure is pending, even if the remote connection fails for
some reason.
Sponsored-by: On-Waves ehf
Currently the flag 'authenticate' is managed per subscriber.
This patch replaces that flag by a global cfg.require_authentication
flag that enables/disables the use of the Auth & Ciph procedure for
every subscriber. The flag is set by the VTY, if and only if the
authorization policy is 'remote'.
The VTY command
- update-subscriber imsi IMSI insert authenticate <0-1>
is removed.
Sponsored-by: On-Waves ehf
This commit adds GSUP client configuration (via VTY), connection set
up, and real message sending.
The following configuration commands are added:
- gsup remote-ip A.B.C.D set server IP address
- gsup remote-port PORT set server TCP port
Ticket: OW#1338
Sponsored-by: On-Waves ehf
This commit adds a new authorization policy 'remote' and uses
the subscriber cache for authorization when this policy is being used.
Note that there is no remote backend implemented yet. After the
IMSI/IMEI have been acquired, a request would be sent to the remote
peer. The attach/auth-ciph procedure continues when authorization
info has been received from the peer. This means, that
gprs_subscr_update() must be called then to tell the GMM layer
that it can proceed. A later commit will add VTY commands to do this
manually.
Sponsored-by: On-Waves ehf
Currently the VTY 'auth-policy' command results in setting or clearing
the acl_enabled flag. This also enables the matching of the MCC/MNC
prefix of the IMSI.
This patch adds an additional policy 'acl-only' which disables the
MCC/MNC matching and relies on the ACL only.
Sponsored-by: On-Waves ehf
This adds a minimalistic ACL by which certain, individual roaming IMSIs
can be authorized to use the SGSN. So you can selectively bypass the
'MCC+MNC == first 5 digits of IMSI' checking for a couple of IMSIs
libosmogsm is a new library that is distributed in the libosmocore.
Now, openbsc depends on it. This patch gets openbsc with this
change.
This patch also rewrites all include path to the new
osmocom/[gsm|core]
Signed-off-by: Pablo Neira Ayuso <pablo@gnumonks.org>
sgsn_rx_sndcp_ud_ind() can no longer make the assumption that msgb_bcid() is
valid, as this is only true for an un-fragmented SN-PDU. So instead,
we now store the RAID in the SNDCP Entity and pass it as an explicit
argument to sgsn_rx_sndcp_ud_ind().
Using the code of this commit, it was possible to provision GPRS
services and access a website from a G1 phone (Qualcomm MSM7k baseband chipset)
using a nanoBTS, Osmo-SGSN and OpenGGSN.
There is still no fragment re-assembly in the uplink path yet,
despite the (untested) code present in the gprs_sndcp.c file
This only works for packets that are small enough to not need
fragmentation at the SNDCP layer (dns queries, ntp and the like).
It requires libgtp built from OpenGGSN dc3744fda045f9fca83de6881176987335a309a8
or later. Plain 0.90 will NOT work.
Using this version, I could see bi-directional traffic from various
phones going all the way through BTS, OsmoSGSN, OpenGGSN and being routed
to and from the real internet. Time to celebrate...
* store LLC SAPI as part of PDP ctx
* store NSEI + BVCI as part of MM ctx
* export gsm48_tx_gsm_act_pdp_acc() and call it from sgsn_libgtp.c
* create and use gsm48_tx_gsm_act_pdp_rej for error cases
* print SAPI as part of VTY show pdp
libgtp of the OpenGGSN project will allow us to speak the GTPv0/v1
protocol of the interface between SGSN and GGSN.
This commit includes code for the main libgtp integration (file
descriptor, select loop, timer) as well as code to encode/send
a CREATE PDP CONTEXT request.
Instead of continuing to add more and more functionality to the
bsc_hack binary, we should have the new SGSN code run as a separate
executable.
After this commit we now build a 'osmo_sgsn' executable, using its
own osmo_sgsn.cfg config file.
However, the SGSN is not yet functional, mainly due to the fact that
the BSSGP and GMM code are written with the assumption that there
is a msgb->trx->bts and the according 'sturct gsm_bts' data model
around - which clearly is no longer the case outside of bsc_hack.