Passpoint ist ein Wi-Fi Alliance (WFA) -Protokoll, das es mobilen Geräten ermöglicht, Wi-Fi-Hotspots zu erkennen und sich bei ihnen zu authentifizieren, die Internetzugang bieten.
Geräteunterstützung
Um Passpoint zu unterstützen, müssen Gerätehersteller die Supplicant-Schnittstelle implementieren. Ab Android 13 verwendet die Schnittstelle AIDL für die HAL-Definition. Bei Versionen vor Android 13 verwenden Schnittstellen und Herstellerpartitionen HIDL. Die HIDL-Dateien befinden sich in hardware/interfaces/supplicant/1.x
und die AIDL-Dateien befinden sich in hardware/interfaces/supplicant/aidl
. 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 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 zur Unterstützung von Passpoint sind in AOSP enthalten.
Validierung
Um Ihre Implementierung der Passpoint-Funktion zu validieren, verwenden Sie die in der Android Comms Test Suite (ACTS) bereitgestellten Komponententests und Integrationstests.
Unit-Tests
Führen Sie die folgenden Passpoint-Paketkomponententests aus.
Servicetests:
atest com.android.server.wifi.hotspot2
Managertests:
atest android.net.wifi.hotspot2
Integrationstests (ACTS)
Die ACTS Passpoint-Testsuite, die sich unter tools/test/connectivity/acts_tests/tests/google/wifi/WifiPasspointTest.py
befindet, 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-Anmeldeinformationen (Release 1) durch webbasiertes Herunterladen einer speziellen Datei, die Profil- und Anmeldeinformationen enthält. Der Client startet automatisch ein spezielles Installationsprogramm für die WLAN-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 Zugangspunkten abgerufen werden, 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 werden, da sie Klartext-Passwort- oder private Schlüsseldaten enthalten kann. Der Inhalt besteht aus umschlossenem mehrteiligem MIME-Text, der in UTF-8 dargestellt und in Base64-Kodierung gemäß RFC-2045 Abschnitt 6.8 kodiert ist.
Die folgenden HTTP-Header-Felder werden vom Client verwendet, um automatisch ein WLAN-Installationsprogramm auf dem Gerät zu starten:
-
Content-Type
muss aufapplication/x-wifi-config
gesetzt sein. -
Content-Transfer-Encoding
muss aufbase64
eingestellt sein. -
Content-Disposition
darf nicht festgelegt 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 Tippen auf ein HTML-Element, beispielsweise 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 oder auch nicht.
Dateizusammensetzung
Der Base64-codierte Inhalt muss aus MIME-Multipart-Inhalt mit einem 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 Zertifikatnutzlast. |
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
Unterbä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 finden Sie im Beispielprofil OMA-DM XML .
Unter HomeSP
werden folgende Teilbaumknoten verwendet:
-
FriendlyName
: Muss festgelegt werden; als Anzeigetext verwendet -
FQDN
: Erforderlich -
RoamingConsortiumOI
Unter Credential
werden folgende Teilbaumknoten verwendet:
-
Realm
: Muss eine nicht leere Zeichenfolge sein UsernamePassword
: Erforderlich für EAP-TTLS mit den folgenden Knoten:-
Username
: Zeichenfolge, die den Benutzernamen enthält -
Password
: Base64-codierte Zeichenfolge (im folgenden Beispiel aufcGFzc3dvcmQ=
gesetzt, die Base64-codierte Zeichenfolge für „Passwort“). -
EAPMethod/EAPType
: Muss auf21
gesetzt sein -
EAPMethod/InnerMethod
: Muss aufPAP
,CHAP
,MS-CHAP
oderMS-CHAP-V2
eingestellt sein
-
DigitalCertificate
: Erforderlich für EAP-TLS. Folgende Knoten müssen gesetzt werden:-
CertificateType
aufx509v3
gesetzt -
CertSHA256Fingerprint
ist im EAP-TLS-Schlüssel-MIME-Abschnitt auf den korrekten SHA-256-Digest des Client-Zertifikats eingestellt
-
SIM
: Erforderlich für EAP-SIM, EAP-AKA und EAP-AKA. DasEAPType
Feld muss auf den entsprechenden EAP-Typ eingestellt sein undIMSI
muss mit einer IMSI einer der SIM-Karten übereinstimmen, die zum Zeitpunkt der Bereitstellung im Gerät installiert waren. Die IMSI-Zeichenfolge kann entweder vollständig aus Dezimalziffern bestehen, um eine vollständige Gleichheitsübereinstimmung zu erzwingen, oder aus 5 oder 6 Dezimalziffern gefolgt von einem Sternchen (*), um die IMSI-Übereinstimmung nur auf MCC/MNC zu beschränken. Beispielsweise entspricht die IMSI-Zeichenfolge 123456* jeder SIM-Karte mit MCC als 123 und MNC als 456.
Android 11 führt Funktionen ein, die die Passpoint R1-Bereitstellung flexibler machen.
- Separater Domänenname für Authentifizierung, Autorisierung und Abrechnung (AAA).
Passpoint-Netzwerkadministratoren, die einen AAA-Domänennamen benötigen, der unabhängig vom vollqualifizierten 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
Extension
angeben . Dies ist ein optionaler Knoten und Geräte mit Android Version 10 oder niedriger ignorieren diesen Knoten.
Android
: Teilbaum der Android-ErweiterungAAAServerTrustedNames
: 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. Zum Beispielexample.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.
- Ermöglichen Sie die Installation von Profilen ohne Root-CA-Zertifikat
- 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 Root-CAs verlassen möchten, können Profile ohne Root-CA-Zertifikat bereitstellen. In diesem Fall überprüft das System die AAA-Serverzertifikate anhand der im Trust Store installierten öffentlichen Root-CA-Zertifikate.
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 zur Bereitstellung 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 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 Einstellungen-App.
Wenn Android einen Passpoint R2-Zugriffspunkt erkennt, führt das Android-Framework Folgendes aus:
- Zeigt eine Liste der vom AP in der Wi-Fi-Auswahl angekündigten Dienstanbieter an (zusätzlich zur Anzeige der SSIDs).
- Fordert den Benutzer auf, auf einen der Dienstanbieter zu tippen, um ein Passpoint-Profil einzurichten.
- Führt den Benutzer durch den Einrichtungsablauf des Passpoint-Profils.
- Installiert das resultierende Passpoint-Profil nach erfolgreichem Abschluss.
- Stellt mithilfe des neu bereitgestellten Passpoint-Profils eine Verbindung zum Passpoint-Netzwerk her.
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
Für die Bereitstellung des Netzwerkzugangs ist an manchen Standorten und Veranstaltungsorten die Annahme der Allgemeinen Geschäftsbedingungen gesetzlich vorgeschrieben. 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 Allgemeinen Geschäftsbedingungen akzeptiert werden müssen.
Die URL der Allgemeinen Geschäftsbedingungen muss auf eine sichere Website mit HTTPS verweisen. Wenn die URL auf eine unsichere Website verweist, trennt das Framework sofort die Verbindung und blockiert das Netzwerk.
- URL der Veranstaltungsortinformationen
Ermöglicht Netzwerkbetreibern und Veranstaltungsorten, dem Benutzer zusätzliche Informationen wie Veranstaltungsortpläne, Verzeichnisse, Werbeaktionen und Gutscheine bereitzustellen. Dem Benutzer wird eine Benachrichtigung angezeigt, wenn das Netzwerk verbunden ist.
Die URL der Veranstaltungsortinformationen 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.
Weitere Passpoint-Funktionen
Android 11 führt die folgenden Passpoint-Funktionen ein, die das Benutzererlebnis, den Stromverbrauch und die Bereitstellungsflexibilität verbessern.
- Durchsetzung und Benachrichtigung des Ablaufdatums
- Durch das Erzwingen von Ablaufdaten für Profile kann das Framework verhindern, dass automatische Verbindungen zu Zugriffspunkten mit abgelaufenen Anmeldeinformationen hergestellt werden, die zwangsläufig fehlschlagen. Dies verhindert die Nutzung der Sendezeit und spart Batterie 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
- Betreiber, 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, das automatisch mit der installierten SIM-Karte abgeglichen und zum Verbinden des Netzwerks verwendet wird.
Android 12 führt die folgenden Passpoint-Funktionen ein, die das Benutzererlebnis, den Stromverbrauch und die Bereitstellungsflexibilität verbessern:
- Dekoriertes 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 ü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 .
- Deauthentifizierung bevorstehende Bearbeitung
- 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 (festgelegt durch eine Timeout-Verzögerung) nicht verfügbar ist. Nach dem Empfang dieses Signals versuchen Geräte erst nach Ablauf der Timeout-Verzögerung, mit denselben Anmeldeinformationen erneut eine Verbindung zum Netzwerk herzustellen. Im Gegensatz dazu versuchen Geräte, die diese Funktion nicht unterstützen, möglicherweise wiederholt, die Verbindung zum Netzwerk wiederherzustellen, 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:
- Der benutzerfreundliche Netzwerkname ist auf
Example Network
festgelegt - Der FQDN ist auf
hotspot.example.net
eingestellt - OIs des Roaming-Konsortiums (für Roaming)
- Anmeldeinformationen mit dem Benutzernamen
user
, dem mit Base64 codiertenpassword
und dem aufexample.net
eingestellten Realm - EAP-Methode auf
21
eingestellt (EAP-TTLS) - Innere Methode der Phase 2 auf
MS-CHAP-V2
eingestellt - Alternative AAA-Domänennamen sind auf
trusted.com
undtrusted.net
eingestellt
<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:
- Der benutzerfreundliche Netzwerkname ist auf
GlobalRoaming
eingestellt - Der FQDN ist auf
globalroaming.net
eingestellt - OIs des Roaming-Konsortiums (für Roaming)
- Der Bereich ist auf
users.globalroaming.net
eingestellt - Berechtigungsnachweis mit einem digitalen Zertifikat, das den angegebenen Fingerabdruck aufweist
<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-Zugangsdaten (EAP-AKA)
Das folgende Beispiel zeigt ein Profil für ein Netzwerk mit:
- Netzwerkfreundlicher Name auf
Purple Passpoint
eingestellt - Der FQDN ist auf
wlan.mnc888.mcc999.3gppnetwork.org
eingestellt - SIM-Zugangsdaten 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>
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 betrifft Benutzer, Netzbetreiber und Dienste, indem es die Wi-Fi-Auslastung verringert.
Segment | Auswirkungen | Größe der Wirkung |
---|---|---|
Carrier und Passpoint-Dienstleister | Erhöhte Belastung des Mobilfunknetzes. | Jeder Mobilfunkanbieter, der Passpoint R1 verwendet. |
Benutzer | Verpasste Gelegenheit zur automatischen Verbindung mit WLAN-Zugangspunkten (APs) des Mobilfunkanbieters, was zu höheren Datenkosten führt. | Jeder Benutzer mit einem Gerät, das in einem Mobilfunkanbieternetzwerk läuft, das Passpoint R1 unterstützt. |
Ursache des Scheiterns
Passpoint gibt einen Mechanismus an, um einen angekündigten (ANQP) Dienstanbieter einem auf dem Gerät installierten Profil zuzuordnen. Die folgenden Abgleichsregeln für EAP-SIM, EAP-AKA und EAP-AKA' sind Teilregeln, 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 stellte das System keine Übereinstimmung mit zuvor funktionierenden Dienstanbietern fest, sodass Passpoint-Geräte keine automatische Verbindung herstellten.
Problemumgehungen
Um das Problem der geänderten Übereinstimmungskriterien zu umgehen, müssen Netzbetreiber und Dienstanbieter den NAI-Bereich (Network Access Identifier) zu den vom Passpoint AP veröffentlichten Informationen hinzufügen.
Die empfohlene Lösung besteht darin, dass Netzwerkdienstanbieter eine netzwerkseitige Problemumgehung implementieren, um die Bereitstellung so schnell wie möglich zu ermöglichen. Eine geräteseitige Problemumgehung hängt davon ab, dass OEMs eine Änderungsliste (CL) von AOSP abholen und dann die Geräte vor Ort aktualisieren.
Netzwerk-Fix für Netzbetreiber 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 nicht das NAI-Realm-ANQP-Element, aber das Hinzufügen dieser Eigenschaft entspricht den Passpoint-Spezifikationen, sodass spezifikationskonforme Client-Implementierungen nicht fehlschlagen sollten.
- Fügen Sie das NAI-Realm-ANQP-Element hinzu.
- Stellen Sie das NAI-Realm-Unterfeld so ein, dass es mit dem
Realm
des auf dem Gerät installierten Profils übereinstimmt. Legen Sie die folgenden Informationen basierend auf jedem EAP-Typ fest:
- EAP-TTLS:
EAPMethod(21)
und unterstützte innere Authentifizierungstypen festlegen (PAP
,CHAP
,MS-CHAP
oderMS-CHAP-V2
) - EAP-TLS:
EAPMethod(13)
festlegen - EAP-SIM:
EAPMethod(18)
festlegen - EAP-AKA:
EAPMethod(23)
festlegen - EAP-AKA':
EAPMethod(50)
festlegen
- EAP-TTLS:
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 verfügbar ist, müssen OEMs die Geräte vor Ort aktualisieren.