Age | Commit message (Collapse) | Author | Files | Lines |
|
Change-Id: I8375ba42dd47d7ccd9ce9290767d6f8653a23b94
|
|
To accomodate the ip.access nano3G without having to recompile, make the
RAB Assignment's Transport Layer Address IE's format configurable, in both
osmo-msc and osmo-sgsn.
The long term perspective is to somehow detect which address encoding a given
3G cell prefers, but for the time being just configure it globally and set each
ue_conn_ctx to the global setting upon creation.
Add VTY command to iu_vty.c, with args passed to iu_vty_init() to insert
at an arbitrary VTY node, so that it can be used both for osmo-msc and
osmo-sgsn. Add generic iu_vty_config_write() to write out the config.
Call iu_vty_init() from msc_vty_init(); msc_vty_init() is in libmsc,
hence linking of osmo-msc now needs libiu to come after libmsc, so move
that further down.
Change-Id: I93728314742b327336f3fb6de98e6457f687e1f9
|
|
The future perspective is to remember the preferred RAB Transport Layer Address
encoding for each 3G cell that is connected, so store per UE conn instead of
globally hardcoding.
Add rab_assign_addr_enc member to ue_conn_ctx. Thus the iu_rab_act_cs() and
iu_rab_act_ps() functions no longer need the explicit use_x213_nsap argument.
Add include/openbsc/common.h in order to define the enum nsap_addr_enc, in a
separate file to be able to easily include it in all of libmsc, libiu and
gprs/* without creating include cycles.
Set the rab_assign_addr_enc when an MM ctx is created for iu, and whenever the
ue_conn_ctx for an Iu MM ctx is updated. This looks a bit clumsy so far, the
hope is that there will be a nice way to setup the ue_conn_ctx prior to that.
Change-Id: I49bb5736df7bdfdd55d3e7b74ee559595cfd2f7d
|
|
Change-Id: Ia7e74087d56996104b6d3935b1cf12166ff67f3a
|
|
Change-Id: I4e34dcd5e48c4dd73d63c6f865298ee7d9c864be
|
|
Postfix the ran type to clarify the purpose.
Because of the new support of the Iu ran type, there are 2 functions to allocate a mm ctx.
For Iu it's sgsn_mm_ctx_alloc_iu(). For gb it should be named in the same way.
Change-Id: Ic49009e8c20c12308855e1409c09004698c79b95
|
|
GMM is the right term. MM state is already occupied.
Change-Id: I9cfdcf921e4ebd14a5e7ce7489ec4ce5d1f5515f
|
|
It is one of these changes that should have never worked but did
for a long time. Only recently a corrupted GTP message was seen.
The code in ccd2312d10e14747e8a4d26d8f72b052ffcfc282 tried to
solve the right problem but was deeply flawed.
* Make the code operate on the copied message and not the original
one that is deleted by the underlaying layers on return
* Add an out variable to determine if the msgb should be deleted
and assume that by default it will be deleted.
Change-Id: I564526e7cde2b8a2f0ce900492cd38fc23c176a7
|
|
in gprs_gmm.c:gsm48_rx_gmm_ra_upd_req the variable reject_cause
is not initalized, which is ok, since it gets initalized before
the jump into the "rejected" path. However, the compiler still
throws a warning. This commit fixes the problem by preinitalizing
the reject_cause to GMM_CAUSE_PROTO_ERR_UNSPEC
Change-Id: I84cffb631e4cad3d4748512b47e3876208f53727
|
|
Shorten some code and make obvious to the reader that the string copy is done
in a safe way.
Change-Id: I900726cf06d34128db22a3d3d911ee0d1423b1bd
|
|
Change-Id: I19b0001650979bf7f1832f04f9fd5a26beb577d0
|
|
For new MM contexts, the ra_id was correctly obtained from the ue_ctx, but in
case an MM ctx is re-used and the ra_id changed, the new ra_id was not copied
to the MM context; instead, the ra_id was overwritten with uninitialized data.
Always initialize the local ra_id variable from the ue_ctx->ra_id for Iu
connections; it is used further below to update the ctx->ra_id.
For the case of a brand new Iu MM ctx, the ctx->ra_id then gets initialized a
second time. We could technically drop the init in sgsn_mm_ctx_alloc_iu(), but
it doesn't hurt either way.
Fixes: CID#57936
Change-Id: Ia06458758362e76925690b1757d8ced95e9609e4
|
|
Timer T3395 starts at the transmission of Deactivate PDP request using
pdpctx_timer_start but there was no corresponding stop function.
The timer is stopped when Deactivate PDP Context Accept is received.
This according to 3gpp spec reference 24.008 section 6.1.3.4.2.
Change-Id: I825c0a47d39e784dd1b8251f564609262530a5c6
|
|
This commit corrects the Logging macro used in pdpctx_timer_start.
Change-Id: Id4e3a7fb934ed82af8096fda9ddd3f4550e05844
|
|
Change-Id: I9385655872c4dcf46aa1d18bcc47b84aba2f34f7
|
|
Change-Id: I47b73a40cbdda6b7c31fb2767f74f9f93d84056b
|
|
This is where IuPS will redirect GTP-U endpoints in a subsequent commit.
Also add comprehensive logging of pmm_state transitions.
Change-Id: I7c2cd1abc1805659b01dffffff31c49fe5161086
|
|
Change-Id: I0df0f3d88085939eb617405e2013ad164eed477b
|
|
Iu needs to page to transfer data in PMM-IDLE state.
Change-Id: Id37778cb9a0328a21c8e8246998ecdb43dd687d8
|
|
Change-Id: I2ea2089895f8a8e125ef39d9bef70dafb2b1ce69
|
|
Change-Id: Ib935de22d23a15f449927840d4d59497ce22abbd
|
|
Change-Id: I0b2593c2df13b79eb36975b0d302e31cfdf8bb09
|
|
DEVELOPMENT HACK: Our current HLR does not support 3G authentication tokens. A
new HLR/VLR implementation is being developed. Until it is ready and actual
milenage authentication is properly supported, we are hardcoding a fixed Ki and
use 2G auth.
Change-Id: Ieca45960fa941a3a706c6e479b04b9f2ef89d860
|
|
Change-Id: Iad65ca9b77c3166d4df9a58af527e6aef7e589ee
|
|
In gsm48_gmm_sendmsg(), redirect to iu_tx() for both cases of MM context
present or not.
In gsm48_rx_gmm_att_req(), compose an MM context marked as Iu for messages
coming in from a ue_conn_ctx (passed in msg->dst). Also make sure cid is
initialized to avoid introducing a compiler warning.
In gsm48_rx_gmm_ra_upd_req(), look up an Iu MM context based on the presence of
the ue_conn_ctx in msg->dst.
In sgsn-test, add libiu and libasn1c, libosmo-sigtran, libosmo-ranap, which are
now needed for an --enable-iu build.
Change-Id: Ia47ffbfa6fa0f5a0cd76a379c57ef42faa0d80e3
|
|
Add main Iu entry points for IuPS:
* gsm0408_gprs_rcvmsg_iu()
* sgsn_ranap_iu_event()
* sgsn_ranap_rab_ass_resp()
Add main MM context management for IuPS:
* sgsn_mm_ctx_by_ue_ctx()
* sgsn_mm_ctx_alloc_iu()
Call iu_init() from sgsn_main.c.
Add asn_debug impl ("extern" from libasn1c).
Initialize asn_debug VTY command (iu_vty_init()).
osmo-sgsn build: add libiu and libasn1c, libosmo-sigtran, libosmo-ranap
Change-Id: I469ae6ca9ef254d04ee0d2d79bdd65aebcd027b5
|
|
For Iu connections, msg->dst will point to the ue_conn_ctx, and we need to make
sure to keep msg->dst intact when copying from/to msgb and from/to MM context.
Change-Id: I90c7ca6c3655d447aaca958e0086ae6ce6f6045a
|
|
Bit 4 is reserved in 3GPP TS 04.08 so exclude it from the type.
In 3GPP TS 24.008 it indicates if a follow-on request is pending by the
MS, but only in Iu mode. According to the spec it is not required to
react to that request with a follow-on proceed so this field can be
ignored for now.
See 3GPP TS 24.008 Ch. 4.4:
"Unless it has specific permission from the network (follow-on proceed)
the mobile station side should await the release of the RR connection
used for a MM specific procedure before a new MM specific procedure or
MM connection establishment is started."
as well as Ch. 4.4.4.6:
"If the network wishes to prolong the RR connection to allow the mobile
station to initiate MM connection establishment (for example if the
mobile station has indicated in the LOCATION UPDATING REQUEST that it
has a follow-on request pending) the network shall send "follow on
proceed" in the LOCATION UPDATING ACCEPT and start timer T3255."
Change-Id: If1dff960c406060e257dafc54132687ffc42ad8f
|
|
Change-Id: I54a3bc518bc38e38b78f6e9ea3705e4fbd5ffb98
|
|
Changing the test to allow still allocated block from the rate
counters.
Change-Id: Ie30e4c3084ee3a138d6b39bb5000234ac814e65f
|
|
The timer is already scheduled by gsm48_tx_gsm_deact_pdp_req().
Change-Id: I8203b939d2196f87b11c0f3b2b0ff481e572835c
|
|
According to 3GPP TS 24.008 § 4.7.1.2 some GMM frames are not supposed
to be ciphered. Propagate information about the necessity for
encryption between MM <-> LLC to ensure only proper frames are
encrypted/decrypted/dropped.
Change-Id: I0358905e60d1b182f75caec81bfcc72bbbbb2aa1
Related: OS#1582
|
|
It is already functional enough to allow testing with real
phones. However, note - there are several limitations in the current
implementation:
* only default value for IOV-UI is supported at the moment
* AUTN-based key material is not supported
Related: OS#1582
Change-Id: I8900b906693496e4e6b35be5a86937c58039ed9e
|
|
Move GEA key from TLLI assignment into separate function.
Change-Id: I8a0bc907072dc19cd9535a28b5252dc0f05357cc
Related: OS#1582
|
|
The A&C reference number specified in 3GPP TS 24.008 § 10.5.5.19
identifies particular request sent by network with the related response
sent by MS. The value transparently copied from request to response by
MS: the spec do not specify what exactly should be in there so we use
rand() to decrease chance for collisions.
Note: variable named 'rand' clashes with standard function rand() so it
was renamed.
Change-Id: I3638821a9b4a0532b28dbbb50faa30c4082579f6
Related: OS#1582
|
|
Change-Id: Ia4df145ab03ebcaad70a13601cff60c488a5de54
Related: OS#1582
|
|
Add missing mmctx NULL check in gsm0408_rcv_gmm(). gsm48_tx_gmm_status() would
dereference mmctx without checking, so we can't call it if mmctx == NULL.
Follows up on recent e98ba82d2b07c835:
"gprs_gmm.c: Don't try to de-reference NULL mmctx".
Change-Id: If59efbde86c76ffe91a0b33be87273783a2a4a02
|
|
Change-Id: I213d21b9ddbf19e56269defcc6aa65aca4947140
|
|
In case the GMM message did not arrive over a Gb interface, there is no
LLME (and thus the associated pointer is NULL). Don't try to perform
operations on a NULL LLME.
Change-Id: If7f24161cd2826f8ee238d4bc1090adf555cea4e
|
|
Soem of the operations we perform in the GMM layer are specific to the
GPRS/EDGE radio access network and its Gb interface. Let's make them
conditional to that in preparation of supporting an Iu interface.
Change-Id: I3efb7c5087afe8e2331ec17bd9fac5029f4bee6c
|
|
There was a comment in the code that certain GMM messages require a
valid mmctx pointer. However, nothing actually checked if that pointer
was in fact non-NULL. We plainly crashed if a MS would send us the
wrong message in the wrong state.
Original patch by Harald Welte, but it broke message validity checking,
resulting in sgsn_test failure. This re-implements the NULL check in a
different way, as explained by in-code comment.
Change-Id: I7908de65bec91599f7042549b832cbbd7ae5a9a8
|
|
This is the entry point for GMM from Gb. We will create a new one
for Iu, so let's be explicit rather than implicit.
Change-Id: I93c074bf99db041117c0dc03dc8255879845a875
|
|
Explicitly mark those sgsn_mm_ctx members that apply for Gb mode and (upcoming)
Iu mode, respectively.
Add some comments in sgsn_mm_ctx.
Change-Id: Ife9b02549f284e2547f16117cf43d7a36948fc4b
Tweaked-By: Neels Hofmeyr <nhofmeyr@sysmocom.de>
|
|
This requres the corresponding commit in libosmocore.
|
|
Rather than having a 'private' structure for kc, sres and rand, we
now finally (with 4 years delay) use osmo_auth_vector from libosmogsm,
which encapsulates authentication vectors that can be either GSM
triplets or UMTS quintuples or a combination of both.
gsm_auth_tuple becomes a wrapper around osmo_auth_vector, adding
use_count and key_seq to it.
key_seq is no longer initialized inside gprs_gsup_messages.c, as there
is no CKSN / key_seq inside the message anyway. If a usre of the code
needs key_seq, they need to manage it themselves.
|
|
libosmocore recently added inline functions to relieve callers from applying
bitmasks and bit shifts to access the transaction id of a GSM 04.08 header.
Apply these functions.
|
|
Replace hardcoded protocol discriminator and message type bitmasks with
function calls recently introduced in libosmocore.
Note that the release 98 bitmasks slightly differ from the release 99 bitmasks.
This patch uses the "default" gsm48_hdr_msg_type invocation, thus it depends on
libosmocore whether 98 or 99 bitmasks are used.
In some places, use of the bitmask was erratic. Fix these implicitly by
employing the bitmask functions:
* silent_call.c: silent_call_reroute(): add missing bitmask for MM.
* bsc_msg_filter.c: bsc_msg_filter_initial(): RR vs. MM messages.
* osmo_bsc_filter.c: bsc_find_msc() and bsc_scan_bts_msg(): RR vs. MM
messages.
* bsc_nat_rewrite.c: bsc_nat_rewrite_msg(): SMS vs. CC messages.
* bsc_ussd.c: no bitmask is applicable for the message types used here.
* gb_proxy.c: gbproxy_imsi_acquisition(): missing bit mask for pdisc.
In gprs_gb_parse.c: gprs_gb_parse_dtap(), add a log notice for unexpected
message types.
|
|
If an MM context cannot be found based on BBSGP info and a RA UPDATE
REQUEST is received, try to find an MM context with an P-TMSI from
which the TLLI could have been derived. This also checks, whether the
routing area matches.
This is similar to the old behaviour removed by the commits
"sgsn: Only look at TLLIs in sgsn_mm_ctx_by_tlli" and
"sgsn: Remove tlli_foreign2local", except that this will only
be done for RA UPDATE REQUESTs now.
Sponsored-by: On-Waves ehf
|
|
Currently the MM context is just overwritten by a call to
sgsn_mm_ctx_by_tlli(msgb_tlli(msg), &old_ra_id) even if it
has already been found by using the BSSGP info. With the changes
made to sgsn_mm_ctx_by_tlli this will never find a MM context if
the routing area has changed. If the routing area has not changed,
the mmctx has already been found if it exists.
This commit splits searching for an MM context (if it hasn't been
found already) from checking, whether a found one can really be
used. The actual search is removed, so that the MS will be forced to
restart the attach procedure, which is less efficient but safe.
Sponsored-by: On-Waves ehf
|
|
At Rhizomatica we see that some GSM 04.08 messages are leaked and
have no other indication if that is Call Control, SMS or something
else.
|