Перейти к содержимому
Калькуляторы

Разработка вопросы разработки

В этой теме обсуждаются исключительно вопросы связанные с разработкой ПО для устройств (в т.ч. принимаются грамотно оформленные багрепорты, патчи и прочее) построенных на чипах семейства MT762x из серии SNR применительно к Wive-NG-MT (за исключением вопросов брендирования).

 

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

 

Актуальная информация (будет дополняться): http://wive-ng.sourceforge.net/?WN-MT_MT7620N%2FH

Исходные тексты: https://sourceforge.net/p/wive-ng/wive-ng-mt/ci/master/tree/

Официальные сборки: http://sourceforge.net/projects/wive-ng/files/wive-ng-mt

 

Тема по 305х (многие вопросы могут быть озвучены там т.к. логика частично пересекается): http://forum.ixbt.com/topic.cgi?id=14:54583

 

1) Для того чтобы вас поняли и максимально быстро смогли разобраться с проблемой при формулировке вопроса вам следует придерживаться рекомендаций в следующем документе http://maddog.sitengine.ru/smart-question-ru.html

2) Не стоит путать OpenSource и халявное пиво.

3) Перед тем как задать вопрос ОБЯЗАТЕЛЬНО воспользуйтесь поиском по теме.

4) Не отвлекайте разработчиков от работы простыми (банальными) вопросами.

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

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


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

Добрый день!

 

Коммитом dc2d13e48141479f1c1a2905bff56d6de8b86322 из-за пропущенного пробела, был полностью поломан DMZ. И с NAT там тоже какая-то ересь получалась на выходе.

 

Fix:

