Age | Commit message (Collapse) | Author | Files | Lines |
|
Change-Id: I71d9abcf7e3a836c475b7adbb95a82580e41ae6d
|
|
Similar to what we already have in osmo-msc.
Change-Id: Iaa9e1d06dd0430848ef4f7498a3c15d13f899904
|
|
Change-Id: Id3a3ccbf168fbbc28153cbf7f0249294eee34d3d
|
|
Change-Id: Ieab9b7696c93de9a5d3d42f614072a6f2181e37d
|
|
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
|
|
VTY command "show timer" is also available now.
Change-Id: Ia0cf5f0a49737fbc419e2ccc86312d01c6e0056e
|
|
Change-Id: I486fc2a56e235a539836894d2042c1ca6e514ab9
|
|
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
|
|
Change-Id: Iba22060d8646bc8ec6227684ccb91d98cb4c7be2
|
|
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
|
|
Change-Id: I357f0af89f5d14d304c3e889a49a5f6c23b7fb7a
|
|
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
|
|
Change-Id: I061144b6994ee40d5b32eb321dd4f3d3786d028d
|
|
Change-Id: I3b53a530ab25434e2b2f4d80ad70a8a5f22bfcac
|
|
Change-Id: Ic6912269d0d69c86f19e57f3271ebda1328e968f
|
|
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
|
|
Change-Id: Ib8be5af2a5e92a7403505b73ce4c1751832de40d
|
|
Change-Id: Ie8ba2b9da695de8730834abb591df64295bb6172
|
|
Change-Id: Iefb9b6dc34d87b4088c7535ef0a246103fe3f7e9
|
|
Change-Id: I1b45f45addc87c74f3ae109e544143a1335180de
|
|
Change-Id: I4d1d47af332d4557e8a3a70c1055bcc172166016
|
|
Change-Id: Ife43559f395b9602f0b131a672f8d87d6ee48ea2
|
|
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
|
|
Change-Id: I3a2b84d386f55447e9eed35e59fdc0272e5147d1
Related: OS#1720
|
|
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
|
|
Change-Id: Id7245eb1011d1f04d5dfa1503a96d100bc98344c
Related: OS#1700
|
|
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
|
|
Change-Id: Id1511c5022a239db5d0b44ec7adf048cca307751
|
|
Related: OS#3047
Change-Id: Ic887518bd149f325a92c3517ee90c655b1368fd8
|
|
Change-Id: I8ee63a3da532285def8de7fe5e90873152adb21e
Related: OS#1700
|
|
Depends: libosmocore I52b9f6b5f3e96d85a390ba2af21d7814df8aaeec
Change-Id: Icf9f466efce520779c926b47b6e6d6c9815120eb
|
|
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
|
|
Depends: osmo-ggsn.git I653cbdc185165592d985e3efab6e3f1add97877b
Related: OS#2873
Change-Id: Iaaffe0ec4d9590309c62b62c446677c6f6732f2a
|
|
Change-Id: I3dfe3598055457cc9724a371590e676f1920652b
|
|
I have verified, that the resulting debian packages build in my own OBS
namespace (see the -doc packages):
https://download.opensuse.org/repositories/home:/osmith42/Debian_9.0/all/
https://build.opensuse.org/project/show/home:osmith42
Depends: Ib7251cca9116151e473798879375cd5eb48ff3ad (osmo-ci)
Related: OS#3899
Change-Id: I9c09a0cb5c65fa2e2cd9817edb4656b2a1a35bb9
|
|
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
|
|
Spec also states same value is used for T3390, which we don't yet
implement.
Change-Id: I1a2276bd42d1ea5706cf9cc26d3e44baa6fbf066
|
|
Change-Id: I68e87f29711a282a97a43b175f13b3c70112ab60
|
|
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
|