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
Include RANAP_KeyStatus.h so that we use the global enum RANAP_KeyStatus
instead of defining another only within the ranap_new_msg_sec_mod_cmd()
function declaration.
Change-Id: Ifefaab32afa962dacdaa738a5419cce0a65a4b22
Set AM_DISTCHECK_CONFIGURE_FLAGS in Makefile.am instead of
DISTCHECK_CONFIGURE_FLAGS. This is the recommended way from the
automake manual, as otherwise the flag can't be changed by the user
anymore.
Related: OS#3718
Change-Id: I3cfc4ccf799108ee2f411be443069c88a013df5b
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 .tarball-version file should contain the *source version* uniquely
identifying the git commit, and not the Debian package name.
With https://gerrit.osmocom.org/#/c/osmo-ci/+/10343/ there is a correct
.tarball-version file in the .tar.xz of the nightly source packages.
Change-Id: I08fa724a9a70e024845f683fb3f5d245a0bd9aa3
Related: OS#3449
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
Provide a sane means of adding the -Werror compiler flag.
Currently, some of our jenkins.sh add -Werror by passing 'CFLAGS="-Werror"',
but that actually *overwrites* all the other CFLAGS we might want to have set.
Maintain these exceptions from -Werror:
a) deprecation (allow upstream to mark deprecation without breaking builds);
b) "#warning" pragmas (allow to remind ourselves of errors without breaking
builds)
As a last configure step before generating the output files, print the complete
CFLAGS and CPPFLAGS by means of AC_MSG_RESULT.
Change-Id: Id659512d2d9fb3f28584ec5f071907f6b6e72e0d
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
Vadim Yanitskiy
Pau Espin
Daniel Willmann
Oliver Smith
Harald Welte