Passpunkt (Hotspot 2.0)

Passpoint ist ein Wi-Fi Alliance (WFA) Protokoll , die mobilen Geräte Wi-Fi - Hotspots , die die Internet - Zugang bieten zu entdecken und zu beglaubigen ermöglicht.

Geräteunterstützung

Passpoint , Gerätehersteller implementieren müssen zur Unterstützung hardware/interfaces/wifi/supplicant/1.0 oder höher. Die Wi-Fi - HAL - Interface - Design - Sprache (HIDL) zur Verfügung gestellt im Android Open Source Project (AOSP) eine HAL an 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 die 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. In device.mk befindet sich in device/<oem>/<device> , ändern Sie die PRODUCT_COPY_FILES variable Umgebung Unterstützung für die Passpoint- Funktion sind:

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 Komponententests und Integrationstests, die in der Android Comms Test Suite (ACTS) bereitgestellt werden.

Unit-Tests

Führen Sie die folgenden Komponententests für das Passpoint-Paket aus.

Servicetests:

atest com.android.server.wifi.hotspot2

Managertests:

atest android.net.wifi.hotspot2

Integrationstests (ACTS)

Die ACTS Passpoint- Test - Suite, in tools/test/connectivity/acts/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 wurden, und die Anmeldeinformationen werden automatisch für jedes übereinstimmende 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 sein, da sie Klartextpasswörter oder private Schlüsseldaten enthalten kann. Der Inhalt besteht aus umschlossenem mehrteiligem MIME-Text, der in UTF-8 dargestellt und in Base64-Codierung gemäß RFC-2045 Abschnitt 6.8 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 eingestellt werden application/x-wifi-config - application/x-wifi-config .
  • Content-Transfer-Encoding muss eingestellt werden base64 .
  • Content-Disposition muss nicht eingestellt 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 bereitstellen oder nicht.

Dateizusammenstellung

Die Base64 codierte Inhalt von MIME - Multipart - Inhalten mit einer bestehen muß Content-Type von multipart/mixed . Die folgenden Teile bilden die einzelnen Teile des mehrteiligen Inhalts.

Teil Inhaltstyp (ohne Anführungszeichen) Erforderlich Beschreibung
Profil application/x-passpoint-profile Immer OMA-DM SyncML formatiert die Nutzlast Passpoint R1 enthält PerProviderSubscription formatiert MO für HomeSP und Credential .
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 Profilschnitt muss als Base64-kodiert, UTF-8-codierten XML - Text, der angibt , Teile der übertragen werden HomeSP und Credential Teilbäume in der R2 Passpoint Technische Spezifikation Version 1.0.0, Abschnitt 9.1.

Der Top-Level - Knoten muss sein MgmtTree und der sofortige Unterknoten muss PerProviderSubscription . Ein Beispiel XML - Datei wird im Beispiel Profil OMA-DM XML .

Der folgende Teilbaum - Knoten wird unter verwendet HomeSP :

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

Der folgende Teilbaum - Knoten wird unter verwendet Credential :

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

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

    • CertificateType auf x509v3
    • CertSHA256Fingerprint Satz auf den korrekten SHA-256 verdauen des Client - Zertifikats in der EAP-TLS Schlüssel MIME Abschnitt
  • SIM : Erforderlich für die EAP-SIM, EAP-AKA und EAP-AKA. Das EAPType Feld muss auf den entsprechenden EAP - Typen festgelegt werden und IMSI muss eine IMSI eines der SIM - Karten in dem Gerät zum Zeitpunkt der Bereitstellung installiert entsprechen. 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 nur auf das Präfix zu lockern. Zum Beispiel stimmt der IMSI-String 123* mit jeder SIM-Karte überein, deren IMSI mit 123 beginnt.

Android 11 bietet Funktionen, die die Bereitstellung von Passpoint R1 flexibler machen.

Separater Domainname für Authentifizierung, Autorisierung und Abrechnung (AAA)

