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
With this commit the already existing XID mechanism has been
modified to suit the needs for the upcomming SNDCP-XID patches.
This commit should not break anything since it does not alter
the current behaviour (incoming XID is still just echoed, on
GMM-Reset a basic XID message is still echoed)
Change-Id: I65b9d625e72d3d61c99abdc7041773701d694d52
For some reason gprs_sndcp.h is located in src/gprs. This commit moves
gprs_sndcp.h to include/openbsc and fixes the include path in
gprs_sndcp.c and gprs_sndcp_vty.c
Change-Id: If4e4f1252c81d7907c1b4d738c982bb172b128c9
The lle-xid encoder/decoder is needed to encode and decode llc
xid parameter messages. We need this to exchange sndcp-parameters
(SNDCP-XID) and also simple parameters such as encryption IOVs
Change-Id: Ia06e4cb08bf9b48c2a4682606d1b1a91d19a9d37
new counters are:
llc.dl_bytes
llc.ul_bytes
llc.dl_packets
llc.ul_packets
The ip payload bytes are waiting for payload compression
because those data are known then.
Change-Id: I068376d35e84283cb98523cd3097a12c55cdb709
f9f4387686 introduced a check for ran_type,
which potentially leaves reject_cause unset. Fix that.
Change-Id: I0220841ff796f949d00a1415d46b54a3eacc9493
Split out generation and application of GEA gamma into separate function
which can be used for both encryption and decryption.
Change-Id: I442f2ead57e40d9bcd24e7f1b261041371595360
Related: OS#1582
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
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
Previously it was possible to start osmo-sgsn with "auth-policy remote"
but without "gsup remote-*" which resulted in broken setup: no MS could
perform GPRS ATTACH. Add consistency check to vty code to fix this.
Related: OS#1582
Change-Id: Ie4296e7d99d7833f7d828b0196435ea81097cf6e
Always set CN domain in outgoing GSUP packets to PS to make it
compatible with osmo-auc.
Change-Id: Ia6ee2e55a41a8ea9e465d7df1b2b3559b553fca8
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
Assert that llme is unused for non-Gb (Iu) connections, and clean up otherwise.
Make sure the cleanup is left below the sgsn_mm_ctx_free() call, as the comment
states.
Change-Id: I891ae21afc1f4f60580b822273b5435e0e17d46f
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>
libosmocore changed in bf990bb8 Update internal GPRS cipher API
from uint_64 to uint8_t*.
Fix a warning.
Change-Id: Ib5bfe1fb05c693347b11ff4faadd3fc2205ebd76
In commit 4adb136da6 we introduced
a new authentication state SGSN_AUTH_AUTHENTICATE, but we didn't
add that to auth_state_names[] resulting in log messages printing
it abut 'unknown 0x1' rather than something more useful.
The existing GSUP code expected the subscriber data to be piggy-backed
onto the location update response, rather than a separate (and nested)
insert subscriber data request/response phase.
With this patch we should now support both the nested as well as the
piggy-backed version.
In general, if a function generates output data like a msgb (or in this
case filling an osmo_oap_message structure), the output argument
precedes the source. This is what we use all over libosmo*, and it is
modelled after memcpy(), where dst is the first argument, before src.
Let's align osmo_oap_decode(). Intestingly, osmo_oap_encode was already
correct, so the encode/decode functions used different conventions
before.
This rename is the first step of moving the associated functions into
libosmocore.
Also, rename gprs_match_* to osmo_match_shift_* to indicate that it is
not just matching the TLV, but also shifting the data portion.
This is a preparation to move the related code to libosmocore, whilst
at the same time generalizing it from GPRS Subscriber Update Protocol
to the Osmocom Generic Subscriber Update Protoco.
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.
Daniel Willmann
Neels Hofmeyr
Philipp Maier
Alexander Couzens
Dieter Spaar
Harald Welte