KorDen

То есть воспроизвести проблему симуляцией потери пакетов в заданном интервале так и не удалось?

Проблему можно воспроизвести даже на SSH/telnet до CLI без подключения накопителей вообще. А вот без TSMB надо попробовать...

Схема возможна. Смотреть security-level для интерфейсов VPN, isolate-private, маршруты, NAT, ACL.

Небольшой оффтоп, решил на авось глянуть, было бы забавно... Не проявляется, FW 2.0.8 (GPL-архив вроде похож на актуальный) ubnt@EdgeRouter-X-SFP-6-Port:~$ uname -a Linux EdgeRouter-X-SFP-6-Port 4.14.54-UBNT #1 SMP Wed Nov 20 11:30:55 UTC 2019 mips GNU/Linux ubnt@EdgeRouter-X-SFP-6-Port:~$ uptime 13:37:04 up 3 days, 2:46, 1 user, load average: 1.18, 1.17, 1.11

Вариантов два.. Первый, правильный - поставить управляемый свич и разрулить вланами. Стоимость управляемых свичей (гигабитных) начинается где-то от 2к, дешевле пожалуй будет купить Keenetic Start по скидкам [насколько я понимаю, у вас Lite, т.е. сеть стомегабитная], и тогда вопрос вообще можно будет закрыть как угодно. Второй, экономный - попробовать пошаманить на L3. Если на PON-терминале можно отключить DHCP-сервер, можно попробовать повесить сегмент WAN алиасом на LAN и сделать маршурт туда.. Фиг знает, насколько вообще это будет работать... т.е. терминал 100.1, на кинетике статикой 100.2 и дефолтный маршрут на 100.1, но в этот же L2-сегмент кинетик выдает свой домашний сегмент... Еще приходят на ум мысли о MAC-based VLAN, но в кинетиках наверное такое не прокатит.. Так вам надо распилить сетку не там где кинетик ведь.

Воспроизвёл проблему на WiFi. Итого, правильное описание бага: В промежутке 268697s - 335544s (3d 02:38:17 - 3d 21:16:46; 0x4010000 - 0x500FFFF) поломаны ретрансмиссии TCP. В дампе от роутера (на WifiMaster0/AccessPoint0) ретрансмиссии есть, до клиента не долетают (хотя сеть уже восстановилась). Стоит аптайму выйти за этот период - и ретрансмиссии уже летят корректно. Проявляется везде - на WiFi, LAN, WAN На уме вертится CVE-2019-11478 (хотя там про другое), но это ведь было летом, а проблему я кажется заметил раньше. Да и потом, система получается ретрансмиссии отправляет, кто их не пускает наружу?

У меня самое раннее прерывание на практике это 2:40:03. Нумерология исходит из самого позднего практического прерывания в 21:16:39

Перестаньте оправдываться Еще раз повторюсь - эта проблема возникает строго в определенной конфигурации сети (не настроек роутера, а именно девайсов за ним). Похоже "Samsung TV по 5Ghz" (конкретнее бы модель) - это еще одна из конфигураций, на которых проблема воспроизводится. Сама по себе %конфигурация% ни сколько не проблемна, но она как-то влияет каким нибудь burst'ом Если моя нумерология верна, то точный интервал 268697s - 335544s (3d 02:38:17 - 3d 21:16:46; 0x4010000 - 0x500FFFF)

Надо сфокусироваться на этом. Настройки 5Ghz дефолтные? (80mhz и тыды и тыпы)? Впрочем, наверное, единственный правильный вопрос - какой ТВ?

Не знаю зачем, но... 0000 010Y xxxx xxxx .... .... .... .... 3d02:40:03 = 268803s = 67200750j = 0x40166EE = 0000 0100 0000 0001 0110 0110 1110 1110 3d02:41:57 = 268917s = 67229250j = 0x401D642 = 0000 0100 0000 0001 1101 0110 0100 0010 3d02:44:58 = 269098s = 67274500j = 0x4028704 = 0000 0100 0000 0010 1000 0111 0000 0100 3d03:18:06 = 271086s = 67771500j = 0x40A1C6C = 0000 0100 0000 1010 0001 1100 0110 1100 TSval 68284553j = 0x411F089 = 0000 0100 0001 0001 1111 0000 1000 1001 TSval 68311805j = 0x4125AFD = 0000 0100 0001 0010 0101 1010 1111 1101 TSval 68416833j = 0x413F541 = 0000 0100 0001 0011 1111 0101 0100 0001 TSval 80923156j = 0x4D2CA14 = 0000 0100 1101 0010 1100 1010 0001 0100 3d21:16:39 = 335799s = 83949750j = 0x500F8B6 = 0000 0101 0000 0000 1111 1000 1011 0110 Пока 4 байт = 0000010{0} но есть единицы в 3 байте, либо0000010{1} и нет единиц в 3 байте...

А при помощи виндовой Realtek Diagnostic Utility длину меряет чуть ли не любой реалтек, включая встроенные. Она же кстати позволяет создавать VLAN-сабинтерфейсы в винде.

При отсутствии заземления (или иногда еще хуже - заземление есть, но уравнивания потенциалов нет) этот самый экран может сыграть еще более злую шутку. Особенно если с обоих сторон будет по всем правилам обжат коннекторами с экраном и соприкасатаься с корпусом свича. Подобные проблемы можно наблюдать у операторов с КТВ по коаксиалу (DVB-C) в домах старой постройки, особенно с газовыми плитами. Разница потенциалов между экраном приходящего кабеля и экраном ТВ в половину сетевого напряжения - запросто. В итоге получаем постоянный уравнивающий ток. Тут смотришь как лепят нынешнюю электрику с TN-C-S на бумаге и ужасом на деле (алюминиевый СИП на столбе закручен в хиленькую латунную нулевую шинку и это типа повторное заземление на новой линии, и так далее и тому подобное) - и понимаешь, что чаще всего лучше просто принимать за данность, что заземления нет.

IMHO самая надежная грозозащита - Giga/Ultra, SFP-модуль, оптический патчкорд и медиаконвертер. Разве что через 220 как-то прошибет. Без покупки Giga/Ultra - просто пару медиаконвертеров в разрыв... Если скорости максимум сотка, и учитывая, что SFP-порт в кинетике крайне всеядный и спокойно поднимает стомегабитный линк на гигабитном SFP - можно на авито стомегабитных медиаконвертеров прикупить за копейки.

Какая глубокая и точная фраза. ------ Скрам, аджайл, график релизов, (перманентно) в следующем спринте/эпике, не воспроизводится, todo, tofix... Интересно, до 30 марта найдут этот чертов сдвинутый инверсный бит, или годовщину справим... (не обращайте внимания, просто от безнадежности)

Или воспроизводится, но истинные условия не соблюдены и не определены 😩