Passpoint (Hotspot 2.0)

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

Gerätesupport

Damit Passpoint unterstützt wird, müssen Gerätehersteller die Supplicant-Schnittstelle implementieren. Ab Android 13 wird für die HAL-Definition AIDL verwendet. Für Releases vor Android 13 verwenden Schnittstellen und Anbieterpartitionen HIDL. 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 GAS (Generic Advertisement Service) und ANQP (Access Network Query Protocol).

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

Android 10 oder niedriger

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

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

Um Passpoint zu unterstützen, implementieren Sie das Wi‑Fi HAL und aktivieren Sie das Feature-Flag für Passpoint. Ändern Sie in device.mk unter device/<oem>/<device> die Umgebungsvariable PRODUCT_COPY_FILES, um Unterstützung für die Passpoint-Funktion 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.

Zertifizierungsstufe

Führen Sie die folgenden Unittests für das Passpoint-Paket aus, um Ihre 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) über das webbasierte 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 anzusehen, 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. 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 Daten privater Schlüssel enthält. Der Inhalt besteht aus umgebrochenem Multipart-MIME-Text, der in UTF-8 dargestellt und gemäß RFC-2045, Abschnitt 6.8, mit 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 festgelegt sein.
  • Content-Transfer-Encoding muss auf base64 festgelegt sein.
  • Content-Disposition darf nicht festgelegt werden.

Die HTTP-Methode, die zum Abrufen der Datei verwendet wird, muss GET sein. Immer wenn der Browser eine Antwort mit diesen MIME-Headern auf eine HTTP GET-Anfrage 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 MIME-Multipart-Inhalten mit einem Content-Type von multipart/mixed bestehen. Die einzelnen Teile des mehrteiligen Inhalts bestehen aus folgenden Elementen.

Teil Content-Type (ohne Anführungszeichen) Erforderlich Beschreibung
Profil application/x-passpoint-profile Immer OMA-DM-Nutzlast im SyncML-Format mit dem Passpoint R1-PerProviderSubscription-formatierten MO für HomeSP und Credential.
Zertifikat vertrauen application/x-x509-ca-cert Für EAP-TLS und EAP-TTLS erforderlich Eine einzelne X.509v3-Zertifikatsnutzlast, die base64-codiert ist.
EAP-TLS-Schlüssel application/x-pkcs12 Für EAP-TLS erforderlich 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 Profilabschnitt muss als Base64-codierter, UTF‑8-codierter XML-Text übertragen werden, der Teile der Unterbäume 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 und der untergeordnete Knoten muss PerProviderSubscription sein. Eine Beispiel-XML-Datei finden Sie unter Beispiel für OMA-DM-XML-Profil.

Die folgenden Unterbaumknoten werden unter HomeSP verwendet:

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

Die folgenden Unterbaumknoten 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 Beispiel unten auf cGFzc3dvcmQ=, den base64-codierten String für „password“, festgelegt)
    • EAPMethod/EAPType: Muss auf 21 festgelegt werden.
    • EAPMethod/InnerMethod: Muss auf PAP, CHAP, MS-CHAP oder MS-CHAP-V2 festgelegt sein.

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

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

  • 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 im Gerät installiert waren. Der IMSI-String kann entweder nur aus Dezimalziffern bestehen, um einen vollständigen Gleichheitsabgleich zu erzwingen, oder aus 5 oder 6 Dezimalziffern, gefolgt von einem Sternchen (*), um den IMSI-Abgleich nur auf MCC/MNC zu beschränken. Der IMSI-String 123456* entspricht beispielsweise jeder SIM-Karte mit dem MCC 123 und dem MNC 456.

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

Separate AAA-Domainnamen (Authentifizierung, Autorisierung und Abrechnung)

