This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/osmocom-commitlog@lists.osmocom.org/.
gitosis at osmocom.org gitosis at osmocom.orgThis 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 75bfa56be9aa9fe98e88278e3a58ade29c2d69f0 (commit)
discards 6ffacf5ea61308243cf2b0bb0b74e2f0923d19c0 (commit)
discards 8380eb2a01e6b5eb375adf1e570fa7293226fd47 (commit)
via 3eb4ad86835b8e16c6d12becc390ec89298174fd (commit)
via 6ec179e7647958b0ab4431b055c3e68136cf8d15 (commit)
via dfd3e11be57852d334107a0f08cd3d6ba4229c77 (commit)
via 065b584f9b771a0a0a8df6cfef77dea932f00a48 (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 (75bfa56be9aa9fe98e88278e3a58ade29c2d69f0)
\
N -- N -- N (3eb4ad86835b8e16c6d12becc390ec89298174fd)
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=3eb4ad86835b8e16c6d12becc390ec89298174fd
commit 3eb4ad86835b8e16c6d12becc390ec89298174fd
Author: Neels Hofmeyr <nhofmeyr at sysmocom.de>
Date: Thu Sep 8 15:39:18 2016 +0200
RAB Assign for voice: heed the x213 nsap flag
Add use_x213_nsap arg to ranap_new_msg_rab_assign_voice() and
new_transp_info_rtp(). Pass this to new_transp_layer_addr() to compose 32bit
addresses when use_x213_nsap == false.
This is analogous to ranap_new_msg_rab_assign_data().
Particularly, the ip.access nano3G does not accept x213 NSAP 56bit addresses,
so we want to send 32bit addresses there.
Change-Id: I0c3c95d709c8a2b1c48d7a187faca34102226329
http://cgit.osmocom.org/osmo-iuh/commit/?id=6ec179e7647958b0ab4431b055c3e68136cf8d15
commit 6ec179e7647958b0ab4431b055c3e68136cf8d15
Author: Harald Welte <laforge at 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=dfd3e11be57852d334107a0f08cd3d6ba4229c77
commit dfd3e11be57852d334107a0f08cd3d6ba4229c77
Author: Neels Hofmeyr <nhofmeyr at 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.
A workaround to make sure the phone uses an IMSI to register: attempt to
register the phone to a different mobile network, which may discard the TMSI
for your network, and then switch back to your network.
Recording the IMSI in hnbgw: 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.
Change-Id: I87bc1aa3e85815ded7ac1dbdca48f1680b468589
http://cgit.osmocom.org/osmo-iuh/commit/?id=065b584f9b771a0a0a8df6cfef77dea932f00a48
commit 065b584f9b771a0a0a8df6cfef77dea932f00a48
Author: Neels Hofmeyr <nhofmeyr at 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.
Change-Id: Ia47e398e50e316842cd260dc0d9a4e2d8a1c627c
-----------------------------------------------------------------------
Summary of changes:
include/osmocom/ranap/ranap_msg_factory.h | 4 +++-
src/hnbgw_hnbap.c | 3 ++-
src/ranap_msg_factory.c | 12 ++++++++----
src/tests/test-ranap.c | 2 +-
4 files changed, 14 insertions(+), 7 deletions(-)
hooks/post-receive
--
Osmocom code for Iuh interface