Age | Commit message (Collapse) | Author | Files | Lines |
|
For Iu mode it is important to know when the UE is in PMM-IDLE mode since the
SGSN will need to page the UE if there is data for it.
|
|
As Dieter has pointed out, the RANAP spec requires the RAB ID to be
equal to the NSAPI of the PDP context for which it is established.
|
|
Add use_x213_nsap parameter to iu_rab_act_ps(), pass the new parameter
from two callers as 1 such that there is no functional change.
|
|
|
|
|
|
|
|
See in-code comment...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Conflicts:
openbsc/src/libmsc/auth.c
openbsc/src/libmsc/gsm_04_08.c
openbsc/src/osmo-bsc/osmo_bsc_vty.c
openbsc/tests/Makefile.am
|
|
In this way the caller can distinguish between sending an IK or an IK+CK
Security Mode Command.
|
|
|
|
gprs_gmm.c: remove extraneous debug print arg.
iu_cs.c: increment should not be in debug statement.
Fixes at least one coverity warning.
|
|
In Iu mode the RA upd request can be called from a new Iu connection so we
might need to reauthenticate the connection as well as turn on integrity
protection.
|
|
gprs_transp_upd_key only sends a security mode command which is needed for CS
as well so change it.
Make sure it is called after the UE is authenticated in Iu mode.
|
|
|
|
|
|
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.
|
|
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.
|
|
Iu mode doesn't have tlli, so look up according to p-tmsi
|
|
|
|
|
|
|
|
In case a Iu connection is reconnected we need to update the ue ctx
|
|
|
|
Iu mode has a GMM service request message which a UE in PMM-IDLE mode
can use to switch back to PMM-CONNECTED mode.
|
|
Try to limit the effect 3G support has on the remaining code base. The
sgsn test still fails, but at a later test.
|
|
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."
|
|
|
|
It was a uint16_t*, but is passed as a uint16_t, and never used anyway, yet.
|
|
|
|
|
|
|
|
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
Let's explicitly mark those sgsn_mm_ctx members that apply for Gb mode
and (upcoming) Iu mode, respectively.
|
|
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.
|
|
The spec unfortuantely uses both terms and has no consistent spelling,
but in our logging output we can at least try to be consistent.
|