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 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.
Sending a proper registration reject speeds up the response seen on the UE and
avoids needless waiting.
See the upcoming commit that enables accepting TMSI identities for further
detail.
Change-Id: I03b69613e6ddd8a08d9358ffc2f74954c231fd2c
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
fix extraneous rebuild for each make invocation: touch the ranap.stamp file in
src/ as the make target suggests.
fix for 'make distcheck': ranap gen: move generated sources to builddir, not
srcdir. Thus we also -I the builddir include to pick up those headers.
hnbap and rua have the same situation as ranap (they generate numerous files
from a single make rule). Use the same makefile semantics for those two
(commit for ranap gen omitted the same changes for hnbap and rua).
The generated headers are thus moved to include/osmocom/*/, so adjust #include
statements accordingly (*_common.h, *_ies_defs.h).
Also move hnbap_common.h to include/osmocom/hnbap and rua_common.h to
include/osmocom/rua, since the *_ies_defs.h want to include them; and since
*_ies_defs.h are now in include/osmocom/*, we want a '<foo>' include now.
Also adjust gitignore.
Change-Id: I32213666fcdfc144008fa7d46497c0938d093e86
When receiving a UE Register Request with TMSI and no IMSI, compose a
Register Reject with the same UE Identity and send.
The accepting function expects a ue_context argument and composes the
message from the IMSI found there. This new rejection message cannot rely
on a ue_context struct and hence uses the asn1 uE_Identity directly.
Change-Id: Ia47e398e50e316842cd260dc0d9a4e2d8a1c627c
Fix log typo 'REGSITER' and add some comments on UE Register with TMSI.
The container_pair struct starts with 'list', so passing the container_pair
pointer is equivalent to passing the list; but instead, explicitly mention the
list member to avoid confusion.
A bit hacky: the ranap_ies_defs.h is generated together with the
ranap_encoder.c and ranap_decoder.c. See comments in src/Makefile.am and
include/osmocom/ranap/Makefile.am.
We now have the RUA and SUA parts interconnected by the
context ID mapper, and should be able to pass messages back and forward
between both sides.
Unfortunately this touches a bit of everything, but the structures are
all still very much in flux. Hopefully they will start to stabilize at
some point soon...
The padding bits in the bit string are at the end and the byte-order is
MSB-first. This means the number needs to be shifted left so the padding
bits are the least significant.
The Accept incudes the IMSI that the phone presented, but
somehow we fail to encode the Context ID as bitstring, see
../pcap/20150911-hnbap-ue_register.pcap
Neels Hofmeyr
Neels Hofmeyr
Daniel Willmann
Harald Welte