Passpoint Netzwerkadministratoren , die ein AAA - Domain - Namen benötigen angegeben unabhängig von der Fully Qualified Domain Name (FQDN) von dem Netzwerk beworbenen durch den Access Network Query - Protocol (ANQP) ein Semikolon getrennte Liste von FQDNs in einem neuen Knoten unter dem angeben Extension subtree . Dies ist ein optionaler Knoten und Geräte mit Android Version 10 oder niedriger ignorieren diesen Knoten.

  • Android : Android Erweiterung subtree

    • AAAServerTrustedNames : Erforderlich für die AAA - Server vertrauenswürdiger Namen mit dem folgenden Knoten festgelegt:

      • FQDN : String, der den AAA - Server enthält vertraute Namen. Verwenden Sie Semikolons, um die vertrauenswürdigen Namen zu trennen. Zum 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 Root-CA-Zertifikat wird für die AAA-Serverauthentifizierung verwendet. Passpoint-Netzwerkadministratoren, die sich für ihre AAA-Serverauthentifizierung auf öffentliche vertrauenswürdige Stammzertifizierungsstellen verlassen möchten, können Profile ohne ein Stammzertifizierungsstellenzertifikat bereitstellen. In diesem Fall verifiziert das System die AAA-Serverzertifikate mit den im Truststore installierten öffentlichen Root-CA-Zertifikaten.

Passpoint R2-Bereitstellung

Mit Android 10 wurde die Unterstützung für Passpoint R2-Funktionen eingeführt. Passpoint R2 implementiert die Online-Anmeldung (OSU), eine Standardmethode zum Bereitstellen neuer Passpoint-Profile. Android 10 und höher unterstützt die Bereitstellung von EAP-TTLS-Profilen mithilfe des SOAP-XML-Protokolls über offenes OSU ESS.

