"127.0.0.1" is changed to "localhost" to let local NSS decide whether to
use IPv4 or IPv6. In newish systems, IPv6 ::1 will be selected since
IPv6 takes precedence over IPv4.
Similarly, the default source addr needs to be changed from NULL to "localhost"
since for some yet unknwon reason, getaddrinfo(AF_UNSPEC, NULL) returns
first IPv4 "0.0.0.0" and later "::", which is inconsistent with
getaddrinfo("localhost") result, resulting in src=IPv4(0.0.0.0) and
dst=IPv6(::1), which is incompatible and will fail. In any case, since
the default remote address is a local one and it's the client side,
there's no real logical change since the kernel would anyway should have
taken a local address anyway.
Change-Id: I3c07e6aa0c87b752c9ea22eb4936f6993de6571f
Let's add the type name whose encoding failed to give us some kind
of a clue what's happening in those situations.
Change-Id: I802677ba7164a4d3382d4bc00f5e1c7ab7067d89
With new gcc 10.1.0, tests failed at runtime when built with ASAN
enabled, since some global variables where defined multiple times.
See OS#4556 for a sample Asan error.
Fixes: OS#4556
Change-Id: I12a667ea8a9f16404c13c9218b246d2e3acfe3e8
The hnbgw application uses LOGL_DEBUG for all its log categories. This
is way to verbose, lets set LOGL_NOTICE as default loglevel instead.
Change-Id: If3dbed88307814764bab9e7f1821e1dc0d8be43b
Related: OS#2577
Caught by compiler:
test-ranap.c:54:30: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 2 has type ‘RANAP_MaxBitrate_t’ {aka ‘long int’} [-Wformat=]
test-ranap.c:78:30: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 2 has type ‘RANAP_CauseMisc_t’ {aka ‘long int’} [-Wformat=]
Change-Id: Icc4e81beaa35e13aea3adfed983016c78b730061
Catched by compiler:
hnb-test-ranap.c:76:44: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘RANAP_CN_DomainIndicator_t’ {aka ‘long int’} [-Wformat=]
Change-Id: Ie4cd6a36fd0e9a871a1815d600e8a321a3d2a208
The cause code no remaining rab should be only used when closing the
Iu connection on this specific reason. Change default to NAS Success
Release which is a usual release.
Change-Id: Icf3f06b0de7dcda9f967ae29863054ef813c75e5
This uses the (modified) Osmocom asn1c on the (modified) SABP ASN.1
syntax to generate C code + header files for SABP parsing/encoding.
It also adds some helper code for message encoding and decoding as well
as a new libosmo-sabp shared library which can be used by programs to
implement SABP related functionality.
Change-Id: Ib9580d1af96354398da4c9f97b28a0e23d56e275
Allow to free UE ctx when receiving a Iu Release Complete.
In preparation of ranap_iu_tx_release_free() it requires
a field to free the Iu ctx on it's own without depending
on the upstream user.
Change-Id: Iac41cd3cce3232d01b2f7ede0cc46226c2cfb6c0
ranap_iu_tx_release_free is a fire and forget function to release
gracefully if possible. It first sends a Iu Release Command. After
a certain timeout the connection will be released.
Change-Id: I349e2c61ba0131e233b7ab927dfced0bd461dd8f
The iu_client is informing the library user about global event.
In prepration to the tx_iu_release_free() call allow to
disable upstream notificatiosn
Change-Id: Ic93ef6fd54c995405e9c37a5e0c53f81a89850b7
As preparation to enable and disable notifications for a specific ue connection,
add a slim proxy before calling global_iu_event_cb
Change-Id: I49a3402a871d6dccd343cda49f8a7f82bffe150b
Otherwise the process hangs if the user enters:
$ show hnb NAME
hnbgw_vty.c: In function ‘show_one_hnb’:
hnbgw_vty.c:234:2: warning: passing argument 1 of
‘hnb_context_by_identity_info’
from incompatible pointer type
[enabled by default]
iuh/hnbgw.h:154:21: note: expected ‘struct hnb_gw *’
but argument is of type ‘struct hnb_gw **’
Change-Id: I42fdb10af5f6427886b5797325830dfc212af30f
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.
Change-Id: I31a286bebe3229671d9960ae32a753d260a26b1d
Related: OS#4138
Seveal of our RANAP messages were using criticality values at the
PDU level differing from what RANAP_PDU_Descriptions.asn states
for the respective procedures. Let's fix that.
This was discovered while working on the initial IuCS TTCN3 tests,
where the receive templates require the criticality to match.
Change-Id: I98eec0bdc0d0cb1b9284bd5d042b1f4403abef95
This ensures that the rpath of the generated binaries is set to use only
the just-compiled so-files and not any system-wide installed libraries
while avoiding the ugly shell script wrapper.
Change-Id: I92c7391631becc09d277981179c23f2e4dba3b54
Rationale: current osmo-msc refactoring introduces RESET handling on IuCS.
In particular, it makes osmo-hnbgw be able to operate with an (upcoming)
osmo-msc that has strict RESET handling: it will send a RESET and require a
RESET ACK if it sees a new IuCS peer sending messages without prior RESET.
Even though a workaround to ignore missing RESET messages on IuCS will also be
in place in the new osmo-msc, this is a first small step towards more sane
RESET handling in osmo-hnbgw.
Related: OS#3820
Change-Id: I02bc74ef9fef61f4490b4d4dc3ce6c0a6d965909
Un-jam the commandline option to disable color: it is so far stuck in
--disable-color and overrides everything so that we never see any colored
logging from osmo-hnbgw, whichever cmdline or cfg we pass.
Change-Id: I00400b626925fa9da707ad6679d8448941dbfa98
Add the 'show hnb NAME' VTY command which displays just
one specific HNB, addressed by its identity string.
This augments the functionality provided by 'show hnb all'.
Change-Id: Iab12aa4ab090b72c472358b84daf6919b30747f6
Related: OS#2774
The nano3G sends the RAB Assignment Response's Transport Layer Address in X.213
NSAP padded to 20 bytes (160bit). Do not interpret it as 4-byte IP address,
which currently breaks nano3G voice calls (wrong RTP IP address).
Recent commit I2cd1b2d8e1c1ae707cfc0dc7961a2b31ecdf29e0 fixed decoding of X.213
NSAP that is exactly seven bytes, but broke decoding of the padded version from
the nano3G.
A proper X.213 NSAP decoding would still be more welcome than this patching
back and forth, but this is (another) quick fix without spending too much time
on it.
Related: OS#3420
Change-Id: I0ad8bce6fcfd3829394c39490058c1ab85cdfde3
Fix ranap_transp_layer_addr_decode() to test == 7 instead of > 7: If a femto
cell sends its Transport Layer Address as X.213 NSAP IPv4, we receive 3 header
bytes and four IP-address bytes, so the length is exactly 7.
This function is very vague on numerous other decoding details, but this patch
only fixes the vital length check that makes 3G usable with X.213 NSAP.
Related: OS#3420
Change-Id: I2cd1b2d8e1c1ae707cfc0dc7961a2b31ecdf29e0
The read callback should catch all errors already.
Previous when a read fails it:
* hnb_context_release() -> osmo_stream_srv_destroy() -> hnb_context_release()
On the second hnb_context_release() the hnbgw will crash because calling
llist_del() twice on the same object.
Fixes: OS#3416
Change-Id: Ic84b2184b7fc850c0de2acacf179e86771e17510
It's cosmetic since the MCC and MNC in the PLMN aren't actually used,
currently. It makes sense to do it properly anyway, while I'm still in the
3-digit MNC topic, for the future.
Change-Id: I29ebcddd45fe3079f8883589a83cc7216a535475
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)
This change depends on a new API in libosmo-netif, which is added in
https://gerrit.osmocom.org/#/c/6844/
Change-Id: Iffd441eb2b6b75dfbe001b49b01bea015ca6e11c
Depends: I8ed78fe39c463e9018756700d13ee5ebe003b57f
Related: OS#2789
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
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
Add commands to get number of connected HNBs and identity string of
connected HNB based on Cell ID.
Change-Id: I3a2d6fa3d6d0829ccee4ecc0998d9299c97820e9
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
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
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
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
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
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
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
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
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
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
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
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
Harald Welte
Pau Espin
Vadim Yanitskiy
Philipp Maier
Vadim Yanitskiy
Martin Hauke
Oliver Smith