All of lore.kernel.org
 help / color / mirror / Atom feed
From: Grant Erickson <gerickson@nuovations.com>
To: ofono@lists.linux.dev
Subject: [PATCH 0/5] Correct Provisioning Database Tags Matching Behavior
Date: Wed,  5 Feb 2025 16:34:41 -0800	[thread overview]
Message-ID: <cover.1738800116.git.gerickson@nuovations.com> (raw)

At least in North America / United States, there exist Cellular MVNOs
(particularly in the IoT / M2M veritical) that neither use mobile
virtual network operator (MVNO) service provider names (SPNs) nor use
unique home network identifiers (HNIs) (that is, mobile country code
(MCC) + mobile network code (MNC) pairs). Instead, they simply use the
HNI of the parent operator.

In addition, those MVNOs typically have two or three APN schemes:

    1. A "public" APN that is broadly used by one or more MVNOs for
       the parent operator that issues PUBLIC IP addresses and does
       NOT route through the MVNOs or parent operator data center
       infrastructure.

    2. A "private" APN that may or may NOT be broadly used by one
       or more MVNOs for the parent operator that issues PRIVATE IP
       addresses and does route through the MVNOs or parent operator
       data center infrastructure.

    3. A "private" APN that is used only by the MVNO that issues
       static or dynamic PRIVATE IP addresses, does route through the
       MVNO data center infrastructure and, from there, via a VPN to
       the customer services infrastructure.

       These are sufficiently MVNO-specific where they do not or
       should not play a role in a generic provisioning database.

Consequently, to effectively distinguish or steer a given device to
(1) or (2), a 'TagsFilter' must be used. However, as presently
implemented, a tag in 'TagsFilter' not only returns APNs matching the
tag(s) but also untagged APNs.

Assuming an APN of both (1) and (2) above, used by the Verizon KORE
Wireless MVNO, prior to this proposed change, the behavior was/is:

No tag specified:

    # ./lookup-apn 311 480
    Opening database in default location
    Searching for info for network: 311480, spn: <None>

    Name: 4G LTE Contract
    APN: vzwims
    Type: 28
    Proto: 2
    Tags: (null)

    Name: 4G LTE Contract (Public)
    APN: vzwinternet
    Type: 1
    Proto: 2
    Tags: kore-m2m-public

    Name: 4G LTE Contract (Private)
    APN: wyleslte.gw7.vzwentp
    Type: 1
    Proto: 2
    Tags: kore-m2m-private

    Name: 4G LTE Contract
    APN: vzwapp
    Type: 4
    Proto: 2
    Tags: (null)

As expected.

One specific tag specified:

    # ./lookup-apn -t "kore-m2m-public" 311 480
    Opening database in default location
    Searching for info for network: 311480, spn: <None>

    Name: 4G LTE Contract
    APN: vzwims
    Type: 28
    Proto: 2
    Tags: (null)

    Name: 4G LTE Contract (Public)
    APN: vzwinternet
    Type: 1
    Proto: 2
    Tags: kore-m2m-public

    Name: 4G LTE Contract
    APN: vzwapp
    Type: 4
    Proto: 2
    Tags: (null)

Surprise! Both 'vzwapp' and 'vzwims' are returned which were not
expected or desired.

Another specific tag specified:

    # ./lookup-apn -t "kore-m2m-private" 311 480
    Opening database in default location
    Searching for info for network: 311480, spn: <None>

    Name: 4G LTE Contract
    APN: vzwims
    Type: 28
    Proto: 2
    Tags: (null)

    Name: 4G LTE Contract (Private)
    APN: wyleslte.gw7.vzwentp
    Type: 1
    Proto: 2
    Tags: kore-m2m-private

    Name: 4G LTE Contract
    APN: vzwapp
    Type: 4
    Proto: 2
    Tags: (null)

Surprise! Both 'vzwapp' and 'vzwims' are returned which were not
expected or desired.

