Passpoint (Hotspot 2.0)

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

Gerätesupport

Zur Unterstützung von Passpoint müssen Gerätehersteller die Supplicant-Schnittstelle implementieren. Ab Android 13 verwendet die Schnittstelle AIDL für die HAL-Definition. Bei Releases vor Android 13 werden für Schnittstellen und Anbieterpartitionen HIDL 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 den Generic Advertisement Service (GAS) und das Access Network Query Protocol (ANQP).

Implementierung

Android 11 oder höher

Damit Passpoint auf Geräten mit Android 11 oder höher unterstützt wird, müssen Gerätehersteller Firmware-Unterstützung für 802.11u bereitstellen. Alle anderen Anforderungen für die Unterstützung von Passpoint sind im 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 Funktions-Flag)
  • Firmware: Unterstützung für 802.11u

Implementieren Sie die Wi‑Fi HAL und aktivieren Sie das Feature-Flag für Passpoint, um Passpoint zu unterstützen. Ändern Sie in device.mk unter device/<oem>/<device> die Umgebungsvariable PRODUCT_COPY_FILES, um die Unterstützung für die Passpoint-Funktion hinzuzufügen:

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 im AOSP enthalten.

Zertifizierungsstufe

Führen Sie die folgenden Unit-Tests für das Passpoint-Paket aus, um die Implementierung der Passpoint-Funktion 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 (Release 1) durch webbasiertes Herunterladen einer speziellen Datei mit Profil- und Anmeldedaten bereitgestellt werden. Der Client startet automatisch ein spezielles Installationsprogramm für die WLAN-Informationen und ermöglicht es dem Nutzer, Teile der Informationen aufzurufen, bevor er den Inhalt akzeptiert oder ablehnt.

Die in der Datei enthaltenen Profilinformationen werden zum Abgleich mit Daten verwendet, die von Passpoint-kompatiblen Zugangspunkten abgerufen wurden. Die Anmeldedaten werden dann automatisch für jedes übereinstimmende Netzwerk angewendet.

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

Downloadmechanismus

Die Passpoint-Konfigurationsdatei muss auf einem Webserver gehostet und mit TLS (HTTPS) geschützt werden, da sie Passwörter im Klartext oder Daten für private Schlüssel enthalten kann. Der Inhalt besteht aus umschlossenem mehrteiligem MIME-Text in UTF-8 und einer base64-Codierung gemäß RFC-2045-Abschnitt 6.8.

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

  • Für „Content-Type“ muss „application/x-wifi-config“ festgelegt werden.
  • Für „Content-Transfer-Encoding“ muss „base64“ festgelegt werden.
  • Content-Disposition darf nicht festgelegt werden.

Die zum Abrufen der Datei verwendete HTTP-Methode muss GET sein. Jedes Mal, wenn eine HTTP-GET-Anfrage vom Browser eine Antwort mit diesen MIME-Headern erhält, wird die Installationsanwendung gestartet. Der Download muss durch Tippen auf ein HTML-Element, z. B. 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

Die Base64-codierten Inhalte müssen aus MIME-Multipart-Inhalten mit einer Content-Type von multipart/mixed bestehen. Die folgenden Teile bilden die einzelnen Teile der mehrteiligen Inhalte.

Teil Content-Type (weniger Anführungszeichen) Erforderlich Beschreibung
Profil application/x-passpoint-profile Immer OMA-DM-SyncML-formatierte Nutzlast mit der Passpoint-R1-PerProviderSubscription-formatierten MO für HomeSP und Credential.
Zertifikat vertrauen application/x-x509-ca-cert Erforderlich für EAP-TLS und EAP-TTLS Eine einzelne base64-codierte X.509v3-Zertifikatnutzlast.
EAP-TLS-Schlüssel application/x-pkcs12 Für EAP-TLS erforderlich Eine base64-codierte PKCS #12-ASN.1-Struktur mit einer Clientzertifikatskette mit mindestens dem Clientzertifikat und dem zugehörigen privaten Schlüssel. Der PKCS 12-Container sowie der private Schlüssel und die Zertifikate müssen im Klartext ohne Passwort vorliegen.

