Перейти к содержанию

sergeyk

Участники форума
  • Постов

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

  • Посещение

  • Победитель дней

    10

Сообщения, опубликованные sergeyk

  1. 8 минут назад, volvic сказал:

    Перезапускаюсь, все начинает работать нормально. Коннект есть. В журнале на попытку войти в web-интерфейс до перезагрузки такие записи:

    Mws::RciClient: "52:ff:20:14:57:39": device is unreachable.

    В Web-интерфейс какого устройства?

    Такая ошибка появляется, когда ретранслятор (не роутер) с указанным адресом становится временно недоступен.

  2. В 28.01.2023 в 08:11, mobile vipka1n сказал:

    Hotspot::Discovery::Explorer: "Bridge0": network conflict: hosts 54:7f::5a::73 and 1c:af::0e::79 have the same IPv4 address 192.168.1.200.

    За час насыпает в логах 200 записей.

     

      Вот как бороться   с этим? DHCP  начинается  192.168.1.250

    Сообщение "... network conflict... have the same IPv4 address..." не имеет никакого отношения к DHCP.
    Компонент Discovery Explorer обнаруживает устройства с одинаковым IP-адресом, опрашивая устройства через рассылку ARP-запросов.

    Очевидно, что конфликтующие устройства имеют одинаковый вручную настроенный IP-адрес, раз вы утверждаете, что 192.168.1.200 в пул не входит. Единственный способ устранить конфликт прописать одному из них другой адрес вручную или включить у него DHCP.

    Если вас беспокоят именно сообщения, вы можете отключить диагностику

    no ip hotspot auto-scan interface Home
    copy running-config startup-config

    Но конфликт в сети, само-собой, от этого не исчезнет.

    • Спасибо 1
  3. 5 часов назад, inoyat сказал:

    Все относительно....

    Из замеченных в таком поведении клиентов - все новые iphone, а в логе выше - ТД Элтекс.

    При этом - при замене кинетика на тупой TP-Link Archer C6 - все клиенты штатно получают адреса

    В таком случае делайте захват обмена DHCP-пакетами, когда обмен кажется неправильным.

  4. 1 час назад, inoyat сказал:

    Однако у части клиентов - проблемы, выдается адрес из пула 0.0.0.Х

    Из вашего журнала видно, что он не выдаётся, а запрашивается клиентом.

    DHCPDISCOVER received from cc:9d:a2:de:38:c0.
    making OFFER of 192.168.0.60 to cc:9d:a2:de:38:c0.
    DHCPREQUEST received (STATE_SELECTING) for 0.0.0.242 from cc:9d:a2:de:38:c0.

    Строки выше означают, что

    1. Сервер принял от cc:9d:a2:de:38:c0 широковещательный запрос на новый адрес.
    2. Сервер предложил клиенту cc:9d:a2:de:38:c0 адрес 192.168.0.60.
    3. Клиент cc:9d:a2:de:38:c0 прислал запрос на продление адреса 0.0.0.242.

    • Спасибо 1
  5. 3 часа назад, MaXaoH сказал:

    Хорошо, даже если такое реализовать невозможно (по крайней мере на данный момент), может есть возможность просто посылать трафик/файл на определенный сервер и вывести график, как на главной?

    Проблема измерения "скорости соединения" заключается в том, что не понятно, что именно измерять.

    Speedtest выделяется тем, что имеет возможность автоматически выбирать ближайший к тестирующему клиенту сервер. Из-за большой собственной инфраструктуры Speedtest может это сделать и поэтому, как правило, его замеры показывают скорость, близкую к скорости, которую обещает провайдер в договоре, имея в виду скорость в своей локальной сети. Наверняка вы замечали, что от смены сервера значения могут заметно отличаться. Совсем не факт, что именно эта скорость вам нужна, зачастую пользователей интересуют замеры до какого-либо определенного IP-адреса, а они могут отличаться от замеров Speedtest радикально.

    • Спасибо 1
  6. @luneman Это сообщение не является ошибкой. Оно появляется, когда устройство обнаруживает, что предыдущая PPP-сессия не была завершена (по любой причине) отправкой терминирующего пакета PADT. Некоторые провайдеры не позволяют устанавливать новую сессию заново с тем же MAC-адресом, если не была явно разорвана старая.

    Похоже, в вашем случае можно разобраться, только если сделать захват пакетов на интерфейсе WAN (GigabitEthernet0/Vlan2).

    • Спасибо 1
    • Лайк 1
  7. 26 минут назад, Евгений29 сказал:

    А в настройках роутера я ничего подобного не вводил)

    В настройках роутера и не надо ничего вводить, достаточно после первого подключения через браузер авторизоваться с любого клиента, чтобы активировать новое подключение с MAC роутера.

    • Лайк 2
  8. @Евгений29 я видел похожую проблему у московского Beeline: ответ на DHCP-запрос не приходит в течение 10 минут, поскольку их оборудование считает, что адрес уже выдан. Если поменять MAC-адрес или подключить, например, ноутбук напрямую к провайдеру (с другим MAC), то IP-адрес тут же выдаётся.

    https://homenet.beeline.ru/index.php?/topic/327637-не-выдаётся-ip-адрес/
    Такая проблема решается только со стороны провайдера.

    • Лайк 2
  9. 2 часа назад, Dimkor сказал:

    Ping-check почему-то не срабатывает (пробовал и автоматический и ручной режим).

    В таком случае я бы посмотрел на self-test, в котором зафиксированы неудачные попытки восстановить работу модема.

  10. 43 минуты назад, Dimkor сказал:

    Для себя я всё настроил, проблем не составило.

    Расскажите, для чего вы его периодически перезагружаете.

    В каком сценарии использования у устройства возникают проблемы, которые решаются только периодической перезагрузкой?

  11. 2 минуты назад, CBLoner сказал:

    ...но как рибутать каждый день разтв час, пока не понял!

    Самый простой вариант

    system reboot 3600
    system configuration save

     

    3 часа назад, CBLoner сказал:

    Может кто подскажет, как правильно собрать расписание, чтобы железяка перегружалась каждый день, скажем раз в час.

    Перезагрузка раз в час без привязки ко дню недели и есть "каждый день".

    • Спасибо 1
×
×
  • Создать...

Важная информация

На этом сайте используются файлы cookie. Нажимая "Я принимаю" или продолжая просмотр сайта, вы разрешаете их использование: Политика конфиденциальности.