Prepend it to the cs7 config .adoc, so that it introduces some concepts
and specifies some limitations of current implementation, etc.
Change-Id: I9faef2dd15b62814e474299c675c2cb05b779c44
Make this deprecated command fatal when in a .cfg file:
hnbgw
sccp cr max-payload-len N
Because we now have:
cs7 instance N
sccp max-optional-data N
from libosmo-sigtran to replace it.
Context: The old command currently has no effect, because we had
implemented the specified fixed 130 byte data limit in libosmo-sigtran.
Recent libosmo-sigtran adds a variable limit configuration.
I considered implementing a shim to redirect the legacy command to the
new implementation, but that would be quite ugly: the old command is
under the 'hnbgw' node and would have to apply to all 'cs7' instances.
But we cannot assume that all 'cs7' are above or below the 'hnbgw' node
in the .cfg file. So I'd have to add global state to remember the legacy
config's value and apply that everywhere else. IMHO this is too much
complexity to support an obsoleted command that has a replacement.
To rule out all confusion that this situation may otherwise create,
abort osmo-hnbgw startup in presence of the legacy VTY command, logging
an error that hints at the new cfg item.
Related: SYS#6423
Change-Id: I71f82efe07af2c32f2aa01084bc8da6ce5c6cd1a
Fix the following compile error, seen on ubuntu 18.04 with GCC 7.5.0,
opensuse 15.4 and our OE builds:
hnbgw.c:549:15: error: initializer element is not constant
.copyright = hnbgw_copyright,
^~~~~~~~~~~~~~~
Fixes: 04844415 ("move main() to separate file")
Change-Id: I13b2569a369724e0298b064a0876b95d6dafd9d0
To ease linking C tests, introduce a libhnbgw.la that contains all of
osmo-hnbgw except the main() and friends.
(I wrote a test that I was going to add, but it turned out to be
obsolete -- now at least we may keep this preparation to add C tests
more easily.)
Change-Id: Id2a706a30fb459005c676bb29c196cf3a582fa01
Conform to recent osmocom practice by having an osmo_hnbgw_main.c file
for main() and its immediate infrastructure.
Prepares for adding a non-installed libhnbgw.la -- which must not
contain a main() function -- so that linking regression tests is easy.
Separating to a new file seems appropriate because hnbgw.c has gathered
a bunch of stuff that is not strictly main() related / might be useful
to access in a C test.
Change-Id: I5f26a6b68f0d380617d73371f40f3b9055cac362
So far we jump through hoops everywhere to pass around osmo-hnbgw's
global singleton state to all code paths. Some files choose to spawn a
static "global" pointer. And we also have the talloc root tall_hnb_ctx.
Simplify:
- Have a single global g_hnbgw pointer. Drop all function args and
backpointers to the global state.
- Use that global g_hnbgw as talloc root context, instead of passing a
separate tall_hnb_ctx around.
(Cosmetic preparation for separate osmo_hnbgw_main.c file)
Change-Id: I3d54a5bb30c16a990c6def2a0ed207f60a95ef5d
It's really just a bloated llist_count() wrapper.
(Cosmetic preparation for separate osmo_hnbgw_main.c file)
Change-Id: Icd4100ddeb98f4dc2e2ec6de2d44a4b861a66078
This fix is really weird: by *removing* a FREE() call, fix a leak of the
replaced transportLayerAddress. (An in-code comment says some more.)
Also remove the other FREE() call that turns out to not be necessary.
This has been verified with a ttcn3 test that is not yet submitted,
which ensures an empty talloc_asn1_ctx at the end of every test
(osmo-ttcn3-hacks I2948ee6f167369a2252f85b493e9653b93c7e4e9 ).
Change-Id: I315d04a07b7dfd4dce26e5b5f871318e27e2bdf6
Include talloc_asn1_context in 'show talloc-context application'. It
belongs there IMO.
Related: SYS#6297
Change-Id: Iffc320c64713b225b57211da4fb95a868bf1f369
Without "null tracking" enabled, the VTY 'show talloc-ctx all' shows
nothing at all.
Since the talloc_asn1_ctx is "created in NULL ctx", it was not visible
in any talloc reports before this patch.
This patch uncovers a slur of leaks, which accumulate in
talloc_asn1_ctx. Fixes follow.
Related: SYS#6297
Change-Id: I5cb4e9a3b393100877f03d68a09acf5817c5a878
Don't fall back to the legacy config if the pool is configured but no
connection to any pool member can be established.
Depends: osmo-mgw I009483ac9dfd6627e414f14d43b89f40ea4644db
Related: OS#5993
Change-Id: Icf3f3f0524c9d27f645c68851aaf9c6f33842927
This option should be used for any executables which are used only
for testing, or for generating other files and are consequently never
installed. By specifying this option, we are telling Libtool that
the executable it links will only ever be executed from where it is
built in the build tree. Libtool is usually able to considerably
speed up the link process for such executables.
Change-Id: Id5f88c331cf1dfd3f38120b4ef59ced9a563d4f0
During tests without an SGSN, I noticed SCCP connections failing, and I
also noticed that I couldn't tell if they were CS or PS related. Add a
"CS"/"PS" indicator to FSM instance IDs for RUA and SCCP.
Change-Id: I5b8242196af3b08eaf64ca5ac1c257a97a5d02cb
When receiving SCTP_RESTART for a given HNB, directly clear the UE
Contexts.
(The HNB typically connects via HNBAP shortly after this causing a UE
Context clearing too, but UE state should always be cleared on
SCTP_RESTART, no matter what.)
Change-Id: I583922193ba73e17ab85152005535188c2762b85
Whenever a HNB reconnects, we want to discard all previous UE state and
any active connections.
In one HNB reconnect scenario, we receive SCTP_RESTART. This sets
hnb_registered == false, which in turn skipped the UE cleanup step in
hnbgw_rx_hnb_register_req(), leaking UE Contexts.
Remove all weird conditions like that, and simply clear out all UE state
whenever a HNB registers, period.
Change-Id: I370966d2d76fd263714e727918fcc1ea2f2315fa
When waiting for CC expires, we should tell the SCCP-SCOC that we've
stopped waiting: send N-DISCONNECT, instead of nothing.
Change-Id: Ie94fcee4e2507a55449050aab96307199aed99a2
the function handle_rab_release() is difficult to read and it is not
immediately clear what happens and why. Lets split this up and add some
comments to improve this.
Related: OS#5916
Change-Id: I3595502b98ea5febbde7f2fab3999e2533766b48
Add braces around context part.
In the HNBGW_Tests.ttcn output, I see this:
DRUA DEBUG TTCN3 HNodeB transmitting RUA DirectTransfer
which reads like the hNodeB would transmit a RUA to us. Instead, this is
us sending RUA to the hNodeB, which is much clearer like this:
DRUA DEBUG (TTCN3 HNodeB) transmitting RUA DirectTransfer
This matches the way we typically show context info in osmo logging.
Change-Id: If6f0c3ae81c737b7488fa93c435179dcf27a5c94
Fix PS RAB Assignment operation:
- add #include "config.h"
- fix uncompilable code in ENABLE_PFCP sections.
A series of oversights made me completely break PFCP / UPF operation for
PS RAB Assignments in this commit:
'context map: introduce RUA and SCCP FSMs to fix leaks'
ed424d5be4
I6ff7e36532ff57c6f2d3e7e419dd22ef27dafd19
- In my HNBGW_Tests.ttcn, I used osmo-hnbgw-with-pfcp.cfg, but failed to
set mp_enable_pfcp_tests := true in HNBGW_Tests.cfg.
- Hence I was under the impression that I was testing PFCP via UPF when
really I wasn't. So I did not notice that:
- in the new files context_map_rua.c and context_map_sccp.c, the
ENABLE_PFCP macro was always unset because I forgot to
#include "config.h".
- Hence I did not notice that the moved PFCP RAB code was never once
compiled or run.
My bad, that was really dumb.
Related: SYS#6297
Change-Id: I5df5073f0092ecdfd73d5d08207ca4042154eab1
Silence the error log about "unknown" PCSTATE prim.
Todo / coming up: instead of ignoring, detect a Destination Unavailable
from prim->u.pcstate and disconnect all conns with that particular CN
link.
Depends: libosmo-sccp If381f537ab91af1feef7f0e51921217f27e18e6a
Change-Id: I547387a5cc14ccb506be04ac785e6807fc4e6a96