[sfstudio]

Что там у вас в гит потерялось?

http://gitorious.org/wive-rtnl-ralink-rt30...er/etc/Wireless

 

Хватит проблемы своего дистра перекладывать то на фирмварь то на гит.

[NiTr0]

Да да, любая кросскомпиляция вызывает определённые неудобства как ты не из?(*)(сь.

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

 

А оно мне нужно возиться с чужими железками?

А я это от вас требую? :)

Это - всего лишь констатация факта, что и ваш дистр as-is не является рабочим искаропки на моей железке/железках, и что мне его придется пилить, обеспечивая совместимость. Как минимум - добавить кой-какие апплеты бизибокса (тот же tr дабы скриптами при первоначальной инициализации можно было безболезненно вытянуть из конфига uboot'а мак-адрес девайса), разобраться с конфигом свича, с GPIO led'ами и т.д. И неизвестно, что вылезет еще в процессе.

 

У всех собирается к вас нет.

Именно.

 

Чаще обновляйтесь да. А пустые диры в гит не заносятся.

16 декабря все стянул собссно. Обновлюсь сейчас.

Кстати неплохо бы было бинарники тулчейна + еще кой-чего из гита нах исключить.

 

В один поток компиляция сделана далеко не ради того чтобы затормозить процесс сборки. Это домашнее задание подумать почему на ранней стадии отладки сборка в 1н поток must have.

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

 

Что тут не верно? Что compile это скрипт для сборки на финальной стадии? На время решения проблем сборки кораздо проще использовать make с конкретными целями?

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

А обработка ошибок в нем какбы должна присутствовать, или конструкции вида make || exit 1 недопустимы в нем по неким соображениям?

 

И почему это стало моей проблемой или проблемой прошивки поддержка древнючего окружения для сборки?

Вполне себе свежее окружение. Насчет версии либтула опечатался несколько - 2.2.10, но роли не играет. Т.к. по отзывам подобные ошибки выплывают на 2.2 ветке при попытке собрать пакет, ориентированный на libtool 1.5.

 

fakeroot отменили? И как это должно напрягать?

Не отменили, но это требует допиливания. Вот собссно патч, если интересно:

diff --git a/Makefile b/Makefile
index df2d045..733a6fa 100644
--- a/Makefile
+++ b/Makefile
@@ -295,13 +295,13 @@ romfs.post:
        cp -vf  $(ROOTDIR)/etc/rc.d/rcS $(ROMFSDIR)/bin/rcS
        cp -vf  $(ROOTDIR)/etc/rc.d/start $(ROMFSDIR)/bin/start
        tar -cp --gzip etc > $(ROMFSDIR)/rwfs.gz
-       tar -zxvf dev.tgz
-       cp -vf dev.tgz $(ROMFSDIR)/dev.gz
-       cp -rfv dev/* $(ROMFSDIR)/dev
-       rm -fr $(ROOTDIR)/dev
+       fakeroot -s $(ROOTDIR)/fakeroot_db tar -zxvf dev.tgz
+       fakeroot -s $(ROOTDIR)/fakeroot_db -i $(ROOTDIR)/fakeroot_db cp -vf dev.tgz $(ROMFSDIR)/dev.gz
+       fakeroot -s $(ROOTDIR)/fakeroot_db -i $(ROOTDIR)/fakeroot_db cp -rfv dev/* $(ROMFSDIR)/dev
+       fakeroot -s $(ROOTDIR)/fakeroot_db -i $(ROOTDIR)/fakeroot_db rm -fr $(ROOTDIR)/dev
        cd $(ROMFSDIR)/bin && ln -fvs ../etc/scripts/* . && cd $(ROOTDIR)
        ./strip.sh
-       $(MAKEARCH) -C vendors romfs.post
+       fakeroot -i $(ROOTDIR)/fakeroot_db $(MAKEARCH) -C vendors romfs.post
        -find $(ROMFSDIR)/. -name CVS | xargs -r rm -rf

.PHONY: image

 

Насчёт вменяемости железа ещё не факт.

Думаю, все же будет не хуже популярного гуана в результате.

 

У меня ровно обратный опыт. То дерьмо что наковырено ралинком попило кровушки мама не горюй.

Я где-то упоминал ралинковский?

 

Да, на счёт стоимости кодэков вы сильно заблуждаетесь. Те же самые дешовые риалтэки (совместимые с AC97) обычно умеют i2c/i2s при цене просто в копейки и значительно дешевле своих собратьев под юбзду.

Не припоминаю таких что-то. ALC250 к примеру - не умеет ничего кроме АС97.

 

Что там у вас в гит потерялось?

http://gitorious.org/wive-rtnl-ralink-rt30...er/etc/Wireless

 

Хватит проблемы своего дистра перекладывать то на фирмварь то на гит.

И где там RT2860? :) Если гит не поддерживает пустые директории - неплохо было бы ее создавать в скрипте сборки при отсутствии что ли... Понимаю, мелочь, но все же.

[sfstudio]

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

Какая нафиг доработка напильником? Трудно пересобрать тулчейн на той машине на которой планируется сборка? Аж один скрипт стартануть. Да и не обязано оно собираться везде.

 

А я это от вас требую? :)

Это - всего лишь констатация факта, что и ваш дистр as-is не является рабочим искаропки на моей железке/железках, и что мне его придется пилить, обеспечивая совместимость.

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

 

Как минимум - добавить кой-какие апплеты бизибокса

Это так сложно сделать? Ужжас. Как страшно жить.

 

(тот же tr дабы скриптами при первоначальной инициализации можно было безболезненно вытянуть из конфига uboot'а мак-адрес девайса),

Т.е. вернуться к практике от которой я ухожу вполне целенаправленно. Может проще взять чистый СДК и не пудрить мозг?

 

разобраться с конфигом свича, с GPIO led'ами и т.д. И неизвестно, что вылезет еще в процессе.

А что с ними не так? И с конфигом свича в чём проблема? Вроде всё работает как часы. Ах да, ***линки с их хитрожопой разводкой GPIO. Ну дык кто мешает это поправить если вам это нужно? И причём тут удобство неудобство. Короче лишь бы потрындеть.

 

16 декабря все стянул собссно. Обновлюсь сейчас.

Кстати неплохо бы было бинарники тулчейна + еще кой-чего из гита нах исключить.

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

 

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

Кого кого сборка? Вы со словом тулчейн пожалуйста определитесь, а то мы о разных вещах говорим. Да и кто сказал что тулчейн более одного раза необходимо собирать?

 

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

А обработка ошибок в нем какбы должна присутствовать, или конструкции вида make || exit 1 недопустимы в нем по неким соображениям?

А я то думаю это просто мкрипт написанный мной чтобы ручками не париться.. А тут оказывается вот оно как. Вот давайте вы будете рассказывать о том что такое compile скрипт кому-нить другому?

 

 

Вполне себе свежее окружение. Насчет версии либтула опечатался несколько - 2.2.10, но роли не играет. Т.к. по отзывам подобные ошибки выплывают на 2.2 ветке при попытке собрать пакет, ориентированный на libtool 1.5.

Почему у меня с 2.4 либтул и ещё у десятков людей никаких проблем со сборкой не возникло? Вы всерьёз думаете что вы первый и вот сейчас пришли и раскрыли всем глаза на наше трудное детство?

 

Не отменили, но это требует допиливания. Вот собссно патч, если интересно:

Не интересно ибо использую совсем иной подход с контейнерами.

 

Думаю, все же будет не хуже популярного гуана в результате.

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

 

Я где-то упоминал ралинковский?

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

 

Не припоминаю таких что-то. ALC250 к примеру - не умеет ничего кроме АС97.

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

 

 

И где там RT2860? :)

Упс. Блин запутался чуток. Кстати пора там ревизию навести и избавиться от этих ошмётков.

 

Если гит не поддерживает пустые директории - неплохо было бы ее создавать в скрипте сборки при отсутствии что ли...

Так и происходит однако.

 

Понимаю, мелочь, но все же.

Это как бы не мелочь, просто проспал. В остальном см выше.

[sfstudio]

P.S. В любом случае этот разговор думаю бессмысленно на форуме разводить т.к. смысловой нагрузки почти ноль. Хочется подискутировать - в Jabber.

[NiTr0]

А что с ними не так? И с конфигом свича в чём проблема? Вроде всё работает как часы. Ах да, ***линки с их хитрожопой разводкой GPIO. Ну дык кто мешает это поправить если вам это нужно? И причём тут удобство неудобство. Короче лишь бы потрындеть.

Буду править, куда деваться. Со свичом - немного в конфиги не вник. С LED'ами - уже нашел что где выведено, буду смотреть как это прикрутить на досуге.

 

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

Пилю понемногу.

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

 

Кого кого сборка? Вы со словом тулчейн пожалуйста определитесь, а то мы о разных вещах говорим. Да и кто сказал что тулчейн более одного раза необходимо собирать?

О том самом тулчейне. Который приходится пересобирать после каждого обновления системных библиотек или компилятора, которое случается порой. Ессно, говорю не о RHEL и иже с ним, где годами латаются/допиливаются бэкпортами одни и те же версии софта.

 

Почему у меня с 2.4 либтул и ещё у десятков людей никаких проблем со сборкой не возникло? Вы всерьёз думаете что вы первый и вот сейчас пришли и раскрыли всем глаза на наше трудное детство?

Все оказалось банальнее - оказывается, надо было на выкачаном из гита срезе сделать вначале make clean дабы поприбивать весь хлам, висящий в гите с прошлых компиляций.

 

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

Затратами времени и кол-вом пойманных в процессе багов.

 

P.S. кстати, ваш udhcpc скрипт не понимает classful routes (опция 33)... Допилить-то немного в принуипе, если нужно - на досуге сделаю патч.

Изменено 19 декабря, 2010 пользователем NiTr0

[sfstudio]

Буду править, куда деваться. Со свичом - немного в конфиги не вник. С LED'ами - уже нашел что где выведено, буду смотреть как это прикрутить на досуге.

Там всё просто.

 

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

Они чистяться по .clean. Если что-то недочищается дело 10е.

 

О том самом тулчейне. Который приходится пересобирать после каждого обновления системных библиотек или компилятора, которое случается порой. Ессно, говорю не о RHEL и иже с ним, где годами латаются/допиливаются бэкпортами одни и те же версии софта.

Завязан он только на glibc. Который обновляется крайне редко, а в стабильных дистрах за срок жизни не обновляется ни разу.

 

Все оказалось банальнее - оказывается, надо было на выкачаном из гита срезе сделать вначале make clean дабы поприбивать весь хлам, висящий в гите с прошлых компиляций.

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

 

Затратами времени и кол-вом пойманных в процессе багов.

И?

 

P.S. кстати, ваш udhcpc скрипт не понимает classful routes (опция 33)... Допилить-то немного в принуипе, если нужно - на досуге сделаю патч.

Есть желание - допилите. В моём распоряжении нет операторов использующих 33ю опцию, а поднимать для тестирования dhcp сервер и настраивать всё это дело откровенно лень, хоть и не долго. Да и других проблем навалом.

[podarok66]

Купил китайский роутер WS-WR511N2 , в принципе аналог Winstar'a. Подолбался пару дней в тщетных попытках поднять VPN и понял, что это не для меня. Поизучав немного панель управления, понял, что надо перепрошиться, тем более, что такая возможность предусматривалась в вебморде. Долго искал сначала сайт производителя, не нашел. Потом сторонние прошивки, тоже никак. Англоязычные форумы как правило утверждают, что подходит прошивка от Aceex-NR22. Но вчитываясь в сообщения, начинаешь понимать, что ни один из советчиков не пробовал сам того, что советует. А погробленных роутеров доверчивых юзеров упоминается не один и не два. Потом следует совет по реанимации через console, затем, когда роутер окончательно сдыхает, предлагается выпаивать чип для перепрограммирования. И уже потом заявляется, что у самого советчика такого оборудования нет и не было.

Сюда попал случайно, после полутора недель поисков, прошу узнал по скрину вебморды. Прошился на раз, настроил роутер минут за 10. Канал 10 Мбит работает на полную. Wi-Fi потерь в скорости не дает. Не смог подключить только КПК iPAQ 2790 , но там проблемы с Wi-Fi всегда, видимо дрова в него вшиты более чем отвратительные. Все остальное, комп по шнурку, второй комп и ноут через Wi-Fi без вопросов. Наблюдается кратковременный(5-7 секунд) разрыв канала непериодично, но не часто , раз в 30-90 минут. В точности утверждать, что сие творит именно роутер не могу, ибо провайдер не надежен, да и линия до поселка есть конвергентное решение, то бишь лазерный луч на 2,5 км примерно. Больше вопросов не возникло. А, да!!! Если можно, добавьте в первый пост первоначальный логин и пароль, а то угадывал)))

В сравнении с D-Link-320 с прошивкой от производителя оборудование радует не переставая. Спасибо преогромное!

Скажите, а локализация - этого не предвидится? А то я в аглицком путаюсь и приходится постоянно что-то себе напоминать словарем. Не сочтите вопрос наглостью... Я вам в любом случае благодарен.

[sfstudio]

Локализация не предвидится. Логины и пароли для всего оборудования акорп дефолтовые идентичны так что никто никуда ничего добавлять не будет.

[ATVATOR]

sfstudio.

приветствую.)

заглянул в гит, а там целое море изменений и улучшений за почти месяц с последнего релиза, работа кипит.

интересно, когда планируете зарелизить новый билд прошивки?

[sfstudio]

Слишком много проблем чтобы релизить. Народу с РТГ32 например потребуется смена бута если я не решу проблему с перезаписью бутом части ядра (а я её не решу). Короче всем кому хочется свежака берёте и собираете из гита, проблем с этим никаких.

[NiTr0]

Покопал немного дистр. Несколько замечаний: checkconfig скрипт - проверка/исправление мака не работает, вылетает на строке

if [ $CHECKMAC != "NO" ] && [ ! -f /var/run/goahead.pid ]; then

(т.к. переменная не определена/пустая). etc/scripts/fs - в районе 70й строки (обнуление rwfs) непонятно зачем забивается все рандомом + начало переписывается паттерном 1234567890. В веб-морде - PPPoE от чего-то назван VPN-соединением (хотя таковым не является, а является просто туннелем). Ну и + прочие мелочи типа присутствующей, но ненужной реально и неработающей генерации маков и т.д.

 

Из того, что возможно вам будет интересно:

Допилил поддержку classful routes + сделал вменяемую подержку маршрутов через интерфейс (актуально для некоторых сетей, раздающих юзерам адреса /32 + маршрут через интерфейс на гейт + маршруты через гейтвей - у нас такое пока в диковинку, а вот у буржуев таки имеется, + прекрасно поддерживается что виндой, что dhcpcd), патч в аттаче.

Также выкинул пакованный /etc из образа - смысла его там держать не вижу, проще подмонтировать rootfs где-то в /var/root, скопировать все оттуда в etc после чего прибрать за собой, т.о. экономится 60кб флэша (ибо пожатый etc уже в squashfs не пожмется более), изменения тривиальные, строк 5, могу выложить патч если нужно.

Заточки/допиливания под свои нужды (типа вытягивания мака из конфиг-зоны юбута, предотвращения ее затирания скриптом fs и т.д.) - предлагать не буду, если кому надо будет - где-то вывешу патчик с заточками, как до ума все это доведу.

 

Остался вопрос по поводу ледов: как я понял, смены статус-леда WAN коннекта с желтого на зеленый при установке туннеля в goahead нет и придется пилить самому? :) И что там делают аж 3 определения WPS_LED'а (WPS_LED_ORANGE, WPS_LED_GREEN в wps.h и WPS_AP_LED_GPIO в wpsledpbc.c) ? wpsledpbc.c вроде как даже не компилится?

 

P.S. Кстати, то, что каждая запись в нврам (а их бывает не одна и не две в процессе загрузки или смены конфига) сразу же туда пишется - не очень кошерно... Все-таки флэш есть флэш, + ротация блоков отсутствует (я прав? глубоко не копал), лимит циклов перезаписи - ограничен (в зависимости от чипа - заявлено от 10К до 100К циклов, на деле - может оказаться и меньше)...

routes.patch.gz

[NiTr0]

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

Заметил, что если роутер стартует с погашенным WAN - при подтыкании кабеля после загрузки не принимает IP по DHCP.

 

P.S. Где настраивается реакция на GPIO события? Драйвер или юзер-левел? Reset при коротком нажатии считает себя WPS кнопкой (длительное - отрабатывает адекватно), соответственно, WPS кнопка молчит - не смертельно, но некрасиво. С GPIO LED тоже пока не копался - вопрос по ним все еще актуален.

 

UPD:

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

 

UPD2:

Кнопки ведут себя как нужно; один минус - "длинное" нажатие на кнопку считалось начиная с 200 мс :) В драйвере это забито хардкодной константой, у себя поправил 200L на 2*HZ, заодно увеличил интервал короткого нажатия до 100мс (запас на дребезг и т.д.). Патч приаттачил, хотя изменения тривиальные.

ralink_gpio.patch.gz

Изменено 25 декабря, 2010 пользователем NiTr0

[sfstudio]

Покопал немного дистр. Несколько замечаний: checkconfig скрипт - проверка/исправление мака не работает, вылетает на строке

if [ $CHECKMAC != "NO" ] && [ ! -f /var/run/goahead.pid ]; then

(т.к. переменная не определена/пустая).

Да как так? =) Всё работает.

 

etc/scripts/fs - в районе 70й строки (обнуление rwfs) непонятно зачем забивается все рандомом + начало переписывается паттерном 1234567890.

А что смущает? =)))

 

В веб-морде - PPPoE от чего-то назван VPN-соединением (хотя таковым не является, а является просто туннелем).

Всё дело в терминологии.

VPN (англ. Virtual Private Network — виртуальная частная сеть) — обобщённое название технологий, позволяющих обеспечить одно или несколько сетевых соединений (логическую сеть) поверх другой сети (например, Интернет).

 

Что pppoe что pptp, что даже gre вполне подходит под эту классификацию, транспорт не важен абсолютно.

 

Ну и + прочие мелочи типа присутствующей, но ненужной реально и неработающей генерации маков и т.д.

Кому не нужной?

 

Из того, что возможно вам будет интересно:

Допилил поддержку classful routes + сделал вменяемую подержку маршрутов через интерфейс (актуально для некоторых сетей, раздающих юзерам адреса /32 + маршрут через интерфейс на гейт + маршруты через гейтвей - у нас такое пока в диковинку, а вот у буржуев таки имеется, + прекрасно поддерживается что виндой, что dhcpcd), патч в аттаче.

Что значит вменяемую? Тема не раскрыта.

 

Также выкинул пакованный /etc из образа - смысла его там держать не вижу, проще подмонтировать rootfs где-то в /var/root, скопировать все оттуда в etc после чего прибрать за собой, т.о. экономится 60кб флэша (ибо пожатый etc уже в squashfs не пожмется более), изменения тривиальные, строк 5, могу выложить патч если нужно.

rootfs может уже не существовать на флэше например после перезаписи mtd при обновлении фирмвари, в то же время архив rwfs всё ещё будет доступен (да да иногда такой финт ушами нужен). Экономии таким финтом практически никакой достигнуть не выйдет. Проверено эксперементально.

 

Заточки/допиливания под свои нужды (типа вытягивания мака из конфиг-зоны юбута, предотвращения ее затирания скриптом fs и т.д.) - предлагать не буду, если кому надо будет - где-то вывешу патчик с заточками, как до ума все это доведу.

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

 

Остался вопрос по поводу ледов: как я понял, смены статус-леда WAN коннекта с желтого на зеленый при установке туннеля в goahead нет и придется пилить самому? :) И что там делают аж 3 определения WPS_LED'а (WPS_LED_ORANGE, WPS_LED_GREEN в wps.h и WPS_AP_LED_GPIO в wpsledpbc.c) ? wpsledpbc.c вроде как даже не компилится?

Там осталось много ошмётков от старой реализации, часть кода вообще никогда не будет скомпилена. Нужно чистить, но откровенно лень.

 

P.S. Кстати, то, что каждая запись в нврам (а их бывает не одна и не две в процессе загрузки или смены конфига) сразу же туда пишется - не очень кошерно... Все-таки флэш есть флэш, + ротация блоков отсутствует (я прав? глубоко не копал), лимит циклов перезаписи - ограничен (в зависимости от чипа - заявлено от 10К до 100К циклов, на деле - может оказаться и меньше)...

1) не каждая а по возможности агрегируется в блоки и пишется через bufset.

2) учитывая сколько раз за день я шью флэш и дёргаю нврам в нормальном режиме то же число перезаписей за всю жизнь устройства врятли удасться достигнуть

 

Флэш сегодня позволяет особо не заморачиваться с такими вещами.

 

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

У нас не ожидается устройств с USB, а аж 2 опции в конфигах включить если такие устройства будут дело 2х минут. Причём отдельным конфигом.

 

Заметил, что если роутер стартует с погашенным WAN - при подтыкании кабеля после загрузки не принимает IP по DHCP.

Никаких проблем не заместил с этим. Разберайтесь почему так происходит на вашем экземляре.

 

Кнопки ведут себя как нужно; один минус - "длинное" нажатие на кнопку считалось начиная с 200 мс :) В драйвере это забито хардкодной константой, у себя поправил 200L на 2*HZ, заодно увеличил интервал короткого нажатия до 100мс (запас на дребезг и т.д.). Патч приаттачил, хотя изменения тривиальные.

Ага, хотя не напрягает особо.

[sfstudio]

Так по роутам в вашей реализации въехал. Т.е. по сути решили запихать роуты из всех опций в одну переменную и разом внести? Ну да, так покрасивше будет. Главное не поймать проблемы с максимальной длинной переменной в ash. Что-то мне подсказывает, что там не всё так красиво. Нуно тестить на корбилайне у них там полный пи*()ц с числом маршрутов передаваемых через dhcp.

[sfstudio]

Да и не понял что у нас будет с dgw. В таком случае? Что-то тут не так. Если будет настроен один из туннелей то всё ясно, если нет то dgw не будет существовать. Или я что-то упустил?

 

Да, синхронизируйте изменения, я там выкинул костыль в части обновления адреса при поднятых туннелях. Так что нужно пересмотреть подход к этому делу и разобраться с dgw в текущем виде как мне кажется это работать по человечески не будет.

 

P.S. Да, забивание rwfs из рандома или заоборот затирание начала можно убить уже. Хотя не смертельно их наличие там.

[NiTr0]

Да как так? =) Всё работает.

В дефолтном конфиге CHECKMAC пустая. В итоге выражение разворачивается в if [ != "NO" ] ....

+ в дефолтовом конфиге забиты маки жестко - в итоге они не генерятся этой ф-ей

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

 

А что смущает? =)))

Бессмысленность этого. Достаточно забить нулями...

 

Что pppoe что pptp, что даже gre вполне подходит под эту классификацию, транспорт не важен абсолютно.

PPTP/GRE - подходят, они работают поверх IP сети. PPPoE - не особо подходит, оно имеет право называться VPN лишь немногим более, чем обычный TCP/IP.

 

Кому не нужной?

В коде она не работает. Да и вообще, в заводских железках менять мак при сбросе - не есть хорошо.

 

Что значит вменяемую? Тема не раскрыта.

Пример: локалка, юзерам выдаются IP адреса с маской /32, выдается маршрут на гейтвей через интерфейс, и маршрут по умолчанию через гейтвей. Винда это прекрасно переваривает, классический dhcpcd - тоже, железяки типа дир-100, дир-300 на родной вари (не копался в кишках что там за дхцп клиент) - тоже переваривают. Собссно, поправил скрипт чтобы это все работало и с udhcpc,

 

rootfs может уже не существовать на флэше например после перезаписи mtd при обновлении фирмвари, в то же время архив rwfs всё ещё будет доступен (да да иногда такой финт ушами нужен).

Если не секрет - где это может сгодиться? Да и не факт, что архив /etc считается с перезаписанной уже squashfs, если он уже давно ушел из кеша...

 

Флэш сегодня позволяет особо не заморачиваться с такими вещами.

Не уверен; во всяком случае я видел compactflash, пользуемую в фотоаппарате, которая "посыпалась"...

 

Никаких проблем не заместил с этим. Разберайтесь почему так происходит на вашем экземляре.

udhcpc скрипт от чего-то получает leasefail... хотя дхцп сервер прекрасно ему отсылает ответ.

 

Да, синхронизируйте изменения, я там выкинул костыль в части обновления адреса при поднятых туннелях. Так что нужно пересмотреть подход к этому делу и разобраться с dgw в текущем виде как мне кажется это работать по человечески не будет.

Ок, стяну изменения, посмотрю. Надобно в скрипте будет сделать проверку, кудой default route идет и если не через eth2.2 - не трогать его.

Изменено 26 декабря, 2010 пользователем NiTr0

[sfstudio]

В дефолтном конфиге CHECKMAC пустая. В итоге выражение разворачивается в if [ != "NO" ] ....

+ в дефолтовом конфиге забиты маки жестко - в итоге они не генерятся этой ф-ей

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

Всё ровно так и задуманно. Вы забываете что прошивка сугубо для Acorp т.е. маки должны лежать в диапазоне зарезервированном для Acorp. CHECKMAC переменная ровно для того и нужна чтобы отключить это поведение.

# cat RT2860_default_novlan-1T1R | grep CHECKMAC
CHECKMAC=YES

Это что касается дефолтов.

 

Бессмысленность этого. Достаточно забить нулями...

Это делалось на время отладки. Сейчас и нулями забивать смысла нет, достаточно записать 1н байт произвольный в раздел.

 

 

PPTP/GRE - подходят, они работают поверх IP сети. PPPoE - не особо подходит, оно имеет право называться VPN лишь немногим более, чем обычный TCP/IP.

Да уж конечно =))) Давайте обзовём его вланом ? =))) Короче, этот момент не обсуждается, название раздела да обсуждаемо, но все ppp туннели, авторизаторы и даже globax будут там без вариантов. Это из опыта работы с SOHO юзерами единственный вариант не устраивать взрыв мозга. Да и в любом случае pppoe чётко попадает под вышеозначенное определение и не противоречит ему. Уж о pppoe relay между сегментами не упоминаю.

 

В коде она не работает. Да и вообще, в заводских железках менять мак при сбросе - не есть хорошо.

При сбросе какраз таки ничего не меняется. А fullreset это крайняя мера. Опять же обращаю внимание что софт затачиватся под Acorp а не под сферического коня в вакууме. Так что мак должен лежать в рамках того что отдано акорпу. Кого не устраивает такое положение дел - берут сырцы, делов на 2 секунды.

 

Пример: локалка, юзерам выдаются IP адреса с маской /32, выдается маршрут на гейтвей через интерфейс, и маршрут по умолчанию через гейтвей. Винда это прекрасно переваривает, классический dhcpcd - тоже, железяки типа дир-100, дир-300 на родной вари (не копался в кишках что там за дхцп клиент) - тоже переваривают. Собссно, поправил скрипт чтобы это все работало и с udhcpc,

Там и стоит udhcpc только очень древний а не из состава бизибокса. Вот только у них совсем другие проблемы.

 

r

Если не секрет - где это может сгодиться? Да и не факт, что архив /etc считается с перезаписанной уже squashfs, если он уже давно ушел из кеша...

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

 

Не уверен; во всяком случае я видел compactflash, пользуемую в фотоаппарате, которая "посыпалась"...

я тоже видел много какашек usb/cf и прочих померших от насилия. А в риалтэках вообще была бага где каждый 10мс перезаписывался один и тот же блок spi флэшки неизвестного происхождения и за месяц протирал до дыр её. Человеческий NOR/SPI флэш угробить таким образом практически не реально.

 

udhcpc скрипт от чего-то получает leasefail... хотя дхцп сервер прекрасно ему отсылает ответ.

Возможно бьются данные. Закатать в прошивку tcpdump и посмотреть?

 

Ок, стяну изменения, посмотрю. Надобно в скрипте будет сделать проверку, кудой default route идет и если не через eth2.2 - не трогать его.

Не совсем так. Вы таким образом исключите работу как wifi клиента. Проверять имеет смысл на соответствие wan_if/lan_if переменных, ну или около того. Сейчас голова забита предновогодними приготовлениями и чесслово не хочется разбираться. Но в лоб то что вы предлагаете в ряде случаев будет таки "рушить" логику. Короче смотреть нужно, а я даже девайс специально с собой брать не стал =) Нуно иногда отдыхать.

[NiTr0]

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

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

Я-то для себя допилю, но все же.

 

название раздела да обсуждаемо, но все ppp туннели, авторизаторы и даже globax будут там без вариантов.

Так я собссно о названии и говорил. Ибо не каждый туннель есть VPN, и не каждая VPN есть туннелем. Себе сделал пока название как VPN/PPPoE (ближе всего к терминам винды), меньше у юзеров вопросов будет.

 

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

Uboot ведь держит мак (и прочий конфиг) отдельно - можно собссно и оттуда мак тянуть. Во всяком случае я так у себя сделал. Хотя - вам виднее.

 

Человеческий NOR/SPI флэш угробить таким образом практически не реально.

Реально. Я в свое время был счастливым обладателем сименса А60, у когорого его NOR флэш протерлась в месте расположения ФС. И это - не единичный случай.

Потому - в общем случае неплохо минимизировать кол-во записей на флэш.

Естати, замечал, что что-то коммитит в процессе работы изменения в нврам, пичем - с одним и тем же CRC (т.е. - фактически изменений нет).

 

Не совсем так. Вы таким образом исключите работу как wifi клиента. Проверять имеет смысл на соответствие wan_if/lan_if переменных, ну или около того.

Немного неточно выразися; имел ввиду соответствие интерфейса дефолт роута интерфейсу dhcp-клиента.

Изменено 26 декабря, 2010 пользователем NiTr0

[sfstudio]

Так я собссно о названии и говорил. Ибо не каждый туннель есть VPN, и не каждая VPN есть туннелем. Себе сделал пока название как VPN/PPPoE (ближе всего к терминам винды), меньше у юзеров вопросов будет.

Не вариант. Да и смысла немного. В общем это дело 39е.

 

Uboot ведь держит мак (и прочий конфиг) отдельно - можно собссно и оттуда мак тянуть. Во всяком случае я так у себя сделал. Хотя - вам виднее.

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

 

Ч

Реально. Я в свое время был счастливым обладателем сименса А60, у когорого его NOR флэш протерлась в месте расположения ФС. И это - не единичный случай.

Потому - в общем случае неплохо минимизировать кол-во записей на флэш.

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

 

Естати, замечал, что что-то коммитит в процессе работы изменения в нврам, пичем - с одним и тем же CRC (т.е. - фактически изменений нет).

Там вообще nvram логику переделать, да и реальные утечки в либе. Но ! Тут есть опять проблема. "Поломав" совместимость функций работы с нврам в том виде в котором они есть теряем совместимость с ралинковским комплектом ПО для тестирования устройства. А вот писать своё ПО под вантуз для фабрики меня вообще как-то не греет.

 

Немного неточно выразися; имел ввиду соответствие интерфейса дефолт роута интерфейсу dhcp-клиента.

Не совсем понимаю магию, наверное всему виной приближающийся НГ и тонна проблем связанная с ним. Меня сейчас почему-то больше интересует куда завтра взять билеты =) В Питер или в Екб к друзьям. Зовут и туда и туда, определиться сложно =)

[sfstudio]

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

Я-то для себя допилю, но все же.

Это позиция нейтралитета. Я сам как ISP гоняю за подобные изобретательства в явном виде позволяющие юзеру менять маки, и с моей позицией согласен каждый 2й ISP. Ну нельзя безголовому юзеру позволять менять мак. У кого голова на месте по ssh перебьёт 2 переменных в nvram и будет счастлив. Считайте это ограничением на порог вхождения.

 

Кстати этот подход уже обкатан мной на W*G/N устройствах, всё хорошо и никто из-за лени позвонить в ТП или почитать форум ещё не сбежал к другому вендору. А потенцильные беглецы слабо интересны в силу полной неспособности жить в реальном мире. Я сторонник подхода что конфигурированием сетевого оборудования должен заниматься человек с необходимыми знаниями и не пугающийся чтения мануалов, и если китайцам не удалось меня переубедить, то вам точно не выйдет =))))

[NiTr0]

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

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

 

P.S. в аттаче русский ленгпак патчем, вроде как все нужные файлы включил. Может где-то и кривоват, но в целом вроде вменяемый вышел.

langpack.patch.gz

[NiTr0]

Итак, собрал tcpdump, посмотрел, что происходит на интерфейсе... Запросы отправляются, пакеты приходят:

00:35:57.763252 1c:af:f7:41:9b:4f > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 333: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 319)
    0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
00:35:57.763527 00:18:f3:fd:22:fe > 1c:af:f7:41:9b:4f, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
    172.19.32.254.67 > 172.19.32.220.68: BOOTP/DHCP, Reply, length 300, xid 0xbc341d43, secs 3, Flags [none] (0x0000)
          Your-IP 172.19.32.220
          Server-IP 172.19.32.254 [|bootp]

iptables очистил - не помогает. Добавил ради проверки в иптейблс в INPUT цепочку вида -p udp --dport 68 -j ACCEPT - после добавления ожидаемого адреса ан интерфейс в эту цепочку посыпались пакеты, но dhcp клиент их опять-таки не видит...

А вот при рестарте клиента (не трогая iptables и т.д.) - адрес прекрасно получается сразу же...

 

P.S. по поводу утечек памяти в libnvram - они не столько в библиотеке (в библиотеке просто говнокод, в котором смешиваются в кучу указатели на строки из из heap'а и указатели на строки из области данных), сколько в итоге в софте, пользующем эту библиотеку; результат strdup надобно освобождать... Переписывать это - либо ломать совместимость с софтом (возвращать null вместо ""), либо - делать костыли в виде malloc'а 1 байта, забивания в него нуля и возврата в качестве строки. Ну и в goahead и т.д. для каждого результата делать free. Либо - внутри библиотеки делать некий static массив строк (к примеру, 32 строки по 128 символов - итого 4кб), занося в него результаты и возвращая указатели уже на строки из этого массива (получаем более-менее адекватное функционирование в многопоточном софте без утечек памяти и необходимости перепиливать софт, требующий libnvram). Патч в аттаче, с ним вроде как goahead живет сносно, но на всякий случай надо будет сделать ревизию коду - на предмет "долгоживущих" значений от nvram_get

nvram.patch.gz

Изменено 26 декабря, 2010 пользователем NiTr0

[sfstudio]

Как бы это просто и вкусно не казалось, но такой вариант уже пробовали =))))) Проблем оно не решает. Анализ ситуации в корне не верный. У меня был такой же при первом приближении, а далее.....

 

Ладно, отбой до НГ там посмотрим.

[NiTr0]

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

Как минимум - один источник утечек памяти он должен прикрыть... Гляну еще в код на досуге.

 

P.S. в логе старта обнаружил следующее:

ip route del 239.255.255.250 1>/dev/null 2>&1
service wscd stop &
iwpriv ra0 set WscConfMode=0 1>/dev/null 2>&1
service zebra restart &
service ripd restart &
service shaper restart &

То ли раньше внимания не обращал, то ли его не было и появилось из-за переполнения буффера в libnvram...

Изменено 26 декабря, 2010 пользователем NiTr0

[sfstudio]

Угу, хорошо. Предлагаю таки переехать в jabber будет проще в разы чем на форуме. Можно порешать вопросы интеграции и доступа на запись в гит. Т.е. нужно определиться с тем как будем взаимодействовать и в разы упростить принятие решений и интеграцию наработок.

 

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