Портировал поддержку basic roaming параметров (ограничения ассоциации/авторизации/probereq и т.д.) на 7610 и в старый 7620 драйвер. Будет доступно в новом релизе, работает в отличии от нового драйвера чётко, в новом из-за баги с отстрелом PSM клиентов (с ним разбираюсь пока) юзать это дело весьма проблематично. Но переходить на него надо обязательно так что буду добивать.

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


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

Хью, удалось избавиться наконец от ложных срабатываний лимитов + пофиксить ещё стопку попутно мелочи. В общем ждём правок рожи от Дена и релизимся.

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


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

Залил 3.5.4 с вышеобозначенными фиксами и перепиленной страницей WDS.

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


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

Кратко по текучке 3.5->3.6:

1) доделали алгорим отстрела по rssi (см http://forum.nag.ru/forum/index.php?showtopic=108990)

2) запустили полноценно chillispot с injectами и прочими плюшками

3) в драйверах закрыли стопку очень долго живущих недочётов

4) стопка бэкпортов на предмет стабильности из текущей devel ветки ядра (включая anti spoofing ipv6)

5) добавлена переменная dhcpARPPTimeout (по дефолту 2000мс), это таймаут arping выполняемого перед тем как выдать адрес клиенту для проверки не занят ли этот адрес кем-то другим в т.ч. станциями со статическими адресами. Т.е. что бы избежать дублей адресов. Проблема в том что когда нужен роуминг эта процедура значительно увеличивает время хэндовера (если клиент с нуля выполняет полную процедуру, как это делают многие андроидные клиенты к примеру), имеет смысл уменьшить этот таймаут или вообще отключить процедуру (в общем-то у других эта логика не используется)

6) дальнейшие правки локализации

 

В общем ждём Дэна с реализацией профилей для сервисов авторизации в настройках хотспота и релизимся.

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


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

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

 

Изменений крайне много, касались буквально всего, от 10 летней ошибки живущей во всхел Linux ядрах младше 3.5 и приводящей к устареванию записи в arp таблице на некоторых коммутаторах. Заметно оптимизирована логика работы с очередями в драйверах wifi что позволило заметно сократить регрессию по производительности с ростом числа клиентов особенно в зашумлённом эфире.

 

Доделаны профили для хотспотов (в будущем добавятся ещё).

 

Обновлены компоненты системы включая ядро.

 

И множество мелких разной степени критичности правок.

 

Залито.

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


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

Едем дальше.

Пол дня "развлекался" нагрузочным тестированием на предмет максимального числа юзеров которые может обслужить один радиомодуль после последних правок на тему обработки очередей. Режим N, для AC значения будут лучше, но не особо. Заметно улучшить ситуацию особенно когда условия приёма у разных клиентов сильно разные можно будет только на 7603/7615 за счёт AirTime.

 

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

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

 

Посему принял решение для младших устройств построенных на MT7620 увеличить лимиты по числу клиентов на модуль с 32 до 56, для старших (будущих) до 72 клиентов на радиомодуль. Будет доступно в 3.6.2.

 

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

 

Общая ёмкость по скорости для одного модуля получается в пределах 60Мбит на границе "насыщения" АП т.е. при числе юзверей близком к максимуму.

 

Задать более жёсткие лимиты так же можно в WebUI.

 

Так же в 3.6.2 будет доступна возможность выставить произвольный TX Rate для мультикаст трафика (ранее было спрятано и все забыли благополучно о полезной крутилке, пора вернуть).

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


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

Такс. Владельцам дуалбэндов обязательно обновиться до 3.6.3. Обнаружена крайне неприятная ошибка приводившая к существенному падению производительности 802.11AN клиентов.

 

Так же переделана логика адаптивной подстройки радио при p2mp (MULTICLIENT_SUPPORT) что привело к ещё более предсказуемому поведению при росте числа клиентов и позволило существенно сгладить кривую деградации общей утилизации полосы.

 

Так же закрыто существенное число регрессий в WEB интерфейсе и закрыта стопка потенциальных проблем в сетевом стеке (особенно касается ipv6).

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


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

