vasek00

Ни какого отношения к служебному трафику не имеет. Может используемые вами WEB адреса - подозрение. https://a.pr-cy.ru/aids.gov/ пересылка на https://www.hiv.gov/

т.е. нагрузить проц роутера

Рассмотрю на одном примере - LG (2015года) UF95хх на базе ARM CA57 Quard Core c 1MB L2 кешем (роли какого года не играет, принцип один и тот же как и у многих производителей). Проц имеет несколько прямых выходов USB портов, к одному подключается USB-Wi-fi адаптер для его работы нужен драйвер, для LAN порта например стоит RTL8201F для его работы нужен драйвер подключен через RMII ( режим работы 10/100Мбит/c, частота синхронизации 50МГц). Основная функция проца это не работа с сетью, а декодирование видео потока и вывода данного потока на матрицу экрана + разные "плюшки" при обработке данного потока, для этого так же есть библиотеки (которые часто-то и дорабатываются). Что там и как внутри проца и какие либы используют разработчик это ведомо им. Согласно инструкции к ТВ (которая выше была скрином) разработчик гарантируют например потоки до 20Мбит для 1980х1080х30/60 для 4K потоки 60/80Мбит. Так же помним что USB2 в теории это 480Мбит, а в данном случае LAN это 100Мбит. "Плеер ТВ" это приложение которое написано разработчиком и в данном случае он считает что данный формат будет с проблемой воспроизводиться на ТВ по LAN сети. Так что на счет кто виноват вы не правы, так как есть железо с определенными параметрами и эти параметры разработчик написал в инструкции к данному ТВ. Так же в инструкции написано какой срок работоспособности дается на данный аппарат разработчиком. Есть еще пример плеер IconBit 2011 года разработки 1GB LAN порт и встроенный винта SATA, в свое время тянул любые потоки так как мощи проца хватало на данное время по DLNA так и по HDMI (имеет выходы USB, аналог ТВ только без матрицы для которой нужно было бы формировать высоко скоростные потоки данных), но в настоящие время например будет тупить при потоках выше всего то 120Мбит даже если просто как DLNA использовать. Доработка SmartHub это на сетевые драйвера не влияет. По поводу прошивки в данном случае ни какого лукавства нет, да она 2016 года, но если например они меняли сервер обновления и заливали прошивки заново то дата будет другая (не однократно встречал такие вещи по прошивкам).

Проблемы с сетью, не видел использую привязку по MAC с конкретным IP, DLNA отлично определяется как по LAN так и по Wi-fi (5GHz), всегда получает один и тот же IP, для дома и ТВ наверное уж можно было стат IP прописать. Проблемы с сетью, если посмотреть данный форум, то можно так же найти проблемы с DHCP, только тут сервер а в ТВ клиент.

Да хоть 2011 года и с поддержки сняты, LAN порты в ТВ часто отдельный чип стоит для LAN -> для этого нужен драйвер, что ж в нем такого чтоб проблему давал или что в нем такого надо сменить ?. Второе данные ТВ имеют инструкции в которой скорей всего должно быть написано формат поддержки видео - поддержку mkv, mpeg4, avi но не кто не написал какой битрейн или профиль данных файлов. Третье все последующие обновления для ТВ думаю не затрагивают LAN часть а только доработки в обработке видео сигнала. Четвертое для данного ТВ - https://www.samsung.com/ru/support/model/UE32ES6307UXRU/ последняя прошивка на сегодня это "Версия 2008.0 : All OS 2017-10-12" к слову, хотя у вас конечно думаю данная версия и стоит. Имея роутеры Keenetic - можно было снимать снифер с LAN порта, второе поставить Mediatomb и т.д, есть один ТВ 2011 года по LAN работает (поддержка снята давным давно), DLNA есть и так же ОК.

Наговоры это на Sams, проверял на днях 4К подключенный по локалке 100Мбит - "4K Warcraft (2160p h265).mkv (56.85 GB)" при видео потоке 60.6 Мбит/с + две дорожки звука 640К и 4834К = ~65-70Мбит. ТВ к КN1010 LAN через DLNA и к диску по USB3 (чтение с данного винта 100-110MB) - ни одного замирания на данном фильме (от начала и до конца), так же смотрел и другие фильмы,были и другие фильмы, так же до 100Мбит все ОК. Если пики выше 100Мбит или поток фильма 70 плюс звук то лучше 5GHz так же без проблем. Так что наговоры это.

Не знаю конечно что за баг и что там описывалось, но если 192.168.1.1 - говорит о конфликте IP то о какой активной записи может идти речь.

Проблем не вижу

2.13B101 на странице "Нome VLAN" - раздел "Профиль доступа для незарегистрированных устройств" выбрать профиль "Без доступа в Интернет" и потом проверить данные настройки в конф файле роутера разделы любое устройство использует интерфейс "Home" => делается запрет "policy Home deny" и "default-policy deny" но разрешается зарег.которые имеют MAC - "host MAC_зарег_устройства permit".

Не много не понятно по данному логу, не стыковка с описанием или роутер считает что подключается WDC WD32 Сделайте проще, отключите все USB, дайте загрузиться роутеру, потом подключите док станцию, подождите 1 минуту и сохраниет self-test файл. В нем найдите по времени (в лог части) данную процедуру подключения и покажите ее.

