arbayten

например, колбасные обрезки с китайских столов: https://github.com/cristiklein/ralink/blob/master/include/oid.h без педалей оно не очень, но хотя бы OID_802_11_STATISTICS помогло бы пользователю при первичном осмотре. ок, без ppe, но все же: https://forum.keenetic.net/topic/348-snmp-мониторинг/?page=7#comment-28495

заодно бы узнать будет ли SNMPv3 с (D)TLS после реализации пользовательского PKI, где все остальные доступные OID и почему учет при PPE (и каком) вроде некошерен.

WSD, безусловно, лишним не будет, т.к. по слухам - идет на замену NBT. Но не поправив NBT - останутся за бортом пользователи на XP и 2003 (пусть и без поддержки, но все же). А на W10 NBT никуда не делся, все есть: > net config redirector Опять же: > nbtstat -A ip_роутера -> вылезает Адрес платы (MAC) = 00-00-00-00-00-00, хотя если так же посмотреть любой другой клиент, то его мак в этом поле при нем. Так-то, на мой взгляд, поправив NBT и порт из самбы для обычного пользователя будет лишним, а так хорошо, что есть в Entware.

Домашний пользователь еще всегда может добавить столбец "Метод обнаружения" в сетевом окружении и все увидеть:

поклёп на светоносную винду я ощущаю. LLMNR - для резолва для простого пользователя, который хотя бы имя роутера помнит из настроек, для дискавери все же целый набор: https://msdn.microsoft.com/en-us/library/windows/desktop/aa363906(v=vs.85).aspx "К" здесь вроде только анонсы на 138-й отсылает. NBNS на 137-й от К я не замечал (м.б. плохо смотрел, т.к. анонс каждые 30 сек для меня означает, что NBNS на К никто не слушает, а цель в том, чтобы просто попасть анонсом BROWSER в 30-секундное окно после выборов мастера), так что вполне вероятно - как одна из причин почему nbtstat -r показывает разное количество разрешенных и зарегистрированных (и почему со временем К может исчезнуть из списка мастера), но все же да, из-за разнообразия дискавери в W нельзя сказать определенно. Вырубать все "лишнее" оставляя на W дефолтные окна для анонсов для пользовательских сценариев с разным парком осей и отлавливать трейсы, чтобы проверить догадку - лень, очень лень. А так всегда можно посмотреть примерную механику во времени и относительную взаимозаменяемость BROWSER и NBNS в рамках "вечных выборов": https://www.cloudshark.org/captures/c7f6f8041f0c

wmp -> поток -> включить потоковую передачу мультимедиа

энтерпрайз-корпораты, наверное, чаще "дрочат" в cisco-like cli с полной гибкостью и знанием технологий (и чтения одного только конфига при этом им достаточно) -> совсем не то же самое, что в консоли по конфигам в разных местах + им не в кайф "это" делать постоянно с одной и той же железкой (вот новую довести до оргазма под конкретные условия - это своего рода челендж) + у них обычно все настроено настолько идеально, что свободного времени на анализ до одного места и трапы приходящие от snmp воспринимаются как праздник и зарядка для ума, а графики с порно на любой вкус всегда под рукой в любом разрезе и на чем угодно (и без доступа к конкретному оборудованию), так что им до фени - есть гуи или нет - когда все работает ожидаемо для них -> как бы, все же, бывают и такие.

на К: more proc:net/arp на W: ipconfig /all arp -a -v

т.е. на уровне протокола у W10 все получается очень избирательно с реализациями под L/U и при этом одну из ошибок можно решить за пару часов (не внося изменения в W10), ага. не, я понимаю, транслируется та мысль, которая удобна для картины мира (порой бессознательно) ... имхо, главное, не увлекаться.

вопрос на логику: что не так с W10, если она нормально работает с Ubuntu, Samba из Entware итп. и не очень с NQ на К? p.s. и это если не брать во внимание сценарии нарочного искажения сути.