--- a/etc/rc.d/W10iptables
+++ b/etc/rc.d/W10iptables
@@ -503,7 +503,7 @@ startv6() {

get_param() {
    # get network, vpn, netfiletrs and others config variables
-    eval `nvram_buf_get 2860 natEnabled use_snatDMZEnable DMZIPAddress DMZNATLoopback PortForwardEnable IPPortFilterEnable WANPingFilter \
+    eval `nvram_buf_get 2860 natEnabled use_snat DMZEnable DMZIPAddress DMZNATLoopback PortForwardEnable IPPortFilterEnable WANPingFilter \
           RemoteSSH RemoteSSHPort RemoteFTP FtpPort RemoteTelnet RemoteManagement RemoteManagementPort \
           dhcpEnabled ipt_account upnpEnabled igmpEnabled xupnpd SmbEnabled TransmissionEnabled TransRPCPort TransInPort TransAccess snmpd \
           parproutedEnabled PrinterSrvEnabled chilli_net vpnType vpnNAT l2tp_srv_enabled MODEMENABLED store_ttl store_ttl_mcast mss_use_pmtu IPv6AllowForward`

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


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

Упс спасиб, реальный ляп, банальная очепятка. Вот только это в тему разработка сразу надо бы раз разобрались что и где (что бы не переносить руками что геморно).

 

Посмотрел внимательнее, с NAT никакой ереси не будет, просто всегда будет юзаться маскарад что чуть медленнее SNAT но при работающем PPE пофигу. Так что сломан был только DMZ. Ещё раз спасибо.

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


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

Т.к. запланировано массовое приворачивание плюшек с релизами торопиться не будем дабы не наплодить регрессий в бинарях, а значит желающие пощупать эти плюшки (заодно потестить) озадачиваются сборкой у себя. Вся сборка сводиться к 2м командам описанным в README, таргет для серийных однобэндов MT7620-2T2R-8M для LowCost серийных дуалбэндов MT7620-2T2R-MT7610-1T1R-5GHZ-8M.

 

Если вы сами правите что-то и считаете это полезным не только вам - мы готовы рассмотреть включение ваших изменений в основную ветку. Оформлено оно должно быть как diff к текущей ветки. Самое простое это стянуть чистую ветку, наложить свои правки сделать git commit . -m "название чего направили" затем git show > <filename>.patch

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


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

Собираю наверное последниюю из 3.3.х серии прошивку 3.3.14. Данная версия полностью стабильна, все известные на данный момент проблемы для однобэндов полностью закрыты (включая репорты от клиентов). По дуалбэндам остаётся пара шероховатостей в 7610 драйвере которые могут проявлять себя с некоторыми клиентами от самсунг при включении поддержки 80МГц в VHT (работаем). Глюк на самом деле в самсунговских дровах, точнее несовметимость ибо Nexus с тем же радио работает в 80МГц без проблем, но попробую ещё раз обойти со своей стороны, благо особого смысла на 100Мбит устройствах в 80МГц полосе особо нет, при 40МГц упираемся в 100Мбит полудуплекса что заглаза для всех мобильных клиентов (больше обычно у них проц не вытягивает).

 

В 3.4.х запланировано полное "распиливание" настроек радио, измениться формат nvram для дуалбэндов, появиться возможность полностью независимо управлять радиомодулями по сути рассматривая их как отдельные устройства, что позволит например огранизовать схему объединения 2х сетей работающих в разных диапазонах через 3е клиентское устройство параллельно с работой WDS в обоих диапазонах и прочие подвыверты. Но это на некоторое время развалит текущую ветку и потребует доп времени на тестирование и отладку. Поэтому в продакшн рекомендую не пытаться пока сползти на 3.4, а оставаться на 3.3.х ветке, попробуем обойтись малой кровью при распилинге, однако проблемы наверняка всплывут.

 

Так же параллельно будем доводить до ума 7621 базу, допинывать китайцев по tr-069 и bandsteering демону, допил режима хотспота. В результате появиться возможность выпуска решений ориентированных на разворачивания 802.11 сетей для массового доступа, а так же AP/Router для корпоратов включая большие офисные сети.

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


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

Некоторое изменение в планах.

Внеочередной 3.3.15 релиз (стопка мелких багфиксов в т.ч. в радио, на данный момент именно эта версия рекомендована для повседневного использования).

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

И только после этого в 3.5.х ветке распил управления радио (то что описано выше).

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


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

Всем кто брал на тест дуалбэнд сэмплы крайне рекомендую обновиться до 3.3.19, в новом драйвере китайцы таки удосужились пофиксить железные косяки 7610. Вообще в 3.3.х ветке довольно много пришлось фиксить для 7610 и без китайцев.

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


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

Такс, чуток ещё изменения по планам. Зарелизил 3.4.1 основные изменения это синхронизация фиксов с 5.0.0.0 SDK + правки для дуалбэндов на тему совместимости с "чужими" клиентами в VHT режиме + прочая мелочь.

 

В 3.4.х ветке будет ещё минимум 2-3 релиза (в планах допилить хотспот и закончить подготовку к распилу логики т.е. обеспечить корректное заполнение nvram в режиме 2х независимых областей для разных радиомодулей), плюс возможно ещё какие-то фиксы по 7610.

 

В общем тем кто брал дуалбэнды на пробу желательно обновиться. Остальным не критично.

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


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

Опубликовал 3.5.0 версию https://sourceforge.net/projects/wive-ng/files/wive-ng-mt/test-only/ .

В ней кроме фиксов ошибок осуществлён переход на новый драйвер для всех 762x устройств.

 

Из новых плюшек.

1) поддержка Intrusion Detection (IDS) позволяет задать следующие ограничения:

Authentication flood threshold

Association request flood threshold

Reassociation request flood threshold

Probe request flood threshold

Disassociation flood threshold

Deauthentication flood threshold

EAP request flood threshold

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

2) Начало реализации поддержки роуминга, пока только лимиты:

Limit probe request per client

Reject auth req due to weak signal

Ignore auth req due to weak signal

Reject assoc req due to weak signal

Ignore assoc req due to weak signal

Ignore probe req due to weak signal

Auto disonnect sta if rssi low

Смысл дать возможность "спихнуть" или не дать соедениться клиентам по определённым критериям завязанным на уровень сигнала дабы обеспечить равномерное распределение клиентов по AP. Возможность лимитировать число клиентов по AP была всегда.

 

Сейчас разбираюсь с реализацией 802.11K/R в новых драйверах и пытаюсь въехать что нужно для реализации полноценной их поддержки. Похоже для их поддержки как и для BandSteering нужен внешний демон (и он есть в SDK но версия не актуальная).

 

Желающие присоединяйтесь, нужны эксперименты по вновь добавленным опциями, а так же всесторонние тестирование драйвера.

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


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

Я тут пытаюсь запилить локальное извращение со Stateless ipv4/ipv6 NAT, и наткнулся на такой момент, что в итоговом romfs/lib оказывается шлак lib*.a, lib*.so, lib*.la, это все для запуска бинарников ну совсем не впилось, но место занимает. Это так и задумывалось?

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


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

С чего вы взяли что не нужны? =) Ну отрубите их копирование в root Makefile и убедитесь что на выходе будет кирпич. Я вас расстрою но линкуются бинари у нас далеко не только статически.

 

Разве что *.la можно повыкидывать, но они о боже аж 8Кб занимают не пожатые.

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


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

Хм... Как-то привык, что lib*.so (не lib*.so.* !) исключительно для нужд линковщика. Ну да ладно. А вот lib*.a зачем? Эти-то каким образом рантайму понадобятся?

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


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

Вы грю посмотрите там половина это симлинки на lib*.so*. Нет там копий и лишнего особо ничего нет. Так что даже не парьтесь на эту тему.

 

Плюс я запускаю тут же блобики собранные на стороне собсно ХЗ как они там слинкованы.

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


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

Симлинки это уже разобрались. Я говорил про *.a - это же статика, они нужны только при статической линковке бинарников, и в работе вообще не участвуют (ибо уже находятся в пузе у бинарника). Завтра на работе прошью роутер сборкой с выпилиными *.a для проверки. Благо JIT есть тв случае чего :)

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


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

*.a там только stub`ы почти. Давно порывался их выкинуть, но помню что наступал на грабли с развалом части юзерспэйса в RTNL ветки. Разбираться откровенно лень ибо даже если лежит 2 версии static и shared одной либы то после прохода lzma поверх суммарный результирующий объём отличается на байты буквально.

 

JTAG нафиг не нужен. И даже UART для восстановления. Как поднять если что описано в соседней теме. Однако если трогаете логику руками лучше таки иметь консольник под рукой. Если бут не будете трогать то JTAG не понадобиться.

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


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

Провёл ревизию, проверил что никто и никак не касается статик либ, выкинул копирование. Итог аж 70кб освободилось =)))) Ну фиг с ним пусть будет. См git.

 

