Comments 119
Если отключить портал авторизации, всё нормально у АйФонов в открытой сети )
Ну не знаю. У меня другая проблема. Все устройства работают прекрасно. Все! И даже iPad. И айфон работал прекрасно. Но в какой-то момент только айфон перестал работать - брать интернет от wifi. У меня обычная точка доступа сяоми и микротик. В афоне просто перестал работать интернет при подключении по wifi. Всё, что только можно делал, и все блокировки отключал, и mac/имя сети менял... После очередного обновления инэт на афоне начал работать и через WiFi, но скорость ~100Кбит.
Опять, что только не делал, не победил. До сих пор такая фигня. С айпадом проблем небыло.
Было решено купить новую точку доступа. И вуаля, снова всё заработало. Но до очередного обновления айфона. Я не знаю как это происходит, словно операционка айфона добавляет мои точки доступа и окружение в блек лист и работает на минимальной скорости. Причём это касается и локальных ресурсов, работающих через WiFi. Ненавижу айфоны.
После очередного обновления инэт на афоне начал работать и через WiFi, но скорость ~100Кбит.
Ваша проблема очень знакома, это другое, не портал авторизации.
У вас телефон не случайно XS модели?
Старенький 6S+.
Старенький 6S+.
С такой проблемой как у вас столкнулся со всеми моделями XS, когда они впервые ночью обновились с iOS 12 на iOS 13.
Откатить версию как известно — невозможно стандартно.
С другими Apple и Андроидами проблем не было никаких. Проблема была только с XS, точку доступа менял на аналогичную, проблема оставалась.
Поэтому проверьте на вашей точке доступа, какая скорость соединения Wi-Fi у iPhone XS. Показывал Tx 1 мбит/с, а Rx от 54 до 128 мбит/с, по факту iPhone XS всё качал со скоростью ~10-100 кбит/с как у вас, а отправка была не менее 30 мбит/с, сигнал был отличным -50 дБм!
На других iPhone и iPad всё отлично было, на 2.4 ГГц 100 мбит/с показывали как на отправку, так и на приём. Они больше показывают, но коммутатор был 100 мбитный.
Долго искал причину, нашёл 3 варианта, которые помогли:
1. отключить 2.4 ГГц и оставить только 5 ГГц.
2. Поиграться с настройками для 2.4 ГГц: support rate; basic rate, MCS, fixed rate Multicast и Multicast To Unicast.
3. Смена шлюза с функционалом контроллера точек доступа (Zyxel NXC5200 был EOL) на Zyxel UAG5100, но ведь когда был iOS 12 никаких проблем не было!
В этом случае проблема была в явной несовместимости iOS 13-14 только у iPhone XS с прошивкой единичного конкретного контроллера EOL, который с 2015 не получает новые прошивки и такая же прошивка стояла у управляемой точки доступа.
Открываем вики и узнаем механизм работы Capativ Portal: https://ru.wikipedia.org/wiki/Captive_portal
Такие ощущение, что Apple в iOS так настроила механизмы поведения системы, что при блокировке телефона сбрасываются активное WiFi-подключение установленное через HTTP-ответ: код-511; ради целей безопасности пользователей в ущерб гибкости, но в угоду защиты.
Связываться с разработчиками стандарта из Стэнфордского университета видимо нет смысла, ибо из описания проблемы видно, что сессия принудительно сбрасывается операционной системой.
Открываем вики и узнаем механизм работы Capativ Portal: ru.wikipedia.org/wiki/Captive_portal
Такие ощущение, что Apple в iOS так настроила механизмы поведения системы, что при блокировке телефона сбрасываются активное WiFi-подключение установленное через HTTP-ответ: код-511; ради целей безопасности пользователей в ущерб гибкости, но в угоду защиты.
Связываться с разработчиками стандарта из Стэнфордского университета видимо нет смысла, ибо из описания проблемы видно, что сессия принудительно сбрасывается операционной системой.
Спасибо. Даже нечего добавить. Жаль, что поизящнее не придумали защиту.
Такие ощущение, что Apple в iOS так настроила механизмы поведения системы, что при блокировке телефона сбрасываются активное WiFi-подключение установленное через HTTP-ответ: код-511; ради целей безопасности пользователей в ущерб гибкости, но в угоду защиты.
stitrace сообщал здесь, что при авторизации 802.1х такая же проблема.
Я это протестирую и если повторится поведение, получается, что не совсем дело в HTTP.
Нет, у меня тоже самое в закрытой wpa-eap сети с mikrotik и ios 14/15
Вот что на этот счёт говорит эпловская страничка https://developer.apple.com/news/?id=q78sq5rv
Моя первая мысль после прочтения статьи была - айфонам может не нравиться открытая сеть без шифрования и\или кэптив портал без шифрования.
Но поводу второго, но ведь, если удалять сеть на АйФоне и заново подключиться авторизованным АйФоном, то ничего не отваливается, получается до авторизации в работу вступает ещё какой-то механизм защиты от перехвата… который впоследствии отключает телефон от Wi-Fi и удаляется с настройками Wi-Fi…
к слову да, касательно hotspot и авторизации - важен сертификат ssl.
Мы так генерим сертификат для микротика на всем известной площадке, подсовываем и после этого так же включается редирект большинства https сайтов. логика в том что данный сертификат помогает хотспоту заглянуть в заголовок пакета, а для редиректа этого достаточно. не работает для таких сайтов как google/yandex в чистом виде, но там появляется кнопка перехода на captive portal))))
С яфонами проблем не наблюдаем на хотспоте(время сессии/лизы/авторизации ставим 30 дней, а так же авторизовываем по mac cooky и по http/https cocky). портал конечно дно, ни лк ни статистики, но зато работает как часы
Вот что на этот счёт говорит эпловская страничка https://developer.apple.com/news/?id=q78sq5rv
Попробовал по их страничке добавить DHCP опцию 114 с указанием адреса на внешнюю страницу авторизации (либо FQDN, либо TEXT). Не помогло к сожалению. Проблема осталась.
Начало статьи несколько более широкую проблему озвучивает, нежели основная часть. Iphone отключают WiFi независимо от наличия Captive Portal (у меня точки доступа с EAP - тоже отрываются), просто способы аутентификации, отличные от Captive Portal, Iphone могут "повторить" без участия пользователя, т.к. помнят credentials (хотя тот же EAP занимает заметное время для восстановления соединения). Для Captive Portal и credentials идут фактически мимо системы, и определить, что WiFi охраняется Captive Portal, Iphone не умеет.
Такая же проблема на сети в основе Cisco WLC2504 с dot1x авторизацией, продолжается годами, от прошивок, моделей точек или конкретных экземпляров железок.
Или у вас только 802.1х настроен и всё?
Только 802.1x и все, никаких дополнительных авторизаций нет.
Есть мнение, что это поведение как то связано с качеством сети в целом, если соединение не стабильное (например иногда пропадает пинг), то айос какими то внутренними алгоритмами оценки качества соединения переходит на более стабильный LTE. Есть в планах проверить поведение с отключённой передачей данных на соединении с сотовой сетью.
Вероятно, там имеется некий алгоритм весов объема трафика и стабильности связи, этим объясняется тот факт, то при разблокировке устройства оно заново переходит на wifi, справедливо предполагая, что сейчас требования к ширине канала могут возрасти.
Есть мнение, что это поведение как то связано с качеством сети в целом, если соединение не стабильное (например иногда пропадает пинг), то айос какими то внутренними алгоритмами оценки качества соединения переходит на более стабильный LTE. Есть в планах проверить поведение с отключённой передачей данных на соединении с сотовой сетью.
Вероятно, там имеется некий алгоритм весов объема трафика и стабильности связи, этим объясняется тот факт, то при разблокировке устройства оно заново переходит на wifi, справедливо предполагая, что сейчас требования к ширине канала могут возрасти.
Согласен с вами. Это не указывал в статье, большая бы получилась.
В общем, пробовал отключение мобильных данных, оставляя только голосовую связь и СМС. Странно получилось, мне на iOS 11 и одному на 5s iOS 12 помогало, но ровно на пару-тройку дней, потом всё снова повторялось и это сложно было. Постоянно забывали, что нужно отключать мобильные данные и включать их обратно, когда удалялись с территории Wi-Fi. Гораздо проще "Удалить сеть".
Такая же проблема на сети в основе Cisco WLC2504 с dot1x авторизацией, продолжается годами, от прошивок, моделей точек или конкретных экземпляров железок.
Проверил у себя авторизацию 802.1X (WPA-Enterprise) при отключённом Captive Portal, iPhone не отключаются, даже если интернета нет вообще.
то есть, iPhone руководствуется не только успешной загрузкой html страницы для wifi соединения.. Возможно есть что-либо еще?
Как вариант, от несведующего - что если сделать перенаправление адреса на внутреннюю страницу?
Как вариант, от несведующего — что если сделать перенаправление адреса на внутреннюю страницу?
Если внутренннюю страницу имеете в виду страницу авторизации, это не помогало.
У шлюзов Zyxel есть встроенный сервис авторизации и фактически его страница находится внутри сети.
Или ПО Элтекс SoftWLC, его страница авторизации тоже внутри сети была.
Или внутреннюю страницу как рекламу имели в виду? Она выскакивает после прохождения авторизации, а не перед авторизацией, но чтобы она выскакивала перед авторизацией, пока не получилось сделать из-за ограничений в телефонах.
На qna когда-то было такое решение проблемы: https://qna.habr.com/q/357448
Но там переделывали логику Captive Portal, так что вам может не подойти.
Если не ошибаюсь, то с ios12 в айфонах появилась опция маскировки Mac адреса в wifi сетях по умолчанию.
Прндполагаю, что именно эта фича и ломает авторизацию.
На домашнем keeneric ultra 2 пока не отключил маскировку мак адреса в айфоне жены, он каждый раз отваливался в список незарегистрированных устройств на маршрутизаторе.
Все именно так. Это частный мак адрес.
Пишу с телефона, долго все детали было описывать.
Все как вы и написали. Генерация случайного мак адреса для роутера означало новое устройство для которого ограничение скорости.
Как отключил это опцию соединения стали стабильнее но с каптив порталом похоже никак не связано.
У меня Keenetic Speedster и никаких проблем с Wi-Fi не наблюдал. Да, тоже использую регистрацию устройств. Посмотрел в настройках - "Частный адрес" включён. Почитал описание - это генерирование уникального мак адреса для каждой сети (чтобы избежать отслеживания по маку разными сетями), он не должен изменяться для уже известной и подключённой сети.
А в логах на контроллере в этот момент что? На каком основании iPhone отключается от AP? Он же должен сообщить что-то.
Второй вариант поснифать трафик, с iPhone, куда он лезет перед отключением. Если экран выключен, там трафика будет немного.
А в логах на контроллере в этот момент что? На каком основании iPhone отключается от AP?
Пишет такого рода событий, что «клиент сам отключился», нет таких событий, как ограничение сессий или типа такого.
Второй вариант поснифать трафик, с iPhone, куда он лезет перед отключением. Если экран выключен, там трафика будет немного.
Успех не приносило, протестирую ещё раз на своём телефоне, может что-то ещё вылезет.
А в логах на контроллере в этот момент что? На каком основании iPhone отключается от AP? Он же должен сообщить что-то.
Прикрепил скриншот с логами, тут.
А тестировали с отключенным private mac address и батареей не в режиме энергосбережения?
Private mac address - не со всеми роутерами работает, по опыту.
А батарея в режиме энергосбережения - как у Вас на скриншоте - пытается отключать максимум всего - не удивлюсь, что при заблокированном экране wifi тоже переходит в режим "ожидания"...
По видеоролику проверить можете, там режим энергосбережения выключен. Вот.
Подскажите, как выглядит настройка Private mac address на iOS? Или это «частный адрес»?
Напротив имени WiFi в настройках айфона нажимаете (i) и там будет второй переключатель сверху - у меня называется Private Address - не знаю, как по-русски его назвали.
Вот многие сети не работают, если его не отключить. Не знаю, с чем связано.
Русский язык — support.apple.com/ru-ru/HT211227
Английский язык — support.apple.com/en-us/HT211227
А еще ИОС при засыпании отрубает любой VPN, а при пробуждении его подключает заново. Бредовая ОС.
Был опыт с точками доступа Ubiquiti и использовал авторизацию по ваучерам, а так же в дальнейшем авторизация через провайдера на его сервисе, правда роутером был не микротик. Проблем с айфонами не было.
Ещё много где в мануалах по настройке микротика рекомендуют при настройке передатчика выставлять страну СШП и конкретно пишут для того, чтобы айфоны лучше работали. возможно копать стоит в эту сторону?
Был опыт с точками доступа Ubiquiti и использовал авторизацию по ваучерам, а так же в дальнейшем авторизация через провайдера на его сервисе, правда роутером был не микротик. Проблем с айфонами не было.
Там страница авторизации сама выскакивала или гости в браузере набирали вручную адрес сайта какого-нибудь, чтобы отредиректило на страницу ввода ваучера?
Ещё много где в мануалах по настройке микротика рекомендуют при настройке передатчика выставлять страну СШП и конкретно пишут для того, чтобы айфоны лучше работали. возможно копать стоит в эту сторону?
Спасибо за идею, попробую.
Такое действительно рекомендуют, тк американские модели (только для США), ограничены в частотах Wi-Fi и могут не найти российские каналы как 12, 13, 132 и дальше.
Как проявляется в РФ? Чистокровный американец не отобразит в списке сетей те точки доступа, которые работают на 12, 13 канале. Аналогично не отобразит точки доступа с каналами 132 и дальше, но 5 ГГц от конкретной модели Apple зависит (например, iPad A1337) и другие.
в США более либеральные ограничения на мощность передатчика, чем в почти всех других странах мира, поэтому один и тот же (модель) роутер для американского и российского рынка будет обладать разной мощностью (и, как уже сказано, диапазонами радиочастот), причём у многих вендор это ограничивается программно. Называется это «регулятореый домен». Например в решениях cisco это нельзя поменять руками в настройках.
Ещё много где в мануалах по настройке микротика рекомендуют при настройке передатчика выставлять страну СШП и конкретно пишут для того, чтобы айфоны лучше работали. возможно копать стоит в эту сторону?
Выставил США в настройках:
Не помогло. Телефон также отваливается при блокировке экрана как обычно.
Чисто из-за расходения поведения при актуальной и не очень версиях ОС: может, девайс ещё и на сервера обновления ломится? И так же, не достучавшись, считает сеть безынтернетной?
Чисто из-за расходения поведения при актуальной и не очень версиях ОС: может, девайс ещё и на сервера обновления ломится? И так же, не достучавшись, считает сеть безынтернетной?
Спасибо за идею. Попробую серверы обновлений Apple занести в «Ресурсы без аутентификации» (Walled Garden), чтобы неактуальные версии «успокоились».
Теперь список актуальных имён этих серверов обновлений найти бы.
Чисто из-за расходения поведения при актуальной и не очень версиях ОС: может, девайс ещё и на сервера обновления ломится? И так же, не достучавшись, считает сеть безынтернетной?
Проверил вашу идею. Добавил сервера обновлений в список ресурсов без аутентификации.
Не помогло. Список брался отсюда. АйФон отключается как прежде.
Для проверки, неавторизованным АйФоном заходил в Настройки -> Основные -> Обновление ПО. Не ругается, подключается к серверам обновлений. Значит список этот действительно разрешился до авторизации. Отключаю этот список, пишет: "Сбой проверки наличия обновлений".
Пробовал подключить АйФон к Wi-Fi, в котором нет интернета и портала авторизации - не отключается АйФон. Получается, что отсутствие доступа к серверам обновлений и к интернету не является причиной отключения АйФонов от Wi-Fi, авторизованных через портал авторизации.
Спасибо за проверку. А неавторизованный аЙфон, кстати, сквозь портал авторизации нормально проходит или так же клинит, как и авторизованный?
Спасибо за проверку. А неавторизованный аЙфон, кстати, сквозь портал авторизации нормально проходит или так же клинит, как и авторизованный?
Не понял ваш вопрос. Пожалуйста, по другому изложите вопрос.
Сорри, неверно интерпретировал ваш ответ. Почему-то подумалось, что "неавторизованный" - это аппарат, на котором в текущий момент не пройдена авторизация в аккаунте Apple (iCloud).
По идее в таком случае каких-то подкапотных попыток достучаться до серверов вендора явно будет меньше (ну хотя бы за счёт того, что девайс не будет пытаться синхронизироваться с iCloud), но это уже прям совсем пальцем в небо.
А что до адресов, принадлежащих Apple - вспомнил, что в своё время просил админов (по совсем другому поводу) открыть доступ ко всему блоку 17.0.0.0/8 (он действительно весь Apple-вский), т.к. конкретных адресов нужного мне сервиса не знал.
WiFi раздает ubiquity, роутер mikrotik, соответственно - hotspot повешен на vlan. Подобная проблема была, когда пробовал внутреннюю авторизацию. Помогло, когда для авторизации использовал radius-сервер, логин-пароль mac-mac. Страницу авторизации микротика переписывал. Проблема только с частным адресом, но научил юзеров отключать.
WiFi раздает ubiquity, роутер mikrotik, соответственно — hotspot повешен на vlan. Подобная проблема была, когда пробовал внутреннюю авторизацию. Помогло, когда для авторизации использовал radius-сервер, логин-пароль mac-mac. Страницу авторизации микротика переписывал. Проблема только с частным адресом, но научил юзеров отключать.
Благодарю за комментарий.
Не понял, что именно отключают?
И ещё вопрос, у гостей страница авторизации сама выскакивает или сами в браузере вводят какой-нибудь адрес сайта, чтобы отредиректило на страницу авторизации?
Не понял, что именно отключают?
Снимите чекбокс "частный адрес".
Если не снять, то при каждом переподключении к вашей гостевой сети, айфон генерит рандомный МАС. И система авторизации начинает сходить с ума)
Снимите чекбокс "частный адрес".
Благодарю. Да, сразу не разобрался о чём речь, а оказалось про генерируемые мак-адреса :)
Но это, к сожалению, не помогло в статье, пробовали отключать и включать. Проблема в другом, авторизованный АйФон в момент блокировки экрана сам отключается от Wi-Fi. Как проснётся, снова ищет Wi-Fi и подключается. Если мак-адрес не поменялся, то дальше выходит в интернет, а если поменяется мак-адрес - снова запрашивает авторизацию.
Если мак-адрес не поменялся, то дальше выходит в интернет, а если поменяется мак-адрес - снова запрашивает авторизацию.
Ну так если снять чекбокс, он не будет менять МАС. А значит не будет запрашивать авторизацию при переподключении к WiFi.
PS
Я похоже знаю одну фирму которая решила все эти проблемы.
Но вряд-ли она поделится информацией)
Если интересно - могу рассказать предысторию.
Ну так если снять чекбокс, он не будет менять МАС. А значит не будет запрашивать авторизацию при переподключении к WiFi.
Всё правильно, но почему успешно авторизованный АйФон отключается от Wi-Fi при блокировке экрана при снятом чекбоксе? Вот видео как он долго ищет Wi-Fi, т.к. он отключился от него при блокировке экрана. Соответственно, сообщения из мессенджеров не приходят при заблокированном экране.
Если интересно - могу рассказать предысторию.
Интересно, расскажите.
Года полтора назад понадобилось сделать гостевой доступ к WiFi в ресторане.
Маршрутизатор mikrotik, точки доступа и контроллер - Ubiquiti.
Изначально решил не изобретать велосипед а получить готовое решение от одной из Московских фирм. Благо все это стоит не очень дорого.
Приехал их инженер, накатил скрипт на мой микротик, кое-что настроили и в общем все заработало.
Но практически сразу полезли проблемы с айфонами. Все как у вас.
Промучался полгода и стал искать альтернативы. Нашел некую фирму Hot-WiFi которая клятвенно уверяла что смогла решить проблемы с айфонами. Каким образом - не рассказывает.
Решил попробовать. Снова приехал инженер, залил скрипт на микротик и все заработало.
Как это ни странно - проблемы с айфонами пропали. Уже несколько месяцев жалоб от посетителей не поступает. Единственное НО - у них бывает что невозможно дозвонится по телефону аутентификации. Но это уже не проблемы айфонов.
Самое интересное что они смогли решить проблемы без манипуляций с абонентскими устройствами... Т.е. они емнип не требуют отключать например рандомизацию MAC-адресов.
PS
Кстати.
Если вы пытаетесь подключится к гостевой WiFi сети Московского метрополитена и у вас включена рандомизация MAC - выскакивает предупреждение что рандомизацию необходимо отключить. Иначе может не работать. И такое предупреждение выскакивает не только на айфонах но и на андроидах последних версий. На 11-м точно.
Radiohead72, спасибо за историю. Вопрос. Когда проблемы исчезли, у гостей на АйФонах страница авторизации сама выскакивает или они сами набирают сайт авторизации как в московском метрополитене, судя по их памятке?
https://maximatelecom.ru/support.html там на втором этапе обязаны набрать:
В адресной строке браузера введите gowifi.ru
Если память не изменяет - сама выскакивает.
Наверное можете спросить у них в телеге - https://t.me/hotwifiofficial
Она кстати и в метро выскакивает. Но не всегда)
Прошу прощения, насколько реально выложить конфиг этого Микротик, скрыв, конечно, все персональные и чувствительные данные?
Постоянные и гостевые у меня один и тот же hotspot используют . Постоянных по mac завожу на radius , чтоб авторизацию не просил. Разруливаю доступ к внутренним сервисам через группы на радиус-сервере (Радиус отдает ip в address-list на роутер)
Негостевые пользователи в настройках wifi отключают частный адрес на айфонах. Гостевые бывают ненадолго , им не надо, ну или повторно авторизуются.
Страница авторизации выскакивает.
За айфон сейчас не вспомню, андроид иногда воспринимает вайфай как открытую сеть без интернета и спрашивает лишнее подтверждение на подключение, но потом нормально страница выскакивает.
Возможно я не прав, но глянул у себя на телефоне, по умолчанию опция "Частный адрес" включена на все WiFI сети, но уникальный мак генерится для всех WiFI сетей и потом не меняется (то есть он разный для разных сетей и не меняется при переподключении)
Возможно, проблема все же не с оборудованием, а с самой системой которая у Вас делает авторизацию Captive Portal и у Вас не правильно настраивается время жизни Hotspot-клиента. Проверит это можно тут: ip hotspot active
Собственно я вижу проблему так:
1. IOS устройство подключилось.
2. IOS устройство ушло в сон
3. IDLE-TIMEOUT - истек и клиента удалили.
4. IOS устройство проснулось, подключилось к WiFI и юзеру нужно опять зайти и "авторизоваться" на Captive Portal-e
Когда делал свою систему для авторизации клиентов через Captive Portal с соц. сетями и смс-ками - я запоминал клиентские маки с неким таймаутом и авторизовывал их на микротик-овом hotspot-e без участия клиента.
1. IOS устройство подключилось.
2. IOS устройство ушло в сон
3. IDLE-TIMEOUT — истек и клиента удалили.
4. IOS устройство проснулось, подключилось к WiFI и юзеру нужно опять зайти и «авторизоваться» на Captive Portal-e
Пункт 3 idle-timeout выставлен на 600 мин (как пример).
Между пунктами 2 и 4 интервал 30-50 секунд и iOS при блокировке экрана (пункт 2) сразу отключается от Wi-Fi и при наступлении пункта 4 ищет точку доступа и успешно подключается к ней обратно. Если частный адрес был отключен, то авторизацию не требует повторно.
Проблема в том, что когда экран тухнет, телефон сам отключается от Wi-Fi сам по себе, но при этом сессия авторизации ещё активна на хотспоте. Как телефон разблокируется, ищет по 5-10 сек точку доступа и обратно подключается к ней и спокойно сёрфится как будто ничего не было и так до следующей блокировки экрана.
Извиняюсь, не совсем по теме, но я в прошлом году ковырялся с офисной IP телефонией для яблочных мобильников и с удивлением узнал, что эта прекрасная операционная система блокирует фоновую передачу UDP. Со всеми вытекающими для телефонии: исходящие звонки можно, а входящие только при включеном экране. Зачем так делать одному Эплу известно, но как говаривал Ричард Столман, если программа выполняет не только команды пользователя устройства, а команды кого-то ещё, то это несвободное программное обеспечение.
Веселее — входящие только через VoIP-пуши и, спасибо индусам, которые любили их юзать для пробуждения телефонов в своих кривых поделиях с сопутствующим пожиранием батарейки — только через CallKit.
Что влечёт за собой мало того что пуш-сервер, так ещё и отображение сраного яблочного окна входящего звонка, которое в некоторых юзкейсах, прямо скажем, не пришей кобыле пятое колесо.
У нас, например, нет никакого звука, пока юзер не ответит на звонок сам, посмотрев на видео с камеры наблюдения. В итоге получается очень всратый UX:
- Юзеру прилетает звонок на залоченный телефон, звучит рингтон
- Юзер отвечает слайдом, высвечивается яблочный интерфейс звонка, звучит опять рингтон! Только уже воспроизводимый приложением.
- Юзер жмякает на кнопку на панели и попадает уже в приложение, видит видео и решает, отвечать или нет.
В панели есть кнопка "видео", которая, впрочем, тоже никакого системного апи не представляет для показа своего видеопотока. И принудительно после ответа прыгнуть в наше приложение можно только при разлоченном телефоне.
При этом до айос 13 всё было нормально, а потом всё ни с того ни с сего обдристали.
по идее, ему нужно идти в Safari и самостоятельно набрать в адресной www.ru или любой http сайт, таких почти не осталось в интернете, всё на https переехало. Большинству набор адреса страницы является трудновыполнимой задачей (в некоторых браузерах адресной строки уже нет).
Для этого есть http://neverssl.com
Для этого есть http://neverssl.com
Кстати, да, забыл про этот момент в статье указать (да нет, это совсем другая тема). Нынешняя статья про конкретную проблему с АйФонами. Пробовали сертификаты, но не прокатило. Они выпускаются только для публичных IP, а в гостевой сети у хотспота внутренний IP, поэтому гостям выдаёт ошибку сертификата, даже если происходит редирект на внешнюю страницу авторизации. Дело в том, что процессом редиректа заведует сам хотспот, поэтому после подключения к точке доступа телефоны сначала к нему подключаются (к его внутреннему IP), а потом к внешнему сервису авторизации. Но всё ломается на этапе подключения к хотспоту.
Например, гость нажал в браузере в разделе "ИЗБРАННОЕ" на страницу с https://yandex.ru, его редиректит сначала на хотспот (не отображено на скриншоте), но выдаёт ошибку как на скриншоте, поэтому дальше никуда не пускает, т.к. браузер телефона предупредил и отказывается какие-либо соединения производить.
Но эта проблема касается всех устройств, как АйФоны, так и Андроиды и Виндовсы.
Поэтому в этой ситуации наилучшим вариантом является CNA браузер, в CNA браузере таких проблем нет, но успешно авторизованные АйФоны потом отключаются от Wi-Fi при блокировке экрана, о чём и было поведано в этой статье.
Необходимо, напрягать внешний сервис авторизации, чтобы сделали http сайт и все гости его вручную набирали? Но как всем гостям расскажешь, что нужно такой-то сайт набирать правильно!? Они всё равно забудут и попрут нажимать на страницу в ИЗБРАННОЕ. Проходили 4 года, знаем, невозможно отучить их от этой привычки. Поэтому CNA является наилучшим вариантом для наших гостей.
сертификат выпускается на доменное имя, если оно у Вас есть, можете хоть wildcard выпустить.
Для примера у меня сертификат выпущен на имя hs.companyname.ru, и адрес у этого доменного имени 10.5.5.5, и норм робит, замочек нормальный имеется и зелёная галочка тоже.
арендуйте доменное имя, если нету, выпустить на летсэнкрипт сертификат - почти уверен будет вам счастье, к слову если нет авторизации по мак кукам и http/https кукам - то проблема скорее всего останется, но зато будет нормальный редирект https)))
попробуйте поюзать связку mikrotik (hotspot) + Freeradius (radius) + Mysql (бд логопасов) + sms портал(можно поизвращаться с астериском)
Так что если хотите попут
Спасибо большое за развёрнутый ответ, вспомнил что в 2018 техподдержка Zyxel аналогичный сценарий предложила, но не получилось на UAG5100 реализовать, там механизм редиректа по FQDN имени не работал, они дефект исследовали и признали его. Обещали, что всё работает на шлюзах VPN, а UAG5100 не исправляют, т.к. он в статусе EOL и не поддерживается разработчиками.
Если до конца года не получится гуманным путём пофиксить АйФоны по предложенным комментариям, придётся пойти по пути сертификатов и попробую реализовать на шлюзе VPN.
У меня Ubiquiti, но на айфонах реально помогает в настройке SSID отключение динамического MAC для этого SSID .
Могу еще посоветовать отключить airtime fairness и порог минимальной скорости для клиентов (потому что фактический uplink клиента в режиме энергосбережения - когда отключен экран равно 1мбит/сек)
Есть еще вариант отключить опцию на DHCP сервере "Add ARP for Leases", если есть (как например в мтиках)
столько исследований, обсуждали жанную проблему на курсах по mikeotik.
проблема аот в чем: iphone при выключении экрана вырубает модуль wifi полностью, а при включении включает обратно, фиксится увеличением времени аренды ip адреса в dhcp сервере, т.к. через половину от времени аренды устройство должно подтвердить что оно все еще арендует адрес, в домашних роутерах это обычно несколько дней, в открытых сетях обычно минуты. но поможет ли это с captive portal я не знаю.
Самое удивительное было то, что когда выходит новая версия iOS, нынешняя исправная версия начинает отваливаться от Wi-Fi. Раньше же нормально работало на этой же версии! Получается, что как версия iOS устаревает, телефон будет отваливаться от Wi-Fi.
похожая штука была с тетерингом через блютус, когда в последнем апдейте iOS он вдруг почему-то "ломался", и старые устройства, которые больше нельзя было обновить на новую версию, переставали нормально работать по расшаренному интернету. словно это такой "привет" от Эппл, с намеком на то, что нефиг использовать старое - иди покупать новое.
Спасибо за комментарии.
Могу еще посоветовать отключить airtime fairness и порог минимальной скорости для клиентов (потому что фактический uplink клиента в режиме энергосбережения - когда отключен экран равно 1мбит/сек)
Попробую, но я столько разных точек доступа перепробовал, одно и тоже.
Есть еще вариант отключить опцию на DHCP сервере "Add ARP for Leases", если есть (как например в мтиках)
проблема аот в чем: iphone при выключении экрана вырубает модуль wifi полностью, а при включении включает обратно, фиксится увеличением времени аренды ip адреса в dhcp сервере, т.к. через половину от времени аренды устройство должно подтвердить что оно все еще арендует адрес, в домашних роутерах это обычно несколько дней, в открытых сетях обычно минуты. но поможет ли это с captive portal я не знаю.
Вы, наверное, пропустили абзац в статье. Я статический IP выставлял, чтобы исключить какое-либо влияние DHCP на АйФоны - абсолютно ничего не поменялось.
Попробуйте ещё открыть доступ к captive.apple.com без авторизации. Я не очень понимаю что это за магия и каким образом работает, но я заметил что в некоторых сетях с captive авторизацией меня на айфоне перебрасывает именно туда. К слову- у нас в компании не знаю чьё решение , но используется captive-авторизация и вайфай не отваливается при выключенном экране.
Спасибо за комментарий.
Попробуйте ещё открыть доступ к captive.apple.com без авторизации. Я не очень понимаю что это за магия и каким образом работает, но я заметил что в некоторых сетях с captive авторизацией меня на айфоне перебрасывает именно туда. К слову- у нас в компании не знаю чьё решение , но используется captive-авторизация и вайфай не отваливается при выключенном экране.
Для интереса пробовал такое :) страница авторизации тогда не выскочит ни у одного Apple.
captive.apple.com нужен для Apple, по нему он определяет, есть ли интернет или его отредиректит на страницу авторизации.
а таблицу ARP проверяли?
а таблицу ARP проверяли?
Где и на что её проверить? На порте коммутатора обычный список мак-адресов, подключившихся к точке доступа и сама точка доступа. Когда АйФон блокирует экран и тухнет, его мак-адрес исчезает из таблицы.
Таблицу ARP нужно смотреть на роутере, и возможно, на контроллере. Нужно посмотреть, какой ip он будет ВИДЕТЬ при новом маке. Эти записи могут отличаться от DHCP кэша. В идеале, на новом маке должен сразу же быть другой новый ip, а не старый.
Таблицу ARP нужно смотреть на роутере, и возможно, на контроллере. Нужно посмотреть, какой ip он будет ВИДЕТЬ при новом маке. Эти записи могут отличаться от DHCP кэша. В идеале, на новом маке должен сразу же быть другой новый ip, а не старый.
На новый МАК-адрес роутер выдаёт новый IP. Старые IP к старым МАК-адресам роутер никому не отдаст пока действует время аренды. Далее по обстоятельствам, исчезает ли клиент или попросит продлить аренду.
Я же специально указал: "какой ip он будет ВИДЕТЬ при новом маке". Не в таблице лизов DHCP, которые он РАЗДАЕТ, а в таблице ARP, где он ВИДИТ.
"Эти записи могут отличаться от DHCP кэша."
Я же специально указал: "какой ip он будет ВИДЕТЬ при новом маке". Не в таблице лизов DHCP, которые он РАЗДАЕТ, а в таблице ARP, где он ВИДИТ.
"Эти записи могут отличаться от DHCP кэша."
Имеете в виду сверку таблицу мак-адресов в CLI с DHCP-таблицей выданных адресов. Правильно понимаю?
И потом, у iOS 9 - 13 нет функции рандомных мак-адресов. Предполагаете, что в момент блокировки (затухании экрана) АйФона в таблице возникает аномалия с мак-адресом с IP-адресом? Пронаблюдаю.
Нет, это таблица кэша, где сверяется mac и айпи. DHCP таблица там не имеет отношения. На винде прописывается как "arp -a". На мтике это нужно зайти на IP==>ARP.
Кстати по цитате "Имеете в виду сверку таблицу мак-адресов в CLI с DHCP-таблицей выданных адресов. Правильно понимаю?", могу предложить, что может срабатывать защита от DHCP спуфинга, и контроллер или роутер для защиты принудительно кикают клиента
Нет, это таблица кэша, где сверяется mac и айпи. DHCP таблица там не имеет отношения. На винде прописывается как "arp -a". На мтике это нужно зайти на IP==>ARP.
Я понял, спасибо. Пронаблюдаю, может что всплывёт.
могу предложить, что может срабатывать защита от DHCP спуфинга, и контроллер или роутер для защиты принудительно кикают клиента
В логи ничего такого аварийного не пишется, кроме сообщений, что телефон отключился от Wi-Fi, типа такого, как потух экран:
Oct 21 10:49:47 UAG5100 src="0.0.0.0:0" dst="0.0.0.0:0" msg="STA Disassociation(8:DISASSOC_STA_HAS_LEFT) MAC:xx:xx:xx:xx:AB:xx, AP:TD01-06" note="" user="unknown" devID="xx5dxxxxxxxx" cat="Wlan Station Info"
Роутер сбрасывал до дефолтных настроек, все-все ограничения были отключены, DHCP выключал целиком и ставил телефонам только статические IP. Ничего не помогло. Отключение портала авторизации или "Забыть сеть" на АйФонах отлично помогает.
Здравствуйте.
Посмотрите ниже статью, может поможет описания работы Apple и сопутсвующие проблемы.
Распределённый Captive Portal в публичных местах и сложности с Apple - https://habr.com/ru/post/252263/
Здравствуйте.
Посмотрите ниже статью, может поможет описания работы Apple и сопутсвующие проблемы.
Распределённый Captive Portal в публичных местах и сложности с Apple - https://habr.com/ru/post/252263/
Благодарю за ссылку. Знакомы с вашей ссылкой и после неё специально проводил тест АйФона только с одной с однодиапазонной 2.4 ГГц точкой доступа, чтобы исключить влияние 5 ГГц и рядом других точек доступа с дублирующим SSID не было. Проблема осталась. Можете убедиться в вышеприведённой таблице №2, как замена имени SSID не помогала, чтобы исключить влияние распределённой сети на iPhone.
Добро. Помимо описанного Вами "Забыть сеть", не помню говорилось ли об этом или нет, может стоит попробовать иные манипуляции с телефоном:
- включить и отключить «Авиарежим»
- "Обновить соединение" (находится ниже "Забыть сеть" - Renew Lease)
- отключить на телефоне "Помощь Wi-Fi" (типа если с ним что-то не то вырубает его и подключает через мобильный интернет)
- отключить службы геолокации и "сетевые сервисы Wi-Fi" (System Services - Wi-Fi Networking)
- деактивировать VPN, если он есть
- деактивировать «Автоподключение»
- включить «Подтверждать соединение»
- поставить DNS вручную (например на 8.8.8.8)
- как крайний вариант, выполнить принудительную перезагрузку или "Сбросить настройки сети" (перезагрузится после этого, после нужно заново водить пароли вайфая - Reset Network Settings).
А на устройстве сети есть такой параметр «Wi-Fi Multimedia» (WMM, WME, ...)? Можно попробовать его активировать.
Когда тестировали при подключении чтоб работал только на 2.4 ГГц, канал (частота) у точки доступа стоял фиксированный или "авто"? Если "авто", то можно попробовать поставить на определённый канал.
RMtechtrend
Ваши вышеуказанные рекомендации неоднократно проделывались на различных моделях АйФонов и различных шлюзах, хотспотах и точках доступа. Это подробно расписано в статье.
А на устройстве сети есть такой параметр «Wi-Fi Multimedia» (WMM, WME, ...)? Можно попробовать его активировать.
По дефолту она была включена у точек доступа Zyxel.
Когда тестировали при подключении чтоб работал только на 2.4 ГГц, канал (частота) у точки доступа стоял фиксированный или "авто"? Если "авто", то можно попробовать поставить на определённый канал.
Фиксированные каналы стоят и однодиапазонные точки доступа ставились, чтобы только 2.4 ГГц (канал 1) работал или 5 ГГц (канал 36).
Не пробовал ли автор отключить в айфонах функцию регулярной смены мак адреса?
Ну и общие рекомендации. Канал не выше 10го, заглавные буквы в SSID, кип алив (если таковой есть в настройках). В микротиках (не знаю есть ли такой параметр в зюкселях) в свое время была проблема с параметром preamble mod, айфоны работали только если параметр равнялся "long" и канал был не выше 10го.
Благодарю за комментарий. По порядку:
Не пробовал ли автор отключить в айфонах функцию регулярной смены мак адреса?
В первую очередь это было отключено и этой функции не было в iOS 9 - iOS13 до 2020 года, а всё равно отключаются с 2016 года и по сегодняшний день с iOS 14-15.
Ну и общие рекомендации. Канал не выше 10го, заглавные буквы в SSID, кип алив (если таковой есть в настройках). В микротиках (не знаю есть ли такой параметр в зюкселях) в свое время была проблема с параметром preamble mod, айфоны работали только если параметр равнялся "long" и канал был не выше 10го.
Рекомендуемые вами параметры для тестируемой точки доступа уже стояли, совпали с вашими ) Преамбула - скорее всего это "Guard Interval". Тем не менее, различные варианты пробовал, ничего не помогает. Прошу учесть, если выключить портал авторизации - всё нормализуется у АйФонов.
Keep Alive не встретил в настройках Wi-Fi. В названии SSID 6 английских букв (маленькие и заглавные) без пробелов. Нет спецсимволов.
Судя по скрину ширина канала 20 МГц. Можно попробовать разширить пропускную способность, поставить 40 МГц (или 20/40 - не знаю какие опции есть). Возможно когда портал авторизации "есть", то при отсутствии "принудиловки" по поддержанию состояния подключения (экран затухет и переходит в эконом режим) он этот "суженный" канал (20 МГц.) считает "не тем что надо" при подключении по 802.11n.
Также пробовали ли "Allow Station Connection after Multiple Retries" ставить на максимум (100)?
Можно также "поиграться" с "Multicast Settings", типа поставить "Мulticast to Unicast" или "Rate" поменять - не понимаю как это поможет, но стоит потыкать всюду.
ОПС ... только заметил что насчёт мультикаста уже писали ...
Судя по скрину ширина канала 20 МГц. Можно попробовать разширить пропускную способность, поставить 40 МГц (или 20/40 — не знаю какие опции есть). Возможно когда портал авторизации «есть», то при отсутствии «принудиловки» по поддержанию состояния подключения (экран затухет и переходит в эконом режим) он этот «суженный» канал (20 МГц.) считает «не тем что надо» при подключении по 802.11n.
Ничего не помогает, к сожалению.
Лечится только удалением сети.
Просмотрите таблицы выше, там написано после чего отключаются от Wi-Fi и два способа частичного лечения.
Ещё особенность, АйФоны от 4s до 7, iPad 1-3 не работают на 40 мГц в 802.11n 2.4 гГц. Специально их проверял на роутере Zyxel Keenetic 4G, он умеет отображать в статусе подключённых устройств ширину канала.
Работают только на 20 мГц в 802.11n 2.4 гГц.
Андроид (производитель Fly) и ноутбук HP работают хорошо с шириной 40 мГц на этом же роутере.
https://developer.apple.com/news/?id=q78sq5rv А сюда смотрели?
https://developer.apple.com/news/?id=q78sq5rv А сюда смотрели?
Спасибо за комментарий. Да, смотрели, выше приводили ссылку. Пока ничего не скажу, нужно детально проанализировать и понять как работает.
На своем примере: смартфон Lenovo C2 (Android 6) + роутер Trendnet (прошивка 2007 года).
IP адрес статический, настройка «Keep WLAN on during sleep» = Always.
А почему такой странный IP-адрес у хотспота шлюза 6.6.6.6?
А почему такой странный IP-адрес у хотспота шлюза 6.6.6.6?
В дефолтном конфига шлюза выставлен. Легко запоминается, легко набирается, никем не занят в интернете. При обращении к нему гостям откроется внутренняя страница хотспота с оставшимся временем сессии интернета и кнопкой завершения сессии интернета.
При желании, этот адрес можно сменить на любой незанятый публичный IP (большой стрелкой указан).
Добавил скриншот логов.
Поведение iPhone iOS 13 по логам шлюза. Отсутствуют критические аварии по мак-адресу и по IP-адресу. Одно спокойствие.
Если бы я был пользователем айфона, то на чьё-то предложение мне поменять телефон, только потому что они не могут настроить гостевой вай-фай со своим дурацким captive порталом, просто отправил бы подальше. Тоже самое, если бы был пользователем любого другого телефона.
Встречаются такие, отстаивают телефон, доводят до замены точки доступа (перевод на 5 ГГц). Казалось, что шлюз как контроллер точек доступа придётся менять, тк показалось, что все новые модели телефонов не будут работать как XS, но к счастью, АйФоны 11, 12 исправили и хорошо работают на нынешних точках доступа и шлюзе, ничего не пришлось менять.
Но столько времени даром потратили на радиоисследование, замену точек доступа, перебор настроек, поиск помех.
Встречаются такие, отстаивают телефон, доводят до замены точки доступа (перевод на 5 ГГц). Казалось, что шлюз как контроллер точек доступа придётся менять, тк показалось, что все новые модели телефонов не будут работать как XS, но к счастью, АйФоны 11, 12 исправили и хорошо работают на нынешних точках доступа и шлюзе, ничего не пришлось менять.
Но столько времени даром потратили на радиоисследование, замену точек доступа, перебор настроек, поиск помех.
Это про случай здесь.
Там не только одну ссылку http://www.apple.com/library/test/success.html надо разрешать.
Доменов у них для этой цели много. Попробуйте разрешить все /library/test/success.html
И у старых iOS другой формат ссылки /hotspot-detect.html
Там не только одну ссылку http://www.apple.com/library/test/success.html надо разрешать.
Доменов у них для этой цели много. Попробуйте разрешить все /library/test/success.html
И у старых iOS другой формат ссылки /hotspot-detect.html
Разрешить всё на адрес /library/test/success.html не получилось, необходимо домен указывать.
Тут добавлял домены серверов Apple, проблема осталась.
Это не те домена которые нужны для Captive Portal.
Среди них должны быть www.apple.com и captive.apple.com
Добавлял "www.apple.com" в "Ресурсы без аутентификации", не помогло. Если туда же добавить "captive.apple.com" страница авторизации не выскочит ни у одного Apple.
captive.apple.com нужен для Apple, по нему он определяет, есть ли интернет или его отредиректит на страницу авторизации.
Перенаправить запросы по url можно через wpad
Можете подробнее рассказать? Есть примеры реализации этого механизма на хотспотах?
Сетка обычная совершенно, без Captive Portal. iPad 6 A1893 (2018 г) постоянно отключается после перехода в ожидание. Так же пока не удаётся найти решения.
Шо, опять?