Passpunkt (Hotspot 2.0)

Passpoint ist ein Protokoll der Wi-Fi Alliance (WFA) , mit dem Mobilgeräte Wi-Fi-Hotspots, die Internetzugang bereitstellen, erkennen und sich bei ihnen authentifizieren können.

Geräteunterstützung

Um Passpoint zu unterstützen, müssen Gerätehersteller hardware/interfaces/wifi/supplicant/1.0 oder höher implementieren. Die im Android Open Source Project (AOSP ) bereitgestellte Wi-Fi HAL Interface Design Language ( HIDL) definiert eine HAL für den Supplicant. Der Supplicant bietet Unterstützung für den 802.11u-Standard, insbesondere Netzwerkerkennungs- und Auswahlfunktionen wie Generic Advertisement Service (GAS) und Access Network Query Protocol (ANQP).

Implementierung

Android 11 oder höher

Um Passpoint auf Geräten mit Android 11 oder höher zu unterstützen, müssen Gerätehersteller Firmware-Unterstützung für 802.11u bereitstellen. Alle anderen Anforderungen zur Unterstützung von Passpoint sind in AOSP enthalten.

Android 10 oder niedriger

Für Geräte mit Android 10 oder niedriger müssen Gerätehersteller sowohl Framework- als auch HAL-/Firmware-Unterstützung bereitstellen:

  • Framework: Passpoint aktivieren (erfordert ein Feature-Flag)
  • Firmware: Unterstützung für 802.11u

Um Passpoint zu unterstützen, implementieren Sie die Wi-Fi-HAL und aktivieren Sie das Feature-Flag für Passpoint. Ändern Sie in der Datei „ device.mk in „ device/<oem>/<device> “ die Umgebungsvariable „PRODUCT_COPY_FILES“, um die PRODUCT_COPY_FILES Funktion zu unterstützen:

PRODUCT_COPY_FILES +=
frameworks/native/data/etc/android.hardware.wifi.passpoint.xml:$(TARGET_COPY_OUT_VENDOR)/etc/permissions/android.hardware.wifi.passpoint.xml

Alle anderen Anforderungen zur Unterstützung von Passpoint sind in AOSP enthalten.

Validierung

Um Ihre Implementierung der Passpoint-Funktion zu validieren, verwenden Sie die Einheitentests und Integrationstests, die in der Android Comms Test Suite (ACTS) bereitgestellt werden.

Unit-Tests

Führen Sie die folgenden Komponententests des Passpoint-Pakets aus.

Servicetests:

atest com.android.server.wifi.hotspot2

Manager-Tests:

atest android.net.wifi.hotspot2

Integrationstests (ACTS)

Die ACTS Passpoint-Testsuite, die sich unter tools/test/connectivity/acts_tests/tests/google/wifi/WifiPasspointTest.py , implementiert eine Reihe von Funktionstests.

Passpoint R1-Bereitstellung

Android unterstützt Passpoint R1 seit Android 6.0 und ermöglicht die Bereitstellung von Passpoint R1 (Release 1)-Anmeldeinformationen durch webbasiertes Herunterladen einer speziellen Datei, die Profil- und Anmeldeinformationen enthält. Der Client startet automatisch ein spezielles Installationsprogramm für die Wi-Fi-Informationen und ermöglicht dem Benutzer, Teile der Informationen anzuzeigen, bevor er den Inhalt akzeptiert oder ablehnt.

Die in der Datei enthaltenen Profilinformationen werden für den Abgleich mit Daten verwendet, die von Passpoint-fähigen Zugriffspunkten abgerufen werden, und die Anmeldeinformationen werden automatisch für jedes abgeglichene Netzwerk angewendet.

Die Android-Referenzimplementierung unterstützt EAP-TTLS, EAP-TLS, EAP-SIM, EAP-AKA und EAP-AKA'.

Download-Mechanismus

