slomblobov

Исправление будет перенесено в стабильную ветку.

Подозреваю, что несмотря на то, что у dhcpv6 сервера мы не запрашиваем DNS recursive name server (23), сервер её присылает. Исправление появится в очередном draft. Для наглядного обоснования нужен дамп трафика с интерфейса ISP. @Kareem Если интересно, то необходимо с помощью модуля захвата пакетов сделать дамп трафика. Для этого выньте кабель из WAN порта, запуcтите мониторинг на интерфейсе ISP, вставьте кабель, дождитесь получения ipv6 адресов.

@Kareem нужен селфтест.

На лету действительно не подчищается список автоматически выданных адресов, поправим. После сохранения конфига и перезагрузки всёравно прилетают dns от провайдера? Прописать свои адреса можно например так: ipv6 name-server 2001:4860:4860::8888 P.S. скрытый пост с селфтестом выложите для лучшего понимания вашей ситуации.

Класс идентифицируется только опцией 60. А какие ещё часто используемые на практике идентификаторы? 3. Несколько серверов с разными пулами посадить на один mac/ip не получится без реализации исключений. 4. Опции для класса имеют более высокий приоритет. В веб изменения пока не планируются. Пробел в строке - норма, на разбор сообщения не влияет. P.S. Всё, я запутался, слишком много параллельных вопросов в сообщении. Не понятно что реально интересует, а без чего можно и обойтись.

1. Создание кусочно-заданного пула не реализовано. 2. Список известных хостов задаётся в непривязанном к пулу виде, этим списком пользуются все пулы, если адрес входит в подсеть. Поэтому нет. Предполагается, что всякие исключения реализуются за счет опции 60. 3. Создать несколько пулов и прицепить на один и тот же интерфейс можно. Каждый пул вызовет создание отдельного dhcp сервера, что вызовет отправку на каждый discovery несколько offer с одно и того же интерфейса. Клиент выбирет один из offer, но один сервер ответит на это ACK, другой однозначно NACK. Возможности протокола не позволяют разграничить работу нескольких серверов на одном интерфейсе. Итого сейчас так можно сделать, но это будет запрещено в конфиге, так как приводит к неопределенному поведению. 4. В веб интерфейсе пока работа с опциями не реализована. В целом я не говорю однозначное нет по хотелкам, есть хорошие идеи. Теперь попробуем разобраться с задачами @cbloner штатными средствами. В приведенном конфиге для пула _WEBADMIN отсутствует диапазон. Поэтому опция не будет раздаваться. Предполагаю, что нужно сделать так: ip dhcp class panasonic option 60 ascii Panasonic ! ip dhcp pool _WEBADMIN class panasonic option 66 ascii tftp://192.168.10.120/buywell/buywell___(01)-(mast)_panasonic.cfg ! range 192.168.10.xx 192.168.10.yy bind Home enable !

Так как нас интересует работа dhcp, то рекомендую фильтровать по udp и портам dhcp

@t800 Ценно конечно заснять момент появления проблемы. Но некоторые выводы удалось сделать и небольшое исправление всё же появится. Далее будем наблюдать уже с ним.

@Stepmak у вас uptime 8 суток или успешно соединяется после разрыва? Кому не сложно, пришлите лог отвала l2tp и успешного переподключения.

Фича, исключение для сети Home, чтобы простые пользователи, не ведающие что такое NAT, могли спокойно пользоваться интернетом.

@Stepmak нужно больше селфтестов. Крайне желательно, чтобы они содержали проблемную ситуацию.

@StepmakПопробуйте изменить способ аутентификации. В предоставленном selftest у вас удалась PAP аутентификация, зайдите в настройки l2tp соединения в включите метод проверки подлинности CHAP.

Нельзя просто так взять и прописать префикс - выщестоящий роутер не будет про него знать и не будет маршрутизировать. Без префикса роутер не знает какие ему адреса раздавать клиентам, поэтому когда вы прописали статический префикс - клиенты получили адреса. Если ваш провайдер не поддерживает делегирование префикса, то поможет ipv6 pass through.

