vst

Данная файловая система совсем недавно увидела свет. Разве уже появилась реализация под linux!?

Попробуйте советы из темы, приведенной ниже, а именно "lcp echo 30 3 adaptive" и различные режимы annex.

Попробуем обновить версию netatalk до актуальной с целью избавиться от ошибки "dsi_stream_read: len:0, unexpected EOF"

@Buha давайте разбираться. Попробуйте выполнить пинг непосредственно с роутера (команда tools ping6 <host>). А также выложите selftest.

Проблема созданием подсетей неверного размера найдена. Префиксы неправильного размера не будут нарезаться на подсети. По поводу валидатора: валидатор в веб-интерфейсе никак не хочет воспринимать префиксы, которые заканчиваются не на двоеточие. Например: 2a01:4f8:173:641:0:2:2:0/112 - не проходит валидацию 2a01:4f8:173:641:0:2:2::/112 - проходит валидацию Данный нюанс запомним, но исправление сделаем позже. @gaaronk Спасибо!

В случае использования делегированного префикса неверного размера, роутер не сможет порезать его на подсети. В таком случае в логе должны появиться сообщения: @gaaronk Если вам удалось подобрать данные, при которых появляются странные подсети, поделитесь пожалуйста логом или селфтестом.

Допустим от провайдера получен префикс 2001:db8:1234:5600:/56. В такой подсети можно разместить 256 сетей размером /64 (64-56 = 8 бит, 2 ^ 8 = 256). Далее необходимо порезать этот префикс на /64 подсети. subnet c номером 0 получит подсеть 2001:db8:1234:5600:/64. subnet c номером 3 получит подсеть 2001:db8:1234:5603:/64. .. subnet c номером 255 получит подсеть 2001:db8:1234:56ff:/64. Если от провайдера прилетел префикс /64, то такой префикс образует только одну подсеть /64. Subnet 0 полностью завладеет данным префиксом. Остальные subnet ничего не получают.

Для ipv6 самой малой маршрутизируемой сетью считается /64. Такое ограничение связано с работой алгоритма автоматического назначения адреса (SLAAC). Именно по причине, что сеть меньше 64 (65,66... и более), роутер не может назначить себе адрес для интерфейса Home. https://www.ripe.net/about-us/press-centre/understanding-ip-addressing

@t800 Необходим selftest с отладкой. Включите режим отладки, как возникнет проблема, зафиксируйте несколько попыток соединения, затем остановите отладку - скачается selfest. По поводу провайдера: в принципе можно докопаться по поводу маршрутов, если есть желание. А именно два одинаковых маршрута по dhcp + большая подсеть для них /8.

@Dmitry Ganaev На вид всё ок, разве что увеличить максимальный размер файла. Если dhpc пакетов нет, а ошибки сыпятся, то это весьма любопытный результат.

@Dmitry Ganaev Если не сложно, снимите пожалуйста небольшой дамп трафика с Home интерфейса. Главное, чтобы в него попали dhcp пакеты. Для этого можно использовать фильтр "udp and ( port 67 or port 68 )". Так же после отключения dhcp клиента, которое вы уже выполнили, попробуйте перезагрузить роутер.

@Dmitry Ganaev Попробуйте отключить dhcp клиент на ISP подключении. Для этого зайдите в настройки подключения ISP и пункте "Настройка параметров IP" вместо автоматически поставьте "без IP-адреса". Сделать это нужно для того, чтобы оценить возможное влияние dhcp клиента на работу dhcp сервера. Так как у вас pppoe, то dhcp клиент не требуется и он бестолку шлет discovery.

Тестовые прошивки

@Stepmak В версии 2.09 было внесено множество изменений, касающихся работы резолвера vpn соединений. Попробуйте установить draft 2.09.

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

Подозреваю, что несмотря на то, что у 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 нужно больше селфтестов. Крайне желательно, чтобы они содержали проблемную ситуацию.