Die Passpoint-Konfigurationsdatei muss auf einem Webserver gehostet werden und sollte mit TLS (HTTPS) geschützt werden, da sie Klartextkennwörter oder private Schlüsseldaten enthalten kann. Der Inhalt besteht aus umschlossenem mehrteiligem MIME-Text, der in UTF-8 dargestellt und gemäß RFC-2045-Abschnitt 6.8 in Base64-Codierung codiert ist.

Die folgenden HTTP-Header-Felder werden vom Client verwendet, um automatisch ein Wi-Fi-Installationsprogramm auf dem Gerät zu starten:

  • Content-Type muss auf application/x-wifi-config gesetzt sein.
  • Content-Transfer-Encoding muss auf base64 gesetzt sein.
  • Content-Disposition darf nicht gesetzt werden.

Die zum Abrufen der Datei verwendete HTTP-Methode muss GET sein. Jedes Mal, wenn ein HTTP GET vom Browser eine Antwort mit diesen MIME-Headern erhält, wird die Installations-App gestartet. Der Download muss durch Antippen eines HTML-Elements wie einer Schaltfläche ausgelöst werden (automatische Weiterleitungen zu einer Download-URL werden nicht unterstützt). Dieses Verhalten ist spezifisch für Google Chrome; andere Webbrowser können ähnliche Funktionen bieten oder auch nicht.

Dateizusammensetzung

Der Base64-codierte Inhalt muss aus mehrteiligem MIME Content-Type von multipart/mixed bestehen. Die folgenden Teile bilden die einzelnen Teile des mehrteiligen Inhalts.

Teil Inhaltstyp (weniger Anführungszeichen) Erforderlich Beschreibung
Profil application/x-passpoint-profile Stets OMA-DM SyncML-formatierte Nutzlast, die das Passpoint R1 PerProviderSubscription formatierte MO für HomeSP und Credential enthält.
Vertrauenszertifikat application/x-x509-ca-cert Erforderlich für EAP-TLS und EAP-TTLS Eine einzelne X.509v3-Base64-codierte Zertifikatsnutzlast.
EAP-TLS-Schlüssel application/x-pkcs12 Erforderlich für EAP-TLS Eine base64-codierte PKCS #12 ASN.1-Struktur, die eine Client-Zertifikatskette mit mindestens dem Client-Zertifikat und dem zugehörigen privaten Schlüssel enthält. Der PKCS 12-Container sowie der private Schlüssel und die Zertifikate müssen alle im Klartext ohne Passwort vorliegen.

Der Profilabschnitt muss als base64-codierter, UTF-8-codierter XML-Text übertragen werden, der Teile der HomeSP und Credential -Teilbäume in der Passpoint R2 Technical Specification Version 1.0.0, Abschnitt 9.1 angibt.

Der Knoten der obersten Ebene muss MgmtTree sein und der unmittelbare Unterknoten muss PerProviderSubscription sein. Eine Beispiel-XML-Datei wird im Beispielprofil OMA-DM XML angezeigt.

Unter HomeSP werden folgende Teilbaumknoten verwendet:

  • FriendlyName : Muss festgelegt werden; als Anzeigetext verwendet
  • FQDN : Erforderlich
  • RoamingConsortiumOI