Der Abschnitt „Profil“ muss als Base64-codierter, UTF-8-codierter XML-Text übertragen werden, der Teile der untergeordneten Knoten HomeSP und Credential in der Passpoint R2-technischen Spezifikation Version 1.0.0, Abschnitt 9.1, angibt.

Der Knoten der obersten Ebene muss MgmtTree und der unmittelbare untergeordnete Knoten muss PerProviderSubscription sein. Eine Beispiel-XML-Datei finden Sie unter Beispielprofil OMA-DM XML.

Unter HomeSP werden die folgenden untergeordneten Knoten verwendet:

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

Unter Credential werden die folgenden untergeordneten Knoten verwendet:

  • Realm: Muss ein nicht leerer String sein.

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

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

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

    • CertificateType festgelegt als x509v3
    • CertSHA256Fingerprint muss im MIME-Abschnitt des EAP-TLS-Schlüssels auf den korrekten SHA-256-Digest des Clientzertifikats festgelegt sein.

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

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

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

Passpoint-Netzwerkadministratoren, die einen AAA-Domainnamen benötigen, der unabhängig vom vom Netzwerk über das ANQP (Access Network Query Protocol) angegebenen FQDN (Fully Qualified Domain Name) angegeben ist, können in einem neuen Knoten unter dem untergeordneten Knoten Extension eine durch Semikolons getrennte Liste von FQDNs angeben. Dies ist ein optionaler Knoten. Auf Geräten mit Android 10 oder niedriger wird er ignoriert.

  • Android: Unterbaum der Android-Erweiterung

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

      • FQDN: String, der die vertrauenswürdigen Namen des AAA-Servers enthält. Trennen Sie die vertrauenswürdigen Namen durch Semikolons. Beispiel: example.org;example.com.
Selbst signierte private Stamm-CAs
Passpoint-Netzwerkadministratoren, die ihre Zertifikate intern verwalten, können Profile mit einer privaten selbst signierten Zertifizierungsstelle für die AAA-Authentifizierung bereitstellen.
Installation von Profilen ohne Stamm-CA-Zertifikat zulassen
Das an das Profil angehängte Root-CA-Zertifikat wird für die AAA-Serverauthentifizierung verwendet. Passpoint-Netzwerkadministratoren, die für ihre AAA-Serverauthentifizierung auf öffentliche vertrauenswürdige Root-Zertifizierungsstellen zurückgreifen möchten, können Profile ohne Root-CA-Zertifikat bereitstellen. In diesem Fall werden die AAA-Serverzertifikate vom System anhand der öffentlichen Root-CA-Zertifikate verifiziert, die im Trust-Store installiert sind.

Passpoint R2-Bereitstellung

Mit Android 10 werden nun Passpoint R2-Funktionen unterstützt. 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 das offene OSU-ESS.

Für die unterstützten Passpoint R2-Funktionen ist nur der AOSP-Referenzcode erforderlich. Es ist keine zusätzliche Treiber- oder Firmwareunterstützung erforderlich. Der AOSP-Referenzcode enthält auch eine Standardimplementierung der Passpoint R2-Benutzeroberfläche in den Einstellungen.

Wenn Android einen Passpoint R2-Zugangspunkt erkennt, führt das Android-Framework folgende Aktionen aus:

  1. In der WLAN-Auswahl wird eine Liste der Dienstanbieter angezeigt, die vom ZP beworben werden (zusätzlich zu den SSIDs).
  2. Der Nutzer wird aufgefordert, einen der Dienstanbieter anzutippen, um ein Passpoint-Profil einzurichten.
  3. Der Nutzer wird durch die Einrichtung des Passpoint-Profils geführt.
  4. Das resultierende Passpoint-Profil wird nach erfolgreichem Abschluss installiert.
  5. Verbindet sich mithilfe des neu bereitgestellten Passpoint-Profils mit dem Passpoint-Netzwerk.

