IgaX

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

не, при секьюрном хэндшейке на лету они, скорее всего, могут ток, например, DN/CN публичного ключа (сертификата) хоста заматчить и дать RST в трубу. при остальных правильных требованиях к шифрованию - не выйдет точечно, ток все подряд, а тут и словят =) *** т.е. под потенциальным ударом только фронт-энд сервиса в плане удобства доступности, на уровне движа ничего им не светит.

Можно ведь и грамотно все сделать. Там OVPN в принципе ничего так, особенно если фьюжн PSK с TLS. Если особо не вдаваться в подробности, то CA разные, клиент генерирует private, при желании паролирует и хранит как зеницу ока, а не светит в паблике как если это норма (тут уже начинаешь сомневаться за будущее вообще), на основе него (private) - CSR, который отправляется туда, где его подпишет нужный CA и вернется клиенту в виде CRT .. и эти транзакции via TLS не ниже 1.2 в рамках тех же ЛК (что для сертификатов в принципе - лишнее, но на всякий). Как бы задача сервиса сделать все так, чтобы все это было понятно, удобно и ненапряжно (желательно на полном автомате, чтобы минимизировать/исключить косяки со стороны хомо сапиенсов), а по вектору "Mellon", например, открывать возможность поднятия отдельного p2p instance на заданном порту. А с базовыми контроллерами всегда начиналось заворачиванием в зазеркалье по диапазону ip, которые светились. А потом в их блогах читать какие они победоносные =) При грамотной схеме им только пыль глотать.

Встроенный DLNA - норм (или Вы ему "что-то" зажимаете?). А сэлф будет? А смарт на телике - это панацея? Там все от стокового плеера зависит. IGMP Proxy - это, кхм, ближе к другому слою, но миф забавный. Minidlna .. все украдено до нас. force_sort_criteria

Если считать, что провайдер ТВ видит mac приставки, а не mac интерфейса, в который заходит, например, его провод, то пока никак.

вот Вы как-то все свое гнете, думая, что простой switch Вам поможет грамотно завернуть мультикаст по разным портам и разным подпискам, а не получить полномасштабный multicast-flood на всех портах switch-а. в общем, вот (вроде все просто): https://help.keenetic.net/hc/ru/articles/213967709-Настройка-одновременного-доступа-в-Интернет-и-к-услуге-IPTV-через-двух-разных-провайдеров выделять downstream в отдельный "сегмент" - на вкус и цвет если igmp snooping нормально пашет (вроде не жаловались в крайнее время). так что, вперед, к победе.

будет, например, 2 порта на WAN (один из которых только для IPTV), будут 3 порта выделены под STB (и как бы все равно надо IGMP Snooping ключ на старт) .. и места под 5-6 LAN-клиентов все равно не хватит .. поэтому .. либо умного на приставки, либо попроще для LAN, которые не влезли .. а там уже дальше думать

ох уж эти интеллигентные провайдеры: колл-центры, рвущиеся сессии, гигабиты, а про фтп-трафик шейпинг/полисинг на донышке

Остальные чатлане, честно отключившие SMBv1 на клиентах и ожидающие поддержку всестороннего шифрования от SMBv3.1.1 по 445/TCP в рамках Embedded SMB/CIFS (от Tuxera? full specs), чтобы секьюрно гонять трафик в 0.0.0.0/0, наверное, уже смирились.

это, видимо, как пульт для усилка, но в dca-стиле .. чтобы на выходе мощу поднять перед передачей на следующий узел .. ламповые еще ценятся в плане сглаживания помех и прочего мусора .. там .. плохо группу слышно, поднял gain и заодно слышишь группу через дорогу если без изоляции и смотря где "звукосниматель" .. ну т.е. если в лесу и надо передачу от клиента поднять на дистанции, то норм по идее. подбирать методом тыка или цеплять под карбюратор, заводить и смотреть в таком стиле:

в общем, если обычный ethernet, то bottleneck: остается если ток поддержка Jumbo на свитче и сетевой, либо через "другой" интерфейс с клиента. посмотреть можно так на винде: netsh int ipv4 show int netsh int ipv6 show int покрасить в нужные цифры всегда можно через консоль под админом: netsh interface ipv4 set subinterface "Имя интерфейса" mtu=Значение store=persistent netsh interface ipv6 set subinterface Или_индекс_интерфейса mtu=Значение store=persistent только ими обычно в сторону уменьшения чужие косяки правят =) *** просто пинг с клиента застревает в первом горлышке до обертки и разбивки.

а mtu какой на интерфейсе, к которому комп подключается?

-> whether .. а то, вдруг, US захватим =)