Unter Credential werden die folgenden Teilbaumknoten verwendet:

  • Realm : Muss eine nicht leere Zeichenfolge sein
  • UsernamePassword : Erforderlich für EAP-TTLS mit den folgenden festgelegten Knoten:

    • Username : Zeichenfolge, die den Benutzernamen enthält
    • Password : Base64-kodierte Zeichenfolge (im Beispiel unten auf cGFzc3dvcmQ= gesetzt, die base64-kodierte Zeichenfolge für „Passwort“)
    • EAPMethod/EAPType : Muss auf 21 gesetzt werden
    • EAPMethod/InnerMethod : Muss auf PAP , CHAP , MS-CHAP oder MS-CHAP-V2 gesetzt werden
  • DigitalCertificate : Erforderlich für EAP-TLS. Folgende Knoten müssen gesetzt werden:

    • CertificateType auf x509v3
    • CertSHA256Fingerprint auf den korrekten SHA-256-Digest des Client-Zertifikats im EAP-TLS-Schlüssel-MIME-Abschnitt gesetzt
  • SIM : Erforderlich für EAP-SIM, EAP-AKA und EAP-AKA'. Das EAPType -Feld muss auf den entsprechenden EAP-Typ eingestellt sein und die IMSI muss mit einer IMSI einer der zum Zeitpunkt der Bereitstellung im Gerät installierten SIM-Karten übereinstimmen. Die IMSI-Zeichenfolge kann entweder vollständig aus Dezimalziffern bestehen, um eine vollständige Gleichheitsübereinstimmung zu erzwingen, oder aus null oder mehr Dezimalziffern, gefolgt von einem Sternchen (*), um die IMSI-Übereinstimmung auf nur das Präfix zu lockern. Beispielsweise entspricht die IMSI-Zeichenfolge 123* jeder SIM-Karte, deren IMSI mit 123 beginnt.

Android 11 führt Funktionen ein, die die Passpoint R1-Bereitstellung flexibler machen.

Separater Authentifizierungs-, Autorisierungs- und Abrechnungsdomänenname (AAA).

Passpoint-Netzwerkadministratoren, die einen AAA-Domänennamen benötigen, der unabhängig vom vollständig qualifizierten Domänennamen (FQDN) angegeben wird, der vom Netzwerk über das Access Network Query Protocol (ANQP) angekündigt wird, können eine durch Semikolons getrennte Liste von FQDNs in einem neuen Knoten unter der Teilstruktur Extension angeben . Dies ist ein optionaler Knoten und Geräte mit Android Version 10 oder niedriger ignorieren diesen Knoten.

  • Android : Unterstruktur der Android-Erweiterung

    • AAAServerTrustedNames : Erforderlich für vertrauenswürdige AAA-Servernamen mit den folgenden festgelegten Knoten:

      • FQDN : Zeichenfolge, die die vertrauenswürdigen Namen des AAA-Servers enthält. Verwenden Sie Semikolons, um die vertrauenswürdigen Namen zu trennen. Beispiel: example.org;example.com .
Selbstsignierte private Root-CAs
Passpoint-Netzwerkadministratoren, die ihre Zertifikate intern verwalten, können Profile mit einer privaten selbstsignierten Zertifizierungsstelle für die AAA-Authentifizierung bereitstellen.
Installation von Profilen ohne Root-CA-Zertifikat zulassen
Das an das Profil angehängte CA-Stammzertifikat wird für die AAA-Serverauthentifizierung verwendet. Passpoint-Netzwerkadministratoren, die sich für ihre AAA-Serverauthentifizierung auf öffentliche vertrauenswürdige Root-CAs verlassen möchten, können Profile ohne ein Root-CA-Zertifikat bereitstellen. In diesem Fall verifiziert das System die AAA-Serverzertifikate gegen die im Truststore installierten öffentlichen Root-CA-Zertifikate.

Passpoint R2-Bereitstellung

Android 10 hat die Unterstützung für Passpoint R2-Funktionen eingeführt. Passpoint R2 implementiert die Online-Anmeldung (OSU), eine Standardmethode zur Bereitstellung neuer Passpoint-Profile. Android 10 und höher unterstützt die Bereitstellung von EAP-TTLS-Profilen mit dem SOAP-XML-Protokoll über offenes OSU ESS.

Die unterstützten Passpoint R2-Funktionen erfordern nur den AOSP-Referenzcode, es ist keine zusätzliche Treiber- oder Firmware-Unterstützung erforderlich). Der AOSP-Referenzcode enthält auch eine Standardimplementierung der Passpoint R2-Benutzeroberfläche in der App „Einstellungen“.

