Как стать автором
Обновить
0
0
Леонов Дмитрий @kraps

Пользователь

Отправить сообщение
Неплохой материал есть здесь: iOS Разработка на языке Swift — Национальный Исследовательский Университет «Высшая Школа Экономики» (https://itun.es/ru/e6Vg4)
Пятый урок посвящён именно CoreData
К сожалению, в данной ситуации 1,6 и 11 каналы не решали проблему. Если я напишу эту рекомендацию, то поступлю не честно. Увы это так. Проблема, связанная с замираниями в ЧНН наблюдалась. Скриншот был снят днем, когда количество клиентов не большое. Проверяли количество ТД в ЧНН оказалось порядка 122, из них активных 32. Да, в WiFi сети полный бардак, но это исключительно настройки ос стороны клиента и нам приходится выходить за грани теории и пытаться решить проблему клиента, конечно с обязательным пояснением по теоретическим основам, хотя далеко не всех они интересуют.
Прежде всего я не давал рекомендации ставить всем поголовно 12 канал. Ровно, как и не писал о том, чтобы пользователи не пытались договариваться с соседями. Как вы считаете, какой канал будет выбран автоматически после перезагрузки роутера: 1,6 или 11?
Согласен с вами при условии, что абсолютно все клиенты «порядочные» и находятся на 1, 6 или 11 канале. На представленном скриншоте все «расселись» вразнобой по собственному усмотрению, будь то ручное или автоматическое размещение. В связи с этим наблюдались описанные проблемы. Теоретическая основа вполне понятна, и спора не вызывает, но как быть в ситуации, которая отображена на скриншоте, с учетом того, что при размещении ТД на 1,6 и 11 каналах «фризы» есть?
Спасибо за ответ. Приведенный Вами пример сравнения ситуаций, к сожалению, не приблизил к решению, как и предложение перегрузить роутер, т.к. по статистике обращений, это первое действие, которое пытается выполнить пользователь до обращения в техническую поддержку оператора связи.
Тогда все начнут повышать мощность что приведет к ухудшению ситуации. Вопрос, как найти золотую середину, чтобы все остались довольны? Теория это безусловно правильно, но практика, к сожалению, бывает с ней не сходится. Статью серьезно раскритиковали, поэтому я предлагаю, чтобы кроме критики комментирующие предлагали рабочее решение, так на мой взгляд будет гораздо продуктивнее. Я со своей стороны готов дать обратную связь применялось ли предложенное решение или нет на практике и что из этого получилось.
При установке на 1,6 или 11 канал наблюдаются «фризы», в данной ситуации какая должна быть рекомендация пользователю в качестве решения проблемы? На представленной картинке скриншот снят днем примерно в 14:00, в вечернее время на 1-м канале ситуация аналогичная остальным. Да и фризы на 1-ом канале также наблюдались в момент снятия скриншота, хотя заметно меньше, чем в вечернее время.
Имеем практическую задачу. Какое техническое решение Вы рекомендуете пользователям при работе на 1,6 и 11 каналах и наличии проблем, выраженных в регулярных «фризах»? Договориться с соседями не техническое решение в данной задаче.
Уважаемые коллеги, прочитав ваши комментарии, хочу дать вам комплексный ответ.
Прежде всего следует ответить, что хабровчане, которые участвуют в обсуждении, являются активными пользователями, обладающие техническими навыками и опытом работы с активным оборудованием. Данные участники обсуждения способны без данной статьи разобраться в вопросе, поэтому в данной статье они вполне продуктивно выступили в качестве экспертов, дополнив статью дополнительной информацией и ссылками на материал, за что им отдельное спасибо. Но следует отметить, что в соотношении с нашей абонентской базой ШПД подготовленных пользователей не много.
Теперь относительно тех вопросов, которые вызвали наибольшее количество критических замечаний:

1. Ограничение пользовательской сети по маске. Надо ли это делать? В 8-летней практике работы были случаи, когда пароль от Wi-Fi становился известным нескольким людям и начинал достаточно быстро распространяться. В данной ситуации необходимо изначально позаботиться о минимизации рисков/убытков. Один из ярких примеров: дело было в студенческой общаге, где пароль стал достоянием большого количества студентов. Сеть, установленная на роутере с маской /24 позволяла подключаться большому количеству клиентов, которые продуктивно «сажали» скорость Wi-Fi. Ограничивая сеть на роутере вы минимизируете количество возможных несанкционированных подключений.

2. Связка MAC+IP в локальной сети роутера. Зачастую в локальной сети есть ресурсы, например, Remote Desktop, доступ к которым ограничен по IP адресу путем настроек на firewall операционной системы. Связка MAC+IP на DHCP запрещает получение данных IP тем клиентам, которых не допущены к указанному ресурсу. Да, никто не запрещает выставить IP адрес на оборудовании вручную, но, во-первых, это возможно не на каждом мобильном устройстве, во-вторых, это дополнительное действие, в-третьих, это вызовет конфликт с реальным устройством, что привлечет внимание пользователя.

3. Ограничение для подключения к сети по Wi-Fi по MAC. Данная опция предлагалась для того, чтобы минимизировать возможность подбора пароля, т.к. для выполнения этой операции требуется изначально установить MAC адрес доверенного клиента, а затем подбирать пароль, это повлияет на работу настоящего устройства, что привлечет внимание пользователя. Также следует отметить, что далеко не каждое мобильное устройство позволяет менять свой MAC-адрес.

4. Клиентская сеть в большинстве случаев имеет ограниченное количество клиентских устройств и практически все они предопределены заранее. Поддерживая домашнюю сеть в строгом учете и порядке пользователь минимизирует возможное возникновение проблем и несанкционированного подключения к своей сети сторонних пользователей.
Соглашусь, возможно, пример с 12 каналом не самый удачный и в данной статье ничего не написано про отключение WPS. Но суть написания и задача статьи — краткий ликбез по поиску причин «фризов» в работе Wi-Fi. Даже если пользователь «сидит» на стандартных каналах 1-6-11, нет никакой гарантии в том, что его сосед не сидит на том же самом канале, что и он. Также следует отметить, что некоторые устройства не смогут «сесть» за 11 канал, такая практика тоже есть.
Обсуждение получилось бурным, понятно, что многие из присутствующих здесь знакомы с материалом, и спасибо им за здоровую критику. Но также я надеюсь, что данный материал и его обсуждение помогут разобраться в данной проблеме тем, кто столкнулся с ней впервые.
В приоритетных планах пока запуск в Московском регионе.
LinSSID Graphical wireless scanning for Linux.
Я не пробовал, это то, что нашел поисковик.
Использование сети 10.0.0.0/8 объясняется тем, что количество пользователей в сети и оборудования, под которое требуется managment существенно больше, чем диапазон 100.64/10. Стандартов интернета мы не нарушаем, т.к. данные адреса во вне не выходят и пересечений в маршрутизации не допускается.
Это так, тогда возникает вопрос, если пользователю нужна связь с хостом или сетью, на которую указывает его адресация с локальной метрикой, как ему попасть на удаленную сеть при такой настройке маршрутов?
Можно также добавить шестую — у части пользователей не отключена опция подключения к роутеру по WAN интерфейсу и я рекомендовал бы ее выключить.
Это так, но в большинстве случаев серые сети используются оператором связи для клиентских подключений, а также для сети управления своего оборудования, это может быть как 10, так и 172 сеть. Посмотрите таблицу маршрутизации на Вашем роутере.
К сожалению, в текущих реалиях не перекрывать канал вообще проблематично. Например, в стандартной девятиэтажке в Москве на лестничной площадке будет примыкать порядка 4х3 (4 квартиры на площадке, 3 этажа) + 6 (квартиры из примыкающего соседнего подъезда)=18 квартир. Практически в каждой сейчас есть устройство Wi-Fi. В диапазоне 2,4ГГц всего 14 каналов, таким образом минимум по одному устройству на канал и то не хватит. С учетом ширины канала (занятости полосы), дать каждому устройству собственный канал без пересечения с соседом не получится. Поэтому приходится проверять занятость канала, мощность и занимаемую полосу.
Сеть 10.80.3.0 можно попытаться использовать, только не всегда получится, т.к. у вас по умолчанию будет маршрут на сеть 10.0.0.0/8 через адрес, полученный по DHCP домовой сети вашего района. 192.168.0.0/24 — это сеть, которая из приватного диапазона, и не используется на оборудовании оператора связи.
Ликбез — это ликбез. Здесь — потому что вопрос очень частый даже от тех, кто считает себя подготовленным. Статья не направлена на описание методологии защиты Wi-Fi от взлома, это тема другого хаба. Задача статьи — это попытаться разобраться в причинах возникающих «фризов» и понять, как самостоятельно решить данную проблему. В основу данной статьи лег практический материал, который помог нашим клиентам в 90% случаев. Надеюсь, что поможет кому-нибудь из читателей.
Сейчас проводятся предварительные испытания по результатам которых сроки станут более определенными.
1

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность