r13

@ndm Рад что тема продвигается Первые мысли: Полагаю нам нужна возможность назначать default route для сегмента и default route для хоста. Отдельный вопрос настройки nat в данной конфигурации. Также понадобится более гибкая настройка.

В ручную на вкладке файлы делается. Там можно сохранить текущую прошивку или обновиться из файла.

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

Новая вебка и так не влезает надо что то из уже установленного.

1. Прошлось криво, надо перепрошить 2 Вебке по хорошему не зачем знать какой набор компонентов установлен в данный момент, она просто делает что выбрал пользователь. ЗЫ Еще раз: зачем мне как пользователю лишнее ограничение моей возможности прошить роутер независимо от причин побудивших меня это сделать?

Еще раз соберет в облаке прошивку с вашим набором компонентов и еще раз прошьет ее в роутер так что кнопка свою функцию выполнит. Функция прошивки работает независимо от того меняли вы что-то или нет. От этого зависит какая прошивка будет запрошена на сервере.

После нажатия кнопки инициируется прошивка роутера, так что эта кнопка работает всегда. В кинетике нельзя поменять набор компонентов без перепрошивки. Если набор компонентов не изменился то повторно пересобирается прошивка в облаке с тем же набором и роутер прошивается. Зачем навешивать лишнюю логику ограничивающую мою возможность инициировать прошивку роутера?

@TAILORD зачем придумывать лишние ограничения?

Команда ipv6 route есть в кинетике, так что если статика, то роутинг можно попробовать прописать. @vst если это возможно, опишите как настроить ЗЫ ну и раз вопрос поднялся, какие планы по развитию ipv6 компонента?

Поддержу, Но проблему можно решить здесь и сейчас с помощью 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. Зы, с тв приставками получать доступ особо не к чЕму.