Я конечно помню как я на 2х Мб флэше трахался за каждый байт. =) Тут свободного места пока полно. Отказ от STA драйвера (APCLI его уже полностью заменяет только надо плюшки типа сканера перенести) даёт выигрыш заметно более существенный.

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


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

Залил на sf.net 3.5.1 версию, те что в test-only это с новым драйвером, те что в корне 7620 со старым. К сожалению в новом драйвере всплыли ещё шероховатости и полный переход на него пока затягивается потому собираю 2 версии.

 

Залил 3.5.2 на новом драйвере, запустил таки STA режим на нём, думал уже тухлое дело, но удалось разобраться где накосячили.

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


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

Провёл ревизию, проверил что никто и никак не касается статик либ, выкинул копирование. Итог аж 70кб освободилось =)))) Ну фиг с ним пусть будет. См git.

 

Спасибо. У меня разница между 3.4.4 и 3.5.2 вышла в -480кб.

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


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

Новый драйвер компактнее вдвое + выкинул пока поддержку 802.11K/R ибо надо разбираться сболее критичными глюками в новом дрове, выкинул iapp демона т.к. без K/R не нужен. В итоге да больше 400кб получилось. А просто выкидывание статик копий дало 70кб на 8Мб таргете для дуалбэндов и около 150 на однобэндах. Как бы не лишнее место конечно.

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


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

