Age | Commit message (Collapse) | Author | Files | Lines |
|
According to some references found in the nano3G MIB help, the CellID as
reported in the HNB-REGISTER-REQ is combined from 16-bit CellID and the
12bit RNC-ID.
The HNB-GW should use this value in the register-req to ensure it is
unique in the network. We should probably reject register requests from
non-unique / overlapping values.
Change-Id: Ib58cc9f3c0e700f8bc5930f4df0d2dfe7888b991
Closes: OS#2789
|
|
Change-Id: Ib6977a9803fdce010eca9fc9a768c89ccf4215f8
|
|
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
|
|
unused since change-id Ic6a645a93406670d58eb5edf5f2f2e1266168c92
"osmo-hnbgw: Avoid useless linking to libosmogsm and libsctp"
Change-Id: I4241a1d84b54a77a6a6dad809f8ec921f45ba4bc
|
|
vty_install_default() and install_default() will soon be deprecated.
Depends: I5021c64a787b63314e0f2f1cba0b8fc7bff4f09b
Change-Id: I61b79f633d36814b53e40f1a92b5847c9ff4fde0
|
|
This fixes the following dh-shlibdeps warnings:
Change-Id: I08be684c45c7e95315dba6ccf9892fe6fc7c3f24
dpkg-shlibdeps: warning: symbol install_element used by debian/libosmo-ranap1/usr/lib/x86_64-linux-gnu/libosmo-ranap.so.1.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol vty_out used by debian/libosmo-ranap1/usr/lib/x86_64-linux-gnu/libosmo-ranap.so.1.0.0 found in none of the libraries
|
|
This fixes the following dpkg-shlibeps warnings:
Change-Id: Ic6a645a93406670d58eb5edf5f2f2e1266168c92
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/osmo-hnbgw/usr/bin/osmo-hnbgw was not linked against libosmogsm.so.8 (it uses none of the library's symbols)
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/osmo-hnbgw/usr/bin/osmo-hnbgw was not linked against libsctp.so.1 (it uses none of the library's symbols)
|
|
See osmo-ci change I2409b2928b4d7ebbd6c005097d4ad7337307dd93 for rationale.
Depends: I2409b2928b4d7ebbd6c005097d4ad7337307dd93
Change-Id: I7261e006163eda4bee8a4695fbd5bd29307babe6
|
|
Change-Id: I4fe653fdde6acda59485c73cee63bfc5326edf28
|
|
We recently fixed package naming / sub-packagign in the libosmo-sccp
git repository, so now we need to depend on the proper package name.
Change-Id: I6e4f8fa96e5f39f988d6993ba3931cb7df70e905
|
|
Now that we have tagged releases that include the support needed
in osmo-iuh, let's require them.
Change-Id: I579ba94e8f0f700b598a2346c5020cce3b159f27
|
|
Change-Id: Ice1c9f51225cef335626d5689ffb306395d7e2b6
|
|
In Change-Id I6a3f7ad15be03fb94689b4af6ccfa828c25f45c0 we introduced
the somewhat arguable combination of Iu code in libosmo-ranap. This Iu
code uses functions provided by libosmo-sigtran.
However, at the time it was overlooked to explicitly link libosmo-ranap
against libosmo-sigtran, which caused linking failures of programs
using libosmo-ranap, such as the unit tests included in this package.
Below example is from building using contrib/jenkins.sh on Ubuntu 17.04:
CCLD test-ranap
../../src/.libs/libosmo-ranap.so: undefined reference to `osmo_sccp_local_addr_by_instance'
../../src/.libs/libosmo-ranap.so: undefined reference to `osmo_sccp_tx_unitdata_msg'
../../src/.libs/libosmo-ranap.so: undefined reference to `vty_out'
../../src/.libs/libosmo-ranap.so: undefined reference to `install_element'
../../src/.libs/libosmo-ranap.so: undefined reference to `osmo_sccp_user_bind'
../../src/.libs/libosmo-ranap.so: undefined reference to `osmo_sccp_user_sap_down'
../../src/.libs/libosmo-ranap.so: undefined reference to `osmo_scu_prim_name'
../../src/.libs/libosmo-ranap.so: undefined reference to `osmo_sccp_addr_dump'
collect2: error: ld returned 1 exit status
Makefile:418: recipe for target 'test-ranap' failed
Change-Id: Ibfbcafd31c91dc630d406ec39b3b076bdb1f4c19
|
|
See
https://osmocom.org/projects/cellular-infrastructure/wiki/Make_a_new_release
for details.
Change-Id: I3ccc8202b650268cc9d1721719ba2f205c351a67
Related: OS#1861
|
|
Change-Id: I9fc4a0ce4ca29f8b76e189d040097f3e63298ba5
|
|
osmo_sccp_addr *addr)
libosmo-sccp introduce the new signature in
564ff618004b ("sccp: make osmo_sccp_addr_name() available")
Change-Id: I5c9abba321ec182d293c33bcffea3462f8717045
|