Saluton ĉiuj!
Mi neniam pensis, ke mi revenos al ĉi tiu kazo, sed
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 "
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