Passpoint R3-Funktionen

Mit Android 12 werden die folgenden Passpoint R3-Funktionen eingeführt, die die Nutzerfreundlichkeit verbessern und es Netzwerken ermöglichen, die lokalen Gesetze einzuhalten:

Nutzungsbedingungen

An einigen Orten und Orten ist die Annahme der Nutzungsbedingungen rechtlich erforderlich, um den Netzwerkzugriff zu ermöglichen. Mit dieser Funktion können bei Netzwerkimplementierungen unsichere Captive Portals, die offene Netzwerke verwenden, durch ein sicheres Passpoint-Netzwerk ersetzt werden. Der Nutzer sieht eine Benachrichtigung, wenn die Nutzungsbedingungen akzeptiert werden müssen.

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

URL zum Veranstaltungsort

Ermöglicht es Betreibern von Übertragungsnetzwerken und Veranstaltungsorten, Nutzern zusätzliche Informationen zur Verfügung zu stellen, z. B. Karten, Verzeichnisse, Werbeaktionen und Gutscheine. Wenn eine Netzwerkverbindung besteht, wird dem Nutzer eine Benachrichtigung angezeigt.

Die URL der 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

Mit Android 11 werden die folgenden Passpoint-Funktionen eingeführt, die die Nutzerfreundlichkeit, den Energieverbrauch und die Flexibilität der Bereitstellung verbessern.

Erzwingung und Benachrichtigung zum Ablaufdatum
Durch die Erzwingung von Ablaufdaten für Profile kann das Framework die automatische Verbindung zu Zugangspunkten mit abgelaufenen Anmeldedaten vermeiden, die zwangsläufig fehlschlagen. So wird die Nutzung der Sendezeit verhindert und Akku und Backend-Bandbreite werden geschont. Das Framework zeigt dem Nutzer eine Benachrichtigung an, wenn sich ein Netzwerk in Reichweite befindet, das seinem Profil entspricht, 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, jeweils eines für jede PLMN-ID. Diese werden automatisch mit der installierten SIM-Karte abgeglichen und für die Netzwerkverbindung verwendet.

Mit Android 12 werden die folgenden Passpoint-Funktionen eingeführt, die die Nutzerfreundlichkeit, den Energieverbrauch und die Flexibilität der Bereitstellung verbessern:

Dekoriertes Identitätspräfix
Bei der Authentifizierung in Netzwerken mit Präfixdekoration können Netzwerkbetreiber über das dekorierte Identitätspräfix den Network Access Identifier (NAI) aktualisieren, um ein explizites Routing über mehrere Proxys innerhalb eines AAA-Netzwerks durchzuführen (siehe RFC 7542). In Android 12 wird diese Funktion gemäß der WBA-Spezifikation für PPS-MO-Erweiterungen implementiert.
Umgang mit bevorstehender Deaktivierung
Ermöglicht Netzwerkbetreibern, einem Gerät zu signalisieren, dass der Dienst für die zur Authentifizierung beim Netzwerk verwendeten Anmeldedaten 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 Anmeldedaten wieder mit dem Netzwerk zu verbinden. Geräte, die diese Funktion nicht unterstützen, versuchen dagegen möglicherweise wiederholt, sich mit dem Netzwerk zu verbinden, während der Dienst nicht verfügbar ist.

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

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

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

  • Netzwerkfreundlicher Name auf „Example Network“ festgelegt
  • FQDN auf hotspot.example.net festgelegt
  • OIs des Roaming-Konsortiums (für Roaming)
  • Anmeldedaten mit dem Nutzernamen user, dem Base64-codierten Passwort password und dem Realm example.net
  • EAP-Methode auf 21 (EAP-TTLS) festgelegt
  • Innere Phase-2-Methode auf MS-CHAP-V2 festgelegt
  • Alternative AAA-Domainnamen wurden auf trusted.com und trusted.net festgelegt