я учитываю, что роутер не предоставляет возможности фрагментировать и собирать ip в любых направлениях и вероятный mss в 1310 в обе стороны, что не должно быть проблемой для работы с указанным ресурсом.

я ведь не говорил, что Вы ошибаетесь. pmtud упрется в mtu, выставленный по направлению на том же pptp0 (или как правильно), так что tcp клиента подстроится и выставит нужный mss ... udp обычно мелкие пакеты, так что с этим проблем чаще всего не бывает ... я имел ввиду, что автоматика pmtud, скорее всего, не спасет, если mtu на подобном интерфейсе (с плавающим оверхедом) будет завышен.

там вроде проблема в том, что pmtud на icmp внутри pptp будет ошибаться на 4, т.к. не учитывает seq. и ack. nmbrs на разгоне, поэтому автоподстройка ... ф.з., те же M$ решили не париться и ставят mtu на такие линки в 1400.

по идее расчетный должен быть: 1492-16-4-20=1452

тогда точно справитесь с самым простым вариантом на дачной ультре из серии: interface Home ip mtu <правильная_цифра> (или как называется бридж); на всякий случай перезапустите сетевые интерфейсы клиентов (чтобы скинуть старый mtu); если будет под рукой, например, W, то проверите, чтобы от бриджа клиент получил переопределение mtu: netsh interface ipv4 show subinterfaces и при таком подходе при внешнем обращении к хосту камеры - L4 подстроится в т.ч. без лишних движений.

изменять пингом? для pptp зондирование icmp вроде как вопрос с подвохом но все же - какие результаты?

=) тут подробнее и со всеми нюансами: http://afar.net/fresnel-zone-calculator/ а с java еще и посчитаете все для мачты с учетом всех "яблонь" на пути

запасное колесо видимо

хотя бы один днс оставить ... или ip host

(утрируя) при осуществлении атаки на сервис еще желательно блокировать диапазон 213.59.252.0/22

ну, пока не попробуешь - не узнаешь =) ... можно попробовать сгладить поставив туннель на tcp, но тоже не самая лучшая идея

вроде чтобы не дробило сильно как раз и используем: sndbuf 0 rcvbuf 0 fragment 0 mssfix 0 остальной сэтап учитывает: т.е. клиенты вроде на стандартном MTU.

просто тут такое дело: https://community.openvpn.net/openvpn/wiki/Gigabit_Networks_Linux и понятно, что с openssl м.б. что-то попробовать решить (интересно): https://forum.lede-project.org/t/hardware-crypto-for-mediatek-missing/3314/19 https://forum.lede-project.org/t/hardware-crypto-for-mediatek-missing/3314/27 не то чтобы я спешил и не мог посмотреть базовые твики для буферов: https://wiki.openwrt.org/toh/d-link/dir-860l#supported_versions мне кажется, что у OVPN на наших хороших железках гораздо бОльший потенциал.

блин, если честно, я уже хотел забыть об этом. что беспроводная сеть де-факто в зоопарке клиентов под нагрузкой может работать на уровне линков 65 Mbps независимо от того, что в покое идут красивые цифры на phy ... даже если максимально возможно решить вопрос с покрытием ... все равно на apcli шум в -85 и растет и колбасит под нагрузкой ... usb3 это в режиме usb2 шумит и/или отключен energy detection в cca, чтобы у большинства были всегда хорошие скорости на tx от ap на всегда зеленом свете при питании от провода и чего еще угодно - мне не диагностировать - только вижу у себя ахтунг в модуляции до 16-QAM под нагрузкой на всех линках от обратной связи неизвестной природы -> а потом будем еще управляющие фреймы рассматривать, а там уже могут быть косяки со стороны дров клиентов и один фиг удобно не подстроить ... если кратко, то все это такой геморрой и хорошо если таких проблем у большинства нет.