Заставил полноценно работать 802.11K на mt76x2 драйвере, к сожалению пока нельзя этот драйвер из-за известной проблемы с PSM клиентами. Будем дальше пинать китайцев.

 

В 3.6.4 из новшевст будет:

1) Возвращён к жизни механизм QBSS позволяющий учитывать загрузку канала при автовыборе,а так же анонсировать в мяках загрузку AP что облегчает роуминг клиентам которые умеют использовать эти данные http://community.arubanetworks.com/t5/Controller-Based-WLANs/What-is-QBSS-What-information-does-it-provides/ta-p/184840, включается вместе с включением WMM или RRM т.к. по сути является его частью подборки рекомендаций по обеспечению QoS в сетях 802.11.

2) Региональные параметры для A диапазона пересмотрены и втиснуты в требования нашего законодательства, так же при автовыборе канала в A диапазоне исключены 149-165е каналы т.к. устройств работающих на них из коробки не видно, при этом эти частоты запрещено использовать в 164х крупнейших городах России.

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


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

Внепланово зарелизил 3.6.4.

 

Всплыла крайне неприятная проблема которую почему-то сразу не отследили.

Видимо в один "прекрасный" момент китайцы решили что:

1) на всех девайсах мак адреса WLAN и LAN могут быть одинаковыми, что не критично пока не используем ethernet converter режим, т.е. в обычной жизни можно и забить т.к. интерфейсы всё равно запихиваются в один бридж и навешивается один мак.

2) на дуалбэндах они вдобавок к п1 решили что можно вообще одинаковые маки на LAN/WLAN на всех девайсах навесить, что уже критично ибо в эфире запросто могут оказаться 2 BSSID одинаковых и у клиентов посносит голову. Или при переключении в режим APBR вообще все устройства будут иметь один мак.

 

В 3.6.4 добавлена проверка этого дела и перегенерация LAN/WLAN/WLAN2 (WAN не трогаем он задан корректно) маков при выявлении этого безобразия.

Крайне рекомендую обновиться всем абсолютно ибо п2 весьма неприятный.

 

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

 

Эти вопросы вы можете задать support@nag.ru. Тут попрошу воздержаться от флудиразма.

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


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

Плановый 3.6.5 релиз. Если не будет выявлено ничего непредвиденного именно он поедет на фабрику.

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


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

Предполагаю что нашел косяки. Дуалбенд, прошивка SNR-CPE-MD1-5GHZ-MT-3.6.6.RU.14112015

Подключение через PPPoE (VPN)

 

При настройке "Сетевой экран/проброс портов" оное не заработало по двум причинам

 

1) Если опция проброса была выключена то изменения в iptables появляются только при условии жмаканья "Сохранить и перезагрузить", без перезагрузки жмаканье кнопки "Применить" не добавляет правил в iptables

После перезагрузки добавляется цепочка "port_forward_pre_vpn" в PREROUTING и правила в ней.

[Wive-NG-MT@/]# iptables -nvL -t nat
Chain PREROUTING (policy ACCEPT 31514 packets, 2059K bytes)
pkts bytes target     prot opt in     out     source               destination         
32970 2150K port_forward_pre_vpn  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
   0     0 MINIUPNPD  all  --  eth2.2 *       0.0.0.0/0            0.0.0.0/0           
19263 1275K MINIUPNPD  all  --  ppp0   *       0.0.0.0/0            0.0.0.0/0           

Chain port_forward_pre_vpn (1 references)
pkts bytes target     prot opt in     out     source               destination         
   1    60 DNAT       tcp  --  ppp0   *       0.0.0.0/0           !192.168.1.0/24      tcp dpt:3022 to:192.168.1.10:22

 

2) И после перезагрузки проброс не работает т.к. нет разрешающих правил в Chain FORWARD

Как только ручками добавляю

iptables -A FORWARD -p tcp -d 192.168.1.10 --dport 22 -i ppp0 -j ACCEPT

вижу в конце своё правило

