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

 

Проверил на 4.1.3 прям ваш файл через renew вкатил - всё ок. Попробуйте в 4.1.3 это сделать, сомнительно конечно.. Ну если не паять консоль то пошагово включать опции и смотреть на какой споткнётся.

 

Сейчас соберу и выложу 4.1.4 что бы уже точно на одной версии проверять.

 

P.S. проверил и по радио и по проводу всё бегает. Странно короче.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Похоже повторил. Развалилась приоритезация (QoSEnable=1). Буду выяснять где был слом. Пока либо оставайтесь на старой версии либо не используйте QoSEnable тем более что толку от неё в режиме c hw_nat около нуля (по сути при включенном hw_nat этот вариант будет только локальный трафик и мммммаааааленькую часть транзитного приоритезировать, только лишняя загрузка CPU, проще уж тогда QoSEnable=3 что бы для этого трафика Codel приюзать).

 

Причём на 7621 слома нет. Нифига не понимаю. Короче будем посмотреть.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ранее до версии 3.3.8 никаких проблем не наблюдалось.

 

Вот блин чего ж так редко грейдитесь. Сейчас найти где закралась регрессия будет оооочень не просто.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В общем разобрался. В 3.3.8 QosEnable=1 (простая приоритезация) вообще не работала. =)))

А косяк в том, что я не учёл что при использовании на корне priomap нельзя в sfq юзать hash по dst ip ибо он будет всегда пуст. Поправил щас соберу 4.1.4.

Ну и таки совет выше не заниматься фигнёй и не трогать вообще шейпер без нужды. Судя по тому что вы использовали вообще не рабочий вариант он вам точно не нужен. Для успокоения можете включить codel.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В общем разобрался. В 3.3.8 QosEnable=1 (простая приоритезация) вообще не работала. =)))

А косяк в том, что я не учёл что при использовании на корне priomap нельзя в sfq юзать hash по dst ip ибо он будет всегда пуст. Поправил щас соберу 4.1.4.

Ну и таки совет выше не заниматься фигнёй и не трогать вообще шейпер без нужды. Судя по тому что вы использовали вообще не рабочий вариант он вам точно не нужен. Для успокоения можете включить codel.

Параметр называется QoS, а вы мне о шейпере пишете. Как бы это не совсем одно и то же, хотя и связанные вещи.

Как посоветуете приоретизировать мультикаст на коробке при условии что он приходит уже покрашенным?

Или можно смело забить на это т.к. не работает?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ещё раз грю ни приоритезировать не шейпить пока включен PPE у вас не выйдет, что бы хоть что-то сделать нужно вынуть поток из PPE как это делает simple shaper или вовсе PPE отключить. Поэтому всё должно быть приоритезировано ещё до клиентской железки. А не ждать что вот мы щас покрасим, а там дай бог клиентская железка какая-нить из сотни тысяч разновидностей поймёт эту раскраску, поймёт правильно и ещё правильно раскидает по очередям приоритетов при этом не сдохнув от натуги.

 

И что значит не работает? =) Оно работает, но вот надо понимать когда стоит подобное юзать и чем придётся пожертвовать. На сети оператора явно не задача end user железки заниматься приоритезацией. Учитывая, что эта железка не может повлиять на то, что на неё свалиться через секунду. Т.е. в любом случае что бы такая приоритезация (при отсутствии приоритезации по пути дл конечной железки) нормально работала потребуется городить достаточно длинные очереди и оно никак не поможет если горлышко в виде FE будет забито. Так что трафик уже должен быть сварен как положено ещё до того как оно прилетит к юзеру. Слава богу в нормальных сетях так обычно и происходит.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Так что трафик уже должен быть сварен как положено ещё до того как оно прилетит к юзеру. Слава богу в нормальных сетях так обычно и происходит.

До CPE с приоритезацией в частности мультикаста всё отлично (по вашей классификации сеть "нормальная"), вопрос только в том чтобы на самой CPE тот же мультикаст не похерился юзером при нагрузке портов внутренним трафиком, например в процессе копирования файлов из одного компа на другой и т.п.

 

Но в общем я понял Ваш посыл - если трафик обрабатывается хардварно то QoS настройки лучше не включать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для того что бы не похерился юзером при нагрузке на CPE трафик подрезается на стороне оператора (т.е. если на порт валиться больше чем по этому порту физически можно пропихнуть то тут без плясок не обойтись) + надо гарантировать что бы у CPE хватило ресурсов переварить всё что валиться. На сотке с MT7620 проблемы со сломом приоритезации сделанной до CPE проблем нет. Ресурсов с запасом.

 

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

 

LAN<=>LAN вообще никакой QoS работать не будет ибо там тупой свитч (тоже самое что любой 5ти портовы неуправляемый железяк). LAN<=>WLAN по сути тоже (с учётом WMM в WLAN).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

SNR-CPE-W4N-MT-4.2.9.RU.17042016

[TL-WA848N@/etc/scripts]# pingerz.sh
-sh: pingerz.sh: not found

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Может сначала покажете

ls -l pingerz.sh

Ну и попутно попробуйте

./pingerz.sh

Изменено пользователем dini

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Может сначала покажете

ls -l pingerz.sh

Ну и попутно попробуйте

./pingerz.sh

 

да толку то... все параметры идентичны скриптам в прошивке. но те выполняются, а мой нет.

 

