[Гость Sterr]

Как в скрипте включить или выключить третий светодиод (vpn)? Просто он не используется, хочу на пингер посадить

[sfstudio]

Смотреть команду gpio.

 

Раскладку GPIO можно в конфиге ядра посмотреть. Для разных девайсов ессно разная.

[Гость sterr]

Имеется в виду 7620 rev m Смотрел в скриптах, но там при ините все кажется включаются. А где wan включается, не нашёл.

[sfstudio]

В git лежат исходники включая конфиги ядра, там задана раскладка GPIO, на память я их не помню, берите - смотрите. Для того они и публикуются.

[Sterr]

копал, копал, ничего не выкопал. методом научного тыка родил для SNR-CPE-W4N-MT-3.5.6.RU.30092015 :

 

/etc/crontab/Admin

SHELL=/bin/bash
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/etc/scripts
MAILTO=root
HOME=/

# run-parts
* */2 * * * echo > /var/log/cron.log
*/1 * * * * /etc/scripts/pingerz.sh

 

кому надо другое время, измените.

 

/etc/scripts/pingerz.sh

#!/bin/sh
   if ping -q -c 1 -W 3 208.67.220.220 > /dev/null; then
       (gpio l 39 0 4000 0 0 0);
else (gpio l 39 4000 0 0 0 0);
  fi

адрес пинга сами выберите.

кстати не нашел GPIO адрес светодиода в конфигах, пришлось отступить от SYS_LED вверх и попробовать.

зажигает/гасит светодиод VPN при наличии/отсутствии пинга, если роутер использует прямое подключение IPoE и не использует VPN сессию.

Изменено 25 октября, 2015 пользователем Sterr

[sfstudio]

cat configs/kernel/config-kernel-MT7620-2T2R-8M | grep GPIO
CONFIG_RALINK_GPIO=y
CONFIG_RALINK_GPIO_BTN_RESET=1
CONFIG_RALINK_GPIO_BTN_WPS=0
CONFIG_RALINK_GPIO_LED=y
CONFIG_RALINK_GPIO_LED_SYS=y
CONFIG_RALINK_GPIO_LED_VPN=y
CONFIG_RALINK_GPIO_SYS_LED=38
CONFIG_RALINK_GPIO_VPN_LED=39

[Sterr]

если честно, искал CONFIG_RALINK_GPIO_VPN_LED, но почему-то именно в 7620 исходниках не нашел. даже в config.sh почему то 2 раза CONFIG_RALINK_GPIO_SYS_LED. наверное баг.

 

CONFIG_BCM_NAT=y
CONFIG_IP_NF_IPTABLES_SPEEDUP=y
CONFIG_RAETH_ESW=y
CONFIG_RALINK_GPIO_SYS_LED=38
CONFIG_RA_HW_NAT_IPV6=y
CONFIG_RT2860V2_AP=m
CONFIG_RT2860V2_AP_APCLI=y
CONFIG_RT2860V2_STA=m
CONFIG_RT_SECOND_IF_NONE=y
CONFIG_RAETH_DHCP_TOUCH=y
CONFIG_RAETH_ESW=y
CONFIG_RALINK_GPIO_SYS_LED=38
CONFIG_RT2860V2_AP_APCLI=y
CONFIG_RT2860V2_AP_MBSS=y
CONFIG_RT2860V2_AP_WDS=y
CONFIG_RT2860V2_STA=m
CONFIG_RT_SECOND_IF_NONE=y

 

кстати весьма полезная функция, не мешало бы встроить ее в WAN DHCP или VPN OFF. но вам то юзабилити ни к чему....

Изменено 25 октября, 2015 пользователем Sterr

[sfstudio]

Я не знаю где икали и как искали, всё там есть.

Дуп записей в config.sh может быть. Как бы абсолютно положить на это.

[sfstudio]

но вам то юзабилити ни к чему....

 

Предупреждение N2. После третьего китайского пойдёте в бан, а вся писанина в оффтоп.

[Sterr]

но вам то юзабилити ни к чему....

 

Предупреждение N2. После третьего китайского пойдёте в бан, а вся писанина в оффтоп.

через день только дошло что-ли? мне то по барабану, большому и звучащему. но если вам нужна обратная связь, вот вам юзабилити, я вплотную с ними работаю. если не нужна так как вы сами. знаете. что. нужно., то можете удалить и забанить.

[Sterr]

Тыпылинк долбаный будь он неладен. У всех же адсл тыпылинк стоял, вот по привычке и дыркают "питание". Ну ладно у 3050 кнопка еще глубоко, а на W4N она торчит очень сильно. А на wr740 и микротиках они внутри и их можно только спичкой нажать. Поэтому сбрасывают в основном W4N

[NewUse]

7620/7610 - лавинообразная деградация сервиса (падение общей утилизации канала одной АП) начинается при ~45 клиентах на один радиомодуль (ранее этот эффект проявлялся при примерно 30 клиентах).

