capsman iphone – це збій підключення iPhone, iPad і macOS-клієнтів до Wi‑Fi на MikroTik після переходу на RouterOS 7.22.x. Найчастіше проблема зводиться не до пароля, DHCP чи VLAN, а до прихованих порожніх значень у Wi‑Fi-конфігурації. Нижче – як це знайти, прибрати і не сплутати з окремими проблемами 5 GHz.
Симптом типовий: Apple-пристрій бачить SSID, приймає пароль, але зависає на етапі join. Іноді мережа збережена раніше й автопідключення працює нестабільно, а перше підключення не проходить. У CAPsMAN-схемах це часто проявляється після редагування конфігів у Winbox.
На практиці тут неприємне не саме значення, а те, що в UI його можна не побачити. У конфігу параметр уже записаний як порожній рядок, а візуально все виглядає чисто. Для Apple-клієнтів цього іноді достатньо, щоб зламати приєднання.
Що ламається в RouterOS 7.22.x
Основний збій у сценарії capsman iphone – поява порожнього значення interworking.realms-raw=”” у Wi‑Fi configuration. Ключовий момент: треба саме unset, а не просто спроба перезапису через інший об’єкт.
Проблема проявлялася і в CAPsMAN, і в окремих non-CAPsMAN конфігураціях. У частині випадків вистачало прибрати тільки interworking.realms-raw. В інших спливали ще й додаткові порожні поля, які Winbox лишав у конфігу без явної причини.
Окремо траплялися такі записи:
- security.multi-passphrase-group=””
- package-path=””
- channel.secondary-frequency=disabled
- сумнівні або зайві ручні значення на кшталт tx-power=0
Нетривіальний висновок тут простий: у Wi‑Fi-конфігах MikroTik порожній рядок і unset – не одне й те саме. Для CAPsMAN це критично.
Як перевірити, чи винен саме capsman iphone
Якщо проблема в capsman iphone, Apple-пристрій зазвичай бачить мережу, але не завершує join після введення ключа. Якщо ж SSID взагалі не з’являється або 5 GHz піднімається із затримкою, спершу треба дивитися на канал і DFS.
Насамперед варто подивитися export і знайти параметри з порожнім рядком. Особливо ті, які не мали бути задані вручну. Якщо в конфігу є interworking.realms-raw=””, це перший кандидат на видалення.
Для CAPsMAN-сценарію перевірка зводиться до секції /interface wifi configuration. Саме там зависав проблемний параметр навіть тоді, коли через Winbox здавалося, що його вже прибрали.
/interface wifi configuration print detail
Якщо підозра падає на звичайний Wi‑Fi інтерфейс без CAPsMAN, тоді дивитися треба вже в /interface wifi. Суть та сама – шукати поля з порожнім значенням, а не лише очевидні налаштування безпеки.
CLI-виправлення, яке реально спрацьовує
Для capsman iphone робочий варіант – масово зробити unset саме в /interface wifi configuration. Спроби чіпати окремий interworking-об’єкт або перемикати параметр через UI не завжди прибирають реальний запис.
Команда, яка виявлялася дієвою:
/interface wifi configuration unset value-name=interworking.realms-raw [find]
Логіка проста: команда знаходить усі входження interworking.realms-raw у поточній секції й скидає їх у null. Саме в null, не в порожній рядок. У цій різниці весь сенс.
Якщо конфіг у non-CAPsMAN і поле висить безпосередньо на Wi‑Fi-інтерфейсах, використовують аналогічний підхід у відповідній секції:
/interface wifi unset value-name=interworking.realms-raw [find]
Після цього варто тим самим способом прибрати інші підозрілі порожні значення, якщо вони є в export.
Які поля ще треба почистити
У сценарії capsman iphone варто пройтися по всіх полях, де зберігся “”. Якщо параметр не використовується, він має бути unset, а не записаний порожнім рядком.
Передусім це стосується таких випадків:
- security.multi-passphrase-group=”” – прибрати, якщо групи паролів не використовуються
- package-path=”” – теж прибрати
- interworking.realms-raw=”” – прибрати обов’язково
Окремо перевіряють і дивні ручні параметри, які могли лишитися після випадкового кліку в Winbox. Наприклад, tx-power=0 або явно зайвий channel.secondary-frequency=disabled. Це не той самий баг, але вони додають шуму в діагностиці й легко маскують справжню причину.
Хороше практичне правило тут таке: якщо параметр не планували задавати явно, а в export він присутній як порожній або явно зайвий, краще його unset.
Чи треба чіпати сам iPhone або Mac
Після виправлення capsman iphone іноді залишається кеш на боці Apple-пристрою. Мінімальна дія – забути конкретну мережу й підключитися заново. Повний reset network settings – уже другий крок, не перший.
У частині випадків після очищення конфіга на MikroTik достатньо видалити тільки цей SSID на одному iPhone і перевірити повторне приєднання. Це швидше й не чіпає всі інші мережі, синхронізовані між пристроями.
Але є важлива межа: якщо після forget network і навіть після network reset поведінка не змінюється, проблема майже напевно ще лишилася на боці конфігурації AP, а не клієнта. На це вказує і сценарій, де навіть ручне задання IP на Apple-пристрої не допомагає.
Коли справа не в CAPsMAN, а в 5 GHz або DFS
Не кожен випадок capsman iphone пов’язаний із hidden fields. Якщо не працює тільки 5 GHz, а 2.4 GHz живий, треба перевірити фактичний канал, DFS і ширину каналу. Інакше легко лікувати не ту проблему.
У 5 GHz AP може піти на частоту, яку конкретний клієнт не підтримує, або зависнути на DFS-перевірці перед стартом передачі. Тоді Apple-пристрій або не бачить мережу, або підключення виглядає як довге зависання. У таких випадках вже не interworking винен.
Для перевірки стану радіо на керованому CAP дивляться monitor:
/interface/wifi/monitor <interface_name>
Там видно, чи інтерфейс уже running, чи ще чекає на DFS, а також який канал реально вибраний. Для homelab це корисніше за перевірку лише provisioning-профілю, бо проблема часто не в шаблоні, а в тому, де реально опинився AP.
Ще один тонкий момент – не всі клієнти добре переживають екзотичні channel layout для широких каналів. Якщо після прибирання порожніх полів проблема лишилася тільки на 5 GHz, далі дивитися треба саме сюди.
Коли CLI-очищення не допомогло
Якщо capsman iphone не зник після unset проблемних полів, не треба одразу списувати все на iOS. Є випадки, де 2.4 GHz працює, а 5 GHz для Apple-пристроїв ні. Там уже треба розділяти конфігурації master/slave, VLAN datapath і реальний radio state.
Були й сценарії, де LAN SSID стабільно ламався, а IOT SSID на тому самому CAP працював. При цьому зміна ролей master/slave не давала ефекту. Це натякає, що інколи проблема сидить не в самому факті CAPsMAN, а в конкретному наборі параметрів окремого профілю.
Що має сенс перевірити далі:
- чи немає інших порожніх полів у /interface wifi configuration та /interface wifi capsman
- чи не залишився зайвий 5 GHz-параметр у конкретному профілі
- чи бачить monitor стабільний running без DFS-затримки
- чи збігається поведінка на 2.4 GHz і 5 GHz
У крайніх випадках є повідомлення, що відкат до 7.21.3 повертав нормальну роботу Apple-клієнтів на 5 GHz. Це не універсальна порада, але як контрольний тест такий крок логічний.
Що робити в сухому залишку
Якщо після RouterOS 7.22.x зламався capsman iphone, починати треба не з DHCP, не з VLAN і не з повного скидання iPhone. Спершу – export, пошук порожніх рядків і точковий unset через CLI.
Найчастіше вирішує саме це:
/interface wifi configuration unset value-name=interworking.realms-raw [find]
Потім – зачистити інші порожні поля, забути SSID на одному Apple-пристрої й перевірити приєднання. Якщо збій лишився тільки на 5 GHz, далі вже дивитися DFS, канал і radio state.
Документація MikroTik тут допоможе з базовим синтаксисом, але справжня пастка в іншому: у Wi‑Fi-конфігах порожнє значення іноді небезпечніше за явно неправильне. Його хоча б видно.
Коментарі
Коментарів ще немає. Обговорення - у Telegram.