Age | Commit message (Collapse) | Author | Files | Lines |
|
These are the osmo-iuh changes corresponding to the libosmo-netif
branch 'destroy_conn_with_txflush_callback'.
Change-Id: I380e9e41161cbf51b272c7f3725ccaeef625546c
|
|
If we receive a HNB-REGISTER-REQ with a cell ID which is already used
by another registered NNB, log an error and send HNB-REGISTER-REJECT.
Tested manually by running two 'hnb-test' programs concurrently (they
need to listen on different telnet ports; this port is hard-coded so
I compiled two different hnb-test binaries).
Then I issued the 'hnbap hnb register' command on the telnet interface
of each, and verified that the correct action is logged by osmo-hnbgw.
Both hnb-test programs can connect, but only one of them can register
at a time. Killing a registered 'hnb-test' program terminates its
connection and allows the previously rejected one to register.
The new rejection log message looks like this:
hnbgw_hnbap.c:429 rejecting HNB-REGISTER-REQ with duplicate cell
identity MCC=901,MNC=99,LAC=49406,RAC=66,SAC=43947,CID=182250155
from (r=127.0.0.1:42828<->l=127.0.0.1:29169)
Change-Id: Iffd441eb2b6b75dfbe001b49b01bea015ca6e11c
Related: OS#2789
|
|
Change-Id: I12d995c0c993483ed940fc173904d6e686fbe0ab
|
|
Change-Id: Ib05f7862081708d578d8f0302d926aab42897dc2
|
|
Change-Id: I3c039267fa2cc047c5678bcfe4a603f70c21cdd1
|
|
HNBAP isn't really that important to osmo-hnbgw operation, all we do is service
the few requests so that the other side is happy and uses our Iuh.
Nevertheless, could at least log if an UnsuccessfulOutcome was received.
Change-Id: I3f309dc2d3436798e9e76bcc2ebd82403ea538a1
|
|
Fixes: CID#57732 CID#57733
Change-Id: Iddf76d23c2c7d5824e82708f7da013c88411e832
|
|
There don't seem to be any evaluations of the rc, nevertheless return
well-defined values.
Fixes: CID#181968
Change-Id: I59295388564e5d270da32db6e7488755231f8a11
|
|
In the UNITDATA case, there is no map, so a) initialize map as NULL and b)
print the RUA ctx id directly from local var context_id instead.
Fixes: CID#181969
Change-Id: I73f508b719b61a389e10cbad1bafad1650634abe
|
|
Fixes: CID#135219
Change-Id: I32c11100c87a59f34d7c1fefd2f0037e5d63f0e0
|
|
Change-Id: If841d403010a73722ff69617a51719421febab56
|
|
Change-Id: I90ca756691e4f644d93af519ed5d54d794d1d401
|
|
Add commands to get number of connected HNBs and identity string of
connected HNB based on Cell ID.
Change-Id: I3a2d6fa3d6d0829ccee4ecc0998d9299c97820e9
|
|
* add libosmoctrl dependency
* bind control interface
Change-Id: I4637e88da00bac1ab0237c29ac73806d024863ba
|
|
Use actual application version instead of hardcoded "0".
Change-Id: I8711b9d819454d810291d57b97119d9fe4a47f8e
|
|
We have to use a format string, we cannot directly print "name".
Fixes a build error on our OBS builds:
hnbgw_vty.c:156:5: error: format not a string literal and no format arguments [-Werror=format-security]
which was introduced in Change-Id I3c937306a011715e163a40bc8ef8ec7e8d4e5d08
about one week ago.
Change-Id: I042989c2b7b379284b2ee5fea3bd8f8ce406b09e
|
|
This was introduced a week ago in Change-Id
I3c937306a011715e163a40bc8ef8ec7e8d4e5d08 and is now cleaned up.
Change-Id: Iaadf941aa7f1c5ae05eb02b51cc646b7b5587ba3
|
|
Change-Id: Iceb29af9f4ef6b4b4ed9778bdd683d30c201371d
|
|
The comments are all right above the line that does the proper asn1 free step.
Change-Id: I60e3be8c56ecc75c22e76f9e9dce8c72753e153b
|
|
Change-Id: I8aeb93fe8037e5fdc0784f5fc3bdb527de3b76bd
|
|
So far, the RNC-Id is hard-coded as 23. Still use 23 as default, but allow
configuring by config file. Hence make it possible to run multiple osmo-hnbgw
with differing RNC-Id each.
Change-Id: I374f558cc4bb36055f39efe9c58ae1b9bd49da46
|
|
Change-Id: I4dd07a4d09d3cd4dc2a08e42ee48344967e5e3a6
|
|
UNITDATA is connection-less, and as can be observed further below, the 'map'
doesn't get used in the N_UNIDATA case.
Related: OS#2776
Change-Id: Ic35562e6d7bfa54b6be859860657f9a235ad5a50
|
|
When an id-Disconnect is received, the RUA to SCCP user context becomes unused.
Mark the context map as inactive in that case. It will be cleaned up by the
context map garbage collector.
Related: OS#2776
Change-Id: I9616f72bfa566de081098ee13e720ff0f5266c77
|
|
The context map garbage collector removes entries from the list, hence it must
use llist_for_each_entry_safe().
We haven't hit this before since nothing is yet flagging context maps to be
discarded.
Related: OS#2776
Change-Id: I9d5899923054d1bf862d542fec862fb1e6f07dce
|
|
Part of the resulting diff in the generated code:
--- /tmp/hnbap_decoder.c 2017-12-24 17:06:50.983979866 +0100
+++ /tmp/hnbap_decoder.c 2017-12-24 17:07:10.760223354 +0100
@@ -1179,6 +1179,7 @@
TNLUpdateResponseIEs_t *tnlUpdateResponseIEs) {
ASN_STRUCT_FREE_CONTENTS_ONLY(asn_DEF_Context_ID, &tnlUpdateResponseIEs->context_ID);
+ return 0;
}
int hnbap_free_tnlupdaterequesties(
@@ -1187,6 +1188,7 @@
ASN_STRUCT_FREE_CONTENTS_ONLY(asn_DEF_Context_ID, &tnlUpdateRequestIEs->context_ID);
ASN_STRUCT_FREE_CONTENTS_ONLY(asn_DEF_RABList, &tnlUpdateRequestIEs->rabList);
ASN_STRUCT_FREE_CONTENTS_ONLY(asn_DEF_Update_cause, &tnlUpdateRequestIEs->update_cause);
+ return 0;
}
int hnbap_free_errorindicationies(
@@ -1197,12 +1199,14 @@
if ((errorIndicationIEs->presenceMask & ERRORINDICATIONIES_CRITICALITYDIAGNOSTICS_PRESENT)
== ERRORINDICATIONIES_CRITICALITYDIAGNOSTICS_PRESENT)
ASN_STRUCT_FREE_CONTENTS_ONLY(asn_DEF_CriticalityDiagnostics, &errorIndicationIEs->criticalityDiagnostics);
+ return 0;
}
int hnbap_free_hnbconfigtransferrequesties(
HNBConfigTransferRequestIEs_t *hnbConfigTransferRequestIEs) {
ASN_STRUCT_FREE_CONTENTS_ONLY(asn_DEF_NeighbourInfoRequestList, &hnbConfigTransferRequestIEs->neighbourInfoRequestList);
+ return 0;
}
int hnbap_free_tnlupdatefailureies(
[etc.]
Related: OS#2670
Change-Id: Ieba12c09c33a81da964bf88a858714d922ced8c0
|
|
Instead of listing each and every context map, rather output a summary of
context counts.
Rationale: in a list of a hundred HNBs, I don't want to also see a dozen (or
potentially thousands of) context map lines for each. Furthermore, the conn IDs
aren't necessarily useful on network traces either.
For example, what was shown as SUA Id is incidentally the SCCP Reference, but
this is not a hard requirement and may change. Also, the reference is shown in
wireshark as a hex in mismatching byte order ... so rather don't bother.
The result now looks like
OsmoHNBGW> show hnb all
HNB (r=192.168.0.124:29169<->l=192.168.0.9:29169) "000295-0000152614@ap.ipaccess.com"
MCC 901 MNC 70 LAC 14357 RAC 11 SAC 1 CID 8595638 SCCP-stream:HNBAP=0,RUA=0
IuCS: 1 contexts: inactive-reserved:1
IuPS: 1 contexts: active:1
1 HNB connected
Related: OS#2772 OS#2773
Change-Id: Iae76b68e85863c8663bb5c508b85534c00e1d2c9
|
|
Add 'show cnlink' (uses new osmo_sccp_user_name(), see 'Depends' below).
Tweak 'show hnb all'.
The result looks something like:
OsmoHNBGW> show cnlink
IuCS: OsmoHNBGW:RI=SSN_PC,PC=0.23.5,SSN=RANAP <-> RI=SSN_PC,PC=0.23.1,SSN=RANAP
SS7 route: pc=0=0.0.0 mask=0x0=0.0.0 via AS as-clnt-OsmoHNBGW proto=m3ua ASP asp-clnt-OsmoHNBGW (r=127.0.0.1:2905<->l=127.0.0.1:37699)
IuPS: OsmoHNBGW:RI=SSN_PC,PC=0.23.5,SSN=RANAP <-> RI=SSN_PC,PC=0.23.4,SSN=RANAP
SS7 route: pc=0=0.0.0 mask=0x0=0.0.0 via AS as-clnt-OsmoHNBGW proto=m3ua ASP asp-clnt-OsmoHNBGW (r=127.0.0.1:2905<->l=127.0.0.1:37699)
OsmoHNBGW> show hnb all
No HNB connected
OsmoHNBGW> show hnb all
HNB (r=192.168.0.124:29169<->l=192.168.0.9:29169) "000295-0000152614@ap.ipaccess.com"
MCC 901 MNC 70 LAC 14357 RAC 11 SAC 1 CID 8595638 SCCP-stream:HNBAP=0,RUA=0
IuCS 24->1002 (RUA->SUA) state=1
IuPS 24->1003 (RUA->SUA) state=1
HNB (r=192.168.0.15:29169<->l=192.168.0.9:29169) "000295-0000154153@ap.ipaccess.com"
MCC 901 MNC 70 LAC 24358 RAC 22 SAC 65535 CID 1048575 SCCP-stream:HNBAP=0,RUA=0
IuCS 23->1000 (RUA->SUA) state=1
IuPS 23->1001 (RUA->SUA) state=1
2 HNB connected
Related: OS#2772 OS#2773
Depends: Ib7abf69cfcf4c56273223054b280458451e6c2f6 (libosmo-sccp)
Ia0d15a2814b08bc3f052a1ed12dbb68bade55309 (libosmo-sccp)
Change-Id: I3c937306a011715e163a40bc8ef8ec7e8d4e5d08
|
|
Looking at hnbap_decode_hnbregisterrequesties(), I noticed a segfault if
decoding the HNB Register Request PDU fails, which is due to an unchecked
return value in code generated by asn1tostruct.py.
Add return value and NULL pointer checks and hence fix null dereference on
erratic PDUs across HNBAP, RUA and RANAP protocols. Similar checks exist in
other places, this one was simply missing.
Since the result of asn1tostruct.py is not committed, here is an example diff
of the resulting change, of which there are 128 instances in total:
@@ -304,7 +329,12 @@
memset(hnbRegisterRequestIEs, 0, sizeof(HNBRegisterRequestIEs_t));
HNBAP_DEBUG("Decoding message HNBRegisterRequestIEs (%s:%d)\n", __FILE__, __LINE__);
- ANY_to_type_aper(any_p, &asn_DEF_HNBRegisterRequest, (void**)&hNBRegisterRequest_p);
+ tempDecoded = ANY_to_type_aper(any_p, &asn_DEF_HNBRegisterRequest, (void**)&hNBRegisterRequest_p);
+
+ if (tempDecoded < 0 || hNBRegisterRequest_p == NULL) {
+ HNBAP_DEBUG("Decoding of message HNBRegisterRequestIEs failed\n");
+ return -1;
+ }
for (i = 0; i < hNBRegisterRequest_p->hnbRegisterRequest_ies.list.count; i++) {
IE_t *ie_p;
Change-Id: I6cb9cc9a88d22f03befa43f0968a874476fa079d
|
|
Before, MCC and MNC were always reported as zero, now the output of 'show hnb all' looks like:
OsmoHNBGW> show hnb all
HNB "000295-0000154153@ap.ipaccess.com" MCC 901 MNC 70 LAC 11111 RAC 99 SAC 65535 CID 1048575
HNBAP ID 0 RUA ID 0
Change-Id: Iae094b36fa1cf18e07ed33914b9425368d7cd34b
|
|
remove variable i in ranap_new_msg_sec_mod_compl() as it is not
used (compiler warning)
Change-Id: I93d9e95109fb78bc6cc161745b9e14de8b623d4f
|
|
in many functions, the returncode (rc) from the IE encoder functions
is not checked.
Add a return code check and log error message (like it is already
done in the functions which already check the return code)
Change-Id: I592c0794a94c50fde5c574b1e9bc581eb28af4ae
|
|
add ranap_transp_assoc_decode() to decode the port information from
an RANAP_IuTransportAssociation_t field.
add ranap_transp_layer_addr_decode() to decode the ip-address from
an RANAP_TransportLayerAddress_t field.
Change-Id: I3c1a0455c5f25cae41ee19229d6daf299e023062
|
|
Change-Id: I355c6e5489f24566612528cd679c5cab21eed008
|
|
ranap_common.c:282 col 45: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 4 has type ‘RANAP_CauseNon_Standard_t {aka const long int}’ [-Wformat=]
ranap_common.c:527 col 15: warning: implicit declaration of function ‘asn1str_to_u16’; did you mean ‘asn_strtol’? [-Wimplicit-function-declaration]
ranap_common.c:546 col 11: warning: unused variable ‘addr’ [-Wunused-variable]
Change-Id: I0b399e78fa7b202a36e5e4be86f338c0ceb9823e
|
|
We used to have hardcoded 2323 from early development, use the proper
libosmocore definition instead.
Depends: Ife52a968a41cb286f640006587877971ff66c1a4 (libosmocore)
Change-Id: Id67d89695ebdc6288f507338c15ad773b8adf6e4
|
|
Introduce a list of LAC+RAC entries for each RNC, hence allow serving more than
one LAC per OsmoHNBGW.
iu_client is used by OsmoMSC and OsmoSGSN, both will be able to page
successfully in a setup with multiple LACs (read: multiple hNodeB) connected to
an OsmoHNBGW.
Ensure that each LAC,RAC is registered with at most one RNC Id. If a LAC,RAC
shows up on a different RNC Id than before, move it over to the new RNC Id.
Future patches should probably add:
* timeouts of RNC Id / LAC,RAC validity, to remove unused entries.
* VTY/CTRL commands to introspect which RNCs and LAC,RACs are listed.
* VTY/CTRL commands to remove RNC Id / LAC,RAC entries.
Change-Id: I189f8e2663353276b1c615d2f78455dafe568045
|
|
It's not necessary to set a local IP to connect to OsmoSTP with, 'any' is as
good as any.
Related: OS#2663
Change-Id: If5d0a1500de5e2c4b80acf025761d0264a8a51a0
|
|
Change-Id: I6395dcde35359617cae52ff59d4eb53930097c7d
|
|
The current default point-code for OsmoMSC is 0.23.1 and for OsmoSGSN 0.23.4.
See https://osmocom.org/projects/cellular-infrastructure/wiki/Point_Codes.
Before this patch, osmo-hnbgw requires a cs7 config and explicit point-codes
for MSC and SGSN as well as a local one. Provide default config if none is
provided:
Use above default point-codes if no MSC and/or SGSN address are provided. Also
create a default cs7 instance with local PC 0.23.5.
This allows completely omitting cs7 instance and SCCP addresses from
osmo-hnbgw.cfg in a single-box setup.
Change-Id: I056547f26858d3ad52e66a15f7a4273dcc300e97
|
|
test_common.c:85:2: warning: implicit declaration of function ‘ranap_set_log_area’
Change-Id: Ice192e1f7f1bdafe0941160f43e573349aaceb75
|
|
The sanitize build complains about writing to a uint32_t that is not 4-byte
aligned. Instead, write the uint32_t by memcpy.
For that, move the common ntohl() to the top and store in a local uint32_t,
memcpy() from that in both code paths.
Change-Id: Iacdd15421f824dd009448a96355b533dff28258b
|
|
Fix various mem leaks in the testing code.
Add test_common_cleanup() in test_common.c, to free talloc contexts; call in
test-{helpers,hnbap,ranap}.c. Upon talloc ctx cleanup, ensure that they are
actually empty, in order to catch newly introduced mem leaks.
If non-empty, print talloc context reports.
Change-Id: Ic66c005f2a264774e18bb54e58b87bef5944511c
|
|
Since we finally started to use -Wall, the related warnings became
visible.
Change-Id: I516700eab2aa7c3412dd62775c4960aed9d4b682
|
|
As the default was called "defualt", it became a standard C label
and was never actually performing any default catch-all behavior.
As we didn't use -Wall, gcc never warned us about it so far :/
Change-Id: I9dbad21e75a55ad91b12d3d3ee8bd6dfb5326c3e
|
|
Since I8ac15fa2fd25bedb26297177e416976a5389b573 in July 2017 we are
not using sctp_*() functions directly anymore but go via
libosmo-sigtran. However, some dead code remained in hnbgw.c, which
means that linkage will fail if compiled without any optimization,
i.e. without -O present.
Change-Id: Ifbcb21d43e17bf512bc7b219e590410e06c434ca
|
|
This is actually default in all other osmocom projects, and it's a
big surprise that it hadn't been enabled for osmo-iuh. Now we finally
can see that there are e.g. unused static functions in the code.
Change-Id: I8d52b11e3f476ffd77f3ab185b679817cd3b2163
|
|
Change-Id: Ib0d2cc538488a995be5278092d3ac105be8aad33
|
|
The stp_host is just the *default* that may be overridden by the VTY
configuration. Don't log it as the one that is going to be used.
It's not trivial to print the actual IP address being used, there may be any
number of ASP, theoretically. Hence leave logging up to
osmo_sccp_simple_client_on_ss7_id(), after another hypothetical patch.
Change-Id: Ia438143606913faccc8cdf4fd5f7d376f93e7891
|
|
Change-Id: Id9bb6cc982cd30b86f772207184398af6b899f66
|