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 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=3eb4ad86835b8e16c6d12becc390ec89...

commit 3eb4ad86835b8e16c6d12becc390ec89298174fd Author: Neels Hofmeyr nhofmeyr@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=6ec179e7647958b0ab4431b055c3e681...

commit 6ec179e7647958b0ab4431b055c3e68136cf8d15 Author: Harald Welte laforge@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=dfd3e11be57852d334107a0f08cd3d6b...

commit dfd3e11be57852d334107a0f08cd3d6ba4229c77 Author: Neels Hofmeyr nhofmeyr@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=065b584f9b771a0a0a8df6cfef77dea9...

commit 065b584f9b771a0a0a8df6cfef77dea932f00a48 Author: Neels Hofmeyr nhofmeyr@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