Die unterstützten Passpoint R2-Funktionen, die unterstützt werden, 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 vom AP angekündigten Dienstanbieter in der Wi-Fi-Auswahl an (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 das Passpoint-Profil.
  4. Installiert das resultierende Passpoint-Profil nach erfolgreichem Abschluss.
  5. Wird dem Passpoint-Netzwerk mithilfe des neu bereitgestellten Passpoint-Profils zugeordnet.

Passpoint R3-Funktionen

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

Geschäftsbedingungen
Die Annahme der Geschäftsbedingungen ist an einigen Standorten und Veranstaltungsorten gesetzlich vorgeschrieben, um den Netzwerkzugang bereitzustellen. Mit dieser Funktion können Netzwerkbereitstellungen unsichere Captive-Portale, die offene Netzwerke verwenden, durch ein sicheres Passpoint-Netzwerk ersetzen. Dem Benutzer wird eine Benachrichtigung angezeigt, wenn die Bedingungen akzeptiert werden müssen.
Veranstaltungsort-Informations-URL
Ermöglicht Netzbetreibern und Veranstaltungsorten, dem Benutzer zusätzliche Informationen bereitzustellen, z. B. Karten der Veranstaltungsorte, Verzeichnisse, Werbeaktionen und Coupons. Dem Benutzer wird eine Benachrichtigung angezeigt, wenn das Netzwerk verbunden ist.

Andere Passpoint-Funktionen

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

Durchsetzung und Benachrichtigung des Ablaufdatums
Das Erzwingen von Ablaufdaten für Profile ermöglicht es dem Framework, die automatische Verbindung mit Zugriffspunkten mit abgelaufenen Anmeldeinformationen zu vermeiden, die zwangsläufig fehlschlagen. Dies verhindert die Nutzung von Sendezeit und spart Akku- und Back-End-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 zur Verbindung mit dem Netzwerk verwendet wird.

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

Dekoriertes Identitätspräfix
Wenn auf Netzwerke mit einem Präfix Dekoration Authentifizierung erlaubt der eingerichtete Identität Präfix Netzbetreiber das Network Access Identifier (NAI) zu aktualisieren innerhalb eines AAA - Netzes (siehe expliziten Routing über mehrere Proxys ausführen RFC 7542 ). Android 12 implementiert diese Funktion nach der WBA - Spezifikation für PPS-MO - Erweiterungen .
Deauthentifizierung unmittelbar bevorstehende Handhabung
Ermöglicht Netzwerkbetreibern, einem Gerät zu signalisieren, dass der Dienst für die zur Authentifizierung beim Netzwerk verwendeten Anmeldeinformationen für eine bestimmte Dauer (angegeben durch eine Zeitüberschreitungsverzögerung) nicht verfügbar ist. Nach Erhalt dieses Signals versuchen die Geräte erst nach Ablauf der Zeitüberschreitung, sich mit denselben Anmeldeinformationen wieder mit dem Netzwerk zu verbinden. Im Gegensatz dazu versuchen Geräte, die diese Funktion nicht unterstützen, möglicherweise wiederholt, sich wieder 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-Anmeldedaten (EAP-TTLS)

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

  • Netzwerk freundlicher Name Satz Example Network
  • FQDN Set hotspot.example.net
  • Roaming-Konsortium-OIs (für Roaming)
  • Credential mit Benutzername user , Passwort password mit Base64 codiert und Reich Satz example.net
  • EAP Verfahren Satz 21 (EAP-TTLS)
  • Phase-2 innere Verfahren Satz MS-CHAP-V2
  • Alternativer AAA Domain - Name 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:

  • Netzwerk freundlichen Name Satz GlobalRoaming
  • FQDN Set globalroaming.net
  • OIs des Roaming-Konsortiums (für Roaming)
  • Realm - Set users.globalroaming.net
  • Berechtigungsnachweis mit einem digitalen Zertifikat mit dem angegebenen Fingerabdruck
<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:

  • Netzwerk angezeigte Name Set Purple Passpoint
  • FQDN Set wlan.mnc888.mcc999.3gppnetwork.org
  • SIM Credential mit PLMN ID 999888
  • EAP Verfahren Satz 23 (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, auf denen Android 8.x oder Android 9 mit einem Passpoint R1-EAP-SIM-, EAP-AKA- oder EAP-AKA-Profil ausgeführt wird, verbinden sich nicht automatisch mit dem Passpoint-Netzwerk. Dieses Problem betrifft Benutzer, Netzbetreiber und Dienste, indem es den Wi-Fi-Offload reduziert.

Segment Auswirkung Größe des Aufpralls
Spediteure und Passpoint-Dienstleister Erhöhte Belastung des Mobilfunknetzes. Jeder Mobilfunkanbieter, der Passpoint R1 verwendet.
Benutzer Verpasste Gelegenheit, sich automatisch mit den WLAN-Zugangspunkten (APs) von Carriern zu verbinden, was zu höheren Datenkosten führt. Jeder Benutzer mit einem Gerät, das in einem Mobilfunknetz ausgeführt wird, das Passpoint R1 unterstützt.

Fehlerursache

Passpoint gibt einen Mechanismus an, um einen angekündigten (ANQP) Dienstanbieter mit einem auf dem Gerät installierten Profil abzugleichen. Die folgenden Abgleichsregeln 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 geändert:

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

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

Problemumgehungen

Um das Problem der geänderten Ü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 Mobilfunkanbieter und Passpoint-Dienstanbieter

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

  1. Fügen Sie das ANQP-Element des NAI-Realms hinzu.
  2. Stellen Sie den NAI Reich Teilfeld die übereinstimmen Realm des Profils auf dem Gerät installiert.
  3. Legen Sie die folgenden Informationen basierend auf jedem EAP-Typ fest:

    • EAP-TTLS: Set EAPMethod(21) und unterstützte innere auth Typen ( PAP , CHAP , MS-CHAP oder MS-CHAP-V2 )
    • EAP-TLS: Set EAPMethod(13)
    • EAP-SIM: Set EAPMethod(18)
    • EAP-AKA: Set EAPMethod(23)
    • EAP-AKA ': Set EAPMethod(50)

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

Um eine geräteseitige Problemumgehung zu implementieren, benötigen OEMs den Patch CL holen AOSP / 718508 . 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 vor Ort aktualisieren.