Wi-CAT LLC

Wireless Comprehensive Advanced Technology. Build your network now.

Wi-CAT LLC
Навигация Форума
Вы должны войти, чтобы создавать сообщения и темы.

(решено, не глюк) Глюк с dhcp клиентом в режиме моста

Перевожу роутер с дефеолтных настроек сразу в режим моста, после перезагрузки он доступен по 192.168.1.1 несколько секунд, а потом пропадает

по dhcp адрес получить не может

Если выключить опцию Try to get IP via DHCP, то на статике работает нормально

Устройство, версия софта и т.д. где? Проверил на DUO-G - не вижу проблемы, т.е. вообще.

Т.е. сброс, обновление, только после этого настройка в режиме АП с dhcp. Полное описание в т.ч. кто в роли dhcp и т.д. и т.п.

Ну и т.к. проблема у нас не воспроизводится то  tcpdump со стороны dhcp сервера что бы посмотреть есть ли вообще запросы к нему, логи с него если запросы есть ну и т.д. и т.п.

DUO-F проверил - тоже вопросов нет.

Железка Duo-G, прошивка 2.9.14 по-моему. Я так и делал, подключал по wan к вышестоящему такому же duo-g. Сброс настроек, заход на 192.168.1.1. Сразу же меняю на режим моста, перегружаемся и такая проблема. Интернет работает вообще без вопросов, просто мост теряет свой ip, не получает другого, и к нему невозможно достучаться.   Если же все настройки делать без подключения каких либо проводов, все работает нормально. Пробовал перед переводом в режим моста менять ip, те же яйца - вид сбоку. Выключаю опцию Try to get IP via DHCP, и после этого я могу подключить в любой порт аплинк на основной duo-g, который висит на 192.168.1.254 и становится виден мост со своим ip. Чуть позже выложу логи.

Грю у меня АП работают в таком режиме (в смысле домашняя сеть так построена + достал для проверки DUO-F и тоже проблем не увидел, и даже на AX прототипе не вижу). Прекрасно получают Ip от DHCP. Никто ничего не теряет.

Какие выводы? Ну кроме того что dhcp сервер в вашей сети не отвечает на запросы адресов от этих устройств? Почему? Ну, простите, вопрос к его вендору устройства которое отвечает за реализацию dhcp сервера вашей сети.

Я понимаю, что поздно было отвечать, но хоть вчитайтесь в текст, который я пишу. В частности, я сказал, что я подключаю uplink на такой же duo-g. Другими словами: вендор ваш!

В целом я купил 3 таких устройства, чтобы организовать роуминг на загородном доме. 1 как роутер и 2 моста.

У меня та же схема, проблем не вижу.

Рядом есть рекомендации как писать репорты и что указывать.

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

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

Напоминаю логику как это работает.

Во время загрузки первым делом пробуем получить адрес по DHCP. Если удалось то всё заработало и всё ОК адрес присвоен с DHCP.

Пример лога при таком кейзе:

# cat /var/log/messages | grep dhcp
Oct 27 10:55:16 udhcpc[1616]: started, v1.32.0
Oct 27 10:55:21 dhcpd: DHCP server disabled. OPMODE=0 APCLIBR=0
Oct 27 10:55:25 udhcpc: AP Use temp 169.254.132.194 for prepare.
Oct 27 10:55:25 udhcpc[1616]: sending discover
Oct 27 10:55:25 udhcpc[1616]: sending select for 192.168.254.39
Oct 27 10:55:27 udhcpc[1616]: lease of 192.168.254.39 obtained, lease time 86400
Oct 27 10:55:27 udhcpc: AP Start full renew procedure.
Oct 27 10:55:27 udhcpc: AP Renew ip adress 192.168.254.39 and netmask 255.255.255.0 for br0 from dhcp
Oct 27 10:55:27 udhcpc: AP Deleting default route dev br0
Oct 27 10:55:27 udhcpc: AP Apply route list. And replace DGW.
Oct 27 10:55:27 udhcpc: AP ip -4 route replace  192.168.254.1/32 via 0.0.0.0 dev br0 metric 1000
Oct 27 10:55:27 udhcpc: AP ip -4 route replace  default via 192.168.254.1 dev br0 metric 50
Oct 27 10:55:27 udhcpc: AP Set fist default gateway to 192.168.254.1 dev br0 via 192.168.254.1 metric 0
Oct 27 10:55:27 udhcpc: AP Add route to multicast subnet.
Oct 27 10:55:27 udhcpc: AP Flush route cache
Oct 27 10:55:27 udhcpc: AP Renew DNS from dhcp 192.168.254.1 SADNET
Oct 27 10:55:27 udhcpc: AP Restart needed services
Oct 27 10:55:27 udhcpc: AP End renew procedure.
Oct 27 10:55:27 services: restart needed services and scripts (dhcp).

 