Внеплановый 3.5.3, окромя фикса GN режима для MBSSID некоторой косметики в 2.7.0.2 драйвере добавлена поддержка простого Hotspot`a (nodogsplash). В рожу пока не выносил, что бы попробовать достаточно сказать nvram_set nodogsplash_enable 1 && reboot. Необходимые для запуска параметры читаются из nvram, остальные параметры пока лежат в виде темплэйта в /etc/nodogsplash, там же лежит страничка приветствия.

 

Так же проверено, комплексный шейпер прекрасно работает в паре с nodogsplash.

 

Кто бы ещё ввернул к этому простому и шустрому captive порталу авторизилку через соц сети (можно договориться за денежку, думаю НАГ в пределах разумного подкинет ибо мы и так загружены да и опыта в работе с апи соц сетей 0), цены бы не было.

 

Chillispot в процессе доводки, чуть чуть осталось и можно будет использовать с такими сервисами авторизации как mifi/hotspotsystem и другими, как и прикрутить к практически любому биллингу. Не откажусь от помощи тех кто уже собаку на coova-chilli съел.

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


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

Понадобилось замутить проброс L2 между несколькими точками, с осложнением в виде нескольких vlan в туннеле. Был рожден приложенный патч, добавляющие l2tp в в ip и соотвествующую поддержку в ядре. В отличии от EoIP возможна работа через NAT

patch0.zip

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


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

Глянул мельком, щас переделаю немного так что бы можно было просто включив в ядре приюзать и затяну, спасибо. Мне к сожалению такое дело тестить не на чем и как конфигурить это дело с трудом представляю. Для полноценной интеграции нужен хотя бы пример на шелле как коннектиться и дырку куда коннектиться, наверняка нужно ещё в нетфильтре что-то добавить и т.д. Разбираться со столь редким кейзом с нуля чесслово желания нет. Ну и надо ещё посмотреть не вылезет ли регрессия на классическом варианте L2TP при включении его V3 в ядре т.к. наверняка добавиться стопка проверок в тайм критикал местах.

 

В общем накидаете скриптик для конфигура и дадите току коннект куда протестить - вытащим в рожу.

 

Да лишнего нараскоментировали в ip, gre/can и прочее не упились для этого, достаточно ipl2tp добавить.

 

P.S. Сделал.

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


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

Как делать в роже даже не представляю. Рисовал скрипт создания всего этого счастья и потом fs save. А делалось все вот по такому примеру (выдрано из какого-то местного холиварного мегатреда):

 

(1) laptus# ip l2tp add tunnel tunnel_id 1 peer_tunnel_id 1 udp_sport 5000 udp_dport 5000 encap udp local 192.168.1.39 remote 213.x.x.x
(2) laptus# ip l2tp add session tunnel_id 1 session_id 1 peer_session_id 1
(3) laptus# ip a a 192.168.30.2/24 dev l2tpeth0

(4) gw# ip l2tp add tunnel tunnel_id 1 peer_tunnel_id 1 udp_sport 5000 udp_dport 11932 encap udp local 213.x.x.x remote 188.134.x.x
(5) gw# ip l2tp add session tunnel_id 1 session_id 1 peer_session_id 1
(6) gw# ip a a 192.168.30.1/24 dev l2tpeth0

теперь у нас есть l2-линк: счастье, радость, слёзы ;)
Попробуем на нём сделать что-то полезное:

(7) laptus# ip link add link l2tpeth0 name vlan5 type vlan id 5
(8) laptus# ip link add link l2tpeth0 name vlan6 type vlan id 6
(9) laptus# ip a a dev vlan5 10.1.5.2/24
(10) laptus# ip a a dev vlan6 10.1.6.2/24

(11) gw# ip link add link l2tpeth0 name vlan5 type vlan id 5
(12) gw# ip link add link l2tpeth0 name vlan6 type vlan id 6
(13) gw# ip a a dev vlan5 10.1.5.1/24
(14) gw# ip a a dev vlan6 10.1.6.1/24

laptus# ping 10.1.6.1
PING 10.1.6.1 (10.1.6.1) 56(84) bytes of data.
64 bytes from 10.1.6.1: icmp_req=1 ttl=64 time=5.77 ms
64 bytes from 10.1.6.1: icmp_req=2 ttl=64 time=13.4 ms
64 bytes from 10.1.6.1: icmp_req=3 ttl=64 time=17.6 ms
^C
--- 10.1.6.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 5.776/12.295/17.671/4.922 ms

при этом tcpdump -e -n -i l2tpeth0 на gw покажет:

16:44:30.055082 b2:19:70:63:90:85 > 76:a9:12:12:c7:30, ethertype IPv4 (0x0800), length 98: 192.168.30.2 > 192.168.30.1: ICMP echo request, id 26927, seq 1376, length 64
16:44:30.055116 76:a9:12:12:c7:30 > b2:19:70:63:90:85, ethertype IPv4 (0x0800), length 98: 192.168.30.1 > 192.168.30.2: ICMP echo reply, id 26927, seq 1376, length 64
16:44:30.990689 b2:19:70:63:90:85 > 76:a9:12:12:c7:30, ethertype 802.1Q (0x8100), length 102: vlan 6, p 0, ethertype IPv4, 10.1.6.2 > 10.1.6.1: ICMP echo request, id 27037, seq 2, length 64
16:44:30.990734 76:a9:12:12:c7:30 > b2:19:70:63:90:85, ethertype 802.1Q (0x8100), length 102: vlan 6, p 0, ethertype IPv4, 10.1.6.1 > 10.1.6.2: ICMP echo reply, id 27037, seq 2, length 64

l2tpeth0 вполне можно добавить в бридж и утащить через ip-сеть весь тегированный трафик. если же вам этого показалось мало, можно сказать:

ip l2tp add session tunnel_id 1 session_id 2 peer_session_id 2

и у вас появится l2tpeth1 и возможность "протащить" еще 4k vlan'ов.

 

У меня все ограничилось командами 1,2,4,5 с загоном l2tpeth0 в br0. После этого кассовые аппараты/весы и видеокамеры перестали подозревать о существовании друг друга. Полную сотку выжать из этого даже и не пытались, но рабочие 25-30М держится стабильно.

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


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

Эх, мне бы такое лет эдак семь назад, вот было бы счастье... :)

Ладно, сегодня нарисую в "морде".

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


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

Полную сотку выжать из этого даже и не пытались, но рабочие 25-30М держится стабильно.

 

Не вижу причин почему не быть сотке. Тут сильно меньше уровней чем в классическом L2TP. Нет PPP нет ROUTE нет NAT, думаю должен сотку прожевать если на WAN IPOE.

 

В общем посмотрел, как и думал добавляется стопка проверок в time critical секции, т.е. производительность классического L2TP упадёт в хламину (ну не в хламину, но замето). Так что нет смысла вытаскивать в рожу, кому надо соберёт сам, терь это решается тупо правкой конфига ядра. Возможно когда-нить и будет иметь смысл это дело вынести в морду.

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


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

Гость
Эта тема закрыта для публикации сообщений.