@doc_bravn Настроено верно, но ipv6 префикс не был получен от провайдера. Сеть Вы случайно не за gpon терминалом сидите? Вот тема, в которой обсуждалась похожая ситуация: GPON терминал переведён в режим бриджа? Поддерживает ли ваш провайдер ipv6 prefix delegation? Ну и нужно разобраться с дичью: Судя по всему в icmpv6 RA рассылается такая опция. Если снимите дамп wan трафика, то будет очень полезно.(запустить мониторинг, воткнуть кабель, дождаться поднятия)

Переключать тип subnet смысла особого нету, все клиенты способны работать с режимом slaac. Цвет порта тоже на ipv6 не влияет. @doc_bravn нужен селфтест.

Итак, у всех разные выводы можно сделать по селфтестам, напишу как продвигается расследование в общем: 1) есть подозрение, что наш dhcp клиент спустя длительное время перестаёт корректно рассылать renew, что приводит к отрубанию устройства на вышестоящем коммутаторе. Нужно проверять. 2) слишком большое время аренды ip адреса у провайдера (1 день), если при этом отвалится один из коммутаторов, то ближайший renew-ack будет не скоро. Так как перетыкание кабеля(или полная перезагрузка) вызывает активность со стороны dhcp клиента, то это и приводит к восстановлению работоспособности. Так же можно воспользоваться кнопкой на главной странице интерфейса "обновить ip адрес" или командой "inteface <имя интерфейса> ip dhcp client renew" 3) возможны проблемы со стороны сервисов yandex.dns skydns. В тестовых целях прошу отключить их и наблюдать изменения. 4) бан dns серверов провайдера со стороны dns proxy. При кратковременной потере связи сервера могут попасть в бан из-за отсутствия ответов на запросы. Таймаут ухода в бан задаётся командой "dns-proxy bantime <time_in_ms>" По умолчанию значение равно 300000 (300 секунд). Для тестов можно его уменьшить на порядок.

Проблема была исправлена начиная с версии 2.08.A.12.0-0

В корне конфига выполнить команду "ipv6 firewall". На этом к сожалению всё, только вкл и выкл. Немного об этом поведано здесь

@AirVetra Команда ipv6cp предназначена для включения одноименного протокола для ppp соединений. https://tools.ietf.org/html/rfc2472 Команда вернула ошибку, так как интерфейс ISP имеет тип ipoe. Если ваш провайдер не поддерживает нативный ipv6, то придётся воспользоваться туннелями 6to4 или 6in4 (белый ipv4 обязателен для этих типов туннелей!). Для защиты от входящих подключений так же необходимо включить "ipv6 firewall".

@jino Здорово, что собираете, но если можно описывайте ситуацию, при которой они возникают. В последнем случае у вас закончилось место на диске?

Драйвер hfs не поддерживает расширенные атрибуты, о чем netatalk периодически пишет в логе. Данные сообщения ни на что не влияют, в принципе можно их и скрыть. По поводу "dsi_stream_read: len:0, unexpected EOF". Очень похоже на https://sourceforge.net/p/netatalk/bugs/633/?limit=25 После обновления netatalk 3.1.8 -> 3.1.10 должно исправиться.

Работу модуля ipv6_pt поправили, ожидайте в очередном draft. По поводу скрина с выданными IPv6: не отражены выданные префиксы, поэтому конкретно по ним что-либо сказать затруднительно.

1 Скорее всего GPON-терминал не предусматривает работу ipv6 роутера за ним. 2 Терминал выдал опцию dhcpv6 prefix delegation, что немного опровергает пункт 1. Но wan адреса находятся в той же сети, что не есть корректно. 3 Терминал выдал dns6 адреса link-local, которые не смогут быть маршрутизированы, что в принципе подтверждает пункт 1. 4 В зависимости от модели терминала возможно обеспечить работу роутера за ним, настроить маршруты и поделить выданный от провайдера префикс на части, но всё придётся делать руками. Попробуйте вот такую команду:

@Sozanovверсия 7 с afp - это девелоперская сборка. Версия 8 уже сварена как положено. Применительно к компоненту afp отличий быть не должно, но всё же лучше основываться на более свежей версии.

Попробуйте ip6tables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT Модуль conntrack ipv6 поддерживается начиная с ядра 2.6.25