Mia iPhone ŝajnas esti forgesinta mian kompanian WiFi-pasvorton.

Saluton ĉiuj!

Mi neniam pensis, ke mi revenos al ĉi tiu kazo, sed Cisco Open Air Wireless Maratono instigis min memori kaj paroli pri mia persona sperto, kiam antaŭ iom pli ol unu jaro mi havis la ŝancon pasigi sufiĉe da tempo por studi problemon kun sendrata reto bazita en Cisco kaj iPhone-telefonoj. Mi estis taskigita rigardi la demandon de unu el la administrantoj: "Kial, post rekomenco, la iPhone ne povas aŭtomate konektiĝi al la reto Wi-Fi, kaj kiam li konektas permane, ĝi petas vin enigi vian uzantnomon kaj pasvorton?"

Mia iPhone ŝajnas esti forgesinta mian kompanian WiFi-pasvorton.

Informoj pri WiFi-reto:

Sendrata regilo - AIR-CT5508-K9.
Versio de la programaro de regilo estas 8.5.120.0.
Alirpunktoj - plejparte AIR-AP3802I-R-K9.
Aŭtentikigmetodo estas 802.1x.
RADIUS-servilo - ISE.
Problemaj klientoj - iPhone 6.
Klienta programaro versio estas 12.3.1.
Ofteco 2,4GHz kaj 5GHz.

Trovi problemon ĉe la kliento

Komence, estis provoj solvi la problemon atakante la klienton. Feliĉe, mi havis la saman telefonmodelon kiel la kandidato kaj povis fari testadon en oportuna tempo por mi. Mi kontrolis la problemon sur mia telefono - ja tuj post ŝaltado de la telefono provas konektiĝi al la kompania reto antaŭe konata de ĝi, sed post ĉirkaŭ 10 sekundoj ĝi restas nekonektita. Se vi elektas la SSID permane, la telefono petas vin enigi vian ensaluton kaj pasvorton. Post enigi ilin, ĉio funkcias ĝuste, sed post rekomenco la telefono denove ne povas aŭtomate konekti al la SSID, malgraŭ la fakto, ke la ensaluto kaj pasvorto estis konservitaj, la SSID estis en la listo de konataj retoj, kaj aŭtomata konekto estas ebligita.

Malsukcesaj provoj estis faritaj por forgesi la SSID kaj aldoni ĝin denove, restarigi la retajn agordojn de la telefono, ĝisdatigi la telefonon per iTunes kaj eĉ ĝisdatigi al la beta-versio de iOS 12.4 (la plej nova en tiu tempo). Sed ĉio ĉi ne helpis. Ankaŭ la modeloj de niaj kolegoj, iPhone 7 kaj iPhone X, estis kontrolitaj, kaj la problemo ankaŭ estis reproduktita sur ili. Sed ĉe Android-telefonoj la problemo ne estas riparita. Aldone, bileto estis kreita en Apple Feedback Assistant, sed ĝis nun neniu respondo estis ricevita.

Solvado de la sendrata regilo

Post ĉio ĉi-supra, oni decidis serĉi la problemon en la WLC. Samtempe, mi malfermis bileton kun Cisco TAC. Surbaze de la rekomendo de TAC, mi ĝisdatigis la regilon al versio 8.5.140.0. Mi ludis per diversaj temporiziloj kaj Rapida Transiro. Ne helpis.

Por testado, mi kreis novan SSID kun 802.1x aŭtentigo. Kaj jen la tordaĵo: la problemo ne reproduktiĝas sur la nova SSID. La demando de la inĝeniero de TAC igas nin demandi, kiajn ŝanĝojn ni faris al la reto Wi-Fi antaŭ ol la problemo aperis. Mi komencas memori... Kaj estas unu indico - la komence problema SSID dum longa tempo havis la aŭtentikigmetodon WPA2-PSK, sed por pliigi la nivelon de sekureco ni ŝanĝis ĝin al 802.1x kun domajna aŭtentigo.

Mi kontrolas la indicon - mi ŝanĝas la aŭtentikigmetodon sur la testa SSID de 802.1x al WPA2-PSK, kaj poste reen. La problemo ne estas reproduktebla.

Vi devas pensi pli kompleze - mi kreas alian testan SSID kun aŭtentigo WPA2-PSK, ligas la telefonon al ĝi kaj memoras la SSID en la telefono. Mi ŝanĝas la aŭtentikigon al 802.1x, aŭtentikigas la telefonon per domajna konto kaj ebligas aŭtomatan konekton.

Mi rekomencas la telefonon... Kaj jes! La problemo ripetiĝis. Tiuj. La ĉefa ellasilo ŝanĝas la aŭtentikigmetodon en konata telefono de WPA2-PSK al 802.1x. Mi raportis ĉi tion al la inĝeniero de Cisco TAC. Kune kun li, ni plurfoje reproduktis la problemon, prenis trafikan rubejon, en kiu estis klare, ke post ŝaltado de la telefono, ĝi komencas la aŭtentikigfazon (Aliro-Defio), sed post iom da tempo ĝi sendas diasocian mesaĝon al la alirpunkto kaj malkonektas de ĝi. Ĉi tio klare estas klienta flanko problemo.

Kaj denove sur la kliento

Manke de subtenkontrakto kun Apple, estis longa sed sukcesa provo atingi ilian duan subtenlinion, en kiu mi raportis la problemon. Tiam estis multaj sendependaj provoj trovi kaj determini la kaŭzon de la problemo en la telefono kaj ĝi estis trovita. La problemo montriĝis esti la ebligita funkcio "iCloud ŝlosilĉeno". Sufiĉe utila funkcio, kiun la plendanto de la problemo kaj mi ne volis malŝalti sur solvotelefonoj. Laŭ mia supozo, la telefono ne povas anstataŭigi informojn pri la metodo de konekti al konataj SSID-oj sur iCloud-serviloj. La trovo estis raportita. al Apple, al kiu ili konfesis, ke ekzistas tia problemo, ĝi estas konata al la programistoj, kaj estos riparita en estontaj eldonoj. Ili ne diris, kiu eldono. Mi ne pretas diri kiel la aferoj estas nuntempe. , sed komence de decembro 2019, la problemo ankoraŭ estis reproduktebla sur la iPhone 11 Pro Max kun iOS 13.

konkludo

Por nia kompanio la problemo estis sukcese solvita. Pro la fakto ke la kompania nomo estis ŝanĝita, estis decidite ŝanĝi la kompanian SSID. Kaj la nova SSID jam estis tuj kreita kun 802.1x aŭtentikigo, kio ne estis ellasilo por la problemo.

fonto: www.habr.com

Aldoni komenton