When a MS MM state is READY its exact location is known (PCU).
On Gb, T3314 (aka TS 23.060 "READY timer") sets the MM state from
READY to STANDBY, where only the RA is known.
Introduce a second set of timer variables, because state timer
can run while another packet state timer is timing out.
Related: OS#1941
Change-Id: I4ce23ebe50d141076c20c9c56990b7103cd25e55
Add a few commands to make sure it's working fine, and print all
available timers with default values.
Change-Id: Ifd092b9561d49be1f62769d95ba49f6e4aeb4066
FSM doesn't expect receiving event names containing spaces (log lines
generated are confusing).
Similar for enums, it's better using code names to match easily and make
log lines more clear.
Change-Id: I16ede8bf8352b09bc772fd7b43fad2c2274b3ec1
For new readers it's very confusing why PMM states and MM states are in
the same enum, but handled with different functions, and sometimes
called one right after the other with different enums. Calling them when
on a different ran_type makes the function early return, so let's better
conditionally call the function to make it clear in the flow when the
function is expected to do something.
Change-Id: I65ad9e180177bc9fc7c4a037cd85cfe33b161f73
Implementation of osmo_sccp_simple_client() API internally uses ss7 id
1, which is confusing since there's no 0 in use in osmo-sgsn. Let's
explicitly use the 0 one so it is configured by "cs7 instance 0" in the
VTY.
Related: OS#4157
Change-Id: I0e23a6a76ebcba0b1b424e3d3b20d06c1da44cbe
This may well be the culprit of OS#3957, were already freed llme is accessed from
mmctx context later on, upon some timer is triggered in mmctx.
Related: OS#3957
Change-Id: I8e1eaeb9b3ebee8e45704b4fe007190c7db609e4
Recent commit added an assert to make sure unexpected conditions were
happening in sgsn_mm_ctx_cleanup_free(). Old code was passing
mm->gb.tlli to gprs_llgmm_assign with "new tlli" being all-1's (aka
unassign mm->gb.tlli).
The commit changed the code to use gprs_llgmm_unassign, which uses
llme->tlli instead of mm->gb.tlli, and the assert was used to make sure
no behavior change occured with the commit.
It seems TTCN3 test TC_attach_auth_id_timeout triggers that assert, and
after closer debug it seems mm->gb.tlli == llme->old_tlli, which makes
sense since there's a mm->gb.tlli_new which is expected to be
llme->tlli.
When TLLI changes in GMM (Attach Request or RA Update), it is stored
into mm->gb.tlli_new and assigned on the LLC layer using gprs_llgm_assign(),
and upon completion signalling from MS, (after handling response to initial request)
it is assigned to mm->gb.tlli (and value kept in mm->gb.tlli_new).
So mm->gb.tlli and mm->gb.tlli_new usually contain the same value unless
a new TLLI is allocated, and during the span of
Request->Response->Complete it is kept different, the LLC layer having assigned
the value of mm->gb.tlli_new.
So, old code (before the commit adding the assert) was wrongly using
mm->gb.tlli instead of mm->gb.tlli_new at the moment of unassigning (but
not really problematic in practice since behavior is the same as long as
"old TLLI" value is not all-1's.
So we are fine and correct using gprs_llgm_unassign() (which passes llme->tlli
as "old TLLI") instead of what used to be done before.
In any case, the expected behavior is to free the llme object and get
rid of everything...
Fixes: 788863cda53298c24110d0fe0f8cd3309cdec747
Change-Id: I482acdbdf05ce0cb0a5804206672512854067f5b
TS 04.64 sec 7.2.1.1 LLGMM-ASSIGN specifies:
"""
If TLLI Old all 1's and TLLI New all 1's then TLLI Old and TLLI New are assigned, and TLLI New shall
be used when (re-)transmitting LLC frames. Both TLLI Old and TLLI New shall be accepted when received
from the peer. It shall be treated as a TLLI change according to subclause 8.3.2.
"""
Change-Id: I3a17715bf2dba7b03c1335ad106307eb4d5f564a
May be useful to detect unexpected conditions which could end up in
memory leaks.
Related: OS#3957
Change-Id: I0d175501083ce458ff1c07ad38761d2cbf4ea470
New APIs only available since libgtp 1.4.0 are needed, and in turn that
libgtp version requires newer libosmocore 1.1.0.
osmo-sgsn itself requires libosmocore 1.2.0 since it uses GSM23003_TMSI_SGSN_MASK.
Change-Id: I1c67d3e7dda093b4869756c7a63dc7a4549084ae
Since March 15th 2017, libosmocore API logging_vty_add_cmds() had its
parameter removed (c65c5b4ea075ef6cef11fff9442ae0b15c1d6af7). However,
definition in C file doesn't contain "(void)", which means number of
parameters is undefined and thus compiler doesn't complain. Let's remove
parameters from all callers before enforcing "(void)" on it.
API osmo_stats_vty_add_cmds never had a param list but has seem problem
(no "void"), so some users decided to pass a parameter to it.
Change-Id: Ic4af704958819e6f65ac01be33ef5b3d69628ad0
Related: OS#4138
Fix some typos, correct data compression command, add example to turn
off compression.
Change-Id: I6beff8c66eacf12f1081d51dd6b124bdd4478558
Related: OS#1720
Listen on 127.0.0.100 by default, so there is no conflict on
127.0.0.1:23000. This allows starting both services with their default
configuration, like we are doing it in the Osmocom-Debian-install-*
jenkins jobs.
Related: OS#3369
Change-Id: I6e3053de8885a7954296d820c6a069d06276e4df
Quite a few features that are listed as not-implemented in the overview
section are actually implemented now.
Change-Id: I8d499a25293b69babc2aebb2d697438f8ba8141f
Related: OS#1720
osmo-sgsn was missing the help text of the -V option
gb_proxy still thought of itself as OpenBSC
Omit the name of the program in the help text to avoid such issues in
the future.
Related: OS#1720
Change-Id: Ib57694b6bff7c98a269dc4b4dbb7173349a57b81
Change bind-to-sgsns from 127.0.0.1 to 127.0.0.10, so osmo-gtphub's
default config does not conflict with the osmo-sgsn default config. The
value of bind-to-ggsns does not clash with osmo-ggsn's config, so it was
left unchanged.
Related: OS#3369
Change-Id: Id892e1f4ab2daabbe9824b819b5fed985373b97a
There is unfortunately no way to suppres this witha pragma,
and gcc 9 uncovers quite a few new instaces with enabled LTO that can't/won't be fixed
"error: potential null pointer dereference"
Related: OS#4123
Change-Id: I4d1219bf84d3b8dcaf925a60cf54abe733fba263
GCC 9 complains that variable 'gsm_cause' in do_act_pdp_req() may
be uninitialized. This may happen if sgsn_mm_ctx_find_ggsn_ctx()
would return NULL due to no static GGSN configured.
Change-Id: I09c608045dd35b9898b82e236a306ab9a6c2c0b9
Previous commit introduced command "authentication (optional|required)",
which is only meaningful if auth-policy is remote. Upon adding the cmd,
it changed the default logic for remote policy to not require
authentication, which broke TTCN3 tests because sgsn no longer tries to
authenticate the users.
Since it's actually good to enable authentication by default where
possible, let's enable it by default when on auth-policy remote.
In order to do so, let's simply not care about the value of variable
require_authentication if auth_policy is not REMOTE. As a result, we
drop parts of the previous patch and remove unneeded checks (which are
only partially useful based on order of commands during VTY read).
Fixes: 794f446a284ed1ac6d31eb79a8f4c874d66fc34e
Change-Id: Ic707a95af178b44f08809df3d3bc8354bf34273c
It may be useful to have 'remote' authorization policy, but do not
require authentication in GERAN at the same time, e.g. in combination
with 'subscriber-create-on-demand' feature of OsmoHLR.
This change introduces a new VTY parameter similar to the one
that we already have in OsmoMSC:
authentication (optional|required)
Please note that 'required' only applies if 'auth-policy' is 'remote'.
Change-Id: I9909145e7e0af587c28827e16301a61b13eedaa9
Commit 176a4d2f33865a5c0433f8679f5e68f209d7b874 moved echo timer related
code to its own function but did some mistakes when moving the logic
from several places into its own function. As a result, echo timer was
only enabled after the 2nd pdp ctx was created, instead of the expected
1st.
First, let's be consistent and always call the function *after* changing
state, since that's what the function expects. This fixes the issue.
Finally make the logic in the function more intuitive by checking in the
if clause the only case where actually the echo timer should be enabled:
Only if policy specifies so and we have at least 1 pdp ctx against that ggsn.
Fixes: 176a4d2f33865a5c0433f8679f5e68f209d7b874
Change-Id: I826030978edb61ea5a172c2b72f63758206a6246
In I73fd54ad3a4ab8be5aff0fee5c722597ad766e9d incorrect fix was added
which only initialize first element of array. Fix this by using explicit
index to initialize entire array.
Change-Id: I26e4aa44f159d1b5b91dda4a586fd4e809711245
Look at PDP Context Status IE: if there are any PDP contexts which are
ACTIVE on MS side and there are no PDP contexts which are ACTIVE on the
network side, then send Service Reject with the cause "NO PDP
ACTIVATED". This forces MS to reactivate the PDP contexts.
3GPP TS 24.008 Section 4.7.13.4 Service request procedure not accepted
by the network. Cause # 40.
Fixes: OS#3937
Change-Id: If610cbef17c25ec44e65d4f1b2340d102c560437
After Activate PDP Context request, Motorola KRZR
sends a zero length XID-Field of Type L3 Parameters
If this is not echoed back, the phone will send
Deactivate PDP Context request with SM Cause:
LLC or SNDCP failure(A/Gb only) (25)
Closes: OS#3426
Change-Id: Ibd75f7b943c84ed7264481fa2e4bc3cb2f6745d4
Pau Espin
Alexander Couzens
Daniel Willmann
Oliver Smith
Eric Wild
Keith Whyte