<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:

  • Netzwerkfreundlicher Name auf „GlobalRoaming“ festgelegt
  • FQDN auf globalroaming.net festgelegt
  • OIs des Roaming-Konsortiums (für Roaming)
  • Bereich auf users.globalroaming.net festgelegt
  • 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:

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

Authentifizierungshinweis

Geräte mit Android 8.x oder Android 9 mit einem Passpoint R1 EAP-SIM-, EAP-AKA- oder EAP-AKA'-Profil stellen keine automatische Verbindung zum Passpoint-Netzwerk her. Dieses Problem wirkt sich auf Nutzer, Mobilfunkanbieter und Dienste aus, da die WLAN-Entlastung reduziert wird.

Segment Auswirkungen Umfang der Auswirkungen
Mobilfunkanbieter und Passpoint-Anbieter Erhöhte Belastung des Mobilfunknetzes. Alle Mobilfunkanbieter, die Passpoint R1 verwenden
Nutzer Verpasste Gelegenheit, automatisch eine Verbindung zu Wi-Fi-Zugangspunkten des Mobilfunkanbieters herzustellen, was zu höheren Datenkosten führt. Jeder Nutzer mit einem Gerät, das in einem Mobilfunknetz ausgeführt wird, das Passpoint R1 unterstützt.

Fehlerursache

Passpoint gibt einen Mechanismus an, mit dem ein beworbener Dienstanbieter (ANQP) mit einem auf dem Gerät installierten Profil abgeglichen wird. Die folgenden Abgleichsregeln für EAP-SIM, EAP-AKA und EAP-AKA' sind eine Teilmenge der Regeln, die sich auf EAP-SIM-/AKA-/AKA'-Fehler 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 konnte das System keine Übereinstimmung mit zuvor funktionierenden Dienstanbietern feststellen, sodass Passpoint-Geräte nicht automatisch verbunden wurden.

Problemumgehungen

Um das Problem mit den geänderten Abgleichskriterien zu umgehen, müssen Mobilfunkanbieter und Dienstanbieter den von Passpoint-Zugangspunkten veröffentlichten Informationen den NAI-Bereich (Network Access Identifier) hinzufügen.

Netzwerkdienstanbieter sollten eine netzwerkseitige Behelfslösung zur schnellstmöglichen Bereitstellung implementieren. Eine geräteseitige Problemumgehung setzt voraus, dass OEMs eine Änderungsliste (CL) von AOSP abrufen und dann die Geräte vor Ort aktualisieren.

Netzwerkkorrektur für Mobilfunkanbieter und Passpoint-Dienstanbieter

Die netzwerkseitige Problemumgehung erfordert eine Neukonfiguration des Netzwerks, um das ANQP-Element des NAI-Bereichs wie unten beschrieben hinzuzufügen. Die Passpoint-Spezifikationen erfordern das ANQP-Element „NAI-Bereich“ nicht. Das Hinzufügen dieser Eigenschaft entspricht jedoch den Passpoint-Spezifikationen. Daher sollten die spezifikationskonformen Clientimplementierungen nicht beeinträchtigt werden.

  1. Fügen Sie das ANQP-Element „NAI-Realm“ hinzu.
  2. Legen Sie das Unterfeld „NAI-Bereich“ so fest, dass es mit der Realm des auf dem Gerät installierten Profils übereinstimmt.

  3. Legen Sie für jeden EAP-Typ die folgenden Informationen fest:

    • EAP-TTLS:Legen Sie EAPMethod(21) und die unterstützten Typen der internen Authentifizierung (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-Fehlerbehebung für OEMs

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

  • Android 9
  • Android 8.x

Wenn der Patch abgerufen wird, müssen OEMs die Geräte vor Ort aktualisieren.