r13

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 и его производные самые шустрые за счет аппаратного ускорения.

Это так его мобильное приложение(ios) выгружает, ничего с ним не делал. Может тогда стоит формат выгрузки в мобильном приложении пофиксить?

@Alex Sh. добрый день добавьте пожалуйста функцию настройки keendns. В частности возможность инициировать обновление ip адреса в сервисе. (Иногда при изменениях ip на роутере сервис не актуализируется, а так будет возможность дернуть его вручную) или изменить прямой/через облако режим если вдруг провайдер ip серый выдал.

С добрым утром ! На старт2 2.11.A.9.0-3 все равно падает strongswan

А поискать по теме как правильно в конфиг логин/пароль писать?