Wenn Android einen Passpoint R2-Zugriffspunkt erkennt, führt das Android-Framework Folgendes aus:

  1. Zeigt eine Liste der Dienstanbieter an, die vom AP in der Wi-Fi-Auswahl beworben werden (zusätzlich zur Anzeige der SSIDs).
  2. Fordert den Benutzer auf, auf einen der Dienstanbieter zu tippen, um ein Passpoint-Profil einzurichten.
  3. Führt den Benutzer durch den Einrichtungsablauf für Passpoint-Profile.
  4. Installiert das resultierende Passpoint-Profil nach erfolgreichem Abschluss.
  5. Ordnet dem Passpoint-Netzwerk mithilfe des neu bereitgestellten Passpoint-Profils zu.

Passpoint R3-Funktionen

Android 12 führt die folgenden Passpoint R3-Funktionen ein, die das Benutzererlebnis verbessern und es Netzwerken ermöglichen, lokale Gesetze einzuhalten:

Geschäftsbedingungen

An einigen Standorten und Veranstaltungsorten ist die Annahme der Nutzungsbedingungen gesetzlich vorgeschrieben, um den Netzwerkzugang bereitzustellen. Mit dieser Funktion können Netzwerkimplementierungen unsichere Captive-Portale, die offene Netzwerke verwenden, durch ein sicheres Passpoint-Netzwerk ersetzen. Eine Benachrichtigung wird dem Benutzer angezeigt, wenn die Bedingungen akzeptiert werden müssen.

Die URL der Nutzungsbedingungen muss auf eine sichere Website mit HTTPS verweisen. Wenn die URL auf eine unsichere Website verweist, trennt und blockiert das Framework sofort das Netzwerk.

URL für Informationen zum Veranstaltungsort

Ermöglicht Netzwerkbetreibern und Veranstaltungsorten, dem Benutzer zusätzliche Informationen bereitzustellen, z. B. Karten von Veranstaltungsorten, Verzeichnisse, Werbeaktionen und Coupons. Eine Benachrichtigung wird dem Benutzer angezeigt, wenn das Netzwerk verbunden ist.

Die URL mit Informationen zum Veranstaltungsort muss auf eine sichere Website mit HTTPS verweisen. Wenn die URL auf eine unsichere Website verweist, ignoriert das Framework die URL und zeigt keine Benachrichtigung an.

Andere Passpoint-Funktionen

Android 11 führt die folgenden Passpoint-Funktionen ein, die die Benutzererfahrung, den Stromverbrauch und die Bereitstellungsflexibilität verbessern.

Durchsetzung und Benachrichtigung des Ablaufdatums
Durch das Erzwingen von Ablaufdaten für Profile kann das Framework die automatische Verbindung zu Zugriffspunkten mit abgelaufenen Anmeldeinformationen vermeiden, die zwangsläufig fehlschlagen. Dies verhindert die Nutzung von Sendezeit und spart Akku und Backend-Bandbreite. Das Framework zeigt dem Benutzer eine Benachrichtigung an, wenn ein Netzwerk, das seinem Profil entspricht, in Reichweite ist und das Profil abgelaufen ist.
Mehrere Profile mit identischem FQDN
Netzbetreiber, die Passpoint-Netzwerke bereitstellen und mehrere PLMN-IDs (Public Land Mobile Network) verwenden, können mehrere Passpoint-Profile mit demselben FQDN bereitstellen, eines für jede PLMN-ID, die automatisch mit der installierten SIM-Karte abgeglichen und zum Verbinden mit dem Netzwerk verwendet wird.

Android 12 führt die folgenden Passpoint-Funktionen ein, die die Benutzererfahrung, den Stromverbrauch und die Bereitstellungsflexibilität verbessern:

