Телевизор я включал один раз, утром, минут на десять. Потом выключил пультом и больше не трогал. За следующие сутки он обратился к 172 разным доменам — среди них компания, которая занимается распознаванием картинки на экране.
Нашёл я это не специально. Просто включил на домашнем роутере файловый журнал DNS-запросов и оставил на выходные. За 39 часов набралось 106 875 запросов от восьми устройств. Ниже — как это поднять у себя за вечер, полные команды, и что показали цифры по каждому прибору в квартире.
Зачем это вообще нужно
Любое устройство, прежде чем куда-то подключиться, спрашивает у DNS-сервера адрес по имени. Если DNS-сервер свой, в журнале видно каждое такое имя: кто спросил, когда и как часто. Содержимое трафика при этом остаётся зашифрованным — мы видим адресатов, но не переписку.
Для домашней сети этого достаточно, чтобы ответить на простой вопрос: с кем разговаривают приборы, когда ими никто не пользуется.
У меня уже стоял AdGuard Home на роутере с OpenWrt — как DNS-сервер для всей локальной сети с блокировкой рекламы по фильтрам. Оставалось включить журнал. Оказалось, что это не одна галка, а несколько неочевидных шагов.
Почему на роутере, и в чём сложность
Отдельной машины под домашние сервисы у меня нет, а роутер работает круглосуточно. Логичное место.
Проблема в объёме. Вот что показывает свободное место:
root@OpenWrt:~# df -h Filesystem Size Used Available Use% Mounted on /dev/root 5.3M 5.3M 0 100% /rom tmpfs 242.5M 231.8M 10.7M 96% /tmp /dev/ubi0_2 44.0M 28.8M 12.9M 69% /overlay overlayfs:/overlay 44.0M 28.8M 12.9M 69% /
Раздел /overlay — это всё пользовательское пространство роутера: 44 МБ, из них свободно 12.9. Журнал DNS на живой домашней сети растёт примерно на 5 МБ в сутки. Через двое суток он забьёт раздел и положит систему.
Раздел /tmp живёт в оперативной памяти и стирается при перезагрузке. Как раз в нём AdGuard Home по умолчанию и работает — то есть вся статистика существует до первого ребута.
Решение — USB-флешка. Дальше по шагам, всё воспроизводится на любом OpenWrt с USB-портом.
Шаг 1. Драйверы
В базовой прошивке поддержки USB-накопителей обычно нет. В OpenWrt 25.x пакетный менеджер сменился с opkg на apk:
apk update apk add kmod-usb-storage block-mount
Если установка обрывается с сообщением Terminated — виноват сторож памяти. У меня стоит earlyoom, и в его списке приоритетного отстрела оказались как раз apk, opkg, sed и awk. Он честно убивал установщик, чтобы спасти память.
Лечится так: посмотреть конфиг, убрать административные утилиты из списка на отстрел, оставив там только фоновые скрипты, которые не жалко перезапустить.
uci show earlyoom uci set earlyoom.main.prefer_regex='^(имя-фонового-скрипта|ещё-один)$' uci commit earlyoom && service earlyoom restart
Заодно стоит проверить, есть ли на роутере раздел подкачки. Если нет — сделаем чуть позже, он снимает эту проблему целиком.
После установки драйверов флешку надо переткнуть и убедиться, что ядро её увидело:
ls /dev/sd*
Шаг 2. Разметка
Я взял старую загрузочную флешку с двумя разделами NTFS. NTFS под OpenWrt работает медленно и требует отдельного драйвера, для журнала он не годится. Правильный вариант — один раздел ext4 на весь объём.
apk add parted e2fsprogs kmod-fs-ext4 parted -s /dev/sda mklabel gpt parted -s /dev/sda mkpart primary ext4 1MiB 100% mkfs.ext4 -F -L AGHDATA -E lazy_itable_init=1,lazy_journal_init=1 /dev/sda1
Про флаги в последней строке. lazy_itable_init и lazy_journal_init откладывают запись части метаданных: они допишутся в фоне при первом использовании. Форматирование проходит за пару секунд вместо минуты. На роутере со сторожем памяти это принципиально — в моей первой попытке mkfs работал долго и был убит ровно на записи суперблоков, оставив мне полубитую файловую систему.
Проверяем результат:
apk add lsblk lsblk -f
Шаг 3. Монтирование, которое переживёт перезагрузку
mkdir -p /mnt/aghdata mount /dev/sda1 /mnt/aghdata block detect > /etc/config/fstab
Команда block detect сама просканирует накопители и сгенерирует конфиг с идентификаторами разделов. Дальше его надо поправить — открыть /etc/config/fstab, найти секцию с нашим разделом и убедиться, что там стоит:
config 'mount' option target '/mnt/aghdata' option uuid 'c1b17845-33a9-4343-a2a3-b64603c4a2f0' option enabled '1'
Ключевое — enabled '1'. По умолчанию генератор ставит ноль, и после перезагрузки флешка не смонтируется.
Подробное описание работы с накопителями есть в документации OpenWrt.
Шаг 4. Заодно раздел подкачки
Раз флешка уже есть, стоит сразу сделать подкачку — она снимает проблему с убитыми установщиками навсегда. Размер берём примерно равным оперативной памяти:
dd if=/dev/zero of=/mnt/aghdata/swapfile bs=1M count=512 chmod 600 /mnt/aghdata/swapfile mkswap /mnt/aghdata/swapfile swapon /mnt/aghdata/swapfile
Обратите внимание: в BusyBox у dd нет флага status=progress, команда с ним просто не выполнится. Процесс идёт молча секунд пятнадцать.
Автоподключение дописываем в тот же /etc/config/fstab:
config 'swap' option device '/mnt/aghdata/swapfile' option enabled '1'
Проверка:
root@OpenWrt:~# free -h total used free shared buff/cache available Mem: 496724 165768 23696 237372 307260 42588 Swap: 524284 0 524284
Шаг 5. Самое интересное — куда положить данные
Здесь была основная возня, поэтому подробно.
Пакет AdGuard Home в моей сборке устроен так: init-скрипт при старте распаковывает бинарь в /tmp/adguardhome-bin и работает с рабочей директорией /tmp/adguardhome. То есть целиком в оперативной памяти. Для роутера с крошечным флеш-разделом решение разумное, но означает, что данные не переживают перезагрузку.
Переписывать init-скрипт целиком не хотелось. Вместо этого — bind mount: директория с флешки подставляется вместо data/ внутри рабочей папки. Сервис продолжает работать со своими привычными путями, а физически всё пишется на флешку.
Сначала копируем то, что уже накопилось:
mkdir -p /mnt/aghdata/adguardhome cp -a /tmp/adguardhome/data /mnt/aghdata/adguardhome/
Флаг -a сохраняет права и владельцев, без него сервис не сможет писать.
Дальше нужно, чтобы монтирование поднималось само при каждом старте. Добавляем блок в /etc/init.d/adguardhome прямо перед строкой procd_open_instance:
AGH_DATA_SRC="/mnt/aghdata/adguardhome/data" AGH_DATA_DST="$AGH_DIR/data" if grep -q " /mnt/aghdata " /proc/mounts; then mkdir -p "$AGH_DATA_SRC" "$AGH_DATA_DST" if ! grep -q " $AGH_DATA_DST " /proc/mounts; then mount --bind "$AGH_DATA_SRC" "$AGH_DATA_DST" \ && logger -t adguardhome "data bind-mounted to USB" \ || logger -t adguardhome "data bind FAILED" fi else logger -t adguardhome "WARNING /mnt/aghdata not mounted, data goes to RAM" fi
После этого один и тот же раздел оказывается смонтирован сразу в двух местах — так сервис не замечает подмены:
root@OpenWrt:~# df -h | grep sda1 /dev/sda1 28.3G 554.2M 26.3G 2% /mnt/aghdata /dev/sda1 28.3G 554.2M 26.3G 2% /tmp/adguardhome/data
Грабля первая: проверки, которых нет
Первую версию этого блока я написал с mountpoint -q — стандартной утилитой для проверки, смонтировано ли что-то. В BusyBox моей сборки её нет. Обе проверки молча провалились, но bind при этом остался с предыдущего ручного запуска, и всё выглядело работающим.
Обнаружилось только когда я специально снял монтирование и перезапустил сервис — вот тогда оно не поднялось.
Отсюда две вещи. Первая: проверять надо через /proc/mounts и grep, это работает везде без дополнительных пакетов. Вторая: любую такую автоматику надо проверять с чистого листа, а не по факту «вроде работает».
Проверка, что хук отработал сам:
service adguardhome stop umount /tmp/adguardhome/data service adguardhome start logread | grep bind-mounted
В логе должно появиться data bind-mounted to USB.
Шаг 6. Две настройки, без которых журнала не существует
Грабля вторая: два разных параметра
В конфиге AdGuardHome.yaml за журнал отвечают два независимых параметра:
querylog: enabled: true file_enabled: true interval: 168h size_memory: 100
enabled включает журнал вообще. file_enabled — запись в файл. У меня второй был выключен по умолчанию, и это давало очень обманчивую картину: веб-интерфейс исправно показывал поток запросов в реальном времени, всё выглядело работающим, а файла querylog.json на диске не существовало вовсе. Журнал жил в оперативной памяти кольцевым буфером и стирался.
Обратите внимание: в веб-интерфейсе параметра file_enabled нет вообще. Он правится только в конфиге.
interval: 168h — это срок хранения, семь суток. size_memory — размер буфера перед сбросом на диск.
Про буфер отдельно. По умолчанию там 1000 записей, и на спокойной сети файл может не появляться часами: я нагенерировал две сотни запросов вручную, подождал полчаса и не увидел ничего. Поставил 10 — файл появился мгновенно, но запись пошла практически непрерывно, что для флешки плохо. Остановился на 100: сброс примерно раз в минуту, износ приемлемый.
Полный список параметров есть в вики AdGuard Home.
Анонимизация
Вторая обязательная настройка — в веб-интерфейсе, раздел «Настройки → Общие настройки». Пункт «Анонимизировать IP-адрес клиента» должен быть выключен. Иначе все устройства сольются в обезличенный поток, и весь разбор потеряет смысл.
Шаг 7. Перехват запросов в обход
Часть устройств игнорирует DNS-сервер, выданный по DHCP, и ходит напрямую на публичные резолверы с зашитыми в прошивку адресами. Такие запросы пройдут мимо журнала.
Одно правило в межсетевом экране заворачивает весь 53-й порт из локальной сети обратно на роутер:
uci add firewall redirect uci set firewall.@redirect[-1].name='DNS-hijack' uci set firewall.@redirect[-1].src='lan' uci set firewall.@redirect[-1].proto='tcp udp' uci set firewall.@redirect[-1].src_dport='53' uci set firewall.@redirect[-1].dest_port='53' uci set firewall.@redirect[-1].dest_ip='192.168.1.1' uci set firewall.@redirect[-1].target='DNAT' uci commit firewall && service firewall restart
Запросы поверх зашифрованных протоколов так не поймать — они идут по другим портам и выглядят как обычный веб-трафик. Но простой DNS на 53-м порту после этого из сети не уходит.
Описание синтаксиса правил — в документации по межсетевому экрану OpenWrt.
Шаг 8. Подписать устройства
Последнее и самое нужное для разбора. В веб-интерфейсе, раздел «Клиенты», добавляем устройства с человекочитаемыми именами.
Здесь есть неочевидная деталь. Указывать надо и MAC-адрес, и локальный IPv6-адрес. Почти все мои устройства резолвили именно по IPv6, и по одному только MAC не опознавались — в журнале так и оставались строки вида fe80::f8a7:887b:7f08:bfdf.
Сопоставить одно с другим помогает таблица соседей:
ip -6 neigh show cat /tmp/dhcp.leases
Первая команда покажет соответствие IPv6-адресов и MAC-адресов, вторая — какие имена устройства сообщили при получении адреса.
Ещё одна тонкость: телефон с рандомизацией MAC-адреса всплыл в журнале отдельным клиентом. Android перегенерирует адрес при переподключении к сети, и одно физическое устройство расползается на несколько «клиентов». В карточке клиента можно указать несколько идентификаторов сразу — туда и надо сложить все известные пары.
Что стоит в фильтрах — чтобы цифры читались правильно
Один момент, без которого дальнейшие проценты можно понять неверно.
Список блокировки у меня ровно один — базовый AdGuard DNS filter, около 158 тысяч правил. Ничего экзотического, никаких агрессивных сборок.
А вот в пользовательских правилах лежат два разрешения:
@@||analytics.google.com^$important @@||report.appmetrica.yandex.net^$important
Оба домена фильтр по умолчанию блокирует, а я их явно разрешил — они нужны мне по работе. Практический эффект для этого разбора такой: часть аналитического трафика, которую AdGuard срезал бы, у меня проходит и попадает в журнал. Так что там, где ниже написано «заблокировано столько-то процентов», у человека без этих правил цифра будет выше. Особенно это касается умной колонки — у неё в топе как раз report.appmetrica.yandex.net.
Мне для наблюдения это скорее плюс: разрешённые запросы видно в журнале целиком, а не как оборванную попытку.
Методика: сначала вычесть себя
Прежде чем смотреть на результаты, важный шаг, без которого выводы будут неверными.
У меня на роутере работает прокси-шлюз со своим сторожем: он раз в минуту проверяет живость соединения, раз в полчаса обновляет список узлов, плюс регулярно опрашивает их доступность. Каждая проверка начинается с резолва имени.
В сумме это дало 46 754 запроса за 39 часов — 43.7% всего трафика сети, обращение к одному имени в среднем раз в 7.7 секунды.
Никакой сенсации тут нет: это особенность конкретной настройки, и лечится она кэшированием или работой по адресу вместо имени. Но для разбора это критично. Если смотреть на сводку веб-интерфейса не разбираясь, свои же служебные домены займут весь топ и перекроют всё остальное.
Поэтому первым делом стоит определить собственную инфраструктуру и вынести её за скобки. Дальше все цифры — без неё.
Общая картина
Восемь устройств: настольный компьютер, ноутбук, телефон, умная колонка, робот-пылесос, телевизор, стиральная машина.
Устройство | Запросов | Доменов | Заблокировано |
|---|---|---|---|
Компьютер | 48 520 | 1423 | 17.8% |
Телефон | 8 276 | 1009 | 18.2% |
Колонка | 1 731 | 36 | 0.9% |
Ноутбук | 535 | 141 | 26.2% |
Телевизор | 503 | 172 | 6.0% |
Пылесос | 476 | 3 | 0% |
Стиральная машина | 80 | 4 | 0% |
Компьютер с ноутбуком дают основную массу — это обычный веб-сёрфинг, там ничего удивительного. Интересное начинается, если посмотреть на бытовые приборы и особенно на соотношение «сколько запросов» к «сколько разных адресатов».
Колонка: раз в 43 секунды, круглосуточно
Умная колонка — самый разговорчивый бытовой прибор в квартире. 1731 запрос при всего 36 доменах: она ходит по одному и тому же кругу с медианой 83 запроса в час, то есть примерно раз в 43 секунды и никогда не останавливаясь.
Домен | Запросов |
|---|---|
| 325 |
| 323 |
| 316 |
| 287 |
| 96 |
| 95 |
| 85 |
Первый и четвёртый — рабочие интерфейсы устройства. Шестой — доставка уведомлений, седьмой — голосовой канал. А вот второй и третий — счётчик переходов и мобильная аналитика, и обращений к ним ровно столько же, сколько к рабочему API.
Третья строка — тот самый домен, который у меня разрешён вручную. На скриншоте ниже он помечен как «Разрешённые — пользовательские правила фильтрации». Без моего правила эти 316 обращений были бы заблокированы, но сама колонка их всё равно бы делала — просто не получала бы ответа.
Ночью, с часу до семи, колонка сделала 545 запросов — то есть примерно столько же в час, сколько днём. Спящего режима у неё нет.
Пылесос: три домена и швейцарская точность
Робот-пылесос оказался самым дисциплинированным устройством в квартире. Три домена за 39 часов, и всё:
Домен | Запросов | Назначение |
|---|---|---|
| 318 | облако производителя |
| 156 | брокер команд |
| 2 | хранилище файлов |
Ночью — ровно 24 запроса в час, час за часом, без единого отклонения. Интервал 150 секунд. Никакой аналитики, никаких сторонних счётчиков.
При этом за двое суток пылесос ни разу не убирался. 476 запросов — цена простого присутствия устройства в сети.
Отдельно отмечу локализацию: и API, и брокер сообщений в российском сегменте, судя по именам. Хранилище — на инфраструктуре китайского облачного провайдера.
Стиральная машина: тише всех, но с нюансом
80 запросов за 39 часов, четыре домена, все — облако производителя:
common.iot.ruic.lgthinq.com 75 objectcontent.lgthinq.com 2 ruic-common.lgthinq.com 2 common.lgthinq.com 1
Интервал около 20 минут, ночью 18 запросов, за всё время наблюдения машина не стирала ни разу. По поведению — образцовый прибор: ходит только к своему производителю, ничего лишнего.
Нюанс обнаружился в другом месте. Когда я подключал машину к сети, в журнале всплыл новый клиент с рандомизированным адресом — это оказался мой же телефон с установленным приложением производителя. И вместе с доменами облака он потянул за собой:
z-m-gateway.facebook.com www.google-analytics.com region1.app-measurement.com
То есть сама стиральная машина ходит только к производителю. А приложение для управления ею приносит три сторонних аналитических сервиса.
Телевизор: молчит ночью, но набирает 172 домена днём
Здесь всё оказалось не так, как я ожидал, причём дважды.
Первая неожиданность — ночью телевизор ведёт себя лучше всех. Два запроса за шесть часов, и те к службе времени и системе уведомлений. Колонка за то же время сделала 545, пылесос 144, стиральная машина 18.
Вторая неожиданность — что происходит днём. 503 запроса при 172 уникальных доменах. Для сравнения: у пылесоса их три, у стиральной машины четыре, у колонки тридцать шесть.
Хронология простая. В восемь утра я включил телевизор минут на десять — тогда прошло 209 запросов, это старт системы, проверка обновлений, загрузка лаунчера. Потом выключил пультом и больше не подходил.
Дальше он продолжал ходить в сеть сам:
Час | Запросов |
|---|---|
08:00 (включал) | 209 |
09:00 | 164 |
10:00 | 43 |
11:00 | 20 |
12:00 | 25 |
14:00 | 19 |
20:00 | 21 |
02:00 | 2 |
Основная масса — инфраструктура операционной системы: play.googleapis.com, android.googleapis.com, connectivitycheck.gstatic.com, mtalk.google.com. Телевизор работает на Android, это ожидаемо.
Но помимо неё в списке лежит вот что:
Домен | Кому принадлежит |
|---|---|
| Samba TV |
| Apple |
| Amazon |
| Amazon |
| Netflix |
| Netflix |
| |
| |
| Яндекс |
| ivi |
Приложения Netflix, ivi и сервисы Amazon я на этом телевизоре не открывал ни разу.
Про первую строку таблицы
Samba TV — компания, которая занимается технологией автоматического распознавания контента, ACR. Работает это так: компонент, встроенный в операционную систему телевизора, периодически снимает отпечаток изображения на экране и отправляет на сервер. Сервер сопоставляет отпечаток с базой и определяет, что именно показывают.
Ключевой момент — источник не имеет значения. Эфирный канал, стриминговый сервис, игровая приставка, флешка с фильмом, презентация с ноутбука. Распознавание идёт по картинке, поэтому видит всё, что попадает на экран.
Дальше я полез искать, откуда этот компонент взялся на телевизоре Philips. И нашёл не в статьях, а в документе самого производителя.
Телевизоры Philips выпускает TP Vision, и в её политике конфиденциальности Samba TV названа поимённо — вместе с юридическим лицом Free Stream Media Corp. и адресом в Сан-Франциско.
Формулировка там следующая. Если пользователь включает настройку «Enable Personalized Content» в разделе Privacy Center, производитель получает данные о просмотре и передаёт их Samba TV, которая на их основе показывает рекомендации и рекламу. Причём — и это отдельно указано — не только на самом телевизоре, но и на других устройствах с тем же IP-адресом. То есть на телефоне и ноутбуке в той же квартире.
Там же рядом есть отдельная настройка «Relevant Advertising», отвечающая за рекламные идентификаторы.
У других производителей та же технология называется по-своему: у Samsung — «Информационные сервисы просмотра», у LG — Live Plus, у Sony — Samba Interactive TV.
Важная оговорка, чтобы не преувеличивать. Обращение к домену означает, что соответствующий компонент присутствует в системе и активен. Согласие на передачу данных даётся при первичной настройке телевизора — и, судя по документу, на экране это выглядит как «персонализированный контент», а не как «отправлять отпечатки изображения на сторонний сервер». Свой телевизор я настраивал давно и что именно тогда нажал, не помню. Утверждать, что распознавание работает без согласия, я не берусь — но и осознанного выбора я не делал.
Где искать у себя: Настройки → Privacy Center → «Персонализированный контент», в англоязычном интерфейсе Enable Personalized Content. Рядом должна быть «Relevant Advertising». Предупрежу честно: на своём телевизоре с Google TV я этот раздел с первого захода не нашёл — меню Philips и меню операционной системы разнесены, и часть настроек производителя лежит не там, где системные. Если через меню не находится, помогает поиск по настройкам: ключевые слова «конфиденциальность», «персонализ», privacy.
И стоит перепроверять этот пункт после крупных обновлений прошивки — настройки приватности иногда возвращаются к значениям по умолчанию.
Телефон ночью
Телефон дал 8276 запросов и 1009 доменов. С часу до семи утра — 1667 запросов, то есть по ночам он тоже не спит.
Домен | Запросов ночью |
|---|---|
| 114 |
| 88 |
| 58 |
| 45 |
| 38 |
| 34 |
| 31 |
| 27 |
| 21 |
| 21 |
| 18 |
Первая строка — приложение маркетплейса, которое будит телефон 114 раз за ночь.
Вторая — федеративное обучение: телефон участвует в обучении моделей, пока стоит на зарядке и не используется. Формально данные при этом с устройства не уходят, уходят только результаты вычислений, но сеть он всё равно дёргает регулярно.
Четвёртая строка — телеметрия, приехавшая внутрь какого-то приложения вместе с чужим набором инструментов разработки. Определить, какого именно, по DNS невозможно — видно только адресата.
Что режут фильтры
За 39 часов фильтры заблокировали 10 307 запросов — 9.6% всего трафика.
Домен | Заблокировано |
|---|---|
| 4 459 |
| 923 |
| 525 |
| 429 |
| 344 |
| 341 |
| 324 |
| 266 |
| 161 |
Первая строка заслуживает отдельного внимания. Это девять разных поддоменов, к которым обращаются примерно поровну — по 480–500 раз к каждому. Такая схема обычно означает распределение нагрузки или запасные каналы: если один поддомен окажется недоступен, запросы уйдут через соседний. Суммарно на них приходится 43% всего заблокированного трафика.
Вторая строка — система мониторинга, которую разработчики встраивают в веб-приложения для сбора ошибок и метрик производительности. Она собирает данные о поведении пользователя в интерфейсе, и почти 900 обращений к ней пришло из браузера на рабочем компьютере.
Что с этим делать
Собрал практическое, по убыванию полезности.
Посмотрите настройки приватности телевизора. Это единственный прибор в квартире, который потенциально видит не свои данные, а содержимое экрана целиком. У Philips пункт называется «Персонализированный контент» и лежит в разделе Privacy Center, у других производителей — по-своему. Учтите, что найти его с первого раза может не получиться: меню производителя и меню операционной системы разнесены.
Разделяйте прибор и приложение к нему. Стиральная машина сама ходит только к производителю, а приложение для неё принесло три сторонних сервиса. Если управлять техникой можно без приложения — это заметно чище.
Отдельная сеть для приборов. Гостевая или отдельный сегмент для всего, что не компьютер и не телефон. Прямого выигрыша по DNS это не даёт, но ограничивает устройства в доступе к остальной домашней сети.
Смотрите ночные часы. Днём картину заслоняет обычный веб-сёрфинг, и разобрать что-либо тяжело. Между часом и семью утра видно ровно то, что устройства делают сами, и там уже нет случайных запросов.
Не делайте выводов, не вычтя себя. Мой прокси-шлюз давал 43% трафика и полностью перекрывал картину. Прежде чем удивляться чужой телеметрии, стоит убедиться, что вы смотрите не на собственные служебные запросы.
Итог
39 часов наблюдения, 106 875 запросов, 2605 доменов, восемь устройств. Что из этого стоило узнать:
Пылесос обошёлся тремя доменами и не позвал никого постороннего. Стиральная машина — четырьмя. Колонка ходит в аналитику ровно столько же раз, сколько по делу, и не останавливается никогда. Телевизор ночью спит крепче всех, а за сутки простоя успевает обратиться к 172 адресатам, включая систему распознавания того, что показано на экране.
Поднимается всё это за вечер и требует USB-флешки. Команды выше воспроизводятся целиком на любом OpenWrt с USB-портом, а первые интересные строчки в журнале появляются минут через двадцать после запуска.
Если запустите у себя — интересно будет сравнить, что нашлось в ваших сетях. Особенно по телевизорам других производителей.
