Wi-CAT LLC

Wireless Comprehensive Advanced Technology. Build your network now.

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

(решено) FT-AIR-DUO-G не получает адрес от DHCP провайдера

После обновления ПО с версии 3.4.6 до 4.1.10 перестал получать по DHCP от провайдера, но при прописывании его вручную - всё работает. Сброс до заводских настроек никак не меняет ситуацию.

Dec 26 15:37:27 udhcpc[10580]: broadcasting discover
Dec 26 15:37:32 udhcpc[10580]: broadcasting discover
Dec 26 15:37:37 udhcpc[10580]: broadcasting discover
Dec 26 15:37:42 udhcpc[10580]: broadcasting discover
Dec 26 15:37:48 udhcpc[10580]: broadcasting discover
Dec 26 15:37:52 udhcpc: Lease fail eth3.

 

А конфиг со статикой зачем шлёте? Зачем выкусили из лога кусок? Весь прикладывать нужно.

По v4  решительно ничего на тему dhcp на WAN не менялось. Может у провайдера что глюкануло, а вы просто поймали совпадение.

В общем убедиться что в статусе коммутатора WAN поднят как минимум на сотке дуплекса, заодно увидите туда ли воткнут. Сбросить настройки и просто вообще ничего не трогая глянуть в лог. Если адрес не будет получен позвонить прову и попросить ребутнуть домовой коммутатор, если подключены через ONU ребутнуть его. Иногда на коммутаторах доступа DHCP снупинг глючит и ответы тупо перестают долетать до клиента. Чаще всего происходит при link down/up. Других предположений нет.

Может вообще у провайдера работы какие на серверах идут, а т.к. lease time обычно сутки, то отключения dhcp серверов никто не заметит как минимум 12 часов или до перезагрузки.

Если бы DHCPC v4 развалился бы, я бы узнал бы от этом первый т.к. на доступе инфраструктуры системы обновлений wi-cat живёт именно DUO-G, включен он в сеть ТТК которая в Омске IPOE+DHCP. И железо обновляется раньше чем прошивка отправляется в плаванье.

После - не значит в следствии. И чаще всего это так.

Попросил приятеля на МТС (там тоже IPOE+DHCP) обновиться - проблем не наблюдается. Так что 99,99999% что-то из озвученного выше.

Рассказывайте по результатам, что бы тема не висела.

Прикладываю полный лог.

Статика в пределах NAT, потому я за неё не переживаю.

Провайдер не МТС (в конфиге имя wifi для совместимости оставлено таким), а небольшой местный. Касаемо оборудования - перезагружал ONU, OLT (есть возможность такая).

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

Мне так и не удалось воспроизвести проблему.

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

 

С 3.4 ветки прошло уже очень много времени, однако других репортов на эту тему нет. А значит надо разбираться с конкретной связкой с привлечением спецов ISP. Это самый верный подход.

Цитата: Andrey_s от 03/01/2022, 05:17

перезагружал ONU, OLT (есть возможность такая).

Кто провайдер? Марка и модель терминала?

На СФО и УФО нет проблем с получением ДХЦП от провайдера.

Речь про: МТС, РТ, дом.ру и еще ряд местных провайдеров, и 100+ устройств FT-AIR-DUO-G.

Г. Ижевск, провайдер "Телепорт" OLT C-Data FD1608, ONU GR-XP-ONU1-1A (CDATA fd511 xpon)

ONU  в каком режиме? В бридже и провайдер по DHCP выдаёт адреса или это роутер со своим DHCP сервером?

Onu в режиме бриджа. Без роутера ПК получает адрес, также получает адрес и другой роутер (zte 298)

Провайдер что говорит? Я уже все доступные мне варианты перепробовал, на всех мне доступных линках, со всеми доступными серверами. Что не нравиться DHCP серверу вашего провайдера лучше всех ответит именно он (провайдер) заглянув в влоги DHCP сервера со своей стороны.

Пока ни одной жалобы кроме вас я не вижу, и попытки повторить у меня провалились полностью, все...

Сделал с помощью Wireshark дамп с WAN порта двух роутеров (предварительно сброшенных до заводских настроек)

DUO_G, который не получает адрес и ZTE H298N, который без проблем подключается. Их же отправил инженерам провайдера

Я надеюсь они хотя бы в логи DHCP сервера перед анализом дампов заглянут. Чаще всего это сразу отвечает на вопрос чего не нравиться. Ну и вообще сдампить на их стороне ибо DHCP снупинг на свитчах может запросто избирательно дропать запросы.

Встречалось пару раз года 4ре назад, обновление софта на коммутаторах решило проблему.

Т.е. мало знать в чём разница, хочется знать на каком этапе затык т.к. во-первых, больше никто так и не сообщил о проблеме, значит она провайдер специфична. Во вторых по мере обновления busybox в устройствах других вендоров начнутся проблемы и с ними.

udhcpc обычно используется без изменений.

