Если стоит auto, рано или поздно нигде работать не будет.
Плюшки - ну это становится заметно если mesh нод у вас много. Они самоорганизуются, сами строят между собой маршруты, сами их перестраивают в случае чего. А sta вы прибиваете роутер к конкретной точке.
Mesh на каждом радио это то как представляют себе работу mesh, юзеры на проприетарных прошивках. Поэтому это надо объяснять еще и с точки зрения что это возможно, но есть нюансы.
Хорошо бы рассказать почему не получится подружить проприетарную реализацию easymesh с openwrt 802.11s
Еще кстати объяснить бы что mesh по проводу это не mesh. Но тут совсем сложно…
Mesh это отдельный интерфейс. Грубо говоря можно взять провод, соединить два роутера, а если провода нет, можно взять mesh. Правила по сути такие же, как если ды вы соединяли два роутера проводом. Далее ваше дело что делать с интерфейсов mesh, натить или бриджевать (со всеми вытекающими).
Из важных нюансов, хочется сказать про каналы. Если вы на физическом радио0 поднимаете mesh и ap, они оба будут использовать один и тот же канал. Нельзя получить 6 канал для ap и 11 для mesh на одном радио. Так же как и нельзя соединить две mesh ноды разными каналами.
А еще хочется сказать про stp. Можно в теории поднять по mesh на каждом радио, забриджевать все в lan, включить stp и радоваться. Только без доп пиналки типа dawn чаще всего роутеры будут соединяться по 2.4Ghz. Если автор статьи знает как сделать выбор несущей более разумным, прошу описать в следующей статье.
Пару лет как использую такие реле. Брал их часто по ~100 на али, в рубрике купи 3 вещи по 100р. У меня накопилось несколько вариантов плат и распиновок к ним. Надо было раньше вас статью писать) Так вот раньше я просто менял стоковые модули на esp. Потом в esphome завезли cb2s и прочие bk (а я использую esphome), стал писать напрямую их. А потом все чаще и чаще стали попадаться реле с распаянными прямо на основную плату мк. И по началу это решалось прошивкой (uart там тоже конечно же есть) и чуть более сложным вычислением распиновки, но потом там все чаще и чаще стали попадаться совсем неподдерживаемые esphome мк. Эти "непрошиваемые" реле у меня остались, но сейчас нет возможности посмотреть что там за мк. Короче, хотел сказать что будьте осторожны, могут попасться такие реле, а отличить их почти невозможно (ну наверное как то можно) без вскрытия.
Это не наш метод - проверим в бою. Вроде поднялось, в конверторе тоже поменял на свой TZ3000bzt33cyu. Не понял насчет второй прошивки. Надо делать? И если делать, то как? Править local_ota_index.json под новый идентификатор?
Прошивка не хотела обновляться, пока в local_ota_index.json не поменял на свой TZ3000bzt33cyu Пока шьется, посмотрим что будет. В принципе если окажется что "не та ревизия" и датчик окирпичится, не расстроюсь. Пол года работал нормально, еще пол года - постоянные отвалы и батарейка то 0, то 100.
Для ipv6 дополню. Допустим у нас ipv6 и его тоже надо обходить (единственное что, у меня для обхода ipv6 отдельный интерфейс, но я думаю направления хватит):
Создаем лист для ipv6 адресов (firewall)
config ipset
option name 'proxy_list'
option match 'dst_net'
option family 'ipv6'
Маркируем пакеты (firewall)
config rule
option name 'Mark-Proxy-for-LAN'
option src 'lan'
option dest '*'
option proto 'all'
option ipset 'proxy_list'
option set_mark '0x2'
option target 'MARK'
option family 'ipv6'
Добавляем маршрут для трафика 0x2 (network)
config rule6
option priority '100'
option lookup 'proxy'
option mark '0x2'
Добавляем маршрут для таблицы (network)
config route6
option interface 'proxy'
option target '::/0'
option table 'proxy'
Добавляем правила для доменов (dnsmasq) nftset=/chatgpt.com/6#inet#fw4#proxy_list
Хоть и решение завернуть wg в vless может показаться странным на первый взгляд, на это есть свои причины... По итогу удалось сделать следующим образом: Взял проект https://github.com/rfc1036/udptunnel. Скопмилировал бинарники для сервера и роутера. Может показаться что, зачем? Есть ведь есть socat (очень сильно режется скорость, буквально до кбит), есть udptunnel в официальных репозиториях openwrt (это не то, хоть и имеет такое же название. Более того, udptunnel из репозиториев openwrt у меня не заработал и судя по форуму openwrt, не только у меня).
На сервере: [tcp который будем слушать] [ip и udp куда нам надо переадресовать] udptunnel -S --server -v 0.0.0.0:12345 127.0.0.1:51820
На клиенте: [udp в который будем ломиться] [адрес сервера с tcp портом] udptunnel -S -v 0.0.0.0:12345 example.com:12345
По итогу такая связка заработала. Wireguard кстати на openwrt капризный, если указывать в endpoint - localhost, wg отказывается у меня запускаться. 127.0.0.1 работает. Скорость получилась 50/20 мбит против эталонных - 110/200, что мало конечно, но лично меня устраивает.
Столкнулся с проблемой. Предыстория - дачный роутер перестал подключаться по Wireguard к городу. Решил завернуть трафик WG в VLESS. Поставил sing-box на роутер, поднял VLESS - тут ок, никаких проблем. Пытаюсь поднять WG через tun от sing-box, все по мануалам выше. Коннекта нет. Почему то tun ни в какую не пропускает udp. Решения не нашел.
Я тоже заметил что некоторые устройства, например друзей приходящих в гости, отображают хоть и подменный, но постоянный мак адрес. Хотя глубоко в вопросе не разбирался. Спасибо что поделились наблюдениями)
Так можно сделать, но проблема в том что невозможно именно сделать template device_tracker, просто в HomeAssistant нет такого типа template. А именно device_tracker нужен был мне для красивого отображения в интерфейсе, и привязки к аккаунта пользователя, к которому тоже невозможно привязать что либо кроме device_tracker.
Я видимо плохо объясняю, а вам видимо нужно пройти весь путь самостоятельно.
Еще кстати, раньше по крайней мере, был нюанс что при такой схеме если забриджевать все в одну сеть, от sta dhcp не работал.
Если стоит auto, рано или поздно нигде работать не будет.
Плюшки - ну это становится заметно если mesh нод у вас много. Они самоорганизуются, сами строят между собой маршруты, сами их перестраивают в случае чего. А sta вы прибиваете роутер к конкретной точке.
Честно говоря одна из самых скотских ИТ специальностей. А еще уровень токсичности в профессии запредельный.
Mesh на каждом радио это то как представляют себе работу mesh, юзеры на проприетарных прошивках. Поэтому это надо объяснять еще и с точки зрения что это возможно, но есть нюансы.
Хорошо бы рассказать почему не получится подружить проприетарную реализацию easymesh с openwrt 802.11s
Еще кстати объяснить бы что mesh по проводу это не mesh. Но тут совсем сложно…
Mesh это отдельный интерфейс. Грубо говоря можно взять провод, соединить два роутера, а если провода нет, можно взять mesh. Правила по сути такие же, как если ды вы соединяли два роутера проводом. Далее ваше дело что делать с интерфейсов mesh, натить или бриджевать (со всеми вытекающими).
Из важных нюансов, хочется сказать про каналы. Если вы на физическом радио0 поднимаете mesh и ap, они оба будут использовать один и тот же канал. Нельзя получить 6 канал для ap и 11 для mesh на одном радио. Так же как и нельзя соединить две mesh ноды разными каналами.
А еще хочется сказать про stp. Можно в теории поднять по mesh на каждом радио, забриджевать все в lan, включить stp и радоваться. Только без доп пиналки типа dawn чаще всего роутеры будут соединяться по 2.4Ghz. Если автор статьи знает как сделать выбор несущей более разумным, прошу описать в следующей статье.
Пару лет как использую такие реле. Брал их часто по ~100 на али, в рубрике купи 3 вещи по 100р. У меня накопилось несколько вариантов плат и распиновок к ним. Надо было раньше вас статью писать) Так вот раньше я просто менял стоковые модули на esp. Потом в esphome завезли cb2s и прочие bk (а я использую esphome), стал писать напрямую их. А потом все чаще и чаще стали попадаться реле с распаянными прямо на основную плату мк. И по началу это решалось прошивкой (uart там тоже конечно же есть) и чуть более сложным вычислением распиновки, но потом там все чаще и чаще стали попадаться совсем неподдерживаемые esphome мк. Эти "непрошиваемые" реле у меня остались, но сейчас нет возможности посмотреть что там за мк. Короче, хотел сказать что будьте осторожны, могут попасться такие реле, а отличить их почти невозможно (ну наверное как то можно) без вскрытия.
Эх, сейчас бы снова XIP пересобирать.
Просто совет для тех кому в конфиг sing-box сложно. Бейте секции на отдельные json и делайте merge в один.
Пользуюсь случаем, хочу сказать какая-же отстойная у sing-box документация
Спасибо, вторая пошла шиться. Добавьте тогда bzt33cyu что ли в список поддерживаемых.
Это не наш метод - проверим в бою. Вроде поднялось, в конверторе тоже поменял на свой TZ3000bzt33cyu.
Не понял насчет второй прошивки. Надо делать? И если делать, то как? Править local_ota_index.json под новый идентификатор?
Прошивка не хотела обновляться, пока в local_ota_index.json не поменял на свой TZ3000bzt33cyu
Пока шьется, посмотрим что будет. В принципе если окажется что "не та ревизия" и датчик окирпичится, не расстроюсь. Пол года работал нормально, еще пол года - постоянные отвалы и батарейка то 0, то 100.
Интересно, а батарейку начнет адекватно показывать наконец?
Для ipv6 дополню. Допустим у нас ipv6 и его тоже надо обходить (единственное что, у меня для обхода ipv6 отдельный интерфейс, но я думаю направления хватит):
Создаем лист для ipv6 адресов (firewall)
config ipset
option name 'proxy_list'
option match 'dst_net'
option family 'ipv6'
Маркируем пакеты (firewall)
config rule
option name 'Mark-Proxy-for-LAN'
option src 'lan'
option dest '*'
option proto 'all'
option ipset 'proxy_list'
option set_mark '0x2'
option target 'MARK'
option family 'ipv6'
Добавляем маршрут для трафика 0x2 (network)
config rule6
option priority '100'
option lookup 'proxy'
option mark '0x2'
Добавляем маршрут для таблицы (network)
config route6
option interface 'proxy'
option target '::/0'
option table 'proxy'
Добавляем правила для доменов (dnsmasq)
nftset=/chatgpt.com/6#inet#fw4#proxy_list
Хоть и решение завернуть wg в vless может показаться странным на первый взгляд, на это есть свои причины... По итогу удалось сделать следующим образом:
Взял проект https://github.com/rfc1036/udptunnel. Скопмилировал бинарники для сервера и роутера.
Может показаться что, зачем? Есть ведь есть socat (очень сильно режется скорость, буквально до кбит), есть udptunnel в официальных репозиториях openwrt (это не то, хоть и имеет такое же название. Более того, udptunnel из репозиториев openwrt у меня не заработал и судя по форуму openwrt, не только у меня).
На сервере: [tcp который будем слушать] [ip и udp куда нам надо переадресовать]
udptunnel -S --server -v 0.0.0.0:12345 127.0.0.1:51820
На клиенте: [udp в который будем ломиться] [адрес сервера с tcp портом]
udptunnel -S -v 0.0.0.0:12345 example.com:12345
По итогу такая связка заработала. Wireguard кстати на openwrt капризный, если указывать в endpoint - localhost, wg отказывается у меня запускаться. 127.0.0.1 работает.
Скорость получилась 50/20 мбит против эталонных - 110/200, что мало конечно, но лично меня устраивает.
Столкнулся с проблемой. Предыстория - дачный роутер перестал подключаться по Wireguard к городу. Решил завернуть трафик WG в VLESS. Поставил sing-box на роутер, поднял VLESS - тут ок, никаких проблем. Пытаюсь поднять WG через tun от sing-box, все по мануалам выше. Коннекта нет. Почему то tun ни в какую не пропускает udp. Решения не нашел.
Я тоже заметил что некоторые устройства, например друзей приходящих в гости, отображают хоть и подменный, но постоянный мак адрес. Хотя глубоко в вопросе не разбирался. Спасибо что поделились наблюдениями)
Да, просто отключаю для домашних сетей.
Так можно сделать, но проблема в том что невозможно именно сделать template device_tracker, просто в HomeAssistant нет такого типа template. А именно device_tracker нужен был мне для красивого отображения в интерфейсе, и привязки к аккаунта пользователя, к которому тоже невозможно привязать что либо кроме device_tracker.