Контроллер новый, временно подключен по WiFi. Но работает как-то нестабильно.
После перезагрузки - все хорошо и быстро.
Потом в течении какого-то времени может начинать странно тормозить (вэб интерфейс теряет сервисы (сверху красным загорается), очень долго прогружается … ssh может давать очень большую задержку.
Проблема началась после следующих действий:
обновление контроллера
подключение его к облаку
Субъективно, проблемы возникают, когда “плохой Интернет”. то есть, от качества Интернет похоже зависит работа по локальной сети.
В момент лагов и проблем загрузка процессора не критичная (в топе логи или wb-rules), памяти и места достаточно … Тормозит именно сетевая карта, похоже … и она занята облаком? В общем, непонятно (и детально пока не разбирался)
И все это напрягает, но еще ладно …но уже дважды контроллер стал полностью недоступным по сети. То есть по WiFi клиенту он сам не подключается и все тут (при этом после прошлого раза поднял точку AP, не безопасно, но думал как временный доступ, но не помогло, клиент пропал вместе с AP точкой).
Помогает только перезагрузка контроллера.
Что это может быть?
приложен диагностический архив, доступен только сотрудникам поддержки
Добрый день.
Хочу обратить внимание что AP может быть только и исключительно wlan0.
Я рекомендую всегда явно указать для соединений используемые интерфейсы и не полагаться на перебор их из NetworkManager.
На данный момент все настройки выполнялись исключительно в WEB UI контроллера. И ничего не удалялось (то есть AP “с завода” на wlan0), штатно через интерфейс добавлен клиент … и все …
После перезагрузки работает стабильно несколько дней (например сейчас) и без лагов, а потом … начинается непонятно что.
Более того, я читал о том что интерфейс пропадает от других пользователей - то есть случаи не единичны (но так как мало кто сидит на чистом WiFi носят не массовый характер, наверное).
Контроллер опять потерял соединение, чтобы проверить как в штатном механизме через WEB UI можно указать или не указать интерфейс.
А также непонятно, как сделать “правильно” так, чтобы не сломать штатный механизм через WEB.
Ну почему же сразу “кирпич”? Есть два независимых Ethernet порта, есть, сетевой порт USB, в конце концов, есть порт консоли…
Видимо, когда пользователь настраивает сетевые интерфейсы, он понимает ,что и зачем он делает. У меня в личном хозяйстве шесть контроллеров WB (WB7 и WB8) и проблем с подключением и работой сетевых интерфейсов не возникало. В том числе есть контроллер который работает по WiFi “на постоянку” (хотя я солидарен с мнением, что самый надежный способ подключения к сети - провод).
Могу рекомендовать такой подход (особенно на этапе, когда в только изучаете контроллер):
Настраиваете оба Ethernet адаптера - один на получения настроек по DHCP, второй на фиксированный адрес (даже не обязательно вашей сети) , проверяете их работу и после этого настраиваете клиентское подключение к сети WiFi (как к домашней/рабочей, так и к сети, которую можете раздавать со смартфона) и как очередной резерв - настраиваете точку доступа на на WB со своими параметрами (имя/пароль).
Естественно необходимо после всех настроек указать приоритеты сетевых подключений.
В таком случае оставить контроллер “без связи” будет весьма не просто.
Стоит заметить, что для работы с контроллером все-таки нужны какие-то базовые знания по ПО и ОС.
PS Для контроллера также не плохо бы проникнуться идеологией “событийного управления/асинхронного программирования” - для тех кто ранее работал с линейным программированием некоторые аспекты асинхронности могут вызвать небольшой дискомфорт
Асинхронность/событийность - это не придумки WB, а типовой подход большинства ПЛК в системах автоматизации.
Доступ туда ограничен.
В базе планируется провод, конечно. Но это будет не быстро …
Из инструментов только телефон и планшет. Я другим уже лет 10 не пользуюсь )))
(Ну еще куча виртуальных машин на разных операционных системах)
Поэтому “кирпичик” )))
Какие оба?
Ближайшие полгода (год) будет только WiFi (и контроллер брался потому, что он там заявлен). Провод от контроллера даже прокинут (и место более доступно на данный момент). И даже обжат. Но воткнуть туда нечего … )))
То есть знаний системного программиста (включая написание драйверов сетевых карт) и администратора (как Linux, так и Windows …) недостаточно? ))))))))))
Дискомфорт пока только по поводу “штатной” работы WiFi.
А также отсутствия в документации много чего …
И нет некоторых очевидных вещей (но это просто сырость … тут просто нужно много времени, это нормальный процесс)
Можно, конечно, все настроить в консоли, но пока разбираюсь со штатным механизмом.
Документирован это механизм от слова “никак” )))
Что можно сломать в штатном механизме при правке руками конфигов - непонятно.
Еще и сверху приблуда для “восстановления Интернета”, алгоритм работы которой странен, действия непонятны (и походе именно она ломает и убивает соединение) … Но не хочется ее сразу ломать.
Штатная точка доступа (AP) падает вместе с клиентом WiFi
Основное предположение, после обнаружения отсутствия связи утилита, которая должна восстанавливать, безвозвратно гасит wlan0 … навсегда (правда три раза перезагрузки помогали, после чего все работало …)