Chain FORWARD (policy DROP 13 packets, 1985 bytes)
pkts bytes target     prot opt in     out     source               destination         
13379  853K MINIUPNPD  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
13376  853K macipport_filter  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
12205  753K ACCEPT     all  --  br0    *       192.168.1.0/24      0.0.0.0/0           
   0     0 ACCEPT     all  --  *      eth2.2  192.168.1.0/24      0.0.0.0/0           
   0     0 ACCEPT     all  --  *      !br0    192.168.1.0/24      0.0.0.0/0           
   0     0 ACCEPT     all  --  *      ppp0    0.0.0.0/0            0.0.0.0/0           
   0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
   1    60 ACCEPT     tcp  --  ppp0   *       0.0.0.0/0            192.168.1.10      tcp dpt:22

И тут же начинает работать как надо проброс портов.

ИМХО просто забыли что одного изменения в PREROUTING недостаточно, нужно ещё разрешить трафик в FORWARD. Ну или это регрессия какая-то...

 

Заранее извиняюсь что не покопался в скриптах и не сделал diff.

Поначалу пробовал там разобраться в последовательностях выполнения, но до конца так и не уловил где и чего искать, а в WEB тем более не силен.

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


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

1) в пробросе там 3000 лет нифига не менялось, чего ему бы вдруг сломаться?

3) правила применяются при подъёме ppp ифэйса, т.е. можно тупо применить нажать

3) покажите как в роже настроено

 

Всё понял что у вас не так. Включен MAC/IP/Port Filtering. Если оно включено и дефолтовая политика DROP то нужно ещё и там разрешить то что протянули. Оно работает там же в цепочке форвард. Можно конечно и перекрывать из логики форварда как вы предлагаете, но это приведёт к коллизиям по логике + отдельные правила в форварде тоже будут проц подъедать.

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


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

3.6.7 - финальная фабричная версия 1,5 месяца вылизывания и допила всего что было сделано со старта по всем фронтам. Именно эту версию на данный момент рекомендую использовать в продакшн.

 

И похоже мне пора взять таймаут хотя бы на неделю, ибо голова скоро взорвётся. Следующим шагом будет таки добить новый единый для 7620/7602/7612 драйвер до юзабельного состояни (имеется одна нерешённая проблема с ним, которая не хочется сдаваться) после чего сосредоточить силы на доводке роуминговых расширений и реализации логики band_steering не требующей поддержки со стороны клиента (есть задумки как мягко практически гарантированно избавиться от прилипчивых клиентов на 2.4АП).

 

По Web основная работа будет сосредоточена по расширению статусов в роже, как минимум для WDS/APCLI, добавлению режима сканирования в режиме AP в UI и т.д. и т.п.

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


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

 

Всё понял что у вас не так. Включен MAC/IP/Port Filtering. Если оно включено и дефолтовая политика DROP то нужно ещё и там разрешить то что протянули. Оно работает там же в цепочке форвард. Можно конечно и перекрывать из логики форварда как вы предлагаете, но это приведёт к коллизиям по логике + отдельные правила в форварде тоже будут проц подъедать.

Это не у меня не так, это в прошивке косяк скорее всего в сочетании с MAC/IP/Port Filtering

Смотрю на роутер без файервола и проброса портов

В цепочке FORWARD дефолтовая политика DROP

А вот правило пропускающее RELATED,ESTABLISHED я бы поместил в самое начало, а уже после него остальные.

 

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination         
1313K 1759M MINIUPNPD  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
1309K 1759M ACCEPT     all  --  *      br0     0.0.0.0/0            224.0.0.0/4         
   0     0 ACCEPT     all  --  br0    *       224.0.0.0/4          0.0.0.0/0           
4239  390K ACCEPT     all  --  br0    *       192.168.1.0/24       0.0.0.0/0           
   0     0 ACCEPT     all  --  *      eth2.2  192.168.1.0/24       0.0.0.0/0           
   0     0 ACCEPT     all  --  *      !br0    192.168.1.0/24       0.0.0.0/0           
 146 16692 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED

 

