Passpoint ist ein Protokoll der Wi-Fi Alliance (WFA), mit dem Mobilgeräte WLAN-Hotspots erkennen und sich bei ihnen authentifizieren können, die einen Internetzugang ermöglichen.
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 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
.
Das Supplicant unterstützt den 802.11u-Standard, insbesondere Funktionen zur Netzwerkerkennung und -auswahl wie Generic Advertising Service (GAS) und Access Network Query Protocol (ANQP).
Implementierung
Android 11 oder höher
Zur Unterstützung von Passpoint auf Geräten mit Android 11 oder höher müssen die Gerätehersteller 802.11u-Firmware unterstützen. Alle anderen Anforderungen für die Unterstützung von Passpoint sind im 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 anbieten:
- Framework: Passpoint aktivieren (Funktions-Flag erforderlich)
- Firmware: Unterstützung für 802.11u
Implementieren Sie den Wi-Fi-HAL und aktivieren Sie das Funktions-Flag für Passpoint, um Passpoint zu unterstützen. Ändern Sie in device.mk
in device/<oem>/<device>
die Umgebungsvariable PRODUCT_COPY_FILES
, damit das Passpoint-Feature unterstützt wird:
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
Verwende die in der Android Comms Test Suite (ACTS) bereitgestellten Einheitentests und Integrationstests, um die Implementierung der Passpoint-Funktion zu validieren.
Einheitentests
Führen Sie die folgenden Einheitentests für das Passpoint-Paket aus.
Diensttests:
atest com.android.server.wifi.hotspot2
Tests für Manager:
atest android.net.wifi.hotspot2
Integrationstests (ACTS)
Die ACTS-Passpoint-Testsuite in tools/test/connectivity/acts_tests/tests/google/wifi/WifiPasspointTest.py
implementiert eine Reihe von Funktionstests.
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 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 Zugangspunkten abgerufen werden. Die Anmeldedaten werden automatisch auf alle übereinstimmenden Netzwerke 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 sein, da sie Klartext-Passwörter oder Daten zu privaten Schlüsseln 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:
Content-Type
muss aufapplication/x-wifi-config
festgelegt sein.Content-Transfer-Encoding
muss aufbase64
festgelegt sein.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 gilt speziell für Google Chrome. Andere Webbrowser bieten möglicherweise ähnliche Funktionen.
Dateizusammensetzung
Der Base64-codierte Inhalt muss aus mehrteiligen MIME-Inhalten mit einem Content-Type
von multipart/mixed
bestehen. Die folgenden Teile bilden die einzelnen Teile des mehrteiligen Inhalts.
Teil | Inhaltstyp (weniger Anführungszeichen) | Erforderlich | Description |
---|---|---|---|
Profil |
application/x-passpoint-profile
|
Immer | Nutzlast im OMA-DM-SyncML-Format, die das Passpoint R1-PerProviderSubscription -formatierte MO für HomeSP und Credential enthält. |
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
|
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 in Klartext und ohne Passwort vorliegen. |
Der Profilabschnitt muss als base64-codierter, UTF-8-codierter XML-Text übertragen werden, der Teile der HomeSP
- und Credential
-Unterstrukturen in Passpoint R2, Version 1.0.0, Abschnitt 9.1 der technischen Spezifikation angibt.
Der Knoten der obersten Ebene muss MgmtTree
und der unmittelbare Unterknoten muss PerProviderSubscription
sein. Eine Beispiel-XML-Datei finden Sie unter Beispielprofil OMA-DM XML.
Die folgenden Unterstrukturknoten werden unter HomeSP
verwendet:
FriendlyName
: Muss festgelegt werden; wird als Anzeigetext verwendetFQDN
: ErforderlichRoamingConsortiumOI
Die folgenden Unterstrukturknoten werden unter Credential
verwendet:
Realm
: Muss ein nicht leerer String seinUsernamePassword
: Erforderlich für EAP-TTLS mit den folgenden Knoten:Username
: String, der den Nutzernamen enthältPassword
: Base64-codierter String (im Beispiel unten aufcGFzc3dvcmQ=
gesetzt, den base64-codierten String für „password“)EAPMethod/EAPType
: muss auf21
festgelegt seinEAPMethod/InnerMethod
: muss aufPAP
,CHAP
,MS-CHAP
oderMS-CHAP-V2
festgelegt sein
DigitalCertificate
: Erforderlich für EAP-TLS. Die folgenden Knoten müssen festgelegt werden:CertificateType
festgelegt alsx509v3
CertSHA256Fingerprint
ist auf den richtigen SHA-256-Digest des Clientzertifikats im MIME-Bereich des EAP-TLS-Schlüssels festgelegt
SIM
: Erforderlich für EAP-SIM, EAP-AKA und EAP-AKA. Das FeldEAPType
muss auf den entsprechenden EAP-Typ gesetzt sein undIMSI
muss mit einer IMSI von einer der SIM-Karten übereinstimmen, die bei der Bereitstellung im 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 das Kundencenter/MNC zu lockern. Der IMSI-String 123456* entspricht z. B. jeder SIM-Karte mit dem Kundencenter-Wert 123 und der MNC 456.
Android 11 bietet Funktionen, die die Passpoint R1-Bereitstellung flexibler machen.
- AAA-Domainname (Separate Authentication, Authorization and Accounting)
Passpoint-Netzwerkadministratoren, die einen AAA-Domainnamen benötigen, der unabhängig vom voll qualifizierten Domainnamen (FQDN) angegeben ist, 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 in der Unterstruktur
Extension
angeben. Dies ist ein optionaler Knoten und Geräte mit Android 10 oder niedriger ignorieren diesen Knoten.
Android
: Unterstruktur der Android-ErweiterungAAAServerTrustedNames
: Erforderlich für vertrauenswürdige AAA-Servernamen mit den folgenden Knoten:FQDN
: String, der die vertrauenswürdigen Namen des AAA-Servers enthält. Verwenden Sie Semikolons, um die vertrauenswürdigen Namen zu trennen. Beispiel:example.org;example.com
.
- Selbstsignierte private Root-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 Root-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 überprüft das System die AAA-Serverzertifikate anhand der öffentlichen Root-CA-Zertifikate, die im Trust Store installiert sind.
Passpoint R2-Bereitstellung
Mit Android 10 werden nun Passpoint R2-Funktionen unterstützt. Passpoint R2 implementiert die Onlineregistrierung (OSU), eine Standardmethode zur Bereitstellung neuer Passpoint-Profile. Android 10 und höher unterstützen 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 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-UI in der App „Einstellungen“.
Wenn Android einen Passpoint R2-Zugangspunkt erkennt, geschieht Folgendes:
- Zeigt eine Liste der vom Zugangspunkt beworbenen Dienstanbieter in der WLAN-Auswahl (zusätzlich zur Anzeige der SSIDs) an.
- Fordert den Nutzer auf, auf einen der Dienstanbieter zu tippen, um ein Passpoint-Profil einzurichten.
- Führt den Nutzer durch die Einrichtung des Passpoint-Profils.
- Installiert das resultierende Passpoint-Profil nach erfolgreichem Abschluss.
- Verbindet sich mithilfe des neu bereitgestellten Passpoint-Profils mit dem Passpoint-Netzwerk.
Funktionen von Passpoint R3
Android 12 führt die folgenden Passpoint R3-Funktionen ein, die die Nutzerfreundlichkeit verbessern und es Netzwerken ermöglichen, lokale Gesetze einzuhalten:
- Angebotsbedingungen
An einigen Orten und Orten ist die Annahme der Nutzungsbedingungen rechtlich erforderlich, um den Netzwerkzugriff zu ermöglichen. Mit diesem Feature können Netzwerkbereitstellungen unsichere Captive Portals, die offene Netzwerke verwenden, durch ein sicheres Passpoint-Netzwerk ersetzen. 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 Netzbetreibern und Veranstaltungsorten die Bereitstellung zusätzlicher Informationen für den Nutzer, z. B. Stadtpläne, Verzeichnisse, Werbeaktionen und Gutscheine. Sobald 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, ignoriert das Framework die URL und zeigt keine Benachrichtigung an.
Weitere Passpoint-Funktionen
Android 11 bietet die folgenden Passpoint-Funktionen, die die Nutzerfreundlichkeit, den Stromverbrauch und die Flexibilität bei der Bereitstellung verbessern.
- Durchsetzung des Ablaufdatums und Benachrichtigung
- Durch das Erzwingen von Ablaufdaten für Profile verhindert das Framework, dass eine automatische Verbindung zu Zugangspunkten mit abgelaufenen Anmeldedaten hergestellt wird, die in der Regel fehlschlagen. Dies verhindert Airtime-Nutzung, spart Akku und Back-End-Bandbreite. Das Framework zeigt dem Nutzer eine Benachrichtigung an, wenn sich ein Netzwerk 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, eines für jede PLMN-ID. Diese werden automatisch der installierten SIM-Karte zugeordnet und zum Verbinden des Netzwerks verwendet.
Android 12 bietet die folgenden Passpoint-Funktionen, die die Nutzerfreundlichkeit, den Stromverbrauch und die Flexibilität bei der Bereitstellung verbessern:
- Verziertes Identitätspräfix
- Bei der Authentifizierung bei Netzwerken mit einem Präfix-Dekor ermöglicht das dekorierte Identitätspräfix Netzwerkbetreibern, die Network Access ID (NAI) zu aktualisieren, um ein explizites Routing durch 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.
- Unmittelbare Verarbeitung der Deauthentifizierung
- 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 dem Empfang dieses Signals versuchen Geräte erst nach Ablauf der Zeitüberschreitungsverzögerung, die Verbindung zum Netzwerk mit denselben Anmeldedaten wiederherzustellen. Im Gegensatz dazu können Geräte, die diese Funktion nicht unterstützen, unter Umständen wiederholt versuchen, die Verbindung zum Netzwerk wiederherzustellen, wenn 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:
- Für das Netzwerk geeigneter Name auf "
Example Network
" festgelegt - FQDN auf
hotspot.example.net
festgelegt - OIs des Roaming-Konsortiums (für Roaming)
- Anmeldedaten mit Nutzername
user
, Passwortpassword
mit Base64-Codierung und Bereich aufexample.net
- EAP-Methode auf
21
(EAP-TTLS) festgelegt - Innere Methode von Phase-2 auf
MS-CHAP-V2
festgelegt - Alternative AAA-Domainnamen wurden auf
trusted.com
undtrusted.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 eines digitalen Zertifikats (EAP-TLS)
Das folgende Beispiel zeigt ein Profil für ein Netzwerk mit:
- Für das Netzwerk geeigneter Name auf "
GlobalRoaming
" festgelegt - FQDN auf
globalroaming.net
festgelegt - OIs des Roaming Consortiums (für Roaming)
- Bereich auf
users.globalroaming.net
festgelegt - Berechtigungsnachweis 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:
- Für das Netzwerk geeigneter Name auf "
Purple Passpoint
" festgelegt - FQDN auf
wlan.mnc888.mcc999.3gppnetwork.org
festgelegt - SIM-Anmeldedaten mit PLMN-ID von
999888
- EAP-Methode auf
23
festgelegt (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 und einem Passpoint R1 EAP-SIM-, EAP-AKA- oder EAP-AKA-Profil werden nicht automatisch mit dem Passpoint-Netzwerk verbunden. Dieses Problem wirkt sich auf Nutzer, Mobilfunkanbieter und Dienste aus, da die WLAN-Entlastung reduziert wird.
Segmentieren | Auswirkungen | Umfang der Auswirkungen |
---|---|---|
Mobilfunkanbieter und Passpoint-Dienstanbieter | Erhöhte Belastung des Mobilfunknetzes. | Jeder Mobilfunkanbieter, der Passpoint R1 verwendet. |
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, um einen beworbenen (ANQP) Dienstanbieter einem auf dem Gerät installierten Profil zuzuordnen. Die folgenden Abgleichregeln für EAP-SIM, EAP-AKA und EAP-AKA sind ein partieller Satz von Regeln, der sich auf Fehler von EAP-SIM-, AKA-/AKA-Fehlern konzentriert:
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.
Mit dieser Änderung hat das System keine Übereinstimmung mit zuvor funktionierenden Dienstanbietern festgestellt, sodass Passpoint-Geräte keine automatische Verbindung herstellen.
Problemumgehungen
Um das Problem der geänderten Abgleichskriterien zu umgehen, müssen Mobilfunkanbieter und Serviceprovider den NAI-Bereich (Network Access Identifier) den vom Passpoint-AP veröffentlichten Informationen hinzufügen.
Netzwerkdienstanbieter sollten eine netzwerkseitige Behelfslösung zur schnellstmöglichen Bereitstellung implementieren. Eine geräteseitige Behelfslösung hängt davon ab, dass OEMs eine Änderungsliste (Ä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. Für die Passpoint-Spezifikationen ist das ANQP-Element des NAI-Bereichs nicht erforderlich. Das Hinzufügen dieses Attributs entspricht jedoch den Passpoint-Spezifikationen. Daher sollten spezifikationskonforme Clientimplementierungen nicht fehlerhaft sein.
- Fügen Sie das ANQP-Element des NAI-Bereichs hinzu.
- Legen Sie das Unterfeld des NAI-Bereichs so fest, dass es mit dem
Realm
des auf dem Gerät installierten Profils übereinstimmt. Legen Sie für jeden EAP-Typ die folgenden Informationen fest:
- EAP-TTLS: Legen Sie
EAPMethod(21)
und unterstützte innere Authentifizierungstypen (PAP
,CHAP
,MS-CHAP
oderMS-CHAP-V2
) fest. - EAP-TLS:
EAPMethod(13)
festlegen - EAP-SIM:
EAPMethod(18)
festlegen - EAP-AKA:
EAPMethod(23)
festlegen - EAP-AKA:
EAPMethod(50)
festlegen
- EAP-TTLS: Legen Sie
Geräte-/AOSP-Korrektur 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.