IgaX

правда, если сделать security-level private на гостевую AP второго и интерфейс аплинка U2 в сторону второго, повернуть на no isolate-private, dhcp гостевой AP задает гейт на внутр.ип U2, приправить стат.маршрутом .. по логике пройдет, фз на практике) вроде легко

прокинуть гостевую (которая, по идее, идет как security-level protected) с U2 на второй (и чтобы еще и как репитер гостевой был, наверное, для бесшовного роуминга), чтобы со двора можно было через основной на U2, либо если тот в дауне, то через резервный свисток на втором .. не, коммерческие зухеля с zymesh тут помогут, я думаю. камера итп. на втором не проблема, ведь первый роутер в случае аплинка будет обычным клиентом для второго и смотреть из первого во второй можно и не ломая первый NAT (просто надо решить, нужно ли, чтобы подсеть второго видела подсеть первого), ну а второй NAT, наверное, в любом случае для свистка нужен, чтобы без сквозняка. идею предпоследнего абзаца не понял до конца .. видимо, где-то еще мелькает мысль о vpn-подобной архитектуре. имхо: если не хотеть всЁ, то все легко делается штатными средствами, за исключением выхода со двора в гостевую второго на основной первого с резервированием на второй, либо идти по схеме @vasek00 , т.к. рутить свисток все равно как бы нужно, чтобы второй не превратился в сквозной свисток габаритами поболее.

Угу, это следующий этап "просветления" для тети Фроси с бытовым роутером)) Например, чтобы в т.ч. призвать демона на правку бага с изменением канала на стороне WifiStation переподнятием нужных AP (наверное).

Как я понял, второй роутер у нас вместо usb-шнурка со свистком, поэтому клиентской частью на втором пренебрегаем. Плюс, можно, например, еще на втором трафик от свистка раздавать по воздуху, а на U2 цеплять через WISP, чтобы кабель не тянуть. Оптимальный вариант в любом случае зависит от того, что конкретно хочет получить ТС.

Как организовать задуманное средствами самой прошивки. Просто считаем, что второй роутер - провайдерский, а как аплинк кинуть, - это уже дело вкуса. Ваш вариант я не критикую

Если бы только резервирование, то можно было бы 4GIII оформить в другую подсеть и поднять запаску на U2 через тот же IPoE. Просто условие ТС со вторым NAT не до конца понятно.

зайти на вкладку сегменты в разделе домашней сети, кликнуть на гостевую сеть, а там глазками дальше, либо в учебнике: traffic-shape rate

а в каком направлении? (шепотом) ;))

я ж хз, мне без превьюшек оно и не надо, пока хватает скоростей с клиентских dlna питать .. но для 4К такой фокус может уже не прокатить .. так что я за развитие (на будущее). просто мне казалось, что в православном ядре )) вся грязная работа фоном на демонах (ну и там по обстоятельствам им часы и память выделяется) .. а переиндексация (не первичная) 1000 видео - оно вот так в лоб? т.е. там .. например, хэш мд5 и таймштамп, чтобы по-быстрому, не? .. про перевод на другое двигло а-ля монги не спрашиваю, не замерял скорости sqlite. да любой здравый смысл в кассу

думаете, не додумаются до чекбокса? а жор цпу оно умеет на диету ставить? ** а БД на мускуле катается?

параноиков этим не пробьешь, они сами сертификаты проверяют

своеобразный, про байки из склепа конденсаторов

Да вроде норм все программно промывается здесь в этом плане. Скорее, в фиче нет необходимости, как правильно заметили коллеги выше. Иначе бы ядро не получило свою известность за стабильность .. помимо отличной гибкости конечно, хоть и не во всем, да, да)) Критерий важный, пусть останется на совести разработчиков как железа, так и софта. Но голосовать не буду) А так это идет со времен царя гороха от проблем глюков софта и железа под нагрузкой (под которое этот софт и не всегда был заточен, да и производители не спешили обновлять дрова под выходившие в тираж железки), что приводило к падению производительности, зависанию части интерфейсов итд. Программный ребут по расписанию несколько раз в день помогал решать проблемы, если устройство продолжало жить своей жизнью, но не был панацеей. Основным бичом (особенно для wifi-модулей) было все же накопление заряда на элементах, что приводило к необходимости отключать роутер от питания для восстановления работоспособности (заряд сбрасывался). Собственно, при этом было найдено и "универсальное решение": розетка с таймером .. оно конечно не позволяло достигнуть гармонии с космосом, но зато Вы точно знали, что в случае проблем роутер не будет простаивать дОльше заданного интервала (касательно зависящих от Вас элементов инфраструктуры). Если есть сомнения - лучше розеткой с таймером, безотказно поднимет из могилы.

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

тёте Фросе, наверное, и половина компонентов не нужна, предлагаю тогда тоже убрать нафиг, и ваще, даешь спартанскую админку из пары/тройки страниц!!!

Не, в обратном направлении .. вот, например, есть у Вас отдельная AP и надо на ней, предположим, настроить доступ к админке по mac, а где его взять до физ.контакта?) я то знаю) а есть те, кто нет) и чо? отправите их микротик баить?)) короч, усе тлен

а что происходит в областях наложения зон покрытия друг на друга? вот для этого, в основном, и сделано

вот на кой это надо, если AP без клиентов и, главное, плотной передачи данных, имеет минимальную плотность излучения? Вы скорее с лестницы упадете чем ощутите негатив от AP в простое

тут кагбэ до идеала не доведено то, что должно быть идеальным по-умолчанию, не до жира

"вероятно" от "многого" зависит. если хватает для покрытия нужной зоны 30% - ставьте 30%, динамически имеет смысл подстраивать только когда относительно сильно меняется окружение, давайте еще лидары прикрутим, систему сенсоров на базе тех же wi spy dbx, подключимся к ibm watson и при этом в качестве критерия оптимальности выберем функцию минимизации площади поглощения волн объектами живой природы

угу, особенно когда клиент при выходе в эфир окажется вне зоны покрытия при 10% мощности AP

например, для настройки доступа по mac еще до физического подключения; а вообще это правило хорошего тона - показывать mac-и поднятых интерфейсов

Т.к. на аплинк mac интерфейса выводится, то соответствующая функция на передачу нужной переменной в окружение админки присутствует, новый элемент UI изобретать и вылизывать не нужно, ибо хватает из текущего набора. Вывод: по-чесноку, делов на пару минут, требуемый скилл: копипэйст. Почему идет игнор - вопрос риторический.

лучше уж на системный монитор, как хотели изначально .. либо добавить input disabled на страницах настройки #wireless.ap .. а так самое простое - открыть командную строку в той же винде и выполнить: arp -a .. и посмотреть на табличку; тот же inssider тоже даст ответы, команды cli

А nand типа вечный? Эстетика решается устройствами из серии ultra fit/cruzer fit. По опыту на флешке раньше увидишь отказ контроллера чем мертвые ячейки памяти на физическом уровне (крайнее вот еще ни разу не пришлось), а первое почти всегда легко решалось переводом контроллера в тестовый режим и перепрошивкой. Поэтому, при прочих равных, скорее роутер плесенью покроется, чем флешка от плейлиста станет невосстанавливаемой. Так что аргумент тут только один: флеш-памяти до одного места при текущем сценарии, все остальное - плач Ярославны. а по ftp клиенты не смогут забирать плейлист?