Как-то неадекватно отрабатывает на WiFi Key Renewal Interval (возможно виноват клиент)
Цитата: RoxsAndy от 05/04/2019, 21:47Прошу проверить пользователей и разработчиков некоторую особенность, которую словил у себя.
Суть "проблемы" в следующем: по умолчанию Key Renewal Interval выставлен в 3600 (1час), но при выходе из спящего режима сотка LG периодически с различным интервалом (без видимых закономерностей) на секунду-две теряет связь с вайфай и переходит на мобильные данные, и затем тут же обратно, т.е. как-будто обновился ключ. Причём это явно происходит не раз в час, а с какой-то непонятной закономерностью, но точно после выхода из спячки.
Пока решил "проблему" установкой Key Renewal Interval в значение 86400. Отвалы после спячки прекратились (или интервал стал более длинным и я их не замечаю теперь).
Возможно виновата сама сотка LG, поэтому тема не в багах.
Прошу проверить пользователей и разработчиков некоторую особенность, которую словил у себя.
Суть "проблемы" в следующем: по умолчанию Key Renewal Interval выставлен в 3600 (1час), но при выходе из спящего режима сотка LG периодически с различным интервалом (без видимых закономерностей) на секунду-две теряет связь с вайфай и переходит на мобильные данные, и затем тут же обратно, т.е. как-будто обновился ключ. Причём это явно происходит не раз в час, а с какой-то непонятной закономерностью, но точно после выхода из спячки.
Пока решил "проблему" установкой Key Renewal Interval в значение 86400. Отвалы после спячки прекратились (или интервал стал более длинным и я их не замечаю теперь).
Возможно виновата сама сотка LG, поэтому тема не в багах.
Цитата: Xelrons от 05/04/2019, 23:35Не разу не замечал отваливание с 5ггц на ме1
Как-то так
Настройки в радио по умолчанию.
Не разу не замечал отваливание с 5ггц на ме1
Как-то так
Настройки в радио по умолчанию.
Цитата: sfstudio от 06/04/2019, 15:43Да эт известный косяк части клиентов. Клиенты так и сяк должны просыпаться что бы выполнить rekey и желательно при этом что-то пукнуть в сторону AP. Но некоторые ведроиды (я на них отлавливал) уходят в мёртвую спячку, а когда очухиваются и лезут со старым ключём до АП получают закономерный "иди отседа".
Так что да, только выкручиваение rekey интервала больше никак. Ну либо забить ибо вот уж точно секундная потеря связи при выходе из сна проблемой мягко сказать назвать сложно.
Да эт известный косяк части клиентов. Клиенты так и сяк должны просыпаться что бы выполнить rekey и желательно при этом что-то пукнуть в сторону AP. Но некоторые ведроиды (я на них отлавливал) уходят в мёртвую спячку, а когда очухиваются и лезут со старым ключём до АП получают закономерный "иди отседа".
Так что да, только выкручиваение rekey интервала больше никак. Ну либо забить ибо вот уж точно секундная потеря связи при выходе из сна проблемой мягко сказать назвать сложно.
Цитата: RoxsAndy от 06/04/2019, 19:12Соглашусь, что это не совсем проблема.
Просто писатель из меня никудышний и суть фичи я донести своим постом не смог. Попробую уточнить.
Дело не в том, что клиент после просыпания обновляет ключ, а в том, что не выдерживается заданный интервал обновления этого ключа. Т.е. после просыпания клиент нормально подключается со старым ключём, но через некоторое время (минута, две, десять, двадцать - интервал всё время разный) происходит реконект клиента. А ещё через некоторое время (опять без определёных таймингов) может произойти ещё один. А может всё работать как часы. Причём между двумя смежными обновлениями ключа клиент не засыпал, но и интервал в один час не был выдержан. Вот как-то так происходит на моей сотке, поэтому подозрения именно на клиента, но чтобы до конца выяснить этот вопрос - попросил здесь проверить, понаблюдать за поведением вайфай на других связках.
PS. Я могу конечно предположить, что по стечению обстоятельств я часто попадаю на конец интервала смены ключа, но что-то верится в это с трудом.
PPS. А можно указать место в драйверах, где раставить принты, чтобы включить вывод в лог моментов апдейта ключа и переподключения клиентов, чтобы более точно отловить закономерность. Сам, боюсь, в сырцах вайфая заблужусь как в дремучем лесу. :)
Соглашусь, что это не совсем проблема.
Просто писатель из меня никудышний и суть фичи я донести своим постом не смог. Попробую уточнить.
Дело не в том, что клиент после просыпания обновляет ключ, а в том, что не выдерживается заданный интервал обновления этого ключа. Т.е. после просыпания клиент нормально подключается со старым ключём, но через некоторое время (минута, две, десять, двадцать - интервал всё время разный) происходит реконект клиента. А ещё через некоторое время (опять без определёных таймингов) может произойти ещё один. А может всё работать как часы. Причём между двумя смежными обновлениями ключа клиент не засыпал, но и интервал в один час не был выдержан. Вот как-то так происходит на моей сотке, поэтому подозрения именно на клиента, но чтобы до конца выяснить этот вопрос - попросил здесь проверить, понаблюдать за поведением вайфай на других связках.
PS. Я могу конечно предположить, что по стечению обстоятельств я часто попадаю на конец интервала смены ключа, но что-то верится в это с трудом.
PPS. А можно указать место в драйверах, где раставить принты, чтобы включить вывод в лог моментов апдейта ключа и переподключения клиентов, чтобы более точно отловить закономерность. Сам, боюсь, в сырцах вайфая заблужусь как в дремучем лесу. :)
Цитата: sfstudio от 06/04/2019, 19:18Включить дебаг, повысить его уровень и посмотреть если сильно интересно. Но в любом случае проблема на клиенте т.к. на стороне АП таймеры тикают всегда без остановки и если бы проблема была бы на стороне АП с таймерами то Ж была бы на всех клиентах.
На уровне ванги могу предположить что на клиенте банальный счётчик по которому считается время до rekey, а во сне этот счётчик тупо не тикает. А дальше как повезёт смотря когда проснулись. В итоге на АП rekey interval почти истёк, а на клиенте до него ещё пол часа например.
Это другая сторона всё той же описанной мной выше проблемы. Когда гугл реализовал deepsleep масса клиентов попало на это дело. Правда относительно быстро это всё и пофиксили или некоторые вендоры отказались от deep sleep вовсе.
Включить дебаг, повысить его уровень и посмотреть если сильно интересно. Но в любом случае проблема на клиенте т.к. на стороне АП таймеры тикают всегда без остановки и если бы проблема была бы на стороне АП с таймерами то Ж была бы на всех клиентах.
На уровне ванги могу предположить что на клиенте банальный счётчик по которому считается время до rekey, а во сне этот счётчик тупо не тикает. А дальше как повезёт смотря когда проснулись. В итоге на АП rekey interval почти истёк, а на клиенте до него ещё пол часа например.
Это другая сторона всё той же описанной мной выше проблемы. Когда гугл реализовал deepsleep масса клиентов попало на это дело. Правда относительно быстро это всё и пофиксили или некоторые вендоры отказались от deep sleep вовсе.