Verziertes Identitätspräfix
Bei der Authentifizierung bei Netzwerken mit einer Präfixdekoration ermöglicht das dekorierte Identitätspräfix Netzwerkbetreibern, den Network Access Identifier (NAI) zu aktualisieren, um explizites Routing durch mehrere Proxys innerhalb eines AAA-Netzwerks durchzuführen (siehe RFC 7542 ). Android 12 implementiert diese Funktion gemäß der WBA-Spezifikation für PPS-MO-Erweiterungen .
Unmittelbare Handhabung der Deauthentifizierung
Ermöglicht Netzwerkbetreibern, einem Gerät zu signalisieren, dass der Dienst für die Anmeldeinformationen, die zur Authentifizierung beim Netzwerk verwendet werden, für eine bestimmte Dauer (angegeben durch eine Timeout-Verzögerung) nicht verfügbar ist. Nach dem Empfang dieses Signals versuchen die Geräte erst nach Ablauf der Timeout-Verzögerung, sich mit denselben Anmeldeinformationen erneut mit dem Netzwerk zu verbinden. Im Gegensatz dazu versuchen Geräte, die diese Funktion nicht unterstützen, möglicherweise wiederholt, sich erneut mit dem Netzwerk zu verbinden, während der Dienst nicht verfügbar ist.

Beispiele für OMA-DM-PerProviderSubscription-MO-XML-Profile

Profil mit Benutzername/Passwort-Anmeldeinformationen (EAP-TTLS)

Das folgende Beispiel zeigt ein Profil für ein Netzwerk mit:

  • Anzeigename des Example Network festgelegt
  • FQDN auf hotspot.example.net gesetzt
  • OIs des Roaming-Konsortiums (für Roaming)
  • Anmeldedaten mit Benutzername user , Passwort password codiert mit Base64 und Realm auf example.net festgelegt
  • EAP-Methode auf 21 eingestellt (EAP-TTLS)
  • Innere Methode der Phase 2 auf MS-CHAP-V2 eingestellt
  • Alternative AAA-Domainnamen sind auf trusted.com und trusted.net
<MgmtTree xmlns="syncml:dmddf1.2">
  <VerDTD>1.2</VerDTD>
  <Node>
    <NodeName>PerProviderSubscription</NodeName>
    <RTProperties>
      <Type>
        <DDFName>urn:wfa:mo:hotspot2dot0-perprovidersubscription:1.0</DDFName>
      </Type>
    </RTProperties>
    <Node>
      <NodeName>i001</NodeName>
      <Node>
        <NodeName>HomeSP</NodeName>
        <Node>
          <NodeName>FriendlyName</NodeName>
          <Value>Example Network</Value>
        </Node>
        <Node>
          <NodeName>FQDN</NodeName>
          <Value>hotspot.example.net</Value>
        </Node>
        <Node>
          <NodeName>RoamingConsortiumOI</NodeName>
          <Value>112233,445566</Value>
        </Node>
      </Node>
      <Node>
        <NodeName>Credential</NodeName>
        <Node>
          <NodeName>Realm</NodeName>
          <Value>example.net</Value>
        </Node>
        <Node>
          <NodeName>UsernamePassword</NodeName>
          <Node>
            <NodeName>Username</NodeName>
            <Value>user</Value>
          </Node>
          <Node>
            <NodeName>Password</NodeName>
            <Value>cGFzc3dvcmQ=</Value>
          </Node>
          <Node>
            <NodeName>EAPMethod</NodeName>
            <Node>
              <NodeName>EAPType</NodeName>
              <Value>21</Value>
            </Node>
            <Node>
              <NodeName>InnerMethod</NodeName>
              <Value>MS-CHAP-V2</Value>
            </Node>
          </Node>
        </Node>
      </Node>
      <Node>
        <NodeName>Extension</NodeName>
        <Node>
            <NodeName>Android</NodeName>
            <Node>
                <NodeName>AAAServerTrustedNames</NodeName>
                <Node>
                    <NodeName>FQDN</NodeName>
                    <Value>trusted.com;trusted.net</Value>
                </Node>
            </Node>
        </Node>
      </Node>
    </Node>
  </Node>
</MgmtTree>

Profil mit einem digitalen Zertifikatsnachweis (EAP-TLS)

