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 75a61858d5bdee9afed1be059b45666702dfdda0 (commit) discards bc03eeeee2dc9b330a7775e652d19b269530c5e9 (commit) via e5c5fd80e1fa77fc766e43003c35947fe99a0840 (commit) via 8823fc735777e5bc06993845a2ce8c8de5fd090c (commit) via deb302cb613157b4ee439cc803537684f7ec64ab (commit) via 56d16886a379270ae4afea9245182b4fa3763e2b (commit) via e6877b1e35fa339b572f2f393a014036047b1ca5 (commit) via 74b0565d9f1a7abbd665b8456b7a851e1d47f0a8 (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 (75a61858d5bdee9afed1be059b45666702dfdda0) \ N -- N -- N (e5c5fd80e1fa77fc766e43003c35947fe99a0840) 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=e5c5fd80e1fa77fc766e43003c35947… commit e5c5fd80e1fa77fc766e43003c35947fe99a0840 Author: Neels Hofmeyr <nhofmeyr(a)sysmocom.de> Date: Mon Sep 26 01:07:19 2016 +0200 hnbgw: vty conformance: rename iuh 'bind' command to 'local-ip' The standard osmo VTY terminology is 'remote-ip', 'remote-port', 'local-ip', 'local-port'. Conform to that. osmo-hnbgw is so far not rolled out widely, so it makes sense to do this now. Change-Id: Ifda2653bf58044552a5f1477cd7008dec3fb9100 http://cgit.osmocom.org/osmo-iuh/commit/?id=8823fc735777e5bc06993845a2ce8c8… commit 8823fc735777e5bc06993845a2ce8c8de5fd090c Author: Neels Hofmeyr <nhofmeyr(a)sysmocom.de> Date: Thu Sep 22 19:37:29 2016 +0200 log: hnbgw: add hnbap UE context allocation info log Change-Id: Iac0ca948d6e699d984c6e424afe7106dcaf2ab1e http://cgit.osmocom.org/osmo-iuh/commit/?id=deb302cb613157b4ee439cc80353768… commit deb302cb613157b4ee439cc803537684f7ec64ab Author: Neels Hofmeyr <nhofmeyr(a)sysmocom.de> Date: Mon Apr 25 15:05:32 2016 +0200 hnbap: accept UE Register Requests with TMSI and pTMSI 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(a)gnumonks.org>rg>, me Change-Id: I87bc1aa3e85815ded7ac1dbdca48f1680b468589 http://cgit.osmocom.org/osmo-iuh/commit/?id=56d16886a379270ae4afea9245182b4… commit 56d16886a379270ae4afea9245182b4fa3763e2b Author: Neels Hofmeyr <nhofmeyr(a)sysmocom.de> Date: Thu Sep 22 18:06:59 2016 +0200 hnbgw: UE context: add handling by tmsi identification 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 http://cgit.osmocom.org/osmo-iuh/commit/?id=e6877b1e35fa339b572f2f393a01403… commit e6877b1e35fa339b572f2f393a014036047b1ca5 Author: Neels Hofmeyr <nhofmeyr(a)sysmocom.de> Date: Mon Sep 26 01:27:55 2016 +0200 hnbap: add UE Register Reject for pTMSIRAI identity 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 ----------------------------------------------------------------------- Summary of changes: include/osmocom/iuh/hnbgw.h | 3 +- src/hnbgw.c | 5 +- src/hnbgw_hnbap.c | 150 ++++++++++++++++++++++++++++++++++++++++++-- src/hnbgw_vty.c | 25 ++++++-- src/ranap_msg_factory.c | 5 +- 5 files changed, 174 insertions(+), 14 deletions(-) hooks/post-receive -- Osmocom code for Iuh interface