Whenever we receive a message and cannot decode the most basic IEs,
or receive an unknown/unsupported procedure code, we should respond
with an ErrorIndication in order to inform the peer.
Change-Id: I7aaa66f83f62ee1b5ba5204248e9f4cc754263ed
If we receive a procedure (like UE-REGISTER) in a state
where it's not permitted (e.g. HNB not registered), we should
send a UE-REGISTER-REJ with proper cause value, rather than not
sending any response at all.
Change-Id: I300db368a3d1d2fb5967f69f2ed4ac90ecf85e75
We always should respond to a UE-REGISTER-REQ. Either it's an ACK
or we must send a REJ. There should not be any "quiet" error cases
where we don't respond at all:
* send general Error Indication at a point where we cannot decode the
UE-Identity-IE (which is mandatory in UE-REGISTER-REJECT)
* send UE-REGISTER-REJECT with matching cause value whenever we have
the decoded UE Identity around
Change-Id: I5338a1324545b2c6d31fb45f1e69fee45842e207
When we reject the HNB-REGISTER-REQ, let's use an as specific as possible
cause value to let the peer know why we rejected registration.
Change-Id: Iadddd26b751a9fd80c829068792aa93cd538c43d
This way the caller can provide the cause value to be used during
reject.
Requires: osmo-iuh I7db92b51847c282d23d568970dfd2bedecdea486
Change-Id: Ic83674523c0326a7ae51fb176bddfd6641ed3ac4
Let's add a per-hnb rate_ctr and stat_item group. Only one initial
counter (number of Iuh establishments) and one initial stat_item
(uptime/downtime) is implemented.
Related: SYS#6773
Change-Id: I26d7c3657cdaf7c6ba5aa10a0677381ab099f8dd
The previous commit was missing the assignment of hnb_persistent->ctx
during successful HNB REGISTER REQ.
Related: SYS#6773
Fixes: Change-Id Ife89a7a206836bd89334d19d3cf8c92969dd74de
Change-Id: I18fe0e5aa968a1095c72e6bf32d08b031b342ac6
This allows us to add a new "hnb-policy closed", which means we do not
accept any random HNB connection anymore, but only those whose identity
is pre-configured explicitly using administrative means.
Furthermore, this new data structure will allow us (in future patches)
to keep persistent data like uptime / downtime of each HNB.
Related: SYS#6773
Change-Id: Ife89a7a206836bd89334d19d3cf8c92969dd74de
Make lots of small tweaks in logging around RUA to SCCP context maps, CN
link selection and HNBAP:
- remove duplicate log context (e.g. LOGHNB() already shows the HNB Id)
- bring more sense into logging categories and levels / reduce noise
- add and clarify the details being logged at what points in time
Related: SYS#6412
Change-Id: I41275d8c3e272177976a9302795884666c35cd06
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
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
User reports show leaked UE contexts over time, in a scenario where HNB
regularly disconnect and reconnect.
So far, when we receive a HNB REGISTER REQ, we log as "duplicated" and
continue to use the hnb_context unchanged. But it seems obvious that a
HNB that registers does not expect any UE state to remain. It will
obviously not tear down UE contexts (HNBAP or RUA) that have been
established before the HNB REGISTER REQUEST. These hence remain in
osmo-hnbgw indefinitely.
When receiving a HNB REGISTER REQUEST, release all its previous UE
state. Allow the HNB to register with a clean slate.
The aim is to alleviate the observed build-up of apparently orphaned UE
contexts, in order to avoid gradual memory exhaustion.
Related: SYS#6297
Change-Id: I7fa8a04cc3b2dfba263bda5b410961c77fbed332
Deallocate a recently allocated UE context if the UE REGISTER procedure
fails internally, in two places.
The UE REGISTER error is rather unlikely to happen in practice: it only
occurs when encoding the HNBAP response fails, which only gets checked
input and thus is unlikely to fail.
The same code paths also possibly leak asn1c allocations -- leave those
for another patch.
Related: SYS#6297
Change-Id: Icf4b82f9a904d56332c567f7ccfb24231ee66270
Under some circumstancies not yet fully known, which seems to
involve bad link quality and high latencies and some specific hNodeB
which reuse its local IP addr+port, it is seen that a 2nd SCTP
connection is created from the same HNB while locally we still keep the
old SCTP connection and its related hnb_context. Hence, when the hNodeB
tries to register again with this new conn, it is rejected all the time
by the HNBGW.
Related: SYS#6113
Change-Id: I33ae901cc37646eca90bf06953e44fcc25f4d6c6
As per what's indicated in 3GPP TS 25.469 8.2.4 Abnormal Conditions:
"""
If the HNB-GW receives a duplicate HNB REGISTER REQUEST (i.e. for an already registered HNB identified by the
unique HNB identity), then the new HNB REGISTER REQUEST shall override the existing registration and the
handling of the new HNB REGISTER REQUEST is according to section 8.2.
"""
Related: SYS#6113
Change-Id: I0250350a14a87498a2c68cd0c726ee2f1e72419d
Don't release the HNB context as there's plenty of code that
assumes there's always a HNB context associated with a SCTP connection.
Instead, simply unset the hnb_registered flag in the context when
processing a HNB_DE-REGISTER.
Related: OS#5676
Change-Id: Id5c4f5c900ea049f54afbf58edb84b4dc00b1dcb
* Use osmo_stream closed_cb to call hnb_context_release() in all cases
* Also call hnbap_free_hnbregisterrequesties() when sending hnb register
reject
Related: OS#5656
Change-Id: I3ba02b0939413c67bc8088ea1a8f2252fc2bda31
Pau Espin
Harald Welte
Neels Hofmeyr
Daniel Willmann
Philipp Maier