Passpoint (Hotspot 2.0)

Passpoint ist ein Protokoll der Wi-Fi Alliance (WFA) , mit dem Mobilgeräte WLAN- Hotspots erkennen und sich bei ihnen authentifizieren können, um Internetzugriff zu erhalten.

Geräteunterstützung

Damit Gerätehersteller Passpoint unterstützen können, müssen sie die Supplicant-Schnittstelle implementieren. Ab Android 13 verwendet die Schnittstelle AIDL für die HAL-Definition. Bei Versionen vor Android 13 werden HIDL für Schnittstellen und Anbieterpartitionen verwendet. Die HIDL-Dateien befinden sich in hardware/interfaces/supplicant/1.x und die AIDL-Dateien in hardware/interfaces/supplicant/aidl. Der Supplicant unterstützt den 802.11u-Standard, insbesondere Funktionen zur Netzwerkerkennung und ‑auswahl wie Generic Advertisement Service (GAS) und Access Network Query Protocol (ANQP).

Implementierung

Die Passpoint-Implementierung variiert je nach Android-Version.

Android 11 oder höher

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

Android 10 oder niedriger

Bei Geräten mit Android 10 oder niedriger müssen Gerätehersteller sowohl Framework- als auch HAL- und Firmware-Unterstützung bereitstellen:

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

Implementieren Sie die WLAN-HAL und aktivieren Sie das Funktions-Flag für Passpoint, um Passpoint zu unterstützen. Ändern Sie in device.mk unter device/<oem>/<device> die PRODUCT_COPY_FILES Umgebungsvariable, um Unterstützung für das Passpoint-Feature einzuschließen:

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 für die Unterstützung von Passpoint sind in AOSP enthalten.

Validierung

Führen Sie die folgenden Unit-Tests für das Passpoint-Paket aus, um die Implementierung des Passpoint-Features zu validieren:

Diensttests:

atest com.android.server.wifi.hotspot2

Manager-Tests:

atest android.net.wifi.hotspot2

Passpoint R1-Bereitstellung

Android unterstützt Passpoint R1 seit Android 6.0. Dadurch können Passpoint R1-Anmeldedaten (Version 1) über das webbasierte Herunterladen einer speziellen Datei bereitgestellt werden, die Profil- und Anmeldeinformationen enthält. Der Client startet automatisch ein spezielles Installationsprogramm für die WLAN-Informationen und ermöglicht es dem Nutzer, Teile der Informationen anzusehen, bevor er die Inhalte akzeptiert oder ablehnt.

Die in der Datei enthaltenen Profilinformationen werden verwendet, um Daten abzugleichen, die von Passpoint-fähigen Zugriffspunkten abgerufen wurden. Die Anmeldedaten 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 und mit TLS (HTTPS) geschützt werden, da sie möglicherweise Klartextpasswörter oder private Schlüsseldaten enthält. Der Inhalt besteht aus umschlossenem mehrteiligem MIME-Text, der in UTF-8 dargestellt und gemäß RFC-2045, Abschnitt 6.8, in Base64 codiert ist.

Die folgenden HTTP-Headerfelder werden vom Client verwendet, um automatisch ein WLAN-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 festgelegt sein.

Die HTTP-Methode, die zum Abrufen der Datei verwendet wird, muss GET sein. Jedes Mal, wenn eine HTTP-GET-Anfrage vom Browser eine Antwort mit diesen MIME-Headern erhält, wird die Installations-App gestartet. Der Download muss durch Tippen auf ein HTML-Element wie eine 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 bieten möglicherweise ähnliche Funktionen.

Dateizusammensetzung

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

Bestandteil Content-Type (ohne Anführungszeichen) Erforderlich Beschreibung
Profil application/x-passpoint-profile Immer OMA-DM-SyncML-formatierte Nutzlast mit dem Passpoint R1 PerProviderSubscription-MO für HomeSP und Credential.
Vertrauenswürdiges Zertifikat application/x-x509-ca-cert Erforderlich für EAP-TLS und EAP-TTLS Eine einzelne base64-codierte X.509v3-Zertifikatsnutzlast.
EAP-TLS-Schlüssel application/x-pkcs12 Erforderlich für EAP-TLS Eine base64-codierte PKCS #12 ASN.1-Struktur, die eine Clientzertifikatskette mit mindestens dem Clientzertifikat 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 Abschnitt „Profil“ muss als base64-codierter, UTF-8-codierter XML-Text übertragen werden, der Teile der Unterstrukturen HomeSP und Credential in der technischen Spezifikation für Passpoint R2, Version 1.0.0, Abschnitt 9.1, angibt.

