IgaX
-
Posts
950 -
Joined
-
Last visited
-
Days Won
3
Content Type
Profiles
Forums
Gallery
Downloads
Blogs
Events
Posts posted by IgaX
-
-
15 минут назад, iggo сказал:
Поделитесь, какие есть
Да, по идее, для любого браузера сделать закладку, где в качестве ссылки указать а-ля:
javascript:(function(c){var a,b="Пятачок покинул здание.";try{a=document.execCommand("ClearAuthenticationCache")}catch(d){}a||((a=window.XMLHttpRequest?new window.XMLHttpRequest:window.ActiveXObject?new ActiveXObject("Microsoft.XMLHTTP"):void 0)?(a.open("HEAD",c||location.href,!0,"logout",(new Date).getTime().toString()),a.send(""),a=1):a=void 0);a||(b="Your browser is too old or too weird to support log out functionality. Close all windows and restart the browser.");alert(b)})(/*pass safeLocation here if you need*/);.. и для выхода из админки просто по этой закладке тапать/кликать (находясь на вкладке с админкой) .. проверил, работает вроде.
-
5 часов назад, Le ecureuil сказал:
Управлением сессиями в данном случае занимается браузер
А как же "больше хаков вкусных и разных"? Уже ведь было.
5 часов назад, Le ecureuil сказал:Сделать это программно невозможно, только если плагин поставите
Совершил "чудо" минутным копипастом в лоб некрасиво на href (кнопку не перекрашивал, просто продублировал "Приложения"):
Скрытый текст
Кликнул по "дублю", получил ожидаемо:
Скрытый текст
Закрыл, попробовал перейти на вкладку #security.acl:
Скрытый текст
В логе ожидаемо:
(conn: *4895338) user "logout" was not found in config, client: 78.47.125.180
Зарезервировать logout в системе и подавить для него ошибку в логе, наверное, не будет сложно. Для IE и этого не потребуется. Кнопку можно показывать в тех браузерах, где точно работает (интересно, где не сможет). В общих случаях пользователям будет достаточно.
-
1
-
-
1 минуту назад, vasek00 сказал:
Это уже пройденный этап - пользователю остается оперативно отслеживать мену порта и IP.
даже ведущие антивирусы нифига не детектяд в запаролированных архивах .. и вот, например, ovpn мимикровал на, например, 8531-й и .. эм .. скажем, превратился в "wsus over https", tls1.2 пройден, rsa под 2048, dhe под 2048 или ecdhe под 256, csr и crt шли с sha-2 .. и какие действия? и вот dpi прямо вот сразу по зубам от TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 или TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 .. а есть и выше, но перформанс .. имхо dpi даже не узнает, что там внутри нет http .. или, может, в следующей жизни =) но если по-чесноку - правоверные даже не посмотрят на 8531-й, пока не покажут, а их там вагон, где встать можно.
-
30 минут назад, vasek00 сказал:
на предмет вложенности пакета
вложенная матрешка зашифрована со всеми потрохами, при должном шифровании - сигнатуры, если и будут применены, смогут давать очень большой процент ложных срабатываний (а поток еще ведь и собрать надо). все что видно: транспортный L4 и зашифрованный до мозга костей payload со всеми вложенными .. и флаг им в руки и барабан на шею =) .. ну вот как по приложению - если только наугад по номеру порта, а его вот поменять и .. усе .. ушел под воду.
-
42 минуты назад, vasek00 сказал:
На много все проще - глубокий анализ пакетов на уровни DPI (сами данные кодированы не кодированы роли не играют они не нужны для провайдера), т.е. суть всего найти нужные "метки" в пакете по которым можно его заблокировать.
не, при секьюрном хэндшейке на лету они, скорее всего, могут ток, например, DN/CN публичного ключа (сертификата) хоста заматчить и дать RST в трубу.
при остальных правильных требованиях к шифрованию - не выйдет точечно, ток все подряд, а тут и словят =)
***
т.е. под потенциальным ударом только фронт-энд сервиса в плане удобства доступности, на уровне движа ничего им не светит. -
16 часов назад, vasek00 сказал:
Но для справки VPN сервисы могут быть блокированы - достаточно посмотреть принцип его работы и как результат
Можно ведь и грамотно все сделать. Там OVPN в принципе ничего так, особенно если фьюжн PSK с TLS.
Если особо не вдаваться в подробности, то CA разные, клиент генерирует private, при желании паролирует и хранит как зеницу ока, а не светит в паблике как если это норма (тут уже начинаешь сомневаться за будущее вообще), на основе него (private) - CSR, который отправляется туда, где его подпишет нужный CA и вернется клиенту в виде CRT .. и эти транзакции via TLS не ниже 1.2 в рамках тех же ЛК (что для сертификатов в принципе - лишнее, но на всякий).
Как бы задача сервиса сделать все так, чтобы все это было понятно, удобно и ненапряжно (желательно на полном автомате, чтобы минимизировать/исключить косяки со стороны хомо сапиенсов), а по вектору "Mellon", например, открывать возможность поднятия отдельного p2p instance на заданном порту.
А с базовыми контроллерами всегда начиналось заворачиванием в зазеркалье по диапазону ip, которые светились. А потом в их блогах читать какие они победоносные =)
При грамотной схеме им только пыль глотать.
-
47 минут назад, Le ecureuil сказал:
Потому делать на статику запрос с if-modified-since и if-none-match раз в минуту при серфинге по страницам и получать 304 вполне себе неплохое решение.
Вот, если не касаться картинок при первом открытии/рефреше страницы (это у меня бзик, что все должно быть без углов, поэтому извините если что), то основная проблема, на мой взгляд, в max-age=60 для всех *.js .. да даже не проблема, а мелкое неудобство, которое может приводить к лишним вопросам пользователя.
Вот, например, хожу я между tools.diag.js?c=25s3u и tools.components.js?c=25s3u и пока действует max-age - все берется из дискового кэша с 200 OK, т.е. Date, ETag, Expires, Last-Modified - все это не учитывается и не трогается, но /ci всегда выдает свежие конструкции.
И вот мы обновляем прошивку, например, быстро. Все завелось и взлетело, /ci стал выдавать свежие конструкции, а нужный *.js все еще под воздействием max-age и если пользователь в этот период зарефрешит, то все равно продолжит хватать ошибки в правом нижнем, если конструкции от /ci для текущих *.js непонятны.
В общем, есть предложение для *.js сделать моментальное устаревание и проверку валидацией по If-None-Match и If-Modified-Since со стороны браузера при помощи нужного заголовка в ответе Nginx:
Cache-Control: must-revalidate, max-age=0
Браузер будет проверять по ETag и Last-Modified, которые обязательно поменяются, если изменится запрашиваемый ресурс в целом или при перепрошивке (дата вроде совпадает с той, когда прошивал). Где не изменилось - все будет 304 Not Modified.
После прошивки при ребуте digest замерзнет и браузер, по идее, при загрузке/обновлении индекса провалидирует и обновит one.js на автомате вместе с остальным.
Другой старый добрый способ - это таймштамп, например, прошивки в url, например, вместо Ваших 25s3u по всем запросам. Но это там, где надо от лишних 304 избавиться и завысить max-age по максимуму оставляя возможность на обновление ресурсов (бандлами через верхний индекс) или чтобы кривые кэширующие прокси пройти или некоторым старым браузерам пургена дать .. ну т.е. .. универсальное средство.
Меня просто TTFB беспокоит, плавает даже на ресурсах при том, что роутер ничем особо не занят и нагрузки от клиентов нет .. не критично конечно но все же .. в общем, непонятно - Nginx или что поглубже.
-
8 минут назад, Le ecureuil сказал:
Какие именно команды выполняются из этого скрина не видно, потому судить рано - может этот запрос выводит список всех интерфейсов и все настройки? Тогда и 100 мс это мало.
Да вот в том-то и дело, что ничего особенного /ci не делает - иначе бы и воплей с моей стороны не было бы.
<packet ref="/"> <request id="1" ref="ndm
/ndm[update:debug_led]"> <command name="show system debug"> </command> </request> </packet> и все дела в Response: <packet> <response id="1"> <debug> <state>off</state> <alarm>off</alarm> </debug> </response> </packet> -
3 минуты назад, Le ecureuil сказал:
Ну подумать-то можно хоть немного, зачем это сделано.
Для удобства разрабов это сделано. Релиз не проверял, но там такая догадка и не прокатит.
4 минуты назад, Le ecureuil сказал:А если при перепрошивке устройства поменялись статические файлы
ETag не сойдется и Last-Modified. И пользователь все же чаще ходит по интерфейсу, чем перепрошивает роутер.
В общем, со мной в этом плане бесполезно.
-
честно еще несколько раз решрефил для чистоты эксперимента .. и мое "любимое" время ожидания от .. localhost?
Скрытый текст
и:
Скрытый текст
34 минуты назад, Le ecureuil сказал:И что в этой картине не так?
Не-не, я согласен с Арамисом. Все правильно и лучше быть не может. Все это плод моего воображения и исключительная неудача при раздаче. Непруха.
-
.. пробегаемся по "кэшу" и что, в основном, видим?
Cache-Control: max-age=60
Т.е. устаревает через 60 сек (статика .. 60 сек, не, ну, Карл!). При этом имеет приоритет перед Expires, который выставляется .. а тоже в одну минуту (но просто не работает, м.б. для legacy). Про доп.опции Cache-Control, которые могли бы в т.ч. помочь "забыть" пользователю "обновлять" "кэш" браузера каждый раз после прошивки для, например, one.js, и сделать его, пользователя, жизнь комфортной, - про это просто не говорю.
Не, есть грамотный момент, не спорю: для /ci выставляется (чтобы сразу устаревало):
Cache-Control: max-age=0
Вы, наверное, решите, что это все безумно сложно настроить, потребуются недели, месяцы и даже годы, но:
more temp:nginx/nginx.conf
И возьмем примеры по настройке кэшей в Nginx, скажем, здесь .. в поисках конструкций:
server { #... location ~* \.(gif|ico|jpe?g|png)(\?[0-9]+)?$ { expires 1w; } location ~* \.(css|js)$ { expires 1d; } #... }и
server { #... location ~* \.(?:ico|css|js|gif|jpe?g|png)$ { add_header Cache-Control "max-age=88000, public"; } #... }и вот он наш Expires (и туда же и заодно):
location ^~ /favicon.ico { return 404; add_header Ndm-Sysmode router; expires 1m; .. и вот: location ~* ^(?!(\/storage\/|storage:\/)).*\.(gif|jpg|png|css|js|ico)$ { include /etc/nginx/mime.types; default_type application/octet-stream; root /usr/share/htdocs; add_header Ndm-Sysmode router; expires 1m; итд... добавить заголовки для Cache-Control .. а .. зачем, Nginx видимо сам добавит на основе expires, не царское это дело.
И справочно (мало ли):
https://habrahabr.ru/post/204464/
http://xmlhack.ru/texts/06/doing-http-caching-right/doing-http-caching-right.html***
Как там было .. "почувствуйте нашу любоff" =) -
Например, после рефреша #web.tc общая картина выглядит так:
Скрытый текст
Эмм .. ну вы понимаете, да? как $#&%@@^*@%*#%*^%#^ и вообще для локального(!) веб-сервера.
1) HTTP/1.1 304 Not Modified .. как бы соединение все равно есть, байтики идут, digest юзается;
2) И скок их тут лишних на простом рефреше где-то в #web.tc? .. на вскидку как бы как мин. 13.Самое забавное, что memory cache то используется (а если делать через encode и data: - то, угу, всегда).
Дальше лучше ..
-
мм .. а еще в браузере можно настроить список/порядок предпочитаемых языков, о чем он потом весело сообщает каждый раз серверу:
GET / HTTP/1.1 Host: 192.168.2.1 Connection: keep-alive Cache-Control: max-age=0 Authorization: ... ... Upgrade-Insecure-Requests: 1 Save-Data: on User-Agent: ... ... Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 DNT: 1 Accept-Encoding: gzip, deflate, sdch Accept-Language: ru,en;q=0.8 Cookie: sysmode=router; _authorized=...
и как бы обычно после этого:
Accept-Language: ru,en;
- сервер и так знает в каком порядке и чем кормить.
.. но опять размышляете на тему системного(!) инпута (тайп-эф) .. для стилизации и локализации которого уже все давно придумано в т.ч. через pure JS.
.. и не видите, например, всего айсберга .. а скок ему .. годы? .. а давайте посмотрим.
-
24 минуты назад, Padavan сказал:
В сухом остатке - если вас не смущает более низкая скорость в Ookla SpeedTest на прием (если провайдер юзает шейпинг), то можно включать tx-burst смело
Нет, не особо. Просто если алгоритм подсчета более-менее универсальный, то может аукнутся в других сценариях. Я ж не придираюсь, так, по делу.
М.б. все же где-то есть неучтенное место при переходе в провод.
По идее, сниф эфира и с провода на выходе аплинка может помочь. Как вариант на комплексный, м.б. и Вам интересно будет.
-
11 минуту назад, hd44780 сказал:
В чём может быть дело?
Встроенный DLNA - норм (или Вы ему "что-то" зажимаете?). А сэлф будет? А смарт на телике - это панацея? Там все от стокового плеера зависит. IGMP Proxy - это, кхм, ближе к другому слою, но миф забавный. Minidlna .. все украдено до нас. force_sort_criteria
-
В 13.05.2017 в 10:22, Reality0802 сказал:
Соответственно приставка не работает так как у провайдера телевидения жестко привязан mac приставки. У меня вопрос, можно ли как то силами маршрутизатора подменить mac адрес клиента по принципу как это делается для интерфейсов маршрутизатора?
Если считать, что провайдер ТВ видит mac приставки, а не mac интерфейса, в который заходит, например, его провод, то пока никак.
-
и на 3d принтере замонстрячить агрессивный корпус, да с карбоновыми вставками .. ух .. и ателье по тюнингу для фанатов =)
-
крутилки вообще вещь хорошая .. согласно DataSheet на MT7612E можно все выкрутить так, чтобы даже на уровне чувствительности только высшие скорости остались .. победить Receive Adjacent Channel Rejection =) .. (или хотя бы попробовать забороть) .. а остальные дальние вне thresholds как такие ля-ля ни о чем, слабые помехи.
эх, такое шикарное железо .. ну вы поняли =)
-
Формально, чтобы OFDM не сваливался в более простую модуляцию, нам надо держать noise меньше -82 dBm .. если noise на WifiStation адекватен в плане показаний, то vga-clamp крутим пока не будет баланса между скоростью/дальностью и noise-ом, чтобы модуляция не проваливалась .. т.е. как одна из педалек поиска золотой середины в плане стабильности линка (а там их еще много =)) при наличии "помехи".
Есть другая полезная вещь, но как она используется - под вопросом. Это - Energy Detection Clear Channel Assessment (EDCCA) - не путать с EDCA (Enhanced Distributed Coordination Access). То что это есть в конфиге, в принципе, означает поддержку гибридного HCF (Hybrid Coordination Function), что в свою очередь, видимо, может подразумевать до кучи поддержку PCF (Point Coordination Function) и HCCA (HCF Controlled Channel Access), но это под большим вопросом .. поэтому формально и предположительно доступ к каналу регулируется либо через универсальный и древний DCF (Distributed Coordination Function), что добавляет веса в необходимости педалек вырезающих саму возможность Legacy, либо через более современный HCF (и да, для QoS нам бы педальки к EDCA в т.ч. помимо базовых WMM
).
Но вернемся к EDCCA - в идеальном мире этот механизм в т.ч. определяет - свободен канал или кто-то передает (тут еще тот курсовик как мин.) и в т.ч. дает зеленый свет на передачу .. все это работает в рамках Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) позволяя избегать коллизий и связанных ретрансмитов. С выключенным EDCCA мы, видимо, полагаемся только на базовый CCA (а что там помимо noise?) и Virtual Carrier Sense (ох уж эти NAV и что их вызывает) .. и как бы с одной стороны с позиции физ.линка у нас зеленый свет чаще (мы ведь всплески энергии не проверяем с выключенным EDCCA) и пашет оркестратор на базе, например, NAV (и тут такой CTS-to-self в воздухе и подбит канал на время действия), но шанс на колижн и лобовое выше (хорошо, что хоть клиенты по идее точно CCA замеряют перед своей отправкой).
В общем, если не разбирать все, то первое знакомое:
EDCCA_AP_RSSI_TH=-80
- если я правильно понимаю, то: а) такую силу сигнала считаем, что канал занят (что логично для порога сваливания OFDM в районе -82 dBm); б) по идее, на этой первой линии в т.ч. отсекаются клиенты, у которых RSSI меньше этого порога (помимо другой похожей настройки/подстройки .. что тоже логично, т.к. ну этих глухих и дальних, только время эфира занимают при передаче на низких скоростях итп. итд. .. если, конечно, нет офигенной направленной с крутой PA и LNA, чтобы достучаться, усилить и услышать).
А теперь к шуму. Если шум (который я вижу у себя, например), вдруг, посчитается EDCCA как передача, то пока генератор шума не будет подавлен, формально, по EDCCA канал будет занят (что как бы и объясняет возможную пропажу маяков - AP просто не будет их выпускать в воздух, т.к. не будет разрешения со стороны CSMA/CA).
Поэтому вопросы:
1) Когда мы сможем покрутить все сами в т.ч. по EDCCA? .. я бы, например, ~ EDCCA_AP_RSSI_TH=-70 попробовал со своим шумом на 2.4.
2) Когда мы сможем вырубить по питанию генератор шума, например, USB3?В 23.05.2017 в 15:55, Padavan сказал:когда в эфире присутствует сильная специфическая помеха, которая приводит к исчезновению AP в эфире (пропадают маячки)
Мысленный эксперимент показывает, что в плане пропажи своих маяков это имеет смысл, только с включенным EDCCA .. который если фабрично для RU - уже пока ни от чего не зависит, а не для RU (а .. Казахстан тоже цэ Европа? Нам бы список, чтобы знать кому что говорить). Может, лучше педальки? У меня почти все ответы есть.
-
5 часов назад, Roman_Petrov сказал:
@IgaX так вы не особо сторонник TX burst? Раньше же он был включен по умолчанию и вроде как ничего все было?
Я сторонник, чтобы все возможные детали раскрыть, чтобы вновь прибывшие духи поменьше головой об стенку бились =)
Опять же, если активных потребителей на единицу времени немного и все устраивает, то почему бы и не "за" для конечного пользователя, если это делает его довольным (но это все равно не отвечает на вопрос: почему на разных процах оно ведет себя по-разному). Просто всему есть цена и если, вдруг, под Rx-нагрузкой от AP Вы услышите - какого Ля со скайпом происходит на другом клиенте, - то эта настройка как один из кандидатов.
-
Ну прям все так безапелляционно. =)
Наверное, все же стоит предположить, что tx-burst не призывает ускорение за счет темной магии, а, скорее всего, питается за счет времени других потенциальных клиентов .. т.е., например, врубает вариацию RTS/CTS для монополизации канала, задирает счетчик в NAV, оставляя другим более длительные затяжки по CW и переходит на SIFS-интервал (а зачем AP PIFS в рамках burst) .. поскольку по времени этот интервал меньше того же VO AIFS1 в рамках WMM QoS .. то ощущение скорости выше .. но, вероятно, в рамках произведения burst со стороны AP до канала не достучаться и все буферизуется. А скок там burst .. наверное, в рамках Win-окна .. м.б. 64К и после него маааленькая такая возможность вклиниться со своим пакетиком и там AP снова отжигает своим burst пока патроны не закончатся. Как-то так, скорее всего.
Итого:
1) Tx-burst хорошо если активных клиентов мало .. скажем, больше одного ненасытного и по идее начнут чувствоваться лаги в определенных сценариях .. про QoS .. там видео на ТВ и одновременное что-то, наверное, виновник будет примерно ясен;
2) А если залпы burst отжигают те же 64К для своих PHY по времени ровно как часы, а TCP (а у нас с ним точно все хоккей?) не поставляет равномерно топливо в эту трубу, то стоит ли винить speedtest? .. по идее, нам нужна та тема с ядром повыше и дисциплиной не pfifo
Мы так скоро и до разбора VO, VI, BE и BK дойдем
-
1 час назад, mehrubon сказал:
или могу дополнительный 5 портовый свич поставит только для трех приставок
вот Вы как-то все свое гнете, думая, что простой 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, которые не влезли .. а там уже дальше думать
-
ох уж эти интеллигентные провайдеры: колл-центры, рвущиеся сессии, гигабиты, а про фтп-трафик шейпинг/полисинг на донышке
).
Выход из Интернет-центра
in Обмен опытом
Posted