Das folgende Beispiel zeigt ein Profil für ein Netzwerk mit:

  • Netzwerkfreundlicher Name auf GlobalRoaming gesetzt
  • FQDN auf globalroaming.net gesetzt
  • Roaming Consortium OIs (für Roaming)
  • Realm auf users.globalroaming.net gesetzt
  • Berechtigung mit einem digitalen Zertifikat, das den angegebenen Fingerabdruck hat
<MgmtTree xmlns="syncml:dmddf1.2">
  <VerDTD>1.2</VerDTD>
  <Node>
    <NodeName>PerProviderSubscription</NodeName>
    <RTProperties>
      <Type>
        <DDFName>urn:wfa:mo:hotspot2dot0-perprovidersubscription:1.0</DDFName>
      </Type>
    </RTProperties>
    <Node>
      <NodeName>i001</NodeName>
      <Node>
        <NodeName>HomeSP</NodeName>
        <Node>
          <NodeName>FriendlyName</NodeName>
          <Value>GlobalRoaming</Value>
        </Node>
        <Node>
          <NodeName>FQDN</NodeName>
          <Value>globalroaming.net</Value>
        </Node>
        <Node>
          <NodeName>RoamingConsortiumOI</NodeName>
          <Value>FFEEDDCC0,FFEEDDCC1,009999,008888</Value>
        </Node>
      </Node>
      <Node>
        <NodeName>Credential</NodeName>
        <Node>
          <NodeName>Realm</NodeName>
          <Value>users.globalroaming.net</Value>
        </Node>
        <Node>
          <NodeName>DigitalCertificate</NodeName>
          <Node>
            <NodeName>CertificateType</NodeName>
            <Value>x509v3</Value>
          </Node>
          <Node>
            <NodeName>CertSHA256Fingerprint</NodeName>
            <Value>0ef08a3d2118700474ca51fa25dc5e6d3d63d779aaad8238b608a853761da533</Value>
          </Node>
        </Node>
      </Node>
    </Node>
  </Node>
</MgmtTree>

Profil mit SIM-Anmeldeinformationen (EAP-AKA)

Das folgende Beispiel zeigt ein Profil für ein Netzwerk mit:

  • Netzwerkfreundlicher Name auf Purple Passpoint gesetzt
  • FQDN auf wlan.mnc888.mcc999.3gppnetwork.org
  • SIM-Anmeldeinformationen mit der PLMN-ID 999888
  • EAP-Methode auf 23 eingestellt (EAP-AKA)
<MgmtTree xmlns="syncml:dmddf1.2">
  <VerDTD>1.2</VerDTD>
  <Node>
    <NodeName>PerProviderSubscription</NodeName>
    <RTProperties>
      <Type>
        <DDFName>urn:wfa:mo:hotspot2dot0-perprovidersubscription:1.0</DDFName>
      </Type>
    </RTProperties>
    <Node>
      <NodeName>i001</NodeName>
      <Node>
        <NodeName>HomeSP</NodeName>
        <Node>
          <NodeName>FriendlyName</NodeName>
          <Value>Purple Passpoint</Value>
        </Node>
        <Node>
          <NodeName>FQDN</NodeName>
          <Value>purplewifi.com</Value>
        </Node>
      </Node>
      <Node>
        <NodeName>Credential</NodeName>
        <Node>
          <NodeName>Realm</NodeName>
          <Value>wlan.mnc888.mcc999.3gppnetwork.org</Value>
        </Node>
        <Node>
          <NodeName>SIM</NodeName>
          <Node>
            <NodeName>IMSI</NodeName>
            <Value>999888*</Value>
          </Node>
          <Node>
            <NodeName>EAPType</NodeName>
            <Value>23</Value>
          </Node>
        </Node>
      </Node>
    </Node>
  </Node>
</MgmtTree>

Auth-Beratung

Geräte mit Android 8.x oder Android 9 mit einem Passpoint R1 EAP-SIM-, EAP-AKA- oder EAP-AKA-Profil verbinden sich nicht automatisch mit dem Passpoint-Netzwerk. Dieses Problem wirkt sich auf Benutzer, Netzbetreiber und Dienste aus, da die Wi-Fi-Verschiebung reduziert wird.