Passpoint-Netzwerkadministratoren, die einen AAA-Domainnamen unabhängig vom vollqualifizierten Domainnamen (Fully Qualified Domain Name, FQDN) angeben müssen, 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 dem Extension-Unterbaum angeben. Dies ist ein optionaler Knoten. Geräte mit Android 10 oder niedriger ignorieren diesen Knoten.

  • Android: Android-Erweiterungsunterbaum

    • AAAServerTrustedNames: Erforderlich für vertrauenswürdige Namen von AAA-Servern 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 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 dem Profil angehängte Stamm-CA-Zertifikat wird für die AAA-Serverauthentifizierung verwendet. Passpoint-Netzwerkadministratoren, die sich bei der AAA-Serverauthentifizierung auf öffentlich vertrauenswürdige Root-Zertifizierungsstellen verlassen möchten, können Profile ohne Root-Zertifizierungsstellenzertifikat bereitstellen. In diesem Fall verifiziert das System die AAA-Serverzertifikate anhand der öffentlichen Root-CA-Zertifikate, die im Trust-Store installiert sind.

Passpoint R2-Bereitstellung

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

Für die unterstützten Passpoint R2-Funktionen ist nur AOSP-Referenzcode erforderlich. Es sind keine zusätzlichen 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-Zugangspunkt erkennt, führt das Android-Framework folgende Schritte aus:

  1. Zeigt eine Liste der von der AP beworbenen Dienstanbieter in der WLAN-Auswahl an (zusätzlich zu den SSIDs).
  2. Der Nutzer wird aufgefordert, auf einen der Dienstanbieter zu tippen, um ein Passpoint-Profil einzurichten.
  3. Führt den Nutzer durch die Einrichtung des Passpoint-Profils.
  4. Installiert das resultierende Passpoint-Profil nach erfolgreichem Abschluss.
  5. Es wird eine Verbindung zum Passpoint-Netzwerk über das neu bereitgestellte Passpoint-Profil hergestellt.

Passpoint R3-Funktionen

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

Nutzungsbedingungen

Die Annahme der Nutzungsbedingungen ist an einigen Orten und Veranstaltungsorten gesetzlich vorgeschrieben, um Netzwerkzugriff zu ermöglichen. Mit dieser Funktion können in Netzwerkbereitstellungen unsichere Captive Portals, die offene Netzwerke verwenden, durch ein sicheres Passpoint-Netzwerk ersetzt werden. Dem Nutzer wird eine Benachrichtigung angezeigt, wenn die Nutzungsbedingungen akzeptiert werden müssen.

Die URL für die 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 für Veranstaltungsortinformationen

Netzwerkbetreiber und Veranstaltungsorte können dem Nutzer zusätzliche Informationen wie Karten, Verzeichnisse, Angebote und Gutscheine zur Verfügung stellen. Wenn das Netzwerk verbunden ist, wird dem Nutzer eine Benachrichtigung angezeigt.

Die URL mit den 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 Stromverbrauch und die Flexibilität bei der Bereitstellung verbessern.

Durchsetzung und Benachrichtigung zum Ablaufdatum
Durch das Erzwingen von Ablaufdaten für Profile kann das Framework die automatische Verbindung zu Zugriffspunkten mit abgelaufenen Anmeldedaten vermeiden, die ohnehin fehlschlagen würden. Dadurch wird die Nutzung von 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 (Fully Qualified Domain Name) bereitstellen, eines für jede PLMN-ID. Diese werden automatisch mit der installierten SIM-Karte abgeglichen und zum Herstellen einer Verbindung zum Netzwerk verwendet.

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

