Обсуждение MT7688AN HLK-7688A

[Алексей.]

traceroute to git.openwrt.org (46.101.214.210), 30 hops max, 46 byte packets
1 10.13.0.1 (10.13.0.1) 46.149 ms 44.930 ms 44.814 ms

Первый прыжок как раз на нужный шлюз.

Провы ныне режут саму передачу https (начальный запрос) и подставляют DNS. Статика только DNS исправит..

Если адрес известен, что останавливает прописать его в хостах? резолвить уже нечего.

root@OpenWrt:~# ping git.openwrt.org
PING git.openwrt.org (46.101.214.210): 56 data bytes
^C
--- git.openwrt.org ping statistics ---
7 packets transmitted, 0 packets received, 100% packet loss
root@OpenWrt:~# echo '8.8.8.8 git.openwrt.org' >>/etc/hosts
root@OpenWrt:~# ping -c 1 git.openwrt.org
PING git.openwrt.org (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=65 time=61.731 ms

--- git.openwrt.org ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 61.731/61.731/61.731 ms

Кроме этого можно использовать DNS over TLS, провайдеру адрес уж подменить не получится.

Без VPN ныне даже docker для сборки OpenWRT не собрать...

docker образ собираю (при наличии впн-а) с максимальным количеством подключенных пакетов, последующие сборки могут выполняться в офлайне.

 

[pvvx]

Если адрес известен, что останавливает прописать его в хостах? резолвить уже нечего.

Ну у нас

route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
10.13.3.129     *               255.255.255.255 UH    0      0        0 tun0
46.101.128.0    *               255.255.128.0   U     0      0        0 tun0
172.17.0.0      *               255.255.0.0     U     0      0        0 docker0
192.168.1.0     *               255.255.255.0   U     0      0        0 eth0
192.168.2.0     *               255.255.255.0   U     0      0        0 br-lan

После появления интерфейса tun0, т.е. после соединения с VPN и паузы, прописанной в route-delay 2.
К нему и надо прописывать route. Но оно вылазит только после соединения OpenVPN...
route add -net 46.101.128.0/17 tun0
Делать как тут < скрипт > что-то мне не нравится портить init-скрипт во всех версиях...
А с самими конфигами OpenVPN я не сильно разобрался. Там всё накручено и сИкретно - доки раскиданы по разным не стыкующимся обрывкам.

Кроме этого можно использовать DNS over TLS, провайдеру адрес уж подменить не получится.

OpenVPN через бесплатные VPN без проблем правильный DNS достает.

 

[pvvx]

В общем с одного захода с этим не разобраться:

IgnoreRedirectGateway – OpenVPN Community

community.openvpn.net

Кто-б подумал, что опции из командной строки работают в *.ovpn

 

[Stari40K]

Провы ныне режут саму передачу https (начальный запрос) и подставляют DNS. Статика только DNS исправит...

Одно к другому имеет посредственное отношение это два разных сервиса/протокола. Перед тем как обратиться по адресу https://kudato.tam, сервис dns преобразует имя в ип. А не наоборот. Именно поэтому у вас проблемы с заблокированными ип.

 

[Алексей.]

Как автоматизировать, т.е. куда вписать route add -net 46.101.128.0/17 tun0 ?

В конфиг клиента openvpn просто добавил маршрут до сети и при коннекте он (маршрут) оказывается в таблице, а после дисконнекта маршрута этого в таблице уже нет.

 

[pvvx]

В конфиг клиента openvpn просто добавил маршрут до сети и при коннекте он (маршрут) оказывается в таблице, а после дисконнекта маршрута этого в таблице уже нет.

OpenVPN подбирает за собой или закрытие интерфейса вызывает чистку в route. Я не разбирался, но так и работает.
По этому и надо встроить в скрипт "открытия" нового интерфейса, но там не один этот, а могут быть назначены и другие. Это и есть причина почему не стал туда пихать что-то, как это описано по ссылке...

 

[pvvx]

Одно к другому имеет посредственное отношение это два разных сервиса/протокола. Перед тем как обратиться по адресу https://kudato.tam, сервис dns преобразует имя в ип. А не наоборот. Именно поэтому у вас проблемы с заблокированными ип.

Все протоколы работают по IP, но разных портах. В случае с VPN имеем виртуальный IP со всеми портами... Дальше сами разберетесь.

 

[pvvx]

По этому и надо встроить в скрипт "открытия" нового интерфейса, но там не один этот, а могут быть назначены и другие. Это и есть причина почему не стал туда пихать что-то, как это описано по ссылке... OpenVPN сам чего-то в этом деле умеет, во всяком случае вызывает другие описанные закорючками команды из *.ovpn когда откроет соединение и ещё выдерживает паузу для исполнения команд передающихся к route, т.к. там тоже не всё сразу прописывается... Кароче целый заколдованный мир и как говорят "без бутылки" не разобраться...

 

[pvvx]

docker образ собираю (при наличии впн-а) с максимальным количеством подключенных пакетов, последующие сборки могут выполняться в офлайне.

Кто нибудь уже создавал docker для сборки OpenWRT с полной интеграцией Eclipse под Windows 10?
Некую такую кашу, чтобы можно было в Eclipse под Windows 10 редактировать все приложения входящие в img и пакеты?
Я пока пытаюсь собирать нечто подобное, но для NanoPi-xx с H3/H5 FriendlyWrt. Пора уже переходить на более новые чипы с eMMC и прочим...
Т.е. нужна среда разработки своих приложений тесно интегрированных в саму итоговую систему, включая kernel и прочее, и по старинке, когда идет работа с одним пакетиком уже не катит.

PS: Уже нарвался на такие подводные камушки - работа с такими объемами на современном компе приводит к быстрой деградации SSD. Один день работы и Smart SSD говорит что перезаписано от 0.5 до 1.5 Тб.

 

[pvvx]

Не понял, зачем "последующие сборки могут выполняться в офлайне"? Если docker-у дать от 4-х до 8-ми ядер, то первая сборка всего FriendlyWrt происходит за 10..30 минут, последующие значительно меньше...
Т.е. полная инсталляция с нуля (docker + всё остальное) до вываливания готового образа - это всего полчаса и идет в автомате... Это под win10, по другому не пробовал.

 

[pvvx]

Как-бы есть мысль перекинуть образы docker в RAM. Видно, что оно тормозит с SSD.
RAM на компе 64G, образы, к примеру с ubuntu18.04 для docker:

• Чистый образ c системой сборки и самими пакетами FriendlyWrt (снап): до 7 ГГб
• После первой сборки это вылезет в около 11 ГГб (+- 10 - там дурная FriendlyArm может наплодить пустые на 90% образы для eMMC по 8 Гб)
• Итоговый DockerDesktop.vhdx, если откинуть ненужные для этого дела images и контейнеры - до 30 Гб (Hyper-V под Win10 не умеет сжимать на ходу vhdx и там много бед у него с Docker... Но вроде понемногу решают...)
• За время работы первой сборки по логу с диска перезаписывается всего около 16..19 ГГб (не считая пустого образа для eMMC - его можно создать и потом, т.к. это несколько секунд).
• Для Docker выделено 4ГГб RAM, сама Win10 никогда не жаждет и не вылезает за объемы в десяток ГГб, ну кроме кеша под диски.

Т.е. в принципе всё лезет в RAM компа.
Будет ли быстрее? Кто пробовал?

 

[sharikov]

Т.е. нужна среда разработки своих приложений тесно интегрированных в саму итоговую систему, включая kernel и прочее, и по старинке, когда идет работа с одним пакетиком уже не катит.

"свои приложения тесно интегрированные в итоговую систему" - тупиковый путь! У нас на работе так сделано и тоже openWRT. Большие трудности в сопровождении. Пакетная система при длительном сопровождении продукта оптимальнее, не зря ее придумали.
Впрочем каждый вправе пройти свой путь по граблям.

 

[Алексей.]

Не понял, зачем "последующие сборки могут выполняться в офлайне"

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

 

[pvvx]

"свои приложения тесно интегрированные в итоговую систему" - тупиковый путь! У нас на работе так сделано и тоже openWRT. Большие трудности в сопровождении. Пакетная система при длительном сопровождении продукта оптимальнее, не зря ее придумали.
Впрочем каждый вправе пройти свой путь по граблям.

Каждому свои грабли. Если у вас развитый отдел ремонта и сервиса, и в цену продукции вложена замена по несколько раз пользователю, да выплата простоев по вине вашей продукции, то пользуйтесь пакетной системой.
Или видимо ваша продукция не рассчитана на работу более пяти минут.
Багов в каждом пакете OpenWRT по сотне, как и в kernel и требуется ПОЛНЫЙ пересмотр, обрезка ненужного и прочие действия.

 

[pvvx]

Большие трудности в сопровождении.

Вы думаете быстро переписать, отладить, протестировать ВСЁ в предоставляемой общей OpenWRT или прочему "open"?
И какие потом могут быть трудности в сопровождении, если у вас получается своя система? Поправил и нажал капу - новый img готов.
Единственное в этом деле - увольнение работников которые писали и знают вашу систему. Это приводит к гораздо большим временным затратам - пока там новые освоятся...
Да, это не по современному, с нормой "текучести" кадров

 

[pvvx]

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

Я про это и писал - сборка идет с уже заранее загруженных, фиксированных, а не новых. По другому и не собрать - ошибок не оберетесь и замучаетесь их исправлять.
Та-же friendlywrt фиг собирается если не загрузить то что они там предлагают "Для пользователей из материкового Китая"
используйте пакет репо из облачного хранилища FriendlyElec
4.2.1 -> http://wiki.friendlyarm.com/wiki/index.php/How_to_Build_FriendlyWrt
И всё это находится типа в Google/Яндекс.дисках, а как туда wget-ить?
Пришлось писать типа батника:

SRC_H3_DIR=e:\NanoPi\NanoPi-R1
docker build -t fwrt-base %SRC_H3_DIR%\sources\docker-fwrt-base
docker run -d --rm --name fwrt-wrk0 -v %SRC_H3_DIR%:/home/dev/extdisk fwrt-base:latest
docker exec -u dev -w /home/dev fwrt-wrk-h3 cp /home/dev/extdisk/sources/docker-fwrt-base/add-src-h3.sh .
docker exec -u dev -w /home/dev fwrt-wrk-h3 chmod -x ./add-src-h3.sh
docker exec -u dev -w /home/dev fwrt-wrk-h3 ./add-src-h3.sh
docker commit fwrt-wrk0 fwrt-h3
docker stop fwrt-wrk0

docker run -it --privileged=true --name fwrt-wrk-h3 -p 8022:22 -v d:/Docker/workspace:/home/dev/extdisk fwrt-h3:latest

 

[pvvx]

Сетевой диск в win10 нормально подключается к докеру с sshd в нутре по SSHFS-Win · SSHFS for Windows

 

[pvvx]

Я вот пока не придумал как лучше запихивать скачанные пакты из repo в создаваемый docker image.
Пока загружаю их в widows в какой директорий, потом создаю docker со средой сборки, запускаю его и копирую в него в нем-же, а далее docker commit.
И среда готова. Остается запустить итоговый контейнер и в нем build.
Какие есть другие варианты под Windows запихать в контейнер заранее скачанные пакеты на этапе его создания?

 

[Алексей.]

При сборке образа в докер-файле содержаться инструкции по сборке.
Инструкция COPY копирует в контейнер файлы/директории.

 

[pvvx]

При сборке образа в докер-файле содержаться инструкции по сборке.
Инструкция COPY копирует в контейнер файлы/директории.

Это я знаю
Но как при docker build будет работать docker copy?
Делать поэтапные image... Одно и то-же.
В самом контейнере это проще, т.к. этапов может быть сотни и оно замещается простым скриптом и подключенными volume c дисками в win-де...