r13

Поддержу, Но проблему можно решить здесь и сейчас с помощью dns-o-matic

Да, специально тестил из энтвари чтоб исключить ожидаемые ограничения на lan

@KorDen проверил у себя: Как и у вас mtu на интерфейсе не меняется до перезагрузки (рассчитанне автоматически). Никакие up/down не помогают. После перезагрузки назначенные вручную настройки mtu меняются на лету без проблем. Значит такая особенность именно автоматики. Вопреки Настройка mtu на интерфейсе важна, фрагментация все равно ограничена этой настройкой Если попытаться передать пинг на пару килобайт с запретом фрагментации то при меньших значениях mtu пинг не проходит, при больших же все проходит. Т е фрагментация работает, но указание подходящего значения mtu на интерфесах обязательно.

А как правильно протестить работу фрагментаци? Доп настройки какие нибудь туннеля делали?

Dyndns позволяет вписать свой произвольный url(то что у вас curl вызывает). Эффект будет такой же. Только по форуму надо поискать синтаксис подстановки своего ip. ЗЫ на чем падает?

А у вас через этот туннель нефрагментированный пинг какой длины пролезает?

Просто вписать её в вызове curl вместо вашей $EXTERNAL_IPV4 Вы же такую же переменную $interface инициализируемую прошивкой уже используете в своем скрипте. Типа так: #!/bin/bash [ "$interface" != "ppp0" ] && exit sleep 5 HEUSER='your.username' # The username you use to login at tunnelbroker.net HEKEY='32f325019357278d' # This 'Update Key' can be found on the 'Advanced' tab of the tunnel details page. HETUNNEL='12356' # The 'Tunnel ID' from the tab IPv6 tunnel on the tunnel details page. curl -k -s "https://ipv4.tunnelbroker.net/nic/update?username=$HEUSER&password=$HEKEY&hostname=$HETUNNEL&myip=$address"

Адрес передается в скрипт в переменной $address почему бы ей не воспользоваться?

Пока есть мнение что данная фича не работает.

Кстати eoip интерфейс в состоянии down можно сказать полуживой, привязанный к нему ip без проблем пингуется локально несмотря на состояние, но сам туннель при этом не работает.

Если нужно чекать то лучше делайте ipsec чтобы он отвечал за поддержание соединения. Пинг чек в такой конфигурации весь бридж будет рестартить что для home сегмента это не есть хорошо.

При ваших устройствах не просядут, просто за счет ipsec ovehead тоже полезная нагрузка подсократиться а по производительности никаких ухудшений не будет.

Да, приставка просто получит ip по dhcp из сегмента home

Раз в бриджах с обоих концов то адреса не нужны

Я про операторские приставки имел ввиду, там обычно ничего нет. Зачем вам двойная инкапсуляция, она снизит полезную нагрузку туннеля? Лучше отдельно. Если с обоих концов белые адреса то и ipsec на eoip не нужен, тв трафик не секретный

Выделять, чтобы обьединить его в бридж с eoip. Зы, с тв приставками получать доступ особо не к чЕму.

Выделяете порт с тв приставкой в отдельный бридж( в настройке сегментов) и с этим бриджом уже объединяете eoip. Приставка в этом случае живет в отдельной сети вместе с eoip никак не пересекаясь с основной домашней сетью.

А вы eoip туннель только для твсприставки пользуйте, а для остального отдельный ipip

Ну разве что udpproxy. Чисто мультикаст в IPIP не пойдет. Чем Eoip не угодил?

Или вернуть порт на 80

В локальном режиме работает только на 80м порту. This is by design.

@Le ecureuil Давно хотел спросить, при соединении L2TP/IPSec на сервере частенько вижу следующий лог Dec 13 07:00:43accel-ppp l2tp tunnel 40070-12939 (176.14.***.***:1702): discarding out of order message (packet Ns/Nr: 657/2, tunnel Ns/Nr: 819/13, tunnel reception window size: 16 bytes) Dec 13 07:01:58accel-ppp l2tp tunnel 40070-12939 (176.14.***.***:1702): discarding out of order message (packet Ns/Nr: 658/2, tunnel Ns/Nr: 820/13, tunnel reception window size: 16 bytes) Dec 13 07:03:13accel-ppp l2tp tunnel 40070-12939 (176.14.***.***:1702): discarding out of order message (packet Ns/Nr: 659/2, tunnel Ns/Nr: 821/13, tunnel reception window size: 16 bytes) Dec 13 07:04:28accel-ppp l2tp tunnel 40070-12939 (176.14.***.***:1702): discarding out of order message (packet Ns/Nr: 660/2, tunnel Ns/Nr: 823/13, tunnel reception window size: 16 bytes) Dec 13 07:05:43accel-ppp l2tp tunnel 40070-12939 (176.14.***.***:1702): discarding out of order message (packet Ns/Nr: 661/2, tunnel Ns/Nr: 824/13, tunnel reception window size: 16 bytes) Dec 13 07:06:58accel-ppp l2tp tunnel 40070-12939 (176.14.***.***:1702): discarding out of order message (packet Ns/Nr: 662/2, tunnel Ns/Nr: 825/13, tunnel reception window size: 16 bytes) Dec 13 07:08:13accel-ppp l2tp tunnel 40070-12939 (176.14.***.***:1702): discarding out of order message (packet Ns/Nr: 663/2, tunnel Ns/Nr: 826/13, tunnel reception window size: 16 bytes) Периодичность записей постоянная, минута 15 секунд. Данном случае соединение Ультра2-Екстра2 на крайних 2.11, но так же было и на Ультра2-Ультра и на различных прошивках Интернет соединение с обоих сторон IPoE Туннель при этом работает нормально. Собственно что это и почему нарушена последовательность.

Уже спрашивал, делегирования префикса нет на кинетике. А так да хотелось бы что бы было, ну и развития ipv6 функционала. Сейчас он в весьма урезанном виде. Надо бы тему в развитии завести с feture request.

Не, 2.05 https://help.keenetic.net/hc/ru/articles/115000773009-My-Keenetic-мобильное-приложение-для-Android-и-iOS

У гиги 3 ipsec и его производные самые шустрые за счет аппаратного ускорения.