Der Knoten der obersten Ebene muss MgmtTree sein und der unmittelbare Unterknoten muss PerProviderSubscription sein. Ein Beispiel für eine XML-Datei finden Sie unter Beispiel für OMA-DM-XML für Profile.

Die folgenden Unterstrukturknoten werden unter HomeSP verwendet:

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

Die folgenden Unterstrukturknoten werden unter Credential verwendet:

  • Realm: Muss ein nicht leerer String sein

  • UsernamePassword: Erforderlich für EAP-TTLS mit den folgenden Knoten:

    • Username: String mit dem Nutzernamen
    • Password: Base64-codierter String (im folgenden Beispiel auf cGFzc3dvcmQ= gesetzt, den base64-codierten String für „password“)
    • EAPMethod/EAPType: Muss auf 21 gesetzt sein
    • EAPMethod/InnerMethod: Muss auf einen der folgenden Werte gesetzt sein: PAP, CHAP, MS-CHAP, oder MS-CHAP-V2

  • DigitalCertificate: Erforderlich für EAP-TLS. Die folgenden Knoten müssen festgelegt sein:

    • CertificateType auf x509v3 gesetzt
    • CertSHA256Fingerprint auf den korrekten SHA-256-Digest des Clientzertifikats im MIME-Abschnitt des EAP-TLS-Schlüssels gesetzt

  • SIM: Erforderlich für EAP-SIM, EAP-AKA und EAP-AKA'. Das Feld EAPType muss auf den entsprechenden EAP-Typ gesetzt sein und IMSI muss mit einer IMSI einer der SIM-Karten übereinstimmen, die zum Zeitpunkt der Bereitstellung im Gerät installiert sind. Der IMSI-String kann entweder nur aus Dezimalziffern bestehen, um eine vollständige Übereinstimmung zu erzwingen, oder aus 5 oder 6 Dezimalziffern, gefolgt von einem Sternchen (*), um die IMSI-Übereinstimmung auf MCC/MNC zu beschränken. Der IMSI-String 123456* stimmt beispielsweise mit jeder SIM-Karte überein, bei der MCC 123 und MNC 456 ist.

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

Separater AAA-Domainname (Authentifizierung, Autorisierung und Abrechnung)

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

  • Android: Unterstruktur für Android-Erweiterungen

    • AAAServerTrustedNames: Erforderlich für vertrauenswürdige Namen von AAA-Servern mit den folgenden Knoten:

      • FQDN: String mit den vertrauenswürdigen Namen von AAA-Servern. Trennen Sie die vertrauenswürdigen Namen durch Semikolons. Beispiel: example.org;example.com.
Selbstsignierte private Stammzertifizierungsstellen

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 Stamm-CA-Zertifikat zulassen

Das an das Profil angehängte Stamm-CA-Zertifikat wird für die AAA-Serverauthentifizierung verwendet. Passpoint-Netzwerkadministratoren, die für die AAA-Serverauthentifizierung auf öffentlich vertrauenswürdige Stammzertifizierungsstellen setzen möchten, können Profile ohne Stamm-CA-Zertifikat bereitstellen. In diesem Fall werden die AAA-Serverzertifikate anhand der im Trust Store installierten öffentlichen Stammzertifizierungsstellen-Zertifikate überprüft.

Passpoint R2-Bereitstellung

