Wi-CAT LLC

Wireless Comprehensive Advanced Technology. Build your network now.

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

(решено) ISP Lentel vs IPv6 dhcp6c - требуется статичный duid.

Здравствуйте. Мой провайдер по какой-то причине дает ipv6 только на 24 часа, потом адреса протухают. Мой старый роутер от одной известной фирмы как-то из коробки это детектит, показывает прям в веб интерфейсе lifetime адресов и обратный отсчет, потом перезапрашивает dhcp. А мой новый FT-AIR-DUO-G говорит "valid_lft forever preferred_lft forever". В час икс начинается network unreachable, лечится перезагрузкой роутера. Проблема повторялась на разных версиях прошивки, включая актуальную 2.7.2.RU.18062020
Аппаратная маршрутизация ipv6 включена, вот конфиг dhcp6c:

interface eth3 {
send ia-pd 12629744;
send ia-na 12629744;
send rapid-commit;
request domain-name-servers;
script "/etc/scripts/dhcp6c-script";
};
id-assoc pd 12629744 {
prefix-interface br0 {
sla-id 0;
sla-len 16;
};
};
id-assoc na 12629744 { };

Логт надо за весь период с загрузки до протухания, подумаю что сделать.

Т.е. надо реконфигур локального сегмента v6 получается запускать заново. Как бы адреса на WAN по RA новые прилетают всяко и сразу на eth3 их можно будет видеть. А вот на br0 переконфигурить сеть...

Вообще провайдеры не меняют постоянно адреса v6 в сторону клиента. Оно и понятно. Это каждый раз обрыв всех соединений же...

Кстати на доступе что? Всмысле PPPOE/IPOE и т.д.

В общем давайте больше данных. Конфиг dhcp клиента мне как раз наименее интересен.

А вот без логов репорты можно даже не писать чаще всего.

P.S. Вот тут специально описаны определённые хотелки по оформлению репортов https://wi-cat.ru/forums/topic/prochti-menya-pravila-i-rekomendacii-dlya-uchastnikov-foruma/

Глянул в лоб. Ну должен dhcp6c-script вызывать реконфигур

service six dhcpradvdreconf

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

 

Кстати тут может быть затык в другом. Возможно придётся уменьшать lifetime именно в конфиге radvd что бы ваши устройства быстрее обновляли настройки у себя.

Сейчас там вот так при нативном дуалстэке значения больше, для туннелей меньше

# different timeouts for tunneled/native modes
if [ "$IPv6OpMode" = "1" ]; then
        MinRtrAdvInterval="5"
        MaxRtrAdvInterval="100"
        AdvValidLifetime="57600"
        AdvPreferredLifetime="10800"
else
        MinRtrAdvInterval "3"
        MaxRtrAdvInterval "20"
        AdvValidLifetime="300"
        AdvPreferredLifetime="120"
fi

Для проверки после появления проблемы достаточно отключить клиента от сети (кабель выдернуть, wifi на нём выключить) и подключить назад. Если после этого заживёт то да. Придётся тогда эти параметры вынести в UI что бы можно было руками задать.

Проверьте, если поможет сделаем блок "advanced" в настройках ipv6. Ну можно прям в /etc/init.d/six поправить аккуратно используя vi и сохранить по fs save. Для проверки идеи.

Был бы лог можно было бы хотя бы понять событие то само для реконфигура есть или нет.

Ок, пособираю инфу.

Я провайдеру высказал свой каприз, он затаился. Уже несколько дней ни единого разрыва. Думаю, они молча что-то подкрутили. Засечь логи в момент протухания адреса в таких условиях не выйдет.

Может просто у них траблы были, поправили и всё полечилось.

Оставим пока тему открытой, помониторим. Дальше будет видно. Я эмулировать косяк не смог  в лоб в своих условиях тоже.

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

Всё, нашел.

Хоршо. А то я только до ПК добрался.