Two specific tags specified:

    # ./lookup-apn -t "kore-m2m-public,kore-m2m-private" 311 480
    Opening database in default location
    Searching for info for network: 311480, spn: <None>

    Name: 4G LTE Contract
    APN: vzwims
    Type: 28
    Proto: 2
    Tags: (null)

    Name: 4G LTE Contract (Public)
    APN: vzwinternet
    Type: 1
    Proto: 2
    Tags: kore-m2m-public

    Name: 4G LTE Contract (Private)
    APN: wyleslte.gw7.vzwentp
    Type: 1
    Proto: 2
    Tags: kore-m2m-private

    Name: 4G LTE Contract
    APN: vzwapp
    Type: 4
    Proto: 2
    Tags: (null)

Surprise! Both 'vzwapp' and 'vzwims' are returned which were not
expected or desired.

With this change, specifying 'TagsFilter' now follows the rule of
least astonishment and matches expectations, returning only those APNs
which match a tag in 'TagsFilter', period.

One specific tag:

    # ./lookup-apn -t "kore-m2m-public" 311 480
    Opening database in default location
    Searching for info for network: 311480, spn: <None>
    Name: 4G LTE Contract (Public)
    APN: vzwinternet
    Type: 1
    Proto: 2
    Tags: kore-m2m-public

As desired / expected.

Another specific tag:

    # ./lookup-apn -t "kore-m2m-private" 311 480
    Opening database in default location
    Searching for info for network: 311480, spn: <None>
    Name: 4G LTE Contract (Private)
    APN: wyleslte.gw7.vzwentp
    Type: 1
    Proto: 2
    Tags: kore-m2m-private

As desired / expected.

Two specific tags:

    # ./lookup-apn -t "kore-m2m-private,kore-m2m-public" 311 480
    Opening database in default location
    Searching for info for network: 311480, spn: <None>
    Name: 4G LTE Contract (Public)
    APN: vzwinternet
    Type: 1
    Proto: 2
    Tags: kore-m2m-public

    Name: 4G LTE Contract (Private)
    APN: wyleslte.gw7.vzwentp
    Type: 1
    Proto: 2
    Tags: kore-m2m-private

As desired / expected.

No tags:

    # ./lookup-apn 311 480
    Opening database in default location
    Searching for info for network: 311480, spn: <None>
    Name: 4G LTE Contract
    APN: vzwims
    Type: 28
    Proto: 2
    Tags: (null)

    Name: 4G LTE Contract (Public)
    APN: vzwinternet
    Type: 1
    Proto: 2
    Tags: kore-m2m-public

    Name: 4G LTE Contract (Private)
    APN: wyleslte.gw7.vzwentp
    Type: 1
    Proto: 2
    Tags: kore-m2m-private

    Name: 4G LTE Contract
    APN: vzwapp
    Type: 4
    Proto: 2
    Tags: (null)

As desired / expected.

Grant Erickson (5):
  provisiondb: Const-qualify '__get_string'.
  provisiondb: Const-qualify '__get_contexts'.
  provisiondb: Correct the precondition return conditions of
    'tags_match'.
  provisiondb: Document 'tags_match'.
  provisiondb: Document '__get_contexts'.

 src/provisiondb.c | 64 ++++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 61 insertions(+), 3 deletions(-)

-- 
2.45.0


             reply	other threads:[~2025-02-06  0:41 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-06  0:34 Grant Erickson [this message]
2025-02-06  0:34 ` [PATCH 1/5] provisiondb: Const-qualify '__get_string' Grant Erickson
2025-02-06  0:34 ` [PATCH 2/5] provisiondb: Const-qualify '__get_contexts' Grant Erickson
2025-02-06  0:34 ` [PATCH 3/5] provisiondb: Correct the precondition return conditions of 'tags_match' Grant Erickson
2025-02-06  0:34 ` [PATCH 4/5] provisiondb: Document 'tags_match' Grant Erickson
2025-02-06  0:34 ` [PATCH 5/5] provisiondb: Document '__get_contexts' Grant Erickson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cover.1738800116.git.gerickson@nuovations.com \
    --to=gerickson@nuovations.com \
    --cc=ofono@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.