Перейти к содержимому
Калькуляторы

KoChegar

Пользователи
  • Публикации

    10
  • Зарегистрирован

  • Посещение

О KoChegar

  • Звание
    Абитуриент
    Абитуриент
  1. Обновил прошивку до последней 2.4.6, проблема изоляции клиентов ушла. Так же исчез баг с периодическим "отваливанием" точек. Всем спасибо за помощь))
  2. Какое-то странное заявление. Я говорю о том что написано в datasheets UniFi(Guest Portal/Hotspot Support). Или у вас какое-то свое определение термина "точка доступа", если так то поясните плиз. Не уверен, возможно через экспорт/импорт конфига. Ну или ручками через скрипт... Конфиг импортируется в виде 2.4.5.unf, подскажите чем его можно править. Не подскажите как они прошиваются? И не влияет ли это на гарантию?
  3. Галка с "Guest Policy (Apply guest policies)" снята. Других похожих настроек не нашел. UniFi как раз таки заявлен как точка доступа с доступной функцией хот-спота.
  4. Тоже думал в эту сторону, но не нашел такой опции на UniFi Controller v 2.4.5.
  5. Добрый день! Есть одноранговая сеть Windows, 3 точки UniFi PRO, коммутатор, 25 пользователей. Есть маршрутизатор NetGear N300 (dhcp, основной шлюз). Установлено ПО контроллера сети. Все работает хорошо быстро за исключением доступа к ресурсам, предоставленным в совместное использование. Если обе станции (сервер, расшаривший ресурс, и клиент, пытающийся подключиться) подключаются к сети через точки (wi-fi), то ничего не получается. Даже не пингуют друг друга и телнетом никакие порты не открываются. Если любая станция, клиент или сервер, подключена к сети проводом - все изумительно. Хотелось бы от этого избавиться. Может кто сталкивался? И еще, все станции в одной рабочей группе. Уточняю.Все справедливо, если станции подключены к одной точке. Если к разным то все работает. Проверка на команде ping - t: развожу на разные точки - работает, подключаю к одной - работает, чищу кэш ARP - не работает, развожу на разные точки - работает.
  6. Проблема решилась при приведении настроек MTU к единому значению. А именно к MTU=1492, такое значение стоит при создании PPPoE подключения. Сейчас мост работает в режиме: PPPoE поднимается на AP и трафик пробрасывается на Station, далее свитч с заведенными в него розетками. В скором времени переделаем на систему с авторизацией на Station, но есть подозрения что проблема вернется.
  7. Сегодня попробуем поиграться с настройками MTU на всех портах. Заменим Scotch – Lockи на розетку, на прямую кабель нет возможности кинуть. Ситуация конечно не понятная. Просто это уже 4 мост, который я реализую, причем остальные были куда более нагружены, работали в сетях уровня крупного предприятия, и подобных проблем не возникало. Грешу ещё на прошивку v 5.5, все остальные были на старых прошивках.
  8. Есть один нюанс, от антенны до POE инжектора идет кабель, срощенный в одном месте с помощью Scotch – Lock. Может это как то повлиять на ситуацию? Просто уже не знаю, в какую сторону копать.
  9. Как я понимаю -- у Вас встроены тест показывает нормальную скорость, сквозной тест без свитча -- тоже. Соотвественно, либо флуд, либо конфликт мак-ов/ип-адресов. Ещё всякие касперские/др.вебы фокусы выделывают, так что тестить надо на linux-ах, и ИМХО, например, на яндксе, в т.ч. и их фтп-шках. То есть вы утверждаете, что источником конфликта мак/ип адресов и флуда, является неуправляемый коммутатор? Так как без него, при подключении напрямую в LAN порт инжектора, всё работает норм. Тем более что проверялось на нескольких устройствах (маршрутизаторы DIR300 и TP-Link TL-MR3420, подключенных как свитчи). И не вижу никакого смысла тестировать на яндексе и их FTP, поскольку это не даёт четкой картины работы моста. Это покажет только совокупную пропускную способность до конечной точки, которая по большей части зависит от провайдера. Поэтому скорость и меряется до ближайшей точки в сети провайдера, то есть в его локалке.