1 May
2016
1 May
'16
3:46 p.m.
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "Osmocom code for Iuh interface".
The branch, sysmocom/ipa_nano3G has been updated
discards 77c960c023c42f06bacf6dae085d04193266bed6 (commit)
discards ecb259dbb9bdd5196a89dc3205602bba2ae3de06 (commit)
discards 87b3bbfb39aa84239d76796353a3acb1d6aec889 (commit)
discards e874a5db5aabd717eba5a8dc02b19cef48cb88ec (commit)
discards 30dc1920bbcbf80146892808a38cfdbffeeafc6a (commit)
discards 4bd1c9f605103b6ff3393ec9185bd47501eea6a3 (commit)
discards 81fb7cb24bf5c66d9d196455ad22801f25e05e61 (commit)
via 575301ae326141af5745b60e286054448b6f1723 (commit)
via ce605fab0a1d3b6eeb417bf31ceeed03dfe724c1 (commit)
via 544b76d6e2db765c57e35af0aa99f162a28685fe (commit)
via bb289e3b810683dadc5e2dd0b345b97cd3e8bddb (commit)
via 0a461568f0d9186328a4878daa040bcdb33160c7 (commit)
via 14da5411a4fbe05eccff5b4f0934d52773a3f97a (commit)
via f764a15c2339d5b24f0258d6605d5c38229209cc (commit)
This update added new revisions after undoing existing revisions. That is
to say, the old revision is not a strict subset of the new revision. This
situation occurs when you --force push a change and generate a repository
containing something like this:
* -- * -- B -- O -- O -- O (77c960c023c42f06bacf6dae085d04193266bed6)
\
N -- N -- N (575301ae326141af5745b60e286054448b6f1723)
When this happens we assume that you've already had alert emails for all
of the O revisions, and so we here report only the revisions in the N
branch from the common base, B.
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
http://cgit.osmocom.org/osmo-iuh/commit/?id=575301ae326141af5745b60e2860544…
commit 575301ae326141af5745b60e286054448b6f1723
Author: Harald Welte <laforge(a)gnumonks.org>
Date: Sat Apr 30 23:52:02 2016 +0200
hack: Accept also UE_Identity_PR_pTMSIRAI in HNBAP from nano3G
I have the feeling that the nano3G simply forwards whatever identity it
receives from the MS in RRC via HNBAP, without sending any IDENTITY
REQUESTS by itself. That seems like a violation of the RANAP
specification, but well.
As opposed to Neels' earlier commit, the phone I was testing with
(GT-I9100) is using the UE_Identity_PR_pTMSIRAI (PS identity) instead of
UE_Identity_PR_tMSILAI (CS identity) when trying its first attempt to
register to the network, so let's support that equally.
http://cgit.osmocom.org/osmo-iuh/commit/?id=ce605fab0a1d3b6eeb417bf31ceeed0…
commit ce605fab0a1d3b6eeb417bf31ceeed03dfe724c1
Author: Neels Hofmeyr <nhofmeyr(a)sysmocom.de>
Date: Mon Apr 25 15:05:32 2016 +0200
hack: simply accept UE Register Requests with TMSI
HNBGW would usually keep 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.
This is particularly helpful with an ip.access nano3G femto cell, as it
tends to send UE registrations with a TMSI+LAI identification instead of
an IMSI when the subscriber is known. This causes timeouts of several
minutes until a UE registration switches back to IMSI. When simply
accepting the TMSI in osmo-hngw, no problems are apparent in our current
code state.
We could use the subscriber list during paging, but 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. However, since we're now failing to record UEs that
register by TMSI, we must be aware that trying to page such UE on only
its last seen HNB will fail; it is plainly missing in the list.
http://cgit.osmocom.org/osmo-iuh/commit/?id=544b76d6e2db765c57e35af0aa99f16…
commit 544b76d6e2db765c57e35af0aa99f162a28685fe
Author: Neels Hofmeyr <nhofmeyr(a)sysmocom.de>
Date: Mon Apr 25 14:55:35 2016 +0200
UE Register with TMSI: reply with a Register Reject
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.
-----------------------------------------------------------------------
Summary of changes:
src/ranap_msg_factory.c | 6 +-----
src/tests/test-ranap.c | 57 +++++++++++++++++++++++++++++++++++++++++++++++++
src/tests/test-ranap.ok | 23 +++++++++++++++-----
3 files changed, 76 insertions(+), 10 deletions(-)
hooks/post-receive
--
Osmocom code for Iuh interface