76x2/7612 - деградация начинается при примерно 65 пользователях (ранее при 60). Большая плотность достигается за счёт использования rate alg grp доступного для этих чипов.

Ещё раз напомню про WiFox...

 

Сорри за оффтоп, но всёж этот алгоритм существенно позволяет уменьшить деградацию и её градиент.

Чёт всю инфу из гугла про WiFox потёрли -- основная идея в том, что ТД при большом количестве попыток выхода на апстрим (проб-пакетов) посылает серию коротких пакетов чтоб ресетнуть защитные таймеры клиентов...

 

Ну и ещё одна софтовая "улучшалка", но уже для мульти-рейта:

http://arxiv.org/pdf/1411.6685.pdf

 

И ещё одна идея по улучшению, на этот раз QoS:

http://www.hindawi.com/journals/ijdsn/2015/385935/

Изменено 31 октября, 2015 пользователем NewUse

[sfstudio]

Ещё раз напомню про WiFox...

 

Сорри за оффтоп, но всёж этот алгоритм существенно позволяет уменьшить деградацию и её градиент.

Чёт всю инфу из гугла про WiFox потёрли -- основная идея в том, что ТД при большом количестве попыток выхода на апстрим (проб-пакетов) посылает серию коротких пакетов чтоб ресетнуть защитные таймеры клиентов...

 

Больше похоже на какую-то шизофрению. Какие такие защитные таймеры и чего надо такого послать что бы резетнуть... Попахивает шаманизмом. Ещё раз грю что я потратил несколько вечеров на анализ всего что нашёл по запросу wifox, констатирую факт - лучше бы (ну не знаю например) сахаринки бы по размеру бы сортировал.

 

Ну и ещё одна софтовая "улучшалка", но уже для мульти-рейта:

http://arxiv.org/pdf/1411.6685.pdf

 

Это по сути ещё один rate_alg. Очень похож на тот что используется в 76x2 модулях. Полностью софтово rage_alg реализовывать крайне недальновидно. Потому у всех нормальных людей тайм критикал часть крутиться в BBP а модерируется кодом в драйвере.

 

И да, у нас не используется MAC80211 логика ядра, и всю её работу делает сам драйвер. У нас не юзаются никаких суппликанты и хостапд, всё это опять же делает драйвер используя по максимуму возможности BBP.

 

В 1000500й раз повторюсь, что архитектура 802.11 настолько ублюдочна что хоть сколько-то существенно её улучшить - значит переделать с нуля. Не ломая совместимости чего-то существенного добиться без вариантов.

 

Всё что можно и так делается, но через голову не прыгнуть, и wifi альянс это понимают. Потому когда появилась так и так ломать совместимость с 802.11a/b/g/n/ac начали разрабатывать отдельно wigyg где многие проблемы на которые наступили с wifi благодаря кривой изначально архитектуре были решены.

 

И ещё одна идея по улучшению, на этот раз QoS:

http://www.hindawi.com/journals/ijdsn/2015/385935/

 

 

Вы решили всё что можно мне скормить? Напуркуа?

[NewUse]

Дурацкая, наверное, идея, а нельзя ли попробовать что-то типа плавующей BSSID:

АП киляет станцию, при этом новая АП (на которую нужно переключиться) поднимает на своём Новом канале BSSID старой станции и сохраняет авторизационную сессию, вроде, софтово реализовать реально.... А вот как на это будут реагировать клиенты -- х.з., хотя у Меру что-то похожее было....

[sfstudio]

Причём тут новые старые каналы. Если канал один ещё можно попробовать прикинуться и дублировать все данные по всем АП, но если канал разный то это сразу 100% полный реконнект. И софтово это реализовать редкий ад будет ибо там же и состояние BBP надо клонировать, причём не полностью как в случае с ZH а лишь для одного клиента. Учитывая что этот BBP чёрный ящик с несколькими тысячами крутилок.

 

Буду дальше разбираться по ситуации и какие места и как можно ускорить раз всё тах хреново мягко говоря. Как раз основные клиенты это таки Android, а основной кейз открытые хотспоты.

[NewUse]

но если канал разный то это сразу 100% полный реконнект.

а как же DFS работает?

[sfstudio]

Вот так и работает, отключается если кто-то из клиентов его не умеет, или дисконнектит тех кто не умеет его (в зависимости от логики). А таких навалом. Тут вопрос в том что клиент тоже должен знать о таких подвывертах, но на логику клиентов мы влять не можем, значит такой подход увы не для нас.

[NewUse]

На всякий случай ещё уточню: проверял? Т.е. пробовал, ничего не посылая клиентам менять только частоту базы, не трогая кэши и прочие параметры временного хранения сессий?

 

Где-то то ли тесты, то ли статья, то ли что-то аналогичное пробегало, что такая штука поддерживается всеми клиентами бай-дизайн (ещё во времена 802.11g).