В общем, я засек, что после ребута у роутера изменился DUID. Это нормально? Насколько я понимаю, мне его надо как-то зафиксировать.

duid генериться из хардвардного адреса на WAN. Функции get_duid->gethwid. Если адрес не меняется - не меняется и duid.

 

Проверил на всякий. Не меняется duid если не меняется мак на WAN. Да и не очень понимаю как это связано должно быть с описанной выше проблемой. Он тогда каждую 1/2 lease time меняться должен. Т.е. мак должен плавать и dhcp6c каждый раз рестартовать в этот момент.

Или уже какую-то другую проблему решить пытаетесь?

С изначальной темой напрямую не связано. Заведу отдельную тему, т.к. теперь ясно, что это не ожидаемое поведение. И еще, не очень хочется публиковать свой mac на форуме. Может я вам его на почту пришлю?

Ну мне ваш мак не нужен в общем-то вообще. Хотя чесслово не очень понимаю что такого тайного в MAC адресах физ интерфейсов? Это же не мак радио по которому можно геолокацию устроить по базам вардрайвинга.

Тему мы можем переименовать. Например в ipv6 vs оператор такой-то и опишите детально таки что там у вас происходит и что и как настроено. Конфиг вот можно на мыло сразу sfstudio[at]wi-cat.ru на посмотреть.

В общем мне нужны данные для повторения. Желательно простая последовательность для достижения результата.

P.S. Правда даже если бы duid менялся бы каждый ребут я лично не вижу в этом никакой проблемы. Даже более того, такое поведение на мой взгляд кажется более разумным. По факту у кого как это реализовано. В wide-dhcpd вот схема как выше. Генериться из mac адреса WAN.

Аааа.. Глянул код. Да, там же в генерации время учавствует. Да. Он будет разный таки, просто период изменения не секунды.

Что бы запретить перегенерацияю достаточно в /etc/init.d/six закоментировать строку

rm -f /etc/dhcp6c_duid

И тогда после save & reboot (ну или fs save) duid больше не будет меняться.

 

Однако регенерация duid не должна приводить к проблемам на стороне оператора. Уберу в новых версиях регенерацию вообще. Не нужна она в общем-то там по большому счёту. Т.е. будет если после настройки сказать save and reboot то до следующего обновления ПО (или иного события по которому будет сброшено состояние rwfs) дуид будет оставаться статичным.

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

 

Ну и оператору стоит донести таки, что вообще регенерация duid хоть каждое обращение не является какой-то запрещённой техникой. =) И таки более чем встречается в устройтсвах. Потому если их доступ к этому чувствителен - ну пусть ждут проблем в будущем и с иными девайсами.

Хотя чесслово не очень понимаю что такого тайного в MAC адресах физ интерфейсов?

У меня как-то давно случилась коллизия по маку в подсети провайдера. Начались странности с выдачей адресов, это очень раздражает, кучу времени и нервов тогда потратил на выяснения и переписку. С тех пор стараюсь мак беречь, не приватности ради.
Сейчас зафиксирую duid, буду дальше мониторить. Спасибо.

https://lentel.ru/
Чтобы донести, нужно как-то аргументировать. А я не настолько сведущ. Могу только попробовать пригласить сюда.

Ладно пока не торопитесь. Проверьте как выше с закоментированной строчкой и сохранением rwfs если заживёт подумаю как лучше сделать. Пока не надо что бы они свою сторону чинили. =) Проверить не где будет на живую. =)))

Надо научить железку и в таком варианте работать. Ну пока попался экземпляр ;)

Пока полёт нормальный. Ребутнул пару раз, duid, адреса зафиксировались. Буду вести наблюдение.

Ок.

2.7.5 доступна с обновлятора.

Переделал генерилку терь duid не должен плавать в принципе хоть сохраняй хоть нет. Сохранение на rwfs тоже оставил, пусть будет.

С dhcp до сих пор проблем нет. Случаются иногда странности с маршрутизацией, по ним еще продолжаю наблюдение.

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

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

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