So far we don't really have any way of matching a given log message
to a specific hNB. Let's introduce a new log macro, together with
a configuration directive to select whether the hNB-ID or the
UMTS CellID shall be used.
Change-Id: I6113925216c6f88add2c6d27bdf47ccbb017f293
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 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
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
Add commands to get number of connected HNBs and identity string of
connected HNB based on Cell ID.
Change-Id: I3a2d6fa3d6d0829ccee4ecc0998d9299c97820e9
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
In the vty config, use the SCCP address book to configure the local and remote
SCCP addresses. Add VTY commands to set the remote SCCP addresses by name,
derive the ss7 instance from these addresses:
cs7 instance 1
point-code 0.23.0
sccp-address msc
point-code 0.0.1
sccp-address sgsn
point-code 0.0.2
hnbgw
iucs
remote-addr msc
iups
remote-addr sgsn
Enforce that both IuCS and IuPS use the same ss7 instance. In the future, we
may add the feature to use two separate instances.
Depends: libosmo-sccp I75c67d289693f1c2a049ac61cf2b2097d6e5687d,
Ie1aedd7894acd69ddc887cd65a8a0df4b888838c,
I85b46269dbe7909e52873ace3f720f6292a4516c
Change-Id: I33a7ba11eb7c2d9a5dc74d10fb0cf04bf664477b
libosmo-sigtran now has a "proper" SCCP/M3UA stack, so we can make our hnb-gw
3GPP compliant by switching from the old SUA code to the new universal SCCP
user API with support for (currently) M3UA and SUA.
Main changes:
Use one cn_link to STP: We will connect to the core network using an (Osmo)STP
instance that routes to MSC and SGSN, so we want one SCCP link instead of two.
The only difference between IuCS and IuPS is a different remote osmo_sccp_addr.
This has various effects through the messaging code; the patch is a bit larger
than I would like, but it is hard to separate out truly independent smaller
changes.
CS or PS domain was previously flagged in the separate cn_link, as ctx pointer
for two separate sccp_sap_up()s. Now there's just one such ctx, so determine
is_ps from the RANAP Domain Indicator, or from the conn's hnbgw_context_map:
- Add is_ps to context_map_alloc_by_hnb().
- To find a matching context, the RUA ID alone is no longer sufficient, also
match is_ps (possible optimization todo: separate lists).
We would send separate CS or PS Reset messages based on the cn_link, instead
send both CS and PS Reset at the same time for the single cn_link. This could
be adjusted to detect presence of MSC or SGSN instead.
Pending: adjust the VTY config to reflect that there is only one remote
address. Place a TODO comment for that.
Smaller changes:
rua_to_scu(): populate called and calling addresses for N_CONNECT and
N_UNITDATA.
Remove DSUA.
Don't build dummy_cn, which is still implemented on SUA. Mark todo to maybe
re-include it based on M3UA later.
In hnbgw_cnlink, place sccp related items in a separate sub-struct.
Do not keep an llist of cn_links, just have the one. Remove iteration and list
management.
Change jenkins script to build libosmo-sccp master.
Patch-by: hwelte, nhofmeyr
Change-Id: I8ac15fa2fd25bedb26297177e416976a5389b573
Basically copy-paste the Iuh local-ip and local-port code to provide
parameterization of the IuCS and IuPS remote addresses.
Add IUCS and IUPS nodes, enhance go_parent_cb and config writing accordingly.
Change-Id: I2c28977011009df4e1fa472290bbbc359e406971
A second level of depth will be added to the hnbgw node soon, which will need
explicit go-parent logic.
Change-Id: I8d1c18a396c215e8425ae49872b5c73316087d7d
Use the g_hnb_gw->config.iuh_local_ip directly, drop hnbgw_get_iuh_local_ip().
Change-Id: Ie91aea82ae5d128ad735a0857ea814b440c3232c
Suggested-by: hwelte
Prepare for parameterization of IuCS and IuPS addresses:
Conform internal variable naming to local-ip, local-port, remote-ip,
remote-port (instead of bind-ip).
Rename HNBGW_IUH_LOCAL_IP_DEFAULT to HNGGW_LOCAL_IP_DEFAULT to be more general
and move it to the top.
Move a function doc comment to the .c file.
Change-Id: Ice85941c978498e3ddf41d151248507e7f56cb5d
The standard osmo VTY terminology is 'remote-ip', 'remote-port', 'local-ip',
'local-port'. Conform to that. osmo-hnbgw is so far not rolled out widely, so
it makes sense to do this now.
Change-Id: Ifda2653bf58044552a5f1477cd7008dec3fb9100
Add the option to allow UE Register Requests with a TMSI identity.
Add VTY command to enable this option, 'hnbap-allow-tmsi'.
Add hnbgw_tx_ue_register_acc_tmsi().
HNBGW so far keeps track of UEs that have registered, with their IMSI. When a
UE registers with only a TMSI, we obviously can't store an IMSI. However, since
we're so far never *using* the list of UEs in osmo-hnbgw, we might as well just
accept the TMSI registration and carry on as usual. All that is needed for
proper operation is a valid UE context.
This is aimed at the ip.access nano3G femto cell, as it apparently feeds
whichever identification the UE sends through to HNBAP (TMSI+LAI, pTMSI+RAI),
instead of an IMSI as expected. So far this caused failures and the need to
make the UE clear its TMSI (wait several minutes or attempt to subscribe to a
different network), so that UE registration switched back to IMSI. When simply
accepting the TMSI in osmo-hngw, no problems are apparent in our current code
state.
For example, a Samsung Galaxy S4 seems to send a UE_Identity_PR_tMSILAI (CS
identity), and a GT-I9100 seems to send a UE_Identity_PR_pTMSIRAI (PS identity)
upon first registration to the network.
Recording the IMSI in hnbgw: we could use the subscriber list during paging, to
page a UE on only its last seen HNB. On the other hand, it doesn't hurt to
anyway always page to all HNBs connected to osmo-hnbgw. The paging procedure
does include a page-to-all-HNBs in case the first HNB paging fails. But we must
be aware that UEs that register by TMSI will simply not have an IMSI recorded
in the list of UE contexts, so a lookup based on IMSI may fail.
Patch-by: Harald Welte <laforge@gnumonks.org>, me
Change-Id: I87bc1aa3e85815ded7ac1dbdca48f1680b468589
To prepare for an upcoming commit that accepts TMSI identification upon UE
Register Requests:
Add tmsi arg to ue_context_alloc().
Add ue_context_by_tmsi().
This is aimed at the ip.access nano3G femto cell, as it apparently feeds
whichever identification the UE sends through to HNBAP (TMSI+LAI, pTMSI+RAI),
instead of an IMSI as expected.
See the upcoming commit that enables accepting TMSI identities for further
detail.
Change-Id: I138458443319cc4cbea5ee7906cf5dd72d582130
This came up while fixing 'make distcheck'; this is certainly not the easiest
way but it makes sense to have the headers in include/, like we do in openbsc.
The easy alternative might be to add -I$(top_srcdir)/src to src/Makefile.am.
Remove -I$(top_srcdir)/src from src/tests/Makefile.am, no longer needed.
Change-Id: I5a82e029dcdc4df0a60a31271a4883393fe59234
Add include/osmocom/iuh/ named after this project (osmo-iuh), and add vty.h to
define VTY node enum values. Also add (to) Makefile.am and configure.ac to
include in the build.
An upcoming commit will add the actual first config item to the hnbgw/iuh node.
Change-Id: I71545823d3bd81cb888c85df8e298a56c98bf131
Pau Espin
Harald Welte
Stefan Sperling
Neels Hofmeyr