В этом случае проброс портов тоже не будет работать

 

Теперь добавляю на этом роутере проброс портов

Chain port_forward_pre (1 references)
pkts bytes target     prot opt in     out     source               destination         
   0     0 DNAT       tcp  --  eth2.2 *       0.0.0.0/0           !192.168.1.0/24       tcp dpt:8880 to:192.168.1.224:8880

 

и вижу в FORWARD

добавление правила из WAN в LAN для вообще любого трафика! Но оно будет работать только при условии преобразования пакетов в PREROUTING

0 0 ACCEPT all -- eth2.2 br0 0.0.0.0/0 192.168.1.0/24

 

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination         
   4   278 MINIUPNPD  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
   0     0 ACCEPT     all  --  *      br0     0.0.0.0/0            224.0.0.0/4         
   0     0 ACCEPT     all  --  br0    *       224.0.0.0/4          0.0.0.0/0           
   4   278 ACCEPT     all  --  br0    *       192.168.1.0/24       0.0.0.0/0           
   0     0 ACCEPT     all  --  *      eth2.2  192.168.1.0/24       0.0.0.0/0           
   0     0 ACCEPT     all  --  *      !br0    192.168.1.0/24       0.0.0.0/0           
   0     0 ACCEPT     all  --  eth2.2 br0     0.0.0.0/0            192.168.1.0/24      
   0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED

 

А вот когда добавляю фильтрацию где "Правило по умолчанию -- пакеты, которые не подходят ни под одно правило, будут: Пропущены"

вижу добавление цепочки

Chain macipport_filter (1 references)
pkts bytes target     prot opt in     out     source               destination         
   0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
   0     0 DROP       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            MAC F8:F0:82:51:12:13

 

И далее вижу что в FORWARD исчезло правило для пропуска трафика из WAN в LAN

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination         
   3   266 MINIUPNPD  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
   3   266 macipport_filter  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
   0     0 ACCEPT     all  --  *      br0     0.0.0.0/0            224.0.0.0/4         
   0     0 ACCEPT     all  --  br0    *       224.0.0.0/4          0.0.0.0/0           
   3   266 ACCEPT     all  --  br0    *       192.168.1.0/24       0.0.0.0/0           
   0     0 ACCEPT     all  --  *      eth2.2  192.168.1.0/24       0.0.0.0/0
   0     0 ACCEPT     all  --  *      !br0    192.168.1.0/24       0.0.0.0/0           
   0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED

 

 

Получается что при пробросе портов трафику из WAN в LAN разрешается бегать по роуту (если конечно в PREROUTING было преобразование)

Но этот проброс сразу же перестает работать как только мы включаем MAC/IP/Port Filtering (даже с пропуском неописанного правилами трафика)

 

Что мешает оставить вот это правило пропуска из WAN в LAN при одновременном использовании проброса портов и фильтеринга? Какая-то особенная религия?

0 0 ACCEPT all -- eth2.2 br0 0.0.0.0/0 192.168.1.0/24

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


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

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

 

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

 

Что мешает оставить вот это правило пропуска из WAN в LAN при одновременном использовании проброса портов и фильтеринга? Какая-то особенная религия?

0 0 ACCEPT all -- eth2.2 br0 0.0.0.0/0 192.168.1.0/24

 