Хотя там были какие-то рассогласования со стандартом....

[sfstudio]

Так, вот давайте мы с вами продолжим разговор когда вы перестаните ссылаться на всякую бредятину типа "Где-то то ли тесты, то ли статья, то ли что-то аналогичное пробегало, что такая штука поддерживается всеми клиентами бай-дизайн (ещё во времена 802.11g).". Сами то мозг включите и поймёте почему не сработает и почему начали городить для этого DFS со своими capabilitis.

 

А так да. Я наверное вот вчера железки увидел и никогда на ходу при отладке канал не крутил. А ещё наверное идиоты в логике автовыбора канала проверяют есть ли активные юзвери ибо иначе их сдует с АП.

 

Да и кода я дров в глаза не видел наверное. Вот откровенно что вам-то мешает прежде чем писаниной страдать попробовать? Ну откровенно же мусор пишите, я потом чистить должен?

[Sterr]

1) full russian ui (work end ~99%).

 

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

 

2) need add McastPhyMode and fix McastMcs in webui (see README, not need add 0-1,4 not used in real life).

 

сами написали, что не используется в реальной жизни.

 

3) need add AckPolicy to UI (0 - normal ack, 1 - no ack, per MBSSID devider ; one parametr set for all MBSSID).

 

думаю что нужно, хотя и так работает.

 

4) need review, experiments with new roaming code in MT76x2 driver, need add multiif support in iappd daemon and implement to WebUI.

 

не для моих аппаратов

 

5) need add subchannel select for 5GHz module.

 

обязательно, но тоже не для моих.

 

6) in fair faif future: need add in firewall support xt_time matches for parental control.

 

нужно. даже больше, чем первые 3.

 

7) in fair faif future: need add davfs2 webui for managment online disk drives (as yandex disk and others very slow, really need?).

 

не думаю, что это прям нужно, работает в сторонних приложениях, а в роутере лишний гемор.

 

8) in fair fair future: need add scripts and webui for support 3g usb dongles uses qmi protocol.

 

не для меня, но думаю нужная фича. впору уже о 4g подумать.

 

9) in fair fair future: need add perip shaper script and webui.

 

нужная фишка. редко конечно, но иногда очень. кстати недавно искал, но не нашел.

 

10) in fair fair future: port support l2tp/pptp hardware NAT offload (really needed? in sdk very ugly code).

 

а много ваших заказчиков работают в l2tp/pptp? что-то думается мне что оно и так работает нормально.

 

мне одному показалось, что некоторые in fair... нужнее, чем приоритетные?

 

 

и еще просьба: можно список изменений делать для каждой версии, чтобы не шить несущественные, либо неиспользуемые исправления?

 

да и еще. можно выдернуть в web список текущих соединений? или может на отдельный log сервер. иногда бывает очень нужно.

Изменено 2 ноября, 2015 пользователем Sterr

[sfstudio]

Это не для вас ToDo а для нас памятка, обсуждать тут не чего. Своё видение можете озвучивать на support@nag.ru И возможно что-то из вашего появиться в этом ToDo. За сим тему закрываю завтра уедет в оффтоп.

 

Все изменений по коду видно в git, учитесь пользоваться.

 

P.S. Очень прошу перестать отвлекать от работы всякой фигнёй, для этого есть support@nag.ru . Вы меня утомили.

[Гость dimk]

Оно реализованно в виде патча ядра или модуля(драйвера)?

В каком месте есть связь hw_nat с netfilter?

Для OpenWrt эта проблема очень актуальна http://dev.openwrt.org/ticket/11779

[sfstudio]

Оффтоп. Уезжает в соответствующую тему. Изучите прежде чем писать http://forum.nag.ru/forum/index.php?showtopic=108629 WRT обсуждайте на форуме WRT. Тут обсуждается Wive-NG-MT.

[Гость dimk]

Необходимо установить кастомный mac адрес каждому из работающих одновременно pppoe соединений.

В OpenWrt это решается навешиванием каждого pppoe на пары veth0-veth1 veth2-veth3 ... (созданные посредством модуля ядра kmod-veth) у которых ставится кастомный mac и другие концы которых объеденены в мост с физическим портом к провайдеру.

А есть ли возможность указать mac каждого pppoe в настройках pppoe-клиента вашей прошивки?

[sfstudio]

У нас вообще нет поддержки множественных VPN соединений в т.ч. pppoe. Юзайте WRT. Мы не стремимся решать экзотические проблемы 1,5 человек на земле. Цели и задачи проекта описаны на wive-ng.sf.net.

 

P.S. Едиснтвеный случай когда это может понадобиться - это обман оператора для подъёма >1 PPPOE туннеля до его браса дабы иметь полосу выше лимита (если конечно оператор не блокирует это дело). А т.к. железо ориентировано на установку операторами...