Android 10 hat die Unterstützung für Passpoint R2-Funktionen eingeführt. Passpoint R2 implementiert die Online-Registrierung (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 offene OSU-ESS.

Für die unterstützten Passpoint R2-Funktionen ist nur AOSP-Referenzcode erforderlich. Zusätzliche Treiber- oder Firmware-Unterstützung ist nicht erforderlich. Der AOSP-Referenzcode enthält auch eine Standardimplementierung der Passpoint R2-UI in der App „Einstellungen“.

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

  1. Es zeigt im WLAN-Auswahlmenü eine Liste der vom ZP beworbenen Dienstleister an (zusätzlich zu den SSIDs).
  2. Es fordert den Nutzer auf, auf einen der Dienstanbieter zu tippen, um ein Passpoint-Profil einzurichten.
  3. Es führt den Nutzer durch den Einrichtungsprozess für das Passpoint-Profil.
  4. Bei erfolgreicher Einrichtung wird das resultierende Passpoint-Profil installiert.
  5. Es stellt mit dem neu bereitgestellten Passpoint-Profil eine Verbindung zum Passpoint-Netzwerk her.

Passpoint R3-Funktionen

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

Nutzungsbedingungen

In einigen Orten und Veranstaltungsorten ist die Annahme der Nutzungsbedingungen rechtlich erforderlich, um Netzwerkzugriff zu erhalten. Mit dieser Funktion können Netzwerke unsichere Captive Portals, die offene Netzwerke verwenden, durch ein sicheres Passpoint-Netzwerk ersetzen. Der Nutzer wird benachrichtigt, wenn die Nutzungsbedingungen akzeptiert werden müssen.

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

URL mit Informationen zum Veranstaltungsort

Netzwerkbetreiber und Veranstaltungsorte können dem Nutzer zusätzliche Informationen zur Verfügung stellen, z. B. Karten, Verzeichnisse, Angebote und Gutscheine. Der Nutzer wird benachrichtigt, 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, wird sie vom Framework ignoriert und es wird keine Benachrichtigung angezeigt.

Weitere Passpoint-Funktionen

Android 11 führt die folgenden Passpoint-Funktionen ein, die die Nutzerfreundlichkeit, den Energieverbrauch und die Flexibilität bei der Bereitstellung verbessern.

Erzwingen von Ablaufdaten und Benachrichtigungen
Durch das Erzwingen von Ablaufdaten für Profile kann das Framework automatische Verbindungen zu Zugriffspunkten mit abgelaufenen Anmeldedaten vermeiden, die mit Sicherheit fehlschlagen. Dadurch wird die Nutzung der Airtime verhindert und Akku und Backend-Bandbreite werden geschont. Das Framework zeigt dem Nutzer eine Benachrichtigung an, wenn ein Netzwerk, das seinem Profil entspricht, in Reichweite ist und das Profil abgelaufen ist.
Mehrere Profile mit identischem FQDN
Mobilfunkanbieter, 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. Diese werden automatisch mit der installierten SIM-Karte abgeglichen und verwendet, um eine Verbindung zum Netzwerk herzustellen.

Android 12 führt die folgenden Passpoint-Funktionen ein, die die Nutzerfreundlichkeit, den Energieverbrauch und die Flexibilität bei der Bereitstellung verbessern:

Präfix für die dekorierte Identität
Bei der Authentifizierung in Netzwerken mit einem Präfix für die dekorierte Identität können Netzwerkbetreiber den Network Access Identifier (NAI) aktualisieren, um explizites Routing über 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.
Umgang mit bevorstehender Deauthentifizierung
Netzwerkbetreiber können einem Gerät signalisieren, dass der Dienst für die Anmeldedaten, die zur Authentifizierung im Netzwerk verwendet werden, für eine bestimmte Zeit (angegeben durch eine Timeout-Verzögerung) nicht verfügbar ist. Nachdem Geräte dieses Signal erhalten haben, versuchen sie erst nach Ablauf der Timeout-Verzögerung, mit denselben Anmeldedaten eine Verbindung zum Netzwerk herzustellen. Im Gegensatz dazu versuchen Geräte, die diese Funktion nicht unterstützen, möglicherweise wiederholt, eine Verbindung zum Netzwerk herzustellen, während der Dienst nicht verfügbar ist.

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

Profil mit Anmeldedaten für Nutzername und Passwort (EAP-TTLS)

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

  • Netzwerkname auf Example Network gesetzt
  • FQDN auf hotspot.example.net gesetzt
  • Roaming-Konsortiums-OIs (für Roaming)
  • Anmeldedaten mit Nutzername user, Passwort password (mit Base64 codiert) und Realm auf example.net gesetzt
  • EAP-Methode auf 21 (EAP-TTLS) gesetzt
  • Innere Methode der Phase 2 auf MS-CHAP-V2 gesetzt
  • Alternative AAA-Domainnamen auf trusted.com und trusted.net gesetzt
<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 Anmeldedaten für ein digitales Zertifikat (EAP-TLS)

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

  • Netzwerkname auf GlobalRoaming gesetzt
  • FQDN auf globalroaming.net gesetzt
  • Roaming-Konsortiums-OIs (für Roaming)
  • Realm auf users.globalroaming.net gesetzt
  • Anmeldedaten 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-Anmeldedaten (EAP-AKA)

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

  • Netzwerkname auf Purple Passpoint gesetzt
  • FQDN auf wlan.mnc888.mcc999.3gppnetwork.org gesetzt
  • SIM-Anmeldedaten mit PLMN-ID 999888
  • EAP-Methode auf 23 (EAP-AKA) gesetzt
<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>
PerProviderSubscription

Hinweis zur Authentifizierung

Geräte mit Android 8.x oder Android 9 mit einem Passpoint R1-Profil für EAP-SIM, EAP-AKA oder EAP-AKA' stellen keine automatische Verbindung zum Passpoint-Netzwerk her. Dieses Problem betrifft Nutzer, Mobilfunkanbieter und Dienste, da es die WLAN-Auslagerung reduziert.

Segment Auswirkungen Umfang der Auswirkungen
Mobilfunkanbieter und Passpoint-Dienstanbieter Erhöhte Last im Mobilfunknetz. Alle Mobilfunkanbieter, die Passpoint R1 verwenden.
Nutzer Verpasste Gelegenheit, automatisch eine Verbindung zu WLAN-Zugriffspunkten des Mobilfunkanbieters herzustellen (APs), was zu höheren Datenkosten führt. Alle Nutzer mit einem Gerät, das in einem Mobilfunknetz mit Unterstützung für Passpoint R1 verwendet wird.

Fehlerursache

Passpoint gibt einen Mechanismus an, um einen beworbenen (ANQP) Dienstanbieter mit einem auf dem Gerät installierten Profil abzugleichen. Die folgenden Abgleichsregeln für EAP-SIM, EAP-AKA und EAP-AKA' sind eine Teilmenge von Regeln, die sich auf die Fehler bei 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.

Durch diese Änderung wurde keine Übereinstimmung für zuvor funktionierende Dienstanbieter gefunden, sodass Passpoint-Geräte keine automatische Verbindung herstellten.

Problemumgehungen

Um das Problem der geänderten Abgleichskriterien zu umgehen, müssen Mobilfunkanbieter und Dienstanbieter den NAI-Realm (Network Access Identifier) zu den Informationen hinzufügen, die vom Passpoint-Zugriffspunkt veröffentlicht werden.

Die empfohlene Lösung besteht darin, dass Netzwerkdienstanbieter eine Problemumgehung auf Netzwerkseite implementieren, um die Bereitstellungszeit zu verkürzen. Eine Problemumgehung auf Geräteseite hängt davon ab, ob OEMs eine Änderungsliste (Changelist, CL) von AOSP übernehmen und dann Geräte im Feld aktualisieren.

Netzwerkseitige Lösung für Mobilfunkanbieter und Passpoint-Dienstanbieter

Für die Problemumgehung auf Netzwerkseite muss das Netzwerk neu konfiguriert werden, um das ANQP-Element für den NAI-Bereich wie folgt hinzuzufügen. Die Passpoint-Spezifikationen erfordern das ANQP-Element für den NAI-Realm nicht, aber das Hinzufügen dieser Eigenschaft entspricht den Passpoint-Spezifikationen, sodass spezifikationskonforme Clientimplementierungen nicht beeinträchtigt werden sollten.

  1. Fügen Sie das ANQP-Element für den NAI-Realm hinzu.
  2. Setzen Sie das Unterfeld für den NAI-Realm so, dass es mit dem Realm des auf dem Gerät installierten Profils übereinstimmt.
  3. Legen Sie die folgenden Informationen basierend auf dem jeweiligen EAP-Typ fest:
    • EAP-TTLS: Legen Sie EAPMethod(21) und die unterstützten inneren Authentifizierungstypen (PAP, CHAP, MS-CHAP oder MS-CHAP-V2) fest.
    • EAP-TLS: Legen Sie EAPMethod(13) fest.
    • EAP-SIM: Legen Sie EAPMethod(18) fest.
    • EAP-AKA: Legen Sie EAPMethod(23) fest.
    • EAP-AKA': Legen Sie EAPMethod(50) fest.

Geräte-/AOSP-Lösung für OEMs

Um eine Problemumgehung auf Geräteseite zu implementieren, müssen OEMs die Patch-CL aosp/718508 übernehmen. Dieser Patch kann auf die folgenden Versionen angewendet werden (gilt nicht für Android 10 oder höher):

  • Android 9
  • Android 8.x

Wenn der Patch übernommen wurde, müssen OEMs Geräte im Feld aktualisieren.