/etc/scripts$ ls -l pingerz.sh
-rwxr-xr-x    1 Admin    Admin          144 Jun 10 00:55 pingerz.sh
/etc/scripts$ ./pingerz.sh
-sh: ./pingerz.sh: not found

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

какой вредный =)))) sh -x /etc/scripts/pingerz.sh расскажет что ash не нравиться в вашем скрипте.

 

И вообще это:

1) не регрессия, корректно написанные скрипты как исполнялись так и исполняются

2) оффтоп, учить писать и отлаживать скрипты тут никто не обещал, для этого есть другие ресурсы

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

да нет, это таки регрессия. но скорее всего не по вашей вине, а по причине повышения версий. раньше на этот скрипт sh не матерился.

он раньше работал, потом с очередным обновлением прошивки со стиранием РВФС был благополучно стерт, и вот сейчас понадобился.

но интересно что пишет то не ошибку в скрипте как по идее должно быть, а not found это то и убивает.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Чего чего? Ещё раз грю. Корректно написанные скрипты как выполнялись так и будут выполняться если загружены и корректно права отданы. Нет никаких регрессий тут и быть не может иначе железка бы не запустилась вообще т.к. весь инит скриптовый.

 

Повторяю для невнимательных, это всё тут оффтоп, как дебажить мной подсказанно. Если этого мало идём на сайт бизибокса и читаем там на тему ash.

 

В общем утром снесу в оффтоп.

 

P.S. А not found он может ругаться запросто на то что в заголовке скрипта неверно указан путь в интерпретатору. Но вы ведь советом данным выше ещё не воспользовались, зато своё мнение уже высказали. Давайте в будущем вы будете наоборот поступать? Сначала попробуете - потом отпишитесь?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Доброго времени суток!

Вроде как регрессия, а может нет. Если не туда - поправьте...

Версия 4.4.16 работает стабильно. Решил попробовать 4.5.10. Поступили 3 жалобы от абонентов - ноутбук пытается подключиться и выдаёт, что не может установить соединение. На 4.6.0 ситуация аналогичная. В логах устройства чисто - только упоминания других подключенных устройств.

Изменение настроек wifi на роутере не даёт результатов, крому одного клиента - там при переходе на N only ноутбук заработал. Узнать что там за ноутбук и сетевка в нём не получилось - абоненту некогда. Два других (Atheros AR9485WB-EG на Win 8.1 и dell wireless 1705 на win 10) заработали только при откате на 4.4.16.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Странно. Нужно больше данных

 

Железка какая одно или 2х диапазонная? Коннектитесь к какому диапазону? Что говорит клиент на тему почему не подключился? У себя проблем не наблюдаю. 4.5.10 надеюсь моя сборка с sf.net ? Шифрование надеюсь wpa2+psk ?

 

Между 4.5.10 и 4.6.0 по дровам разницы нет. Что бы выяснить надо по шагам откатываться с 4.5.10 по 4.5.0 и проверять что внесло регрессию (специально делаю частые срезы что бы можно было сделать гиту хард резет и проверить), какая из правок. Если есть возможность - был бы лагодарен. Т.к. у меня не повторяется и без вашей помощи оперативно поправить не смогу.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Wireless->Main->Advanced Wireless, какой Region settings выставлен? У нас подобное случалось со всяким железом (от айфона до всякоразный китаефонов и ноутбуков и планшетов) когда регион был MKK (1-14 каналы), ставим везде IC (1-13).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Скорее с RU на US переводить. MKK/FCC и т.д. это только ограничение по каналам и для Legacy B. На остальное оно не влияет. А автовыбор давно ограничен 1-11 каналами (если не трогали дефолты в nvram руками).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

У себя ещё раз перепроверили со всеми доступными клиентами - проблем нет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Переведите на 1ый канал, была фигня с тренднетом и старым длинком, на 7 канале не хотел работать, а при автовыборе 7 часто выбирался, но это так -- крайне мало вероятно, но вдруг

...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Выбор канала 1-11 это чисто эфиро-избирательно зависимые пляски. Вообще давно пора в 5ГГц уходить при таких проблемах. Просто на 7мом канале (т.к. он дефолтовый у 70% девайсов точно) видимо засрано так, что даже нойз гейт в BBP вашего трендетом (ну или старым длинком) отработать не мог.

 

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

 

Так что ещё раз рекомендую где возможно юзать дуалбэнды.

 

P.S. Не забывайте что в 2.4 при 1-11 только 3 непересекающихся канала.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Немного дополнил рекомендации (добавил известные проблемы с клиентами, чаще всего отличается в глюках как не странно Apple и Samsung) http://forum.nag.ru/forum/index.php?showtopic=104359

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Про ноут и вифи пока неясно, по возможности ещё с тем ноутом повоюю.

Нашёл другое. Не знаю регрессия или бага, т.к. раньше данной функцией не пользовался.

Суть: имеем RemoteManagementPort=80. В Сервисы-Разное ставим другой порт, например 8080, жмём применить. Система говорит, что для применения изменений нужен ребут. Соглашаемся - говорит что ребутится, идёт отсчёт. Но уустройство продолжает работать дальше. Если посмотреть в консоли, то правила к айпитаблес применяются уже с новым портом, но гоахеад всё ещё работает по старому порту. Ребутаю роутер руками - всё начинает работать на новом порту.

Проверял на крайней версии, чистой и без правок.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!


Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.


Войти