Берем голый, свежий и обновленный wb7.
Подключаем его через ethernet к роутеру
Подключаем его через wifi к тому же роутеру
Смотрим, что сетевые метрики на месте, все хорошо и так далее и тому подобное. Я так тыщу раз делал (тм)
…
Обнаруживаем, что каждую минуту wb7 становится недоступным секунд на 10-15. Все равно идти на wifi адрес или на ethernet. Можно просто пинговать снаружи.
Медленно охреневаем.
Включаем journalctl -f. Обнаруживаем, что зачем-то каждую минуту что-то дергает NM. Если подключение одно (не важно - вифи или ethernet), то NM говорит “вот соединение есть, на остальных нет керриера, отвали”. Но если есть два соединения, то это “что-то” дропает оба, а потом поднимает их.
В итоге, пока все договорятся, как раз и проходят те самые 10-15 секунд недоступности.
возможно роутер отправляет ответ не в тот интерфейс? Я бы рекомендовал поставить обоим соедиениям:wifi и ethernet одинаковый приоритет в настройке и проверить вручную как работают запросы с контроллера.
Ещё, пожалуйста, включите галочку для сбора отладки в настройках переключения:
Нет, контроллер, а вернее линукс внизу не виноват. Он все отправляет туда, куда надо. Ведь оставшиеся 40 секунд все работает нормально с обоих интерфейсов. Да и эти 15 секунд… ну не успевает быстро dhcp отработать и роутинги с днс переделать - уж больно дохлый цпу
Я пока вернулся на один интерфейс, но вот очень охота попробовать найти и отрубить то, что каждую минуту дергает NM - подозреваю, проблема решится сама.
Так же в планах подсоеденить второй интерфейс, но уже с другой подсетью. Если оно заработает, то 100% ошибка где-то в пинговалке-автоподнималке
Скорее всего это переключатель соединений, настройки которого на скриншоте. У вас настроен разный приоритет у Ethernet и Wi-Fi, вот он и переключает их туда-сюда. Поэтому галочку лучше нажать и посмотреть подробнее.
не очень понял, как это связано. Ни dns, ни dhcp тут совершенно не при чём.
я не знаю, что вам видно в диагностических логах. но в обычных четко видно, что дропаются оба соединения и начинается вызов dhcp, установка ntp и прочее, прочее, прочее. И пока они (как минимум dhcp с роутингом) не отработают, как раз это время и нет соединения.
а с обоими соединениями с одним приоритетом завтра обязательно попробую
Очень странно. Решил продолжить эксперименты. Обновил все, воткнул назад кабель, включил галочку отладки и… и ничего.
Выключил откладку … и снова ничего. Подергал в разных вариациях интерфейсы - снова ничего. Даже “тех самых” сообщений нет
В общем, я пока не могу повторить то самое поведение вечером попробую перезагрузить контроллер.
Что еще обнаружилось.
я не закрывал терминал и осталось
когда все работало
default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.118 metric 55
default via 192.168.1.1 dev wlan0 proto dhcp src 192.168.1.37 metric 600
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.118 metric 55
192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.37 metric 600
когда начало колбасить
default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.118 metric 55
default via 192.168.1.1 dev wlan0 proto dhcp src 192.168.1.37 metric 205
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.118 metric 55
192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.37 metric 205
по идее, разницы не должно быть, все равно один маршрут имеет бОльшую метрику, но откуда цифры …
приложен диагностический архив, доступен только сотрудникам поддержки
(172.5 KB)
А вот это ужк с равными приоритетами. Но все равно поведение точно такое же - каждую минуту все интерфейсы переинициализируются
default via 192.168.1.1 dev wlan0 proto dhcp src 192.168.1.37 metric 55
default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.118 metric 105
192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.37 metric 55
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.118 metric 105
Да, это оно. Поставил dhcp lease в 120 секунд, включил-выключил wifi, подождал, передернул eth0. И началось
Судя по всему, wb-connect-manager дерется с NM.
policy: set 'multik' (wlan0) as default for IPv4 routing and DNS
NM включает по умолчанию маршрут через wlan, там чек обламывается (потому что eth0 живой и имеет более низкий приоритет) и все начинает перезагружаться
Для проверки поставил URL проверочный localhost, а строчку <!doctype html> и смотрите, какое великолепие! При этом eth0 отлично работает
Feb 05 15:52:02 wirenboard-AG4LVLTQ wb-connection-manager[19521]: checking connection multik
Feb 05 15:52:02 wirenboard-AG4LVLTQ wb-connection-manager[19521]: interfaces for multik: wlan0
Feb 05 15:52:02 wirenboard-AG4LVLTQ wb-connection-manager[19521]: localhost resolves to ['127.0.0.1']
Feb 05 15:52:17 wirenboard-AG4LVLTQ wb-connection-manager[19521]: Error during wlan0 connectivity check: (28, 'Connection timed out after 15000 milliseconds')
Открыл исходники wb-connect-manager. Стало понятно, что адрес 127.0.0.1 не подходит, там биндится на интерфейс. Ок, взял 192.168.1.1. В ответ wb-connection-manager начал все проверять каждые 5 секунд
Feb 05 16:17:24 wirenboard-AG4LVLTQ wb-connection-manager[28472]: Connectivity via eth0 is True
Feb 05 16:18:06 wirenboard-AG4LVLTQ wb-connection-manager[28472]: Connectivity via eth0 is True
Feb 05 16:18:11 wirenboard-AG4LVLTQ wb-connection-manager[28472]: Connectivity via eth0 is True
Feb 05 16:18:16 wirenboard-AG4LVLTQ wb-connection-manager[28472]: Connectivity via eth0 is True
Feb 05 16:18:22 wirenboard-AG4LVLTQ wb-connection-manager[28472]: Connectivity via eth0 is True
Feb 05 16:18:27 wirenboard-AG4LVLTQ wb-connection-manager[28472]: Connectivity via eth0 is True
Feb 05 16:18:32 wirenboard-AG4LVLTQ wb-connection-manager[28472]: Connectivity via eth0 is True
Feb 05 16:18:37 wirenboard-AG4LVLTQ wb-connection-manager[28472]: Connectivity via eth0 is True
Feb 05 16:18:42 wirenboard-AG4LVLTQ wb-connection-manager[28472]: Connectivity via eth0 is True
Feb 05 16:18:47 wirenboard-AG4LVLTQ wb-connection-manager[28472]: Connectivity via eth0 is True
Вырубил wb-connection-manager. И внезапно ничего не изменилось. NM точно так же тупо на каждой dhcp lease начинает расколбас
Feb 05 16:22:16 wirenboard-AG4LVLTQ NetworkManager[414]: <info> [1707139336.7072] dhcp4 (eth0): activation: beginning transaction (timeout in 45 seconds)
Feb 05 16:22:16 wirenboard-AG4LVLTQ NetworkManager[414]: <info> [1707139336.7074] dhcp4 (eth0): state changed no lease
Feb 05 16:22:16 wirenboard-AG4LVLTQ NetworkManager[414]: <info> [1707139336.7311] dhcp4 (eth0): state changed no lease
Feb 05 16:22:16 wirenboard-AG4LVLTQ NetworkManager[414]: <info> [1707139336.9607] dhcp4 (wlan0): activation: beginning transaction (timeout in 45 seconds)
Feb 05 16:22:16 wirenboard-AG4LVLTQ NetworkManager[414]: <info> [1707139336.9609] dhcp4 (wlan0): state changed no lease
Feb 05 16:22:17 wirenboard-AG4LVLTQ NetworkManager[414]: <info> [1707139337.0008] dhcp4 (wlan0): state changed no lease
Feb 05 16:22:18 wirenboard-AG4LVLTQ NetworkManager[414]: <info> [1707139338.7593] dhcp4 (eth0): state changed no lease
Feb 05 16:22:19 wirenboard-AG4LVLTQ NetworkManager[414]: <info> [1707139339.0561] dhcp4 (wlan0): state changed no lease
В общем, это какая-то бага в NM. В 1.42 (который в WB) она есть, а в 1.44 (который у меня на другом хосте с такой же конфигурацией) - ее нет. Так что оно само полечится, когда в апстриме дебиана поднимут версию
А пока рецепт один: “не делайте так”
вечером попробую перезагрузить контроллер.