Да. Добавьте на время разбирательства в /etc/init.d/wan в строку UDHCPCOPTS= после $dhcpHostName ключик -v что бы заставить udhcp быть более разговорчивым. Может тут ещё что в отладке увидим.

В списках рассылки busybox я так же не вижу репортов по dhcp клиенту кроме как http://lists.busybox.net/pipermail/busybox-cvs/2021-December/040956.html но если бы в этом была бы проблема то была бы с 2014г. https://git.busybox.net/busybox/commit/?id=e2318bbad786d6f9ebff704490246bfe52e588c0

 

Есть ещё связанный с ним фикс https://git.busybox.net/busybox/commit/networking/udhcp/dhcpc.c?id=9e27fed6b9a21454149873cfc4e034c8226f8ffb который был в июне 21г. Т.е. относительно недавно. Но глазками не вижу с ним проблем. Да и времени прошло уже с июня достаточно что бы ещё хоть у кого-то проявилось.

Собсно могу откатить его и собрать вам на тест версию для проверки. Но лучше сначала подождём что скажет оператор. Не очень хочется городить воркэраунды если проблема таки на их стороне (на что ну прям всё указывает).

с ключом "-v" вот такой лог. провайдер на следующей неделе посмотрят логи

Проверки разумности не проходят:

/* make sure its the right packet for us, and that it passes sanity checks */
if (packet.ip.protocol != IPPROTO_UDP
 || packet.ip.version != IPVERSION
 || packet.ip.ihl != (sizeof(packet.ip) >> 2)
 || packet.udp.dest != htons(CLIENT_PORT)
/* || bytes > (int) sizeof(packet) - can't happen */
 || ntohs(packet.udp.len) != (uint16_t)(bytes - sizeof(packet.ip))
) {
        log1s("unrelated/bogus packet, ignoring");
        return -2;
}

Гляну завтра менялось ли в апстриме на эту тему что-то.  Но врятли ИМХО. Интересно только какое из условий отрабатывает.

В логах провайдера абсолютная пустота

А запрос-то вообще от роутера до них долетает или каким "умным" коммутатором по пути дропается? Тогда надо в логи коммутатора смотреть что ему не нравиться. Им так и сяк это чинить придётся.

Может вообще ONU дропает или голова запросы. ONU же в мосту? (ну так на всякий, подзабыл уже).

Onu в режиме моста. Но проблема именно этого роутера и только с прошивкой версий после 3.4.6 

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

Ни одного больше репорта, ни от одного клиента нам больше не поступало, хотя на прямой связи со многими операторами с IPOE + DHCP на доступе. Не умею лечить то, что не ломалось. Поэтому у меня нет иных предложений кроме как по шагам выяснять что происходит. На своей стороне всё что можно я проверил. Дело за оператором. Точек отказа может быть много, начиная с ONU. Что именно вдруг перестало нравиться в запросах (ну раз в логах провайдера тишина то я как понимаю запросы не долетают до них вообще) оборудованию вашего провайдера мне неведомо.

Валидность запросов уже проверил ручками. Криминала не увидел.

Увы, больше мне вам помочь не чем.

P.S. В апстриме бизибокса тоже репортов нет, а там вообще репорты со всего мира льются, и от юзверей и от провайдеров и от разрабов.... Я не знаю как тут можно говорить что проблема в udhcpc при этом, а не на стороне провайдера... ;)

Был бы у меня доступ к инфраструктуре вашего ISP давно бы уже как минимум было бы понятно, где причина, а скорее бы и что не нравиться и добавлен workaround. Увы, у меня нет такого доступа и врятли появится.

На OLT по вашему порту случаем вообще фильрации какой нет? Статистику фильтров на OLT пусть глянут хоть. Судя по https://cdatatec.com/wp-content/uploads/2016/09/C-Data-Cortina-EPON-OLTFD1108SFD1104SFD1104SNFD1104BFD1104Y-CLI-User-Manual-V1.6-20151126.pdf (п6.5 и ниже) или шторм контролов каких… Вот почти уверен что эти умности что-то избыточно фильтруют.

 

Появился дамп dhcp провайдера

Спойлер
Извините, только авторизованные пользователи могут видеть спойлеры.

К сожалению это не дамп. Это фигня какая-то. Дамп эт файлик в формате обычно pcap (что бы можно было нормальными инструментами разобрать, где запечатлён обмен сторон "любезностями" дабы можно было понять какой стороне и что потенциально не нравиться и сравнить со случаем когда всё проходит (второй дамп).

В случае с wive вы такой дамп можете снять самостоятельно используя встроенный tcpdump. Но нужен и второй когда всё ок. Хотя может и одного хватит, но врятли.

Проблема решена сменой "имени хоста" в роутере

Бред какой. Проще гря проблема на стороне оператора (раз не может прожевать хостнэйм произвольный в dhcp запросах) и могли бы сразу глянуть логи на своей стороне. Чего и следовало ожидать.

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


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

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