<p>neels <strong>uploaded patch set #15</strong> to this change.</p><p><a href="https://gerrit.osmocom.org/c/osmo-hlr/+/16764">View Change</a></p><pre style="font-family: monospace,monospace; white-space: pre-wrap;">db v6: determine 3G AUC IND from VLR name<br><br>Each VLR requesting auth tuples should use a distinct IND pool for 3G<br>auth.  So far we tied the IND to the GSUP peer connection; MSC and SGSN<br>were always distinct GSUP peers, they ended up using distinct INDs.<br><br>However, we have implemented a GSUP proxy, so that, in a distributed<br>setup, a remotely roaming subscriber has only one direct GSUP peer<br>proxying for both remote MSC and SGSN. That means as soon as a<br>subscriber roams to a different site, we would use the GSUP proxy name<br>to determine the IND instead of the separate MSC and SGSN. The site's<br>MSC and SGSN appear as the same client, get the same IND bucket, waste<br>SQNs rapidly and cause auth tuple generation load.<br><br>So instead of using the local client as IND, persistently keep a list of<br>VLR names and assign a different IND to each. Use the<br>gsup_req->source_name as indicator, which reflects the actual remote<br>VLR's name (remote MSC or SGSN).<br><br>Persist the site <-> IND assignments in the database.<br><br>Add an IND test to db_test.c<br><br>There was an earlier patch version that separated the IND pools by<br>cn_domain, but it turned out to add complex semantics, while only<br>solving one aspect of the "adjacent VLR" problem. We need a solution not<br>only for CS vs PS, but also for 2,3G vs 4G, and for sites that are<br>physically adjacent to each other. This patch version does not offer any<br>automatic solution for that -- as soon as more than 2^IND_bitlen<br>(usually 32) VLRs show up, it is the responsibility of the admin to<br>ensure the 'ind' table in the hlr.db does not have unfortunate IND<br>assignments. So far no VTY commands exist for that, they may be added in<br>the future.<br><br>Related: OS#4319<br>Change-Id: I6f0a6bbef3a27507605c3b4a0e1a89bdfd468374<br>---<br>M configure.ac<br>M include/osmocom/hlr/db.h<br>M include/osmocom/hlr/gsup_server.h<br>M sql/hlr.sql<br>M src/db.c<br>M src/db_hlr.c<br>M src/gsup_server.c<br>M src/hlr.c<br>M src/hlr_vty.c<br>M tests/Makefile.am<br>M tests/db/db_test.c<br>M tests/db/db_test.err<br>M tests/db_upgrade/db_upgrade_test.ok<br>D tests/gsup_server/Makefile.am<br>D tests/gsup_server/gsup_server_test.c<br>D tests/gsup_server/gsup_server_test.err<br>D tests/gsup_server/gsup_server_test.ok<br>M tests/testsuite.at<br>18 files changed, 296 insertions(+), 341 deletions(-)<br><br></pre><pre style="font-family: monospace,monospace; white-space: pre-wrap;">git pull ssh://gerrit.osmocom.org:29418/osmo-hlr refs/changes/64/16764/15</pre><p>To view, visit <a href="https://gerrit.osmocom.org/c/osmo-hlr/+/16764">change 16764</a>. To unsubscribe, or for help writing mail filters, visit <a href="https://gerrit.osmocom.org/settings">settings</a>.</p><div itemscope itemtype="http://schema.org/EmailMessage"><div itemscope itemprop="action" itemtype="http://schema.org/ViewAction"><link itemprop="url" href="https://gerrit.osmocom.org/c/osmo-hlr/+/16764"/><meta itemprop="name" content="View Change"/></div></div>

<div style="display:none"> Gerrit-Project: osmo-hlr </div>
<div style="display:none"> Gerrit-Branch: master </div>
<div style="display:none"> Gerrit-Change-Id: I6f0a6bbef3a27507605c3b4a0e1a89bdfd468374 </div>
<div style="display:none"> Gerrit-Change-Number: 16764 </div>
<div style="display:none"> Gerrit-PatchSet: 15 </div>
<div style="display:none"> Gerrit-Owner: neels <nhofmeyr@sysmocom.de> </div>
<div style="display:none"> Gerrit-Reviewer: Jenkins Builder </div>
<div style="display:none"> Gerrit-Reviewer: laforge <laforge@osmocom.org> </div>
<div style="display:none"> Gerrit-Reviewer: osmith <osmith@sysmocom.de> </div>
<div style="display:none"> Gerrit-Reviewer: pespin <pespin@sysmocom.de> </div>
<div style="display:none"> Gerrit-MessageType: newpatchset </div>