Segment Einfluss Größe der Auswirkung
Netzbetreiber und Passpoint-Dienstleister Erhöhte Belastung des Mobilfunknetzes. Jeder Spediteur, der Passpoint R1 verwendet.
Benutzer Verpasste Gelegenheit, sich automatisch mit Carrier Wi-Fi Access Points (APs) zu verbinden, was zu höheren Datenkosten führt. Jeder Benutzer mit einem Gerät, das in einem Netzbetreiber läuft, der Passpoint R1 unterstützt.

Fehlerursache

Passpoint gibt einen Mechanismus an, um einen angekündigten (ANQP) Dienstanbieter einem auf dem Gerät installierten Profil zuzuordnen. Die folgenden Übereinstimmungsregeln für EAP-SIM, EAP-AKA und EAP-AKA' sind ein Teilsatz von Regeln, die sich auf die Fehler von EAP-SIM/AKA/AKA' konzentrieren:

If the FQDN (Fully Qualified Domain Name) matches
    then the service is a Home Service Provider.
Else: If the PLMN ID (3GPP Network) matches
    then the service is a Roaming Service Provider.

Das zweite Kriterium wurde in Android 8.0 modifiziert:

Else: If the PLMN ID (3GPP Network) matches AND the NAI Realm matches
    then the service is a Roaming Service Provider.

Mit dieser Änderung hat das System keine Übereinstimmung mit zuvor funktionierenden Dienstanbietern festgestellt, sodass Passpoint-Geräte keine automatische Verbindung hergestellt haben.

Problemumgehungen

Um das Problem der modifizierten Übereinstimmungskriterien zu umgehen, müssen Netzbetreiber und Dienstanbieter den Bereich der Netzwerkzugriffskennung (NAI) zu den vom Passpoint AP veröffentlichten Informationen hinzufügen.

Die empfohlene Lösung besteht darin, dass Netzwerkdienstanbieter eine netzwerkseitige Problemumgehung für die schnellste Bereitstellungszeit implementieren. Eine geräteseitige Problemumgehung hängt davon ab, dass OEMs eine Änderungsliste (CL) von AOSP abrufen und dann Geräte im Feld aktualisieren.

Netzwerkkorrektur für Netzbetreiber und Passpoint-Dienstanbieter

Die netzwerkseitige Problemumgehung erfordert eine Neukonfiguration des Netzwerks, um das ANQP-Element des NAI-Bereichs wie unten angegeben hinzuzufügen. Die Passpoint-Spezifikationen erfordern kein NAI-Realm-ANQP-Element, aber das Hinzufügen dieser Eigenschaft entspricht den Passpoint-Spezifikationen, sodass spezifikationskonforme Client-Implementierungen nicht brechen sollten.

  1. Fügen Sie das NAI-Realm-ANQP-Element hinzu.
  2. Stellen Sie das Unterfeld NAI-Realm so ein, dass es mit dem Realm des auf dem Gerät installierten Profils übereinstimmt.
  3. Legen Sie die folgenden Informationen basierend auf jedem EAP-Typ fest:

    • EAP-TTLS: Legen Sie EAPMethod(21) und unterstützte innere Authentifizierungstypen fest ( PAP , CHAP , MS-CHAP oder MS-CHAP-V2 )
    • EAP-TLS: EAPMethod(13)
    • EAP-SIM: EAPMethod(18)
    • EAP-AKA: EAPMethod(23)
    • EAP-AKA': Setze EAPMethod(50)

Geräte-/AOSP-Fix für OEMs

Um eine geräteseitige Problemumgehung zu implementieren, müssen OEMs den Patch CL aosp/718508 auswählen . Dieser Patch kann zusätzlich zu den folgenden Versionen angewendet werden (gilt nicht für Android 10 oder höher):

  • Android 9
  • Android 8.x

Wenn der Patch abgeholt wird, müssen OEMs Geräte im Feld aktualisieren.