Если при загрузке адрес получить по dhcp не удалось то, пытаемся использовать заданные в ручную настройки со страницы LAN. Т.е. заданные там адреса используем как fallback параметры если оные не получены от DHCP (лучше из корректно задать в любом случае, ессно на каждой AP разные, лучше те же что выдал DHCP).

Причём перед тем как назначить fallback адрес на br0 проверяем не занят ли этот адрес другим устройством используя arping.

Если свободен - всё ок, назначили и завершили процедуру.

Если занят то используем сгенерированный из zeroconf (local scope) диапазона (169.254/16) адрес что бы избежать конфликта IP и не мешать работать другим устройствам.

Лог такого варианта:

Oct 27 10:55:25 udhcpc: AP Use temp 169.254.22.8 for prepare.
Oct 27 10:55:25 udhcpc[1616]: sending discover
Oct 27 10:55:30 udhcpc[1616]: sending discover
Oct 27 10:55:35 udhcpc[1616]: sending discover
Oct 27 10:55:40 udhcpc[1616]: sending discover
Oct 27 10:55:45 udhcpc[1616]: sending discover
Oct 27 10:55:50 udhcpc: AP Lease fail br0.
Oct 27 10:55:52 udhcpc: AP DHCP adress get fail use default 192.168.254.131
Oct 27 10:55:52 udhcpc: AP Add default route via 192.168.254.1.
Oct 27 10:55:52 udhcpc: AP Use manual dns servers 192.168.254.1 
Oct 27 10:55:52 udhcpc: AP Add route to multicast subnet.
Oct 27 10:55:52 udhcpc: AP Restart needed services
Oct 27 10:55:52 udhcpc: AP End fallback procedure.
Oct 27 10:55:52 services: restart needed services and scripts (dhcp).

 

Надо понимать что с момента запуска до запуска fallback процедуры пройдёт дополнительно секунд 30 пока AP будет пытаться получить адрес от DHCP прежде чем назначить статические адреса.

 

Пример настроек.

В общем заливаю 2.9.17 с немного переделанной процедурой. Если и на ней будет проблема - нужно смотреть что крутили + логи. Иначе понять что происходит шансов 0.

я подозреваю, что жалоба на то, что при переключении из роутера в мост адрес начинает получатся по dhcp.

для пользователя выглядит именно так: коробочка была доступна, переключаешь в мост, после ребута не отвечает по старому ip.

Ну это тем более не глюк. Каноны интерпрайза они такие. Фолбэк на статику выполняется только если нет DHCP. А если при фоллбэке окажется что заданный в LAN адрес занят то АП вообще уедет в Zeroconf.

Такая логика позволяет полностью исключить проблемы при развёртывании сети на объектах.

Ну т.е. ткнули роутер, ткнули в него АПшки. Зашли на роутере в netdiag увидели все адреса всех АПшек. Очень долго до меня докапывались что бы реализовать такое поведение по умолчанию.

Галка в LAN что бы отключить имеется.

Угодить всем не выйдет. Для автоматизации развёртывания такая логика увы безальтернативна.

Цитата: sfstudio от 18/11/2020, 19:17

Галка в LAN что бы отключить имеется.

не в режиме роутера )

Ну дык предконфигурим по одному. В режиме роутера там глалка это вообще был бы верх маразма.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: