(решено) FT-AIR-DUO-G не получает адрес от DHCP провайдера
Цитата: Andrey_s от 26/12/2021, 17:00После обновления ПО с версии 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.
После обновления ПО с версии 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.
Цитата: sfstudio от 26/12/2021, 17:45А конфиг со статикой зачем шлёте? Зачем выкусили из лога кусок? Весь прикладывать нужно.
По v4 решительно ничего на тему dhcp на WAN не менялось. Может у провайдера что глюкануло, а вы просто поймали совпадение.
В общем убедиться что в статусе коммутатора WAN поднят как минимум на сотке дуплекса, заодно увидите туда ли воткнут. Сбросить настройки и просто вообще ничего не трогая глянуть в лог. Если адрес не будет получен позвонить прову и попросить ребутнуть домовой коммутатор, если подключены через ONU ребутнуть его. Иногда на коммутаторах доступа DHCP снупинг глючит и ответы тупо перестают долетать до клиента. Чаще всего происходит при link down/up. Других предположений нет.
Может вообще у провайдера работы какие на серверах идут, а т.к. lease time обычно сутки, то отключения dhcp серверов никто не заметит как минимум 12 часов или до перезагрузки.
Если бы DHCPC v4 развалился бы, я бы узнал бы от этом первый т.к. на доступе инфраструктуры системы обновлений wi-cat живёт именно DUO-G, включен он в сеть ТТК которая в Омске IPOE+DHCP. И железо обновляется раньше чем прошивка отправляется в плаванье.
После - не значит в следствии. И чаще всего это так.
А конфиг со статикой зачем шлёте? Зачем выкусили из лога кусок? Весь прикладывать нужно.
По v4 решительно ничего на тему dhcp на WAN не менялось. Может у провайдера что глюкануло, а вы просто поймали совпадение.
В общем убедиться что в статусе коммутатора WAN поднят как минимум на сотке дуплекса, заодно увидите туда ли воткнут. Сбросить настройки и просто вообще ничего не трогая глянуть в лог. Если адрес не будет получен позвонить прову и попросить ребутнуть домовой коммутатор, если подключены через ONU ребутнуть его. Иногда на коммутаторах доступа DHCP снупинг глючит и ответы тупо перестают долетать до клиента. Чаще всего происходит при link down/up. Других предположений нет.
Может вообще у провайдера работы какие на серверах идут, а т.к. lease time обычно сутки, то отключения dhcp серверов никто не заметит как минимум 12 часов или до перезагрузки.
Если бы DHCPC v4 развалился бы, я бы узнал бы от этом первый т.к. на доступе инфраструктуры системы обновлений wi-cat живёт именно DUO-G, включен он в сеть ТТК которая в Омске IPOE+DHCP. И железо обновляется раньше чем прошивка отправляется в плаванье.
После - не значит в следствии. И чаще всего это так.
Цитата: sfstudio от 26/12/2021, 21:37Попросил приятеля на МТС (там тоже IPOE+DHCP) обновиться - проблем не наблюдается. Так что 99,99999% что-то из озвученного выше.
Рассказывайте по результатам, что бы тема не висела.
Попросил приятеля на МТС (там тоже IPOE+DHCP) обновиться - проблем не наблюдается. Так что 99,99999% что-то из озвученного выше.
Рассказывайте по результатам, что бы тема не висела.
Цитата: Andrey_s от 03/01/2022, 05:17Прикладываю полный лог.
Статика в пределах NAT, потому я за неё не переживаю.
Провайдер не МТС (в конфиге имя wifi для совместимости оставлено таким), а небольшой местный. Касаемо оборудования - перезагружал ONU, OLT (есть возможность такая).
Проблема сохраняется именно на этом роутере, именно на прошивках выше, чем версия 3.4.6. На других роутерах, ПК, на этом с прошивкой 3.4.6 проблема не наблюдается.
Прикладываю полный лог.
Статика в пределах NAT, потому я за неё не переживаю.
Провайдер не МТС (в конфиге имя wifi для совместимости оставлено таким), а небольшой местный. Касаемо оборудования - перезагружал ONU, OLT (есть возможность такая).
Проблема сохраняется именно на этом роутере, именно на прошивках выше, чем версия 3.4.6. На других роутерах, ПК, на этом с прошивкой 3.4.6 проблема не наблюдается.
Цитата: sfstudio от 03/01/2022, 15:30Мне так и не удалось воспроизвести проблему.
Видимо придётся подключать ТП оператора что бы глянул на своей стороне что не нравиться их DHCP серверу, что он решает не отвечать.
С 3.4 ветки прошло уже очень много времени, однако других репортов на эту тему нет. А значит надо разбираться с конкретной связкой с привлечением спецов ISP. Это самый верный подход.
Мне так и не удалось воспроизвести проблему.
Видимо придётся подключать ТП оператора что бы глянул на своей стороне что не нравиться их DHCP серверу, что он решает не отвечать.
С 3.4 ветки прошло уже очень много времени, однако других репортов на эту тему нет. А значит надо разбираться с конкретной связкой с привлечением спецов ISP. Это самый верный подход.
Цитата: CrazyNub от 03/01/2022, 19:10Цитата: Andrey_s от 03/01/2022, 05:17перезагружал ONU, OLT (есть возможность такая).
Кто провайдер? Марка и модель терминала?
На СФО и УФО нет проблем с получением ДХЦП от провайдера.
Речь про: МТС, РТ, дом.ру и еще ряд местных провайдеров, и 100+ устройств FT-AIR-DUO-G.
Цитата: Andrey_s от 03/01/2022, 05:17перезагружал ONU, OLT (есть возможность такая).
Кто провайдер? Марка и модель терминала?
На СФО и УФО нет проблем с получением ДХЦП от провайдера.
Речь про: МТС, РТ, дом.ру и еще ряд местных провайдеров, и 100+ устройств FT-AIR-DUO-G.
Цитата: sfstudio от 21/01/2022, 01:51Провайдер что говорит? Я уже все доступные мне варианты перепробовал, на всех мне доступных линках, со всеми доступными серверами. Что не нравиться DHCP серверу вашего провайдера лучше всех ответит именно он (провайдер) заглянув в влоги DHCP сервера со своей стороны.
Пока ни одной жалобы кроме вас я не вижу, и попытки повторить у меня провалились полностью, все...
Провайдер что говорит? Я уже все доступные мне варианты перепробовал, на всех мне доступных линках, со всеми доступными серверами. Что не нравиться DHCP серверу вашего провайдера лучше всех ответит именно он (провайдер) заглянув в влоги DHCP сервера со своей стороны.
Пока ни одной жалобы кроме вас я не вижу, и попытки повторить у меня провалились полностью, все...
Цитата: Andrey_s от 22/01/2022, 15:35Сделал с помощью Wireshark дамп с WAN порта двух роутеров (предварительно сброшенных до заводских настроек)
DUO_G, который не получает адрес и ZTE H298N, который без проблем подключается. Их же отправил инженерам провайдера
Сделал с помощью Wireshark дамп с WAN порта двух роутеров (предварительно сброшенных до заводских настроек)
DUO_G, который не получает адрес и ZTE H298N, который без проблем подключается. Их же отправил инженерам провайдера
Цитата: sfstudio от 22/01/2022, 15:57Я надеюсь они хотя бы в логи DHCP сервера перед анализом дампов заглянут. Чаще всего это сразу отвечает на вопрос чего не нравиться. Ну и вообще сдампить на их стороне ибо DHCP снупинг на свитчах может запросто избирательно дропать запросы.
Встречалось пару раз года 4ре назад, обновление софта на коммутаторах решило проблему.
Т.е. мало знать в чём разница, хочется знать на каком этапе затык т.к. во-первых, больше никто так и не сообщил о проблеме, значит она провайдер специфична. Во вторых по мере обновления busybox в устройствах других вендоров начнутся проблемы и с ними.
udhcpc обычно используется без изменений.
Я надеюсь они хотя бы в логи DHCP сервера перед анализом дампов заглянут. Чаще всего это сразу отвечает на вопрос чего не нравиться. Ну и вообще сдампить на их стороне ибо DHCP снупинг на свитчах может запросто избирательно дропать запросы.
Встречалось пару раз года 4ре назад, обновление софта на коммутаторах решило проблему.
Т.е. мало знать в чём разница, хочется знать на каком этапе затык т.к. во-первых, больше никто так и не сообщил о проблеме, значит она провайдер специфична. Во вторых по мере обновления busybox в устройствах других вендоров начнутся проблемы и с ними.
udhcpc обычно используется без изменений.
Цитата: sfstudio от 22/01/2022, 16:07Да. Добавьте на время разбирательства в /etc/init.d/wan в строку UDHCPCOPTS= после $dhcpHostName ключик -v что бы заставить udhcp быть более разговорчивым. Может тут ещё что в отладке увидим.
Да. Добавьте на время разбирательства в /etc/init.d/wan в строку UDHCPCOPTS= после $dhcpHostName ключик -v что бы заставить udhcp быть более разговорчивым. Может тут ещё что в отладке увидим.
Цитата: sfstudio от 22/01/2022, 16:11В списках рассылки busybox я так же не вижу репортов по dhcp клиенту кроме как http://lists.busybox.net/pipermail/busybox-cvs/2021-December/040956.html но если бы в этом была бы проблема то была бы с 2014г. https://git.busybox.net/busybox/commit/?id=e2318bbad786d6f9ebff704490246bfe52e588c0
В списках рассылки busybox я так же не вижу репортов по dhcp клиенту кроме как http://lists.busybox.net/pipermail/busybox-cvs/2021-December/040956.html но если бы в этом была бы проблема то была бы с 2014г. https://git.busybox.net/busybox/commit/?id=e2318bbad786d6f9ebff704490246bfe52e588c0
Цитата: sfstudio от 22/01/2022, 16:29Есть ещё связанный с ним фикс https://git.busybox.net/busybox/commit/networking/udhcp/dhcpc.c?id=9e27fed6b9a21454149873cfc4e034c8226f8ffb который был в июне 21г. Т.е. относительно недавно. Но глазками не вижу с ним проблем. Да и времени прошло уже с июня достаточно что бы ещё хоть у кого-то проявилось.
Собсно могу откатить его и собрать вам на тест версию для проверки. Но лучше сначала подождём что скажет оператор. Не очень хочется городить воркэраунды если проблема таки на их стороне (на что ну прям всё указывает).
Есть ещё связанный с ним фикс https://git.busybox.net/busybox/commit/networking/udhcp/dhcpc.c?id=9e27fed6b9a21454149873cfc4e034c8226f8ffb который был в июне 21г. Т.е. относительно недавно. Но глазками не вижу с ним проблем. Да и времени прошло уже с июня достаточно что бы ещё хоть у кого-то проявилось.
Собсно могу откатить его и собрать вам на тест версию для проверки. Но лучше сначала подождём что скажет оператор. Не очень хочется городить воркэраунды если проблема таки на их стороне (на что ну прям всё указывает).
Цитата: sfstudio от 29/01/2022, 00:16Проверки разумности не проходят:
/* 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; }Гляну завтра менялось ли в апстриме на эту тему что-то. Но врятли ИМХО. Интересно только какое из условий отрабатывает.
Проверки разумности не проходят:
/* 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;
}
Гляну завтра менялось ли в апстриме на эту тему что-то. Но врятли ИМХО. Интересно только какое из условий отрабатывает.
Цитата: sfstudio от 12/02/2022, 15:01А запрос-то вообще от роутера до них долетает или каким "умным" коммутатором по пути дропается? Тогда надо в логи коммутатора смотреть что ему не нравиться. Им так и сяк это чинить придётся.
А запрос-то вообще от роутера до них долетает или каким "умным" коммутатором по пути дропается? Тогда надо в логи коммутатора смотреть что ему не нравиться. Им так и сяк это чинить придётся.
Цитата: sfstudio от 12/02/2022, 15:36Не переживайте, скоро это будет проблемой вашего провайдера с почти любой новой прошивкой почти любого вменяемого вендора обновляющего свой софт хотя бы на новые срезы SDK от чипмэйкера. Ибо повторюсь ещё раз. udhcpc используется из состава бизибокса.
Ни одного больше репорта, ни от одного клиента нам больше не поступало, хотя на прямой связи со многими операторами с IPOE + DHCP на доступе. Не умею лечить то, что не ломалось. Поэтому у меня нет иных предложений кроме как по шагам выяснять что происходит. На своей стороне всё что можно я проверил. Дело за оператором. Точек отказа может быть много, начиная с ONU. Что именно вдруг перестало нравиться в запросах (ну раз в логах провайдера тишина то я как понимаю запросы не долетают до них вообще) оборудованию вашего провайдера мне неведомо.
Валидность запросов уже проверил ручками. Криминала не увидел.
Увы, больше мне вам помочь не чем.
P.S. В апстриме бизибокса тоже репортов нет, а там вообще репорты со всего мира льются, и от юзверей и от провайдеров и от разрабов.... Я не знаю как тут можно говорить что проблема в udhcpc при этом, а не на стороне провайдера... ;)
Не переживайте, скоро это будет проблемой вашего провайдера с почти любой новой прошивкой почти любого вменяемого вендора обновляющего свой софт хотя бы на новые срезы SDK от чипмэйкера. Ибо повторюсь ещё раз. udhcpc используется из состава бизибокса.
Ни одного больше репорта, ни от одного клиента нам больше не поступало, хотя на прямой связи со многими операторами с IPOE + DHCP на доступе. Не умею лечить то, что не ломалось. Поэтому у меня нет иных предложений кроме как по шагам выяснять что происходит. На своей стороне всё что можно я проверил. Дело за оператором. Точек отказа может быть много, начиная с ONU. Что именно вдруг перестало нравиться в запросах (ну раз в логах провайдера тишина то я как понимаю запросы не долетают до них вообще) оборудованию вашего провайдера мне неведомо.
Валидность запросов уже проверил ручками. Криминала не увидел.
Увы, больше мне вам помочь не чем.
P.S. В апстриме бизибокса тоже репортов нет, а там вообще репорты со всего мира льются, и от юзверей и от провайдеров и от разрабов.... Я не знаю как тут можно говорить что проблема в udhcpc при этом, а не на стороне провайдера... ;)
Цитата: sfstudio от 12/02/2022, 15:59Был бы у меня доступ к инфраструктуре вашего ISP давно бы уже как минимум было бы понятно, где причина, а скорее бы и что не нравиться и добавлен workaround. Увы, у меня нет такого доступа и врятли появится.
Был бы у меня доступ к инфраструктуре вашего ISP давно бы уже как минимум было бы понятно, где причина, а скорее бы и что не нравиться и добавлен workaround. Увы, у меня нет такого доступа и врятли появится.
Цитата: sfstudio от 12/02/2022, 16:15На OLT по вашему порту случаем вообще фильрации какой нет? Статистику фильтров на OLT пусть глянут хоть. Судя по https://cdatatec.com/wp-content/uploads/2016/09/C-Data-Cortina-EPON-OLTFD1108SFD1104SFD1104SNFD1104BFD1104Y-CLI-User-Manual-V1.6-20151126.pdf (п6.5 и ниже) или шторм контролов каких… Вот почти уверен что эти умности что-то избыточно фильтруют.
На OLT по вашему порту случаем вообще фильрации какой нет? Статистику фильтров на OLT пусть глянут хоть. Судя по https://cdatatec.com/wp-content/uploads/2016/09/C-Data-Cortina-EPON-OLTFD1108SFD1104SFD1104SNFD1104BFD1104Y-CLI-User-Manual-V1.6-20151126.pdf (п6.5 и ниже) или шторм контролов каких… Вот почти уверен что эти умности что-то избыточно фильтруют.
Цитата: Andrey_s от 03/08/2022, 18:42Появился дамп dhcp провайдера
[spoiler title=""] TIME: 2022-08-03 16:56:16.164
IP: [IP adress] ([MAC adress]) > [IP adress] ([MAC adress])
OP: 2 (BOOTPREPLY)
HTYPE: 1 (Ethernet)
HLEN: 6
HOPS: 0
XID: 434eea15
SECS: 0
FLAGS: 0
CIADDR: 0.0.0.0
YIADDR: [IP adress]
SIADDR: 0.0.0.0
GIADDR: [IP adress]
CHADDR: a0:33:4e:c0:b5:44:00:00:00:00:00:00:00:00:00:00
SNAME: .
FNAME: .
OPTION: 1 ( 4) Subnet mask [IP adress]
OPTION: 3 ( 4) Routers [IP adress]
OPTION: 6 ( 8) DNS server [IP adress],[IP adress]
OPTION: 12 ( 11) Host name dhcp-client
OPTION: 15 ( 14) Domainname [IP adress]
OPTION: 26 ( 2) Interface MTU 1472
OPTION: 28 ( 4) Broadcast address [IP adress]
OPTION: 51 ( 4) IP address leasetime 864000 (1w3d)[/spoiler]
Появился дамп dhcp провайдера
Цитата: sfstudio от 04/08/2022, 12:46К сожалению это не дамп. Это фигня какая-то. Дамп эт файлик в формате обычно pcap (что бы можно было нормальными инструментами разобрать, где запечатлён обмен сторон "любезностями" дабы можно было понять какой стороне и что потенциально не нравиться и сравнить со случаем когда всё проходит (второй дамп).
В случае с wive вы такой дамп можете снять самостоятельно используя встроенный tcpdump. Но нужен и второй когда всё ок. Хотя может и одного хватит, но врятли.
К сожалению это не дамп. Это фигня какая-то. Дамп эт файлик в формате обычно pcap (что бы можно было нормальными инструментами разобрать, где запечатлён обмен сторон "любезностями" дабы можно было понять какой стороне и что потенциально не нравиться и сравнить со случаем когда всё проходит (второй дамп).
В случае с wive вы такой дамп можете снять самостоятельно используя встроенный tcpdump. Но нужен и второй когда всё ок. Хотя может и одного хватит, но врятли.
Цитата: sfstudio от 22/12/2022, 02:31Бред какой. Проще гря проблема на стороне оператора (раз не может прожевать хостнэйм произвольный в dhcp запросах) и могли бы сразу глянуть логи на своей стороне. Чего и следовало ожидать.
Бред какой. Проще гря проблема на стороне оператора (раз не может прожевать хостнэйм произвольный в dhcp запросах) и могли бы сразу глянуть логи на своей стороне. Чего и следовало ожидать.
