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/gerrit-log@lists.osmocom.org/.
neels gerrit-no-reply at lists.osmocom.orgHello osmith, Jenkins Builder, laforge, pespin, I'd like you to reexamine a change. Please visit https://gerrit.osmocom.org/c/osmo-hlr/+/16764 to look at the new patch set (#14). Change subject: db v6: determine 3G AUC IND from VLR name ...................................................................... db v6: determine 3G AUC IND from VLR name Each VLR requesting auth tuples should use a distinct IND pool for 3G auth. So far we tied the IND to the GSUP peer connection; MSC and SGSN were always distinct GSUP peers, they ended up using distinct INDs. However, we have implemented a GSUP proxy, so that, in a distributed setup, a remotely roaming subscriber has only one direct GSUP peer proxying for both remote MSC and SGSN. That means as soon as a subscriber roams to a different site, we would use the GSUP proxy name to determine the IND instead of the separate MSC and SGSN. The site's MSC and SGSN appear as the same client, get the same IND bucket, waste SQNs rapidly and cause auth tuple generation load. So instead of using the local client as IND, persistently keep a list of VLR names and assign a different IND to each. Use the gsup_req->source_name as indicator, which reflects the actual remote VLR's name (remote MSC or SGSN). Persist the site <-> IND assignments in the database. Add an IND test to db_test.c There was an earlier patch version that separated the IND pools by cn_domain, but it turned out to add complex semantics, while only solving one aspect of the "adjacent VLR" problem. We need a solution not only for CS vs PS, but also for 2,3G vs 4G, and for sites that are physically adjacent to each other. This patch version does not offer any automatic solution for that -- as soon as more than 2^IND_bitlen (usually 32) VLRs show up, it is the responsibility of the admin to ensure the 'ind' table in the hlr.db does not have unfortunate IND assignments. So far no VTY commands exist for that, they may be added in the future. Related: OS#4319 Change-Id: I6f0a6bbef3a27507605c3b4a0e1a89bdfd468374 --- M configure.ac M include/osmocom/hlr/db.h M include/osmocom/hlr/gsup_server.h M sql/hlr.sql M src/db.c M src/db_hlr.c M src/gsup_server.c M src/hlr.c M src/hlr_vty.c M tests/Makefile.am M tests/db/db_test.c M tests/db/db_test.err M tests/db_upgrade/db_upgrade_test.ok D tests/gsup_server/Makefile.am D tests/gsup_server/gsup_server_test.c D tests/gsup_server/gsup_server_test.err D tests/gsup_server/gsup_server_test.ok M tests/testsuite.at 18 files changed, 296 insertions(+), 341 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-hlr refs/changes/64/16764/14 -- To view, visit https://gerrit.osmocom.org/c/osmo-hlr/+/16764 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-hlr Gerrit-Branch: master Gerrit-Change-Id: I6f0a6bbef3a27507605c3b4a0e1a89bdfd468374 Gerrit-Change-Number: 16764 Gerrit-PatchSet: 14 Gerrit-Owner: neels <nhofmeyr at sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: laforge <laforge at osmocom.org> Gerrit-Reviewer: osmith <osmith at sysmocom.de> Gerrit-Reviewer: pespin <pespin at sysmocom.de> Gerrit-MessageType: newpatchset -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20210713/d5dc1055/attachment.htm>