Не, конечно, если глянуть интернеты, то может появиться мысль, что еще пол поколения и пользователь будет напичкан булшитом по самые гланды, а нормальные/продвинутые вообще перестанут транслировать знание в сеть, но .. опять же, почему бы не сделать удобные расширения (пусть и по моделям, как для IntelliQoS, вроде) на странице обновления компонентов .. даже в качестве мотивации - более дорогому железу - больше полезных плюшек на стоке и с удобством, а то реально выходит, что сток по нижней границе всего модельного ряда идет, а котел с ПО практически общий. Да и пользователь на данный момент не настолько глуп, чтобы не осилить инструкцию, например, согласно этой статье (а что ей мешает быть на странице настройки компонента под тем же "спойлером"?). А то упоминают про аналог NAS, про SMBv1 молчат, а юзер потом в депрессии, особенно, когда со всех сторон ему подсказывают, что это клиенты у него *овно .. психика рушится итп. .. неправильно так, вовсе ни к чему так маркетологам об юзера ноги вытирать =)

Все равно сток с SMBv1 - это несерьезно, особенно режет слух, когда начинают скоростями мериться и эта мантра: все норм, окей, офигенно итд. - сразу всех видно Кстати, даже неполный список преимуществ по версиям предполагает насколько обычные пользователи могли бы быть благодарнее (речь идет про "не opkg").

Волков бояться - в лес не ходить. Как вы всё поворачиваете в нужную сторону =) Я помню времена, когда про os/2 говорили как про безвирусное будущее и к чему все пришло?)

а еще epicscale вроде как занималась расшифровкой генома =) но мне, как и многим другим, не повезло, все это как-то прошло мимо меня

да как бы дожил до 43580 и рекламы все в упор не вижу .. т.е. один раз сделал и все

реально не проблема + комменты

О как! Чего только не увидишь, может, Вам спросить это у человека, который Вам это подсказал? =) В целом, если есть желание понять, как все примерно работает, то открываете, например, на Windows - Монитор ресурсов - вкладка "Сеть" - аккордеон "TCP-подключения" + это/это (в конце есть важная ремарка). Гоняйте свой ftp-клиент в локалке в несколько подходов, следите за номерами локальных/удаленных портов в мониторе выше (по удаленным проще поставить сортировку). В принципе, будут все ответы.

Ну, если добавить вжух к топу в виде пассивного WiFi и BT-радио для всеобъемлющего анализа RF + WIDS + WIPS в реалтайм, чтобы основные лошадки не отвлекались и не ломали кхе-кхе перформанс (до которого еще идти, просто Вы на проводе и почти не замечаете это на low-latency), то трансформер по концепции напоминал бы слегка тот же Meraki Wireless, а это нехилый value-add и мог бы претендовать на коммерческого пользователя с претензией. Но как бы нам не светит .. от слова вообще .. ответ по FCC просто добил любые надежды

На ранних билдах W10 проблема встречалась часто судя по всему, поэтому нужны подробности по клиенту с W10. Здесь описаны разные подходы (в т.ч. по ссылкам и метод с форсированием SMBv1 тоже есть). Если у ТС W10 давно, то м.б. это его случай. P.S. У меня работает с MSA (и без - c локального) на обоих клиентах с W10 по ярлыку к шаре cifs G3 из быстрого доступа независимо от капризов netbios при одинаковых настройках соответствующих веток реестра: Надеюсь, поможет. Запасная граната в виде чистой установки всегда в наличии. Удачи.

А хз Вывод Windows PowerShell под админом командами: dir \\localhost\c$ # Потом нужно успеть ввести в течение 10 сек. команду: Get-SmbConnection Говорит, что система поддерживает текущий диалект 3.1.1. Если зайти на шару CIFS и просто посмотреть в PS: Get-SmbConnection то уже будет видно, что: PS C:\WINDOWS\system32> Get-SmbConnection ServerName ShareName UserName Credential Dialect NumOpens ---------- --------- -------- ---------- ------- -------- KEENETIC-GIGA SanDisk ***********\********* MicrosoftAccount\**************** 1.5 2 Т.е. текущий клиент с W10 без бубнов согласовал SMBv1(?) и норм. Надо посмотреть примерно похожий подход на XP .. возможно CIFS не может говорить одновременно на разных диалектах. В общем, нужен дамп

а это как посмотреть .. кто был первый: smb или cifs попробуйте: https://support.microsoft.com/en-us/help/2696547/how-to-enable-and-disable-smbv1,-smbv2,-and-smbv3-in-windows-vista,-windows-server-2008,-windows-7,-windows-server-2008-r2,-windows-8,-and-windows-server-2012 в части команд: To disable SMBv2 and SMBv3 on the SMB client, run the following commands: sc.exe config lanmanworkstation depend= bowser/mrxsmb10/nsi sc.exe config mrxsmb20 start= disabled To enable SMBv1 on the SMB client, run the following commands: sc.exe config lanmanworkstation depend= bowser/mrxsmb10/mrxsmb20/nsi sc.exe config mrxsmb10 start= auto т.е. отключаете на клиенте с W10 SMBv2 и 3 и включате SMBv1 .. если это решает, то можно записать, что CIFS роутера имеет нюансы.

Ну, на XP SMBv1, на W10 уже по-умолчанию вроде 3я .. получается, что коммерческий cifs не может обслужить клиентов по разным версиям SMB? А кста это мысль.