Le ecureuil

Для iOS нет, и не будет согласно политике Apple. Даже из My.Keenetic пришлось удалить эту функциональность после угроз удалить приложение из AppStore.

Все, для которых выпущена 2.08, уже поддерживают. Насчет официальности выпуска 2.08 - смотрите объявления.

Не нужно вводить всех в заблуждение, теперь у вас показывает не наличие Интернета, а всего лишь доступность хоста, указанного в pingchecker. Выше уже сказано, как обманывается Windows, и pingcheck с легкостью может быть обманут провайдером, если он весь трафик будет заворачивать на свой сервер, который будет отвечать на ping Проблема "доступности Интернета" настолько сложна, что надежнее чем показывать наличие default route плюс линка/соединения на WAN придумать мало что можно.

Нет, перезаписывается весь netfilter целиком по каждой нужде. Пока это невозможно "быстро" исправить.

А теперь внимательно прочтите этот пост: И вы увидете, что да, в IF-MIB::ifDescr.N = STRING: FastEthernet0/Vlan2 ставится системное неизменяемое Ralink-специфичное наименование интерфейса, однако в IF-MIB::ifName.N = STRING: ISP и IF-MIB::ifAlias.N = STRING: ISP вы можете увидеть кастомное наименование интерфейса, заданное командой rename, которое как раз и отображается в Web (Для Home аналогично, IF-MIB::IfDescr выставляется в Bridge0, а IF-MIB::ifName и IF-MIB::ifAlias выставляются в Home). Просто используйте другие значения из IF-MIB для получения имен интерфейсов, и все. Причем через rename вы их сами можете задать какими угодно.

Нет, пока прошивка сделана именно так, и переделывать ее не запланировано.

Не совсем, IPsec ставил/снимал марки на своих пакетах, потому fwmarks конфликтовал с ним.

Да, все так.

Итак, начиная с версии прошивки 2.08.A.11.0-3 мы полностью исключили использование skb->mark в ndm, поэтому вы можете его спокойно использовать (iptables match mark и target MARK). Для полной совместимости с ядром и системой NDMS необходимо использовать следующие патчи для iptables: 920-xt_ndmmark.patch, 930-xt_conndmmark.patch, 940-xt_connskip.patch, 950-xt_PPE.patch, 960-xt_tls.patch (в этом случае iptables-save и iptables-restore не будут ругаться). У вас будут показываться ndmmark/conndmmark/connskip/tls match и NDMMARK/CONNDMMARK/PPE target, но трогать их не стоит - они активно используются системой. Однако, следует понимать, что в ядре NDMS присутствуют различные ускорители, которые так или иначе меняют логику работы netfilter. Поэтому если у вас что-то не работает в netfilter, tc, policy routing и подобных вещах, то сперва проверьте, сделали ли вы нижеследующее: - отключить FastNAT: > system set net.ipv4.netfilter.ip_conntrack_fastnat 0 (NDMS 2.x) > system set net.netfilter.nf_conntrack_fastnat 0 (NDMS 3.x) (обратно включить можно через > system set net.ipv4.netfilter.ip_conntrack_fastnat 1 (NDMS 2.x) > system set net.netfilter.nf_conntrack_fastnat 1 (NDMS 3.x) - отключить ppe software: > no ppe software - отключить ppe hardware: > no ppe hardware И проверить результат работы. Если поведение ядра вас устраивает, можете сохранить настройки: > system configuration save Начиная с 2.11 стоит учитывать, что таблица raw монопольно захватывается компонентом netflow и не загружается автоматически. Если она вам нужна - удалите компонент netflow, и загружайте руками iptable_raw.ko. Важно: скрипты в netfilter.d могут вызываться очень часто и с произвольным интервалом, потому обязательно проверьте свои скрипты на работу в таких условиях + на то, что вы проверяете и версию протокола (IPv4 или IPv6), как указано здесь: https://github.com/ndmsystems/packages/wiki/Opkg-Component#ndmnetfilterd Важный момент: скорость без всех ускорителей будет так себе, но вы должны понимать на что идете: или полноценная функциональность, или скорость. Если после всего описанного все равно остаются вопросы, лучше их задать в этой теме. Новая важная информация будет заноситься в шапку.

2.08 еще не вышла, потому мануал по cli еще не написан до конца. А в web подобное врядли кто будет дописывать.

У нас и web, и система, и cli изначально не рассчитаны на то, что будут видны реальные системные linux-интерфейсы Плюс ко всему, там не прямое отображение 1:1, например у WifiMaster0 нет аналога в системе. Потому так все и сделано. Основной вопрос - зачем нужно выводить реальные системные названия интерфейсов, кроме как "хочется"?

Хорошо, проверим.

Уже неоднократно обсуждалась эта тема: Окончательное решение вот такое:

По идее переподключится через 90 секунд.

В текущей реализации резервирования никак, это особенность реализации. Полноценный multiwan обсуждается здесь:

Заменять нужно не default-config, а startup-config.

Какой именно интерфейс вас смущает своим именем?

Текущий wan.d срабатывает при переходе default route с одного интерфейса на другой, при появлении интерфейса с default route, или его пропадании (в случае если он был единственным).

Некоторая порция исправлений внесена в 2.08.A.11.0-2, просьба всем протестировать.

Попробуйте самую последнюю версию 2.08.A.11.0-2, по идее обе проблемы должны быть решены.

Пока всего один голос, этого откровенно мало, чтобы добавлять его на все устройства всем юзерам. Подождем, нужно ли это еще кому-то, или всем достаточно encfs.

Пока эта функция не реализована, хоть и есть в отдаленном плане.

Именно в wan.d - нет, но есть возможность создать еще один хук с состояниями интерфейсов в случае интереса. Опишите, что такое для вас "упал"? Был административно отключен (например командой interface down)? На Ethernet интерфейсе пропал линк? У PPP упало PPP-соединение? С интерфейса ушел default route? Это все разные вещи с точки зрения NDMS.

А ничего, что это вообще-то очень сомнительное с точки зрения закона и правоохранительных органов действие?

Возможности поменять нет. Я указал вам комаду для использования snmpwalk с TCP. Она не работает?