В ipfilter дефолтовую политику accept (поле Default Policy -- Packets that don't match any rules will be:) используйте и будет ваше желаемое. По дефолту там Drop для всех не своих.

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


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

Я перепроверю этот кейз но не помню с ним проблем. Быстно не обещаю, сил нет уже это всё видеть. Нужен таймаут.

 

Похоже вижу, да логика пропущена. Щас добавлю.

 

Поправил. Придётся внепланово ещё фабрику пнуть.

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


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

А вот правило пропускающее RELATED,ESTABLISHED я бы поместил в самое начало, а уже после него остальные.

 

Это вопрос оптимизации. Это правило само по себе дорогое с точки зрения CPU гораздо дороже чем сотня ACCEPT правил без проверки state в контраке. Потому в самое начало её запихивать как бы.

 

На самом деле руки всё недойдут (пока) отрефакторить и это дело, в планах значиться, но пока не до этого.

 

В общем в 3.6.9 на коленке проверил, вроде терь всё ОК. Действительно была регрессия и видимо жила ещё со времён переезда на новую кодовую базу.

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


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

С вервии 3.7.4 будет доступен новый режим изоляции, LanWifiIsolate изолирующий доступ из WIFI сети в LAN и наоборот на уровне бриджа, т.е. по прежнему все остаются в одном адресном пространстве, но трафик между радио и проводными интерфейсами запрещён (работает только в режиме роутера, в режиме AP т.к. все интерфесы в бридже это приведёт к потери связности).

 

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

 

Так же будет доступен режим ограничения числа TCP сессий через шлюз (ForwardSesLimit). Полезно на публичных хотспотах.

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


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

Есть простая и красивая идея, обеспечить возможность загрузки пакета RWFS с сервера оператора по какому-то событию (нажатие кнопки, появление линка и т.д.). Тем самым обеспечив возможность единого варианта "кастомизации", изменения любых настроек, обновления прошивки, подтягивать свои утилитки для реализации чего-то сверх того что умеет прошивка и т.д.

 

Вопрос такой, надо либо определиться с дефолтовым урлом, или придумать в какой опции dhcp и в каком формате передавать. Придумать какие-то флаги на тему контроля версий и т.д. и т.п.

 

Какие будут предложения?

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


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

Я конечно не доктор, но у оператора обычно есть днс сервера которые он выдаëт клиентам.

Может быть заморочиться как в своë время с ретрекерами и зоной local. Хотя использование последней часто критиковали в разрезе работы яблочных компьютеров и mdns если верно помню.

 

Тобиш по событию определëнному скажем обращаться на http://snr.local/$modelname/rwfs.bin

Нуили rwfs.zip, или вообще list.txt с заделом на будущее в котором писать уже можно много чего, хотя в начале лучше кмк не усложнять пока.

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


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

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

 

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

 

Опять таки нужно определиться будем мы просто перезаписывать существующие данные в rwfs или восстанавливать оригинальную копию из RO области и накладывать поверх то что загрузилось. Понятно что это можно на откуп тому кто пакет формирует отдать, но как-то...

 

Вот по таким всем вопросам тем кто заинтересован в подобной плюшке надо бы тут собраться и договориться. Без дикого оверкила по логике ессно, что бы не получилось что хотели как лучше... Хуки какие нужны будут добавим, это не проблема. Можно это вынести вообще на короткое нажатие кнопки резета. Ибо не гоже по дефолту подобное держать, как бы дырка может выйти. А так сказали юзеру кратковременно нажать резет для автонастройки и поехали.

 

Опять же в запросе можно передать всё что угодно и в зависимости от этого сформировать ответ сервера или даже динамически сгенерить пакет.Т.е. надо определитсья что таки отдавать.

 

В общем надо продумать. Идея простая и эффективная, но как сделать лучше и не прострелить себе ногу ещё тот вопрос.

 

P.S. пакет RWFS это банальный tar.gz архив который распаковываясь перезаписывает своим содержимым содержимое /etc + если в пакете есть пост скрипт выполняет его (http://forum.nag.ru/forum/index.php?showtopic=102590). Т.е. делать можно что угодно, это и хорошо и плохо одновременно.

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


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

Пока тут тихо, изложу немного:

 

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

Пока тут никто не нафантазировал, в качестве простоты и учитывая вашу стабильную привычку в нумерации вида x.x.x, вариации:

http://snr.local/modelname/x.x.x/rwfs.tar.gz

http://snr.local/modelname/rwfs.x.x.x.tar.gz

 

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

...

Опять же в запросе можно передать всё что угодно и в зависимости от этого сформировать ответ сервера или даже динамически сгенерить пакет.Т.е. надо определитсья что таки отдавать.

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

 

Можно это вынести вообще на короткое нажатие кнопки резета.

Вроде тут у вас в темах кто-то паниковал по поводу лишних нажатий пользователями кнопки на устройствах.

Хотя если есть защита от дурака ввиде проверок самого архива и ресурс флешки приличен, почему нет.

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


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

С tr-069 всё заткнулось на:

1) недоступности нам коммерческих голов в личной сети где можно реверсить логику с обоих сторон, OSS решения увы не подходят

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

3) что по контроллерам что по tr-069 таки надо брать ещё одного прикладника, и вроде с финансовой стороны проблемы нет, а не кого. Того кого я бы взял (с точки зрения квалификации) и в ком уверен, я не возьму точно, по не техническим и даже не финансовым причинам.

 