Präfix für dekorierte Identitäten
Bei der Authentifizierung in Netzwerken mit einer Präfixdekoration ermöglicht das dekorierte Identitätspräfix Netzbetreibern, die Network Access Identifier (NAI) zu aktualisieren, um explizites Routing über mehrere Proxys in einem AAA-Netzwerk durchzuführen (siehe RFC 7542). In Android 12 wird diese Funktion gemäß der WBA-Spezifikation für PPS-MO-Erweiterungen implementiert.
Umgang mit bevorstehender Deauthentifizierung
Ermöglicht Netzbetreibern, einem Gerät zu signalisieren, dass der Dienst für die Anmeldedaten, die zur Authentifizierung im Netzwerk verwendet werden, für einen bestimmten Zeitraum (angegeben durch eine Zeitüberschreitungsverzögerung) nicht verfügbar ist. Nachdem sie dieses Signal empfangen haben, versuchen Geräte erst nach Ablauf des Zeitlimits, mit denselben Anmeldedaten wieder eine Verbindung zum Netzwerk herzustellen. Geräte, die diese Funktion nicht unterstützen, versuchen 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:

  • Anzeigenetzwerk-Name auf „Example Network“ festgelegt
  • FQDN auf hotspot.example.net festgelegt
  • Roaming-Konsortium-OIs (für Roaming)
  • Anmeldedaten mit dem Nutzernamen user, dem mit Base64 codierten Passwort password und dem auf example.net festgelegten Bereich
  • EAP-Methode auf 21 (EAP-TTLS) festgelegt
  • Innere Methode für Phase 2 auf MS-CHAP-V2 festgelegt
  • Alternative AAA-Domainnamen 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 digitales Zertifikat (EAP-TLS)

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

  • Anzeigenetzwerk-Name auf „GlobalRoaming“ festgelegt
  • FQDN auf globalroaming.net festgelegt
  • Roaming-Konsortium-OIs (für Roaming)
  • Realm auf users.globalroaming.net festgelegt
  • Anmeldedaten 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-Anmeldedaten (EAP-AKA)

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

  • Anzeigenetzwerk-Name auf „Purple Passpoint“ festgelegt
  • FQDN auf wlan.mnc888.mcc999.3gppnetwork.org festgelegt
  • SIM-Anmeldedaten mit der 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>

Auth-Hinweis

Geräte mit Android 8.x oder Android 9, auf denen ein Passpoint-Profil mit EAP-SIM, EAP-AKA oder EAP-AKA' installiert ist, stellen keine automatische Verbindung zum Passpoint-Netzwerk her. Dieses Problem betrifft Nutzer, Mobilfunkanbieter und Dienste, da es die WLAN-Auslagerung reduziert.

Segment Auswirkungen Größe der Auswirkungen
Mobilfunkanbieter und Passpoint-Dienstanbieter Erhöhte Belastung des Mobilfunknetzes Alle Mobilfunkanbieter, die Passpoint R1 verwenden.
Nutzer Es wurde verpasst, automatisch eine Verbindung zu WLAN-Zugangspunkten des Mobilfunkanbieters herzustellen, was zu höheren Datenkosten führte. Jeder Nutzer mit einem Gerät, das in einem Mobilfunknetzwerk ausgeführt wird, das Passpoint R1 unterstützt.

Fehlerursache

Passpoint gibt einen Mechanismus an, mit dem ein beworbener (ANQP-)Dienstanbieter mit einem auf dem Gerät installierten Profil abgeglichen wird. Die folgenden Abgleichsregeln für EAP-SIM, EAP-AKA und EAP-AKA' sind ein Teilsatz 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 konnte das System keine Übereinstimmung für zuvor funktionierende Dienstanbieter feststellen, sodass Passpoint-Geräte keine automatische Verbindung herstellen konnten.

Problemumgehungen

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

Die empfohlene Lösung besteht darin, dass Netzwerkanbieter eine netzwerkseitige Problemumgehung implementieren, um die Bereitstellung so schnell wie möglich zu ermöglichen. Eine geräteseitige Umgehungslösung hängt davon ab, ob OEMs eine Änderungsliste (Changelist, CL) aus AOSP übernehmen und dann Geräte im Feld aktualisieren.

Netzwerkfehlerbehebung für Mobilfunkanbieter und Passpoint-Dienstanbieter

Für den netzwerkseitigen Workaround muss das Netzwerk neu konfiguriert werden, um das ANQP-Element für den NAI-Realm wie unten angegeben hinzuzufügen. Die Passpoint-Spezifikationen erfordern das ANQP-Element „NAI-Realm“ nicht. Das Hinzufügen dieser Eigenschaft entspricht jedoch den Passpoint-Spezifikationen, sodass spezifikationskonforme Clientimplementierungen nicht beeinträchtigt werden sollten.

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

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

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

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

Um eine geräteseitige Problemumgehung 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 übernommen wird, müssen OEMs die Geräte im Feld aktualisieren.