Не много не понял фишку при схеме NAS---1GB----Asix_USB-ExtraII----5GHz----Клиент Клиент не видит DLNA от NAS но видит на ExtraII, релиз 2.13A5ххх на последней так же. Подозрения проход на пакетов 239.x.x.x. Помимо DLNA так же и SMB не видно NAS. При включении NAS на LAN порт все встает на места interface CdcEthernet0 rename Asix description "Asix USB-LAN" usb device-id 2001 4a00 security-level private ip dhcp client dns-routes ip dhcp client name-servers ip dhcp client displace Home ip global 900 up interface Bridge0 rename Home description "Home VLAN" inherit FastEthernet0/Vlan1 include Asix include AccessPoint include AccessPoint_5G ... security-level private ... up cdc_br0 Link encap:Ethernet HWaddr хх:хх:хх:хх:хх:60 inet6 addr: хххх::хххх:хххх:хххх:хх60/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:689917 errors:0 dropped:0 overruns:0 frame:0 TX packets:1475113 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:460794836 (439.4 MiB) TX bytes:1981366016 (1.8 GiB) eth0 Link encap:Ethernet HWaddr хх:хх:хх:хх:хх:60 inet6 addr: хххх::хххх:хххх:хххх:хх60/64 Scope:Link UP BROADCAST RUNNING MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) bridge name bridge id STP enabled interfaces br0 8000.хххххххххххх no eth2.1 cdc_br0 ra0 rai0 В остальном все работает. Возможная причина, система по WEB понимает данный интерфейс как WAN и ставит парамерт "global" и в резерв.

Осталось только в логах посмотреть что данный ORICO (внутри USB <-> SATA) определился системой

Не однократно делал opkg update -->> opkg upgrade проблем нет с ssh при следующем условии :

100Мбит - РТ

В DNSCrypt = ['cloudflare', '....', 'adguard-dns', 'yandex'] и в текущий момент времени Повторюсь он в связке с dnsmasq.

Это хорошо или плохо?

И с завернутым 53 портом

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

Клиент все запросы отправляет параллельно на google dns - это как это? т.е. на реальном скрине экрана speedtest отправил два каких то запроса один по DNS роутера (так как клиент его получил) и параллельный на DNS Google для получения IP для рекламного блока. Придется посмотреть про механизм - "AdMob реклама в Android приложение" и про "Google AdWords" и реально пощупать проход.

Блокировка по черному списку доменных имен и без направления на 53 порт происходит. т.е. перехватом пакетов на 53 порт вы избавились от рекламы google в приложениях приложениях например которые ниже

Наверное я чего-то не догоняю в чем фишка. Имеем Android клиента и на нем сервис один/два имеют запрос к 8.8.8.8:53 и 8.8.4.4:53, тогда имеем два варианта прохода данного запроса например "mtalk.google.com" или "mobile-gtalk.l.google.com" и т.д.: Клиент Android -- запрос -->-- 8.8.8.8:53 -->-- Интернет Клиент Android -- запрос -->-- 8.8.8.8:53 -->---Черный_ящик-->-- Интернет Где черный ящик "отлавливает" запросы 53 порта и перенаправляет их на какой-то сервис для обработки и далее в интернет. Вопрос в чем разница прохождения данного запроса, если ответ будет получен клиентом в любом случае?

Для простоты кто мешает запустить второй сервис для IPv6 dnscrypt-proxy --local-address='[::1]:53'.... в итоге будут запущены два сервиса "dnscrypt-proxy"

Конечно нет, кто хочет из домашних пусть ставит хоть 8.8.8.8 хоть что угодно со всеми вытекающими, речь идет о домашней сети в настоящие время желающих нет пока. Заблокировать публичные DNS без проблем в одно действие без iptables так же, только не вижу в этом смысла для домашних клиентов.

Ни куда не чего не добавлял из правил iptables. / # netstat -ntulp | grep dns tcp 0 0 127.0.0.2:65053 0.0.0.0:* LISTEN 748/dnscrypt-proxy tcp 0 0 192.168.1.1:53 0.0.0.0:* LISTEN 744/dnsmasq tcp 0 0 fe80::xxxx:xxxx:xxxx:xxxx:53 :::* LISTEN 744/dnsmasq udp 0 0 192.168.1.1:53 0.0.0.0:* 744/dnsmasq udp 0 0 127.0.0.2:65053 0.0.0.0:* 748/dnscrypt-proxy udp 0 0 fe80::xxxx:xxxx:xxxx:xxxx:53 :::* 744/dnsmasq / # В данном случае просто dnsmasq слушает все что летит на 53 порту. Хорошо ну не используете dnsmasq тогда кто мешает запустить dnscrypt-proxy на прослушку 53 порта в конфе ## List of local addresses and ports to listen to. Can be IPv4 and/or IPv6. ## To only use systemd activation sockets, use an empty set: [] listen_addresses = ['127.0.0.1:53'] ну или из команды запуска например для dnscrypt-proxy --local-address=127.0.0.1:53 dnscrypt-proxy --local-address='[::1]:53'....