Поэтому когда там что сдвинется с tr`ами...

 

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

 

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

 

Вроде тут у вас в темах кто-то паниковал по поводу лишних нажатий пользователями кнопки на устройствах.

Хотя если есть защита от дурака ввиде проверок самого архива и ресурс флешки приличен, почему нет.

 

Ну в обычном режиме флэш вообще всегда в RO. Т.е. как минимум 10к раз можно перезаписать. Даже если это делать каждый день по одному разу то это около 30 лет службы. Т.е. ресурса хватит точно.

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


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

Пока тут тихо, изложу немного:

 

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

Пока тут никто не нафантазировал, в качестве простоты и учитывая вашу стабильную привычку в нумерации вида x.x.x, вариации:

http://snr.local/modelname/x.x.x/rwfs.tar.gz

http://snr.local/modelname/rwfs.x.x.x.tar.gz

 

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

...

Опять же в запросе можно передать всё что угодно и в зависимости от этого сформировать ответ сервера или даже динамически сгенерить пакет.Т.е. надо определитсья что таки отдавать.

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

 

Можно это вынести вообще на короткое нажатие кнопки резета.

Вроде тут у вас в темах кто-то паниковал по поводу лишних нажатий пользователями кнопки на устройствах.

Хотя если есть защита от дурака ввиде проверок самого архива и ресурс флешки приличен, почему нет.

 

Почерпнуть аналогичный опыт Eltex по обновлению прошивок STB и кастомизацией.

Пару лет тому ковырялся с их системой - вполне продуманное решение было.

Вкратце

1. DNS отдает адрес хоста обновления что-то типа eltex-stb.local где на HTTP-сервере в структуре каталогов лежат подписанные сертификатом прошивки и кастомизация

2. При загрузке STB ищет файлики с указанием версии актуального ПО по URL

3. Если найдено обновление прошивки - обновляется, нет - грузится дальше

4. Ищет файлики кастомизации для конкретной версии в дереве подкаталогов.

5. если есть кастомизация - подгружает её без сохранения во флеше девайса

 

6. Коробка STB запускается с кастомизацией, например с плейлистом оператора и командой запуска при старте IPTV-плеера

 

Более мелкие детали уже не припомню

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


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

Есть простая и красивая идея, обеспечить возможность загрузки пакета RWFS с сервера оператора по какому-то событию (нажатие кнопки, появление линка и т.д.). Тем самым обеспечив возможность единого варианта "кастомизации", изменения любых настроек, обновления прошивки, подтягивать свои утилитки для реализации чего-то сверх того что умеет прошивка и т.д.

 

Вопрос такой, надо либо определиться с дефолтовым урлом, или придумать в какой опции dhcp и в каком формате передавать. Придумать какие-то флаги на тему контроля версий и т.д. и т.п.

 

Какие будут предложения?

Предложения уже озвучивал ранее.

Внезапно понял что эта фича очень сильно нужна, иначе с версиями прошивок полный зоопарк.

Кроме того очень надо автоматом (а не вручную!!!) вливать в девайсы определенный набор предустановленных настроек под оператора (типа IPTV, ALG и прочее).

Готов участвовать в качестве бета-тестера, отладчика и т.п.

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


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

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

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

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

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


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

Войти

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


Войти