Le ecureuil
-
Постов
10 850 -
Зарегистрирован
-
Посещение
-
Победитель дней
634
Тип контента
Профили
Форумы
Галерея
Загрузки
Блоги
События
Весь контент Le ecureuil
-
Последние официальные, но на них из-за устаревшего на 9 лет ядра не дается никаких гарантий по работе opkg с современным софтом (собственно там вообще никаких гарантий по opkg не дается). Есть последние неофициальные, они должны вести себя лучше.
-
Если нужен стабильный отлаженный opkg - обновляйтесь до 2.08/2.09, все остальное - это боль и страдание.
-
Разработчики работают с техническими деталями проблем и снятыми диагностиками. У вас в посте их около нуля.
-
Приводите примеры. Web должен делать все нормально. -
Переходите на 2.08 / 2.09.
-
@r13 спасибо за интересную поднятую тему, мы пока думаем
-
Вы описываете свой частный случай, и не пытаетесь думать сразу о всех вариантах, в том числе о малограмотных пользователях (учитывая, что эта фича должна работать у всех по-умолчанию, мы обязаны думать о них даже больше).
-
@r13 обработка состояния tunnel source поправлена, просьба проверить на следующем релизе.
-
Давайте пока без новых команд или изменения поведения уже существующих. Это конечно возможно, но не так просто как вы думаете.
-
Не у всех и не везде винда. Например IP-камеры, NAS, и много устройств IoT не делают никаких проверок, потому нам нужно выявлять их и конфликты с ними самостоятельно.
-
Увы, не годится. В таком случае мы не сможем достоверно определить в сети ли хост, или просто статически забит в кэш и при этом в оффлайне.
-
Да, только один. Точнее можно сделать несколько, но будет работать только первый настроенный.
-
Ок, проверим.
-
Еще какие-либо идеи есть?
-
Unicast ARP хоть и стандартизован, но многими антивирусами и IDS воспринимается как "атака" или "подозрительная активность", потому сразу нет.
-
Адрес 10.70.70.10 точно отвечает на ping от 10.70.70.200?
-
Задать адрес EoIP3 статикой, а не по DHCP. Именно в этом и кроется причина всех проблем. Да и вообще, если нужен ping-check внутри туннеля, то лучше задать адреса обоих концов статикой.
-
Нет, логика неправильная. ip static - это ручное управление любым NAT, как SNAT, так и DNAT, так и вообще отключение NAT (подробности в CLI Guide). ip nat - это автоматика (в первую очередь для упрощения работы Web).
-
А oetX это точно EoIP, а не EtherIP по RFC3378?
-
Да, web стирает настройки в cli, и это не считается багом: как только вы сами полезли в cli, то считается что вы понимаете что делаете.
-
ip nat - это для "автоматики", которая вам как раз и не нужна.
-
Безынтерфейсные пока вообще без вариантов. Прикрутить не проблема, проблемы в обратной совместимости и в черезмерной перегруженности этой команды и неявном поведении в зависимости от настроек аргументов. Если мы сейчас что-то прикрутим не подумав, придется этот костыль таскать всегда, потому мы десять раз думаем перед разработкой новых команд и особенно расширением старых.
-
Web ничего не знает о новой команде, и затирает ее полностью (как и любую другую команду ip static, не относящуюся к пробросу портов). Потому если хотите выключения nat индивидуально по сегментам - настраивайте проброс портов через ip static тоже только в CLI. Больше проблем не замечено.
-
Важное замечание - этот синтаксис не работает так, как ожидается. При этом еще и включается проброс портов с сетей 192.168.0.0/255.255.252.0 на адрес интерфейса ISP, что противоречит логике. Короче, единственный рабочий вариант: > ip static <in-iface> <out-iface>
-
Сюда. Сперва ознакомьтесь в объявлениях с правилами оформления постов с отладкой. С tplink неужели даже системный журнал нельзя получить?
