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, neels/ipa_nano3g has been updated discards 343f77721f60be25ed5bb426bbee5416771b955b (commit) discards 9de1b9fa9d0c06a799722021fb8723f8781747f6 (commit) discards 4326bc6cc7e9fd78eebc59d4b7f479c04babc71a (commit) discards 449223eb423dd0db026a7c1acf62bebb03be51eb (commit) discards 0b5a049c40fd4744083698b3f29cf9a3ba0e47af (commit) via d419ffcdd09cc19b91f5e1b0404c05e657bf2e5f (commit) via e9d86b7a108e121328f3c50cba6ef5150f7a38af (commit) via 4f014aa873bde7c1bcfb450fe412c408e9127afc (commit) via 6148f344e2f55da59237616a90e53f44ca90d4ae (commit) via 7b48749783827ebad52483278df287ece6e7d279 (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 (343f77721f60be25ed5bb426bbee5416771b955b) \ N -- N -- N (d419ffcdd09cc19b91f5e1b0404c05e657bf2e5f)

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=d419ffcdd09cc19b91f5e1b0404c05e6...

commit d419ffcdd09cc19b91f5e1b0404c05e657bf2e5f Author: Neels Hofmeyr nhofmeyr@sysmocom.de Date: Fri Sep 16 01:38:46 2016 +0200

fix msgb talloc context initialization

Properly initialize msgb talloc context in hnbgw and all tests, using the new msgb_talloc_ctx_init().

test-ranap.c: since msgb talloc ctx is now in test_common_init(), remove msgb talloc init here.

Change-Id: I807c799aff1239184728551ed77fdafa73bd683f

http://cgit.osmocom.org/osmo-iuh/commit/?id=e9d86b7a108e121328f3c50cba6ef515...

commit e9d86b7a108e121328f3c50cba6ef5150f7a38af Author: Neels Hofmeyr nhofmeyr@sysmocom.de Date: Fri Sep 9 01:25:22 2016 +0200

comment: note RAB assignment spec reference

Change-Id: Ifef8da82a01cd781ef560d1ec21cbfb23efb1495

http://cgit.osmocom.org/osmo-iuh/commit/?id=4f014aa873bde7c1bcfb450fe412c408...

commit 4f014aa873bde7c1bcfb450fe412c408e9127afc 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=6148f344e2f55da59237616a90e53f44...

commit 6148f344e2f55da59237616a90e53f44ca90d4ae 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=7b48749783827ebad52483278df287ec...

commit 7b48749783827ebad52483278df287ece6e7d279 Author: Neels Hofmeyr nhofmeyr@sysmocom.de Date: Wed Sep 7 17:04:08 2016 +0200

ranap: include port in RTP TransportLayerInformation

Remove an #if 0 to properly include the port information (verified to work).

Adjust test expectations.

Change-Id: I45fb134959dea9bcdfbfd9d8a061e67c3cc80fb7

-----------------------------------------------------------------------

Summary of changes: src/ranap_msg_factory.c | 5 ----- 1 file changed, 5 deletions(-)

hooks/post-receive