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

Rtl8186 Firmware Всем, кто пишет под RTL8186

Привет всем!!!!!!!!

 

Нужна ваша помощь.

Имеется точка доступа DWL-G700AP - перепрошитая в Wive-v0.6.1, и ADSL modem Dlink - 2500U/BRU/D сойдененный с интернетом (Шлюз для компьютеров 192.168.1.1 - чтобы был интернет).

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

ардеса компов в локальной сети начинаеются с 192.168.1.10 и по 192.168.1.20. Также имеется ноут с Вай-Фай его адрес 192.168.1.25 и шлюз для инета 192.168.1.1 прописаны, но немогу некак настроить DWL-G700AP с прошивкой Wive-v0.6.1 ничего неполучается не ИНТЕРНЕТА не локалки по Вай-Фай.

помогите с нуля настроить DWL-G700AP с прошивкой Wive-v0.6.1, если мождно то пошагово.

Помогите пойжалуста.

Зарание сапсибо.

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


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

Gynaecologist > а что именно так работает ?

вопрос был про переброс портов с eth1 на внутренний адрес

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


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

а ктото пробовал залить в DAP-1150. Получилось ли?

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


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

а ктото пробовал залить в DAP-1150. Получилось ли?

Конечно. Работает там отлично!

В ДАП-1160 тоже, но при повторной очистке флэша, он файликом black_fw не чистится, помогает только fs fullcrash.

 

 

Вопрос ко всем :)

Вот возникла необходимость вкомпилить очень полезную утилитку iftop в wive-ng.

Где взять исходники под MIPS?

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

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


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

Вот возникла необходимость вкомпилить очень полезную утилитку iftop в wive-ng.

Где взять исходники под MIPS?

Исходники есть на сайте http://www.ex-parrot.com/pdw/iftop/

Вот только оно с libpcap собирается, а значит совсем не маленькое :) да еще и curses за собой тянет...

В исходниках прошивки wive-ng есть tcpdump который собирается, но не копируется в прошивку. Весит около метра - только в дивайсы у которого флеша > 4Мб, иначе не влезет.

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


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

Надежно работает, даже повода для обновления прошивки не найти :(

post-66257-1264576829_thumb.jpg

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


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

Тут народ схватился за морду когда я проект уже хороню https://sourceforge.net/apps/phpbb/wive-ng/...hp?f=1&t=11

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


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

Привет,

 

Евгений, для начала хочу вас поблагодарить за отличную прошивку, грамотный подход и адекватное отношение к GPL. Спасибо большое!

 

По сути дела: так уж получилось, что у нас в лаборатории есть аж 3 "***линка" G700AP и для повышения надежности хотелось бы использовать вменяемую прошивку (по сути нам достаточно просто bridge между wlan и lan). Я знаю, что вы уже не поддерживаете убогие 8-мегабайтные устройства, но решил все же попробовать самостоятельно скомпилировать, отключив лишнее (fyi при прошивке вашего образа 0.3.17 рутер показывал активацию проводных интерфейсов и потом через пару минут перезагружался, видимо по watchdog, без oom killer или kernel panic, просто вдруг перезагружался). Кстати, я не очень понимаю, почему вы по умолчанию не отключаете в прошивке вообще все, кроме eth0 и inetd/dropbear, т.к. все равно же нужно подсоединяться и полностью все отстраивать под свои задачи, но при этом консоль на последовательном порту по умолчанию отключена (и, кстати, то, что mkimg перезаписывает изменения в etc/inittab, было для меня сюрпризом).

 

 

Комментарии по сборке:

 

Для сборки toolchain я применил gcc 4.3.4, единственная тонкость -- перед make нужно сделать export CFLAGS=-D_FORTIFY_SOURCE=0. Скрипт make_links.sh мне показался сомнительным (у меня в local другие программы тоже установлены, поэтому bin и прочие радости уже присутствуют) и вообще ненужным -- я добавил /opt/Wive/toolchain/bin в PATH перед сборкой. Это оказалось необходимо, т.к. не во всех местах корректно учитывается CROSS_COMPILE, где-то подразумевается, что toolchain доступен в PATH, а в Makefile ядра путь к toolchain вообще hardcoded (знаю, что для 2.6.x достаточно запускать make CROSS_COMPILE=/path/to/chain/prefix-, как это корректно делается в 2.4 -- не интересовался, может это и не важно; как вариант -- добавить include ../.config и заменить = на ?=). Вообще было бы неплохо, чтобы был сразу очевиден метод собрать и установить весь toolchain и прошивку, не имея прав root, это и удобно и безопасно (и порой необходимо, если кто-нибудь захочет собирать это на чужой машине). Даже если для rtl8186 ничего делать уже не имеет смысла, возможно, вы учтете это пожелание для других ваших разработок.

 

Еще непонятный момент: мне показалось, что сборка ramdisk происходит на последнем этапе, уже после линковки ядра, т.о. получается, что после любых изменений файловой системы нужно запускать make два раза подряд.

 

 

Комментарии по устройству:

 

Насколько я могу понять, работает нормально после отключения ненужных компонентов. Размер ramdisk сделал 512k, но это оказалось совсем впритык -- /tmp/tgzfs не умещался, пока я не удалил пару ненужных конфигов. Возможно, стоит немного подправить скрипт, чтобы он предупреждал пользователя, если не удается его создать, а то получается, что он полуготовый архив записывает, потом, естественно, при перезагрузке возвращается к значениям по умолчанию.

 

Thanks again for all your efforts,

Happy hacking!

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


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

Я знаю, что вы уже не поддерживаете убогие 8-мегабайтные устройства

Я уже вообще забил на 8186. Не отвечают ни требованиям сегодняшнего для. Работаем над Ralink RT305*.

 

, но решил все же попробовать самостоятельно скомпилировать, отключив лишнее

А зачем? Почему не отключить всё лишнее в процессе настройки? Чем вам мешает это лишнее банально лежащие на флэше.

 

(fyi при прошивке вашего образа 0.3.17 рутер показывал активацию проводных интерфейсов и потом через пару минут перезагружался, видимо по watchdog, без oom killer или kernel panic, просто вдруг перезагружался).

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

 

Кстати, я не очень понимаю, почему вы по умолчанию не отключаете в прошивке вообще все, кроме eth0 и inetd/dropbear,

Потому что не ориентируюсь на кастрированные 8мб девайсы с одним eth.

 

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

И что?

 

но при этом консоль на последовательном порту по умолчанию отключена

Чего чего? Вы пробовали лить бинарь который я собирал?

 

Даже если для rtl8186 ничего делать уже не имеет смысла, возможно, вы учтете это пожелание для других ваших разработок.

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

 

Еще непонятный момент: мне показалось, что сборка ramdisk происходит на последнем этапе, уже после линковки ядра, т.о. получается, что после любых изменений файловой системы нужно запускать make два раза подряд.

Не нужно вообще запускать make есть скрипк compile доверьте ему процесс сборки.

 

 

Комментарии по устройству:

Не трогайте ничего, лейте уже собранный образ в Г700 и отключайте "лишнее" в процессе настройки. То что вы делаете никак не поможет нормальной работе девайса. Всё что можно по оптимизации там уже выполнено с учётом всех нюансов.

 

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

Чем они вам там мешают? Не запускайте туннели и сислог, для этого пересборка НЕ НУЖНА!.

 

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

Простите кого предупреждал? =) Пользователя? Для пользователей бинари есть, остальные в состоянии читать что пишут и думать головой а не уменьшать размер рамдиска учитывая что это бессмысленно.

 

 

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


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

Я знаю, что вы уже не поддерживаете убогие 8-мегабайтные устройства
Я уже вообще забил на 8186. Не отвечают ни требованиям сегодняшнего для. Работаем над Ralink RT305*.

В курсе.

 

, но решил все же попробовать самостоятельно скомпилировать, отключив лишнее
А зачем? Почему не отключить всё лишнее в процессе настройки? Чем вам мешает это лишнее банально лежащие на флэше.

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

 

(fyi при прошивке вашего образа 0.3.17 рутер показывал активацию проводных интерфейсов и потом через пару минут перезагружался, видимо по watchdog, без oom killer или kernel panic, просто вдруг перезагружался).
Вывод консоли с момента включения до перезагрузки в студию.
Угу. Только мне кажется, что без /etc/debug информации маловато... http://paste.debian.net/59725/. Timestamps как в minicom сделать я не знаю, по ощущениям до перезагрузки пара минут, могу точнее померить, если надо.

 

Кстати, я не очень понимаю, почему вы по умолчанию не отключаете в прошивке вообще все, кроме eth0 и inetd/dropbear,
Потому что не ориентируюсь на кастрированные 8мб девайсы с одним eth.

 

т.к. все равно же нужно подсоединяться и полностью все отстраивать под свои задачи,
И что?

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

 

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

Лог после заливки бинарника из wive-ng-0.3.17.tar.7z с SF выше. В исходниках BASE_STATION нигде не устанавливается, а без него shell на последовательной консоли отключен, судя по mkimg и по результату, который я видел после прошивки самособранного образа.

 

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

Согласен, что git format-patch для точной передачи идеи гораздо лучше, но и подготовка патча требует больше времени. И если вам сама идея не нравится, то получается, что он того не стоит. Путь к toolchain намертво задан в kernel/Makefile, кстати. И в toolchain/nonmips-tcb/Makefile. Т.е. менять нужно как минимум в нескольких местах, если хочется, что не вполне очевидно.

 

Еще непонятный момент: мне показалось, что сборка ramdisk происходит на последнем этапе, уже после линковки ядра, т.о. получается, что после любых изменений файловой системы нужно запускать make два раза подряд.
Не нужно вообще запускать make есть скрипк compile доверьте ему процесс сборки.

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

 

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

Ну вот я ведь головой думал так: у устройства и так мало памяти. Ramdisk забит менее, чем наполовину. В 0.2.x его размер был меньше. Почему бы его и не уменьшить, чтобы иметь лишних 512kiB. А то, что у gz может не получиться записать настройки из-за нехватки места, не сразу в голову приходит, когда пишешь "fs store" и он отвечает, что все ok. Да, выдает gzip ошибку, но не такую уж и очевидную. А ramdisk может по разным причинам забиться -- может пользователь syslog криво настроил или еще что-нибудь такое. И вот он видит ошибку, правит конфиг, fs store, он ему говорит, что все ок, после ребута дефолтные настройки. Круто.

 

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


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

Я смотрю, вы суровый разработчик, похоже, что образы под root'ом собираете :) Вот маленький патч: http://paste.debian.net/59749/.

 

Что касается зависания -- когда виснет, всегда виснет на этапе bridge start eth1. Иногда везет (или, может быть, влияет то, что я держу Enter, чтобы видеть, когда shell на ttyS0 перестанет отвечать), то пишет ``ip: ioctl 0x8914 failed: Cannot allocate memory'' и идет дальше.

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


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

Я смотрю, вы суровый разработчик, похоже, что образы под root'ом собираете :)

Всё верно, в контейнере.

 

Вот маленький патч: http://paste.debian.net/59749/.

Посмотрел, включил, даже не собирал. Работоспособность не проверял, все какашки в сторону PaulFertser =) Всё ребят, некада 8186 заниматься. Желающие продолжать разврекаться с трупиками и выходцы из рядов некрофилов могут смело форкнуть и продолжать пилить.

 

Что касается зависания -- когда виснет, всегда виснет на этапе bridge start eth1. Иногда везет (или, может быть, влияет то, что я держу Enter, чтобы видеть, когда shell на ttyS0 перестанет отвечать), то пишет ``ip: ioctl 0x8914 failed: Cannot allocate memory'' и идет дальше.

А отключить после загрузки eth1 принудительно не пробовали?

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


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

Что касается зависания -- когда виснет, всегда виснет на этапе bridge start eth1. Иногда везет (или, может быть, влияет то, что я держу Enter, чтобы видеть, когда shell на ttyS0 перестанет отвечать), то пишет ``ip: ioctl 0x8914 failed: Cannot allocate memory'' и идет дальше.
А отключить после загрузки eth1 принудительно не пробовали?
Если использовать тот образ, что в бинарнике с SF.net, то там нет shell на последовательной консоли вообще, а успеть отключить eth1 в тот малый период после старта eth0 по ssh мне не представляется возможным. А в той сборке (все параметры по умолчанию, только в config DEBUG=YES и BASE_STATION=YES, что сейчас я попробовал, наверное, можно успеть, если прямо в терминалку команды правильные вставить, вот только не особо изящный это метод и требует последовательной консоли и пересборки все равно. После bridge start eth1 почти всегда виснет совершенно намертво, ни консоль, ни ssh не работают. Я, конечно, понимаю, что это убогость d-link'а и т.д., но ведь у вас есть хитрый workaround для этого, либо он должен срабатывать, либо вообще по умолчанию eth1 отключить, а кому надо -- включит.

 

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


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

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

А вот остальные смогли. Вопрос - ЧОДНТ ? =)

 

информации маловато...

Достаточно. Тут всё банально, загрузитесь с отключенным кабелем и полегчает.

 

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

Читайте внимательно с какими устройствами я рекомендую использовать прошивку? Список совместимого железа не означает что у вас с этими девайсами всё будет гладко. А рекомендации чётко описывают 16Мб рамы минимум 2 eth с или без коммутатора.

 

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

Я вот не хочу сечас опять браться и просматривать всё это дело. Но я собираю ровно из тех же сырцов и не меняю никакие настройки однако прямо сейчас передо мной лежит устройство с доступом к шеллу. BASE_STATION переменная 300 лет назад выкорчевана. Может конечно что-то некорректно залилось в гит, но не существенно. Собсно неогда это выяснять.

 

Согласен, что git format-patch для точной передачи идеи гораздо лучше, но и подготовка патча требует больше времени.

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

 

И если вам сама идея не нравится, то получается, что он того не стоит. Путь к toolchain намертво задан в kernel/Makefile, кстати.

# cat kernel/Makefile | grep toolc

и где простите?

 

И в toolchain/nonmips-tcb/Makefile. Т.е. менять нужно как минимум в нескольких местах, если хочется, что не вполне очевидно.

Тут да, но о очевидности однако никто не говорил как и о необходимости пересборки тулчейна.

 

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

Каждый делает так как угодно ему. FOSS однако. Мне удобно так, если вам так неудобно - переделайте.

 

Ну вот я ведь головой думал так: у устройства и так мало памяти. Ramdisk забит менее, чем наполовину. В 0.2.x его размер был меньше. Почему бы его и не уменьшить, чтобы иметь лишних 512kiB. А то, что у gz может не получиться записать настройки из-за нехватки места, не сразу в голову приходит, когда пишешь "fs store" и он отвечает, что все ok. Да, выдает gzip ошибку, но не такую уж и очевидную. А ramdisk может по разным причинам забиться -- может пользователь syslog криво настроил или еще что-нибудь такое. И вот он видит ошибку, правит конфиг, fs store, он ему говорит, что все ок, после ребута дефолтные настройки. Круто.

Чего чего? Вы бы со штатной б разобрались бы со структурой хоть. А то понастроили умозаключений полезли что-то менять, а я вот такой вот дятел не додумался до этого =)))))

 

Если вам нужны мосты то вообще нет смысла что-то менять. Загрузились - отрубили eth1 - готов к работе/настройки. Чтобы железка не улетала в ребут с включенным eth1 не включайте её в одбщую сеть жопой. Я же не виноват что экономисты из одной весьма интересной компании пожалели привернуть 2 phy и съэкономили на памяти.

 

Кстати для любителей кастратов есть wive.

 

Засинкался с гитом на sf. Опять же не стал ничего проверять, сменил BASE_STATION на SERIAL_CONSOLE и включил в конфиге по дефолту.

 

а успеть отключить eth1 в тот малый период после старта eth0 по ssh мне не представляется возможным.

arg s/g

 

А в той сборке (все параметры по умолчанию, только в config DEBUG=YES и BASE_STATION=YES, что сейчас я попробовал, наверное, можно успеть, если прямо в терминалку команды правильные вставить, вот только не особо изящный это метод и требует последовательной консоли и пересборки все равно. После bridge start eth1 почти всегда виснет совершенно намертво, ни консоль, ни ssh не работают.

Значит по eth ифейсу у вас чтото такое летит на точку типа броадкаста что драйверу сразу сносит крышу и даже костыль не успевает отрабатывать.

 

 

Я, конечно, понимаю, что это убогость d-link'а и т.д., но ведь у вас есть хитрый workaround для этого, либо он должен срабатывать, либо вообще по умолчанию eth1 отключить, а кому надо -- включит.

Вот поэтому там и есть этот воркэраунд. Это компромис между совсем забить нафиг на бялинки с их кастратами или ...

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

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


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

Только тем, что я не смог настраивать готовый образ после запуска.
А вот остальные смогли. Вопрос - ЧОДНТ ? =)
информации маловато...
Достаточно. Тут всё банально, загрузитесь с отключенным кабелем и полегчает.

Пробовал, и не раз. И сейчас попробовал -- не полегчало, все равно намертво виснет. И я не думаю, что кто-то использует сколько-нибудь современные wive-ng на g700ap, по крайней мере google мне про таких не рассказывал.

 

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

Я вот не хочу сечас опять браться и просматривать всё это дело. Но я собираю ровно из тех же сырцов и не меняю никакие настройки однако прямо сейчас передо мной лежит устройство с доступом к шеллу. BASE_STATION переменная 300 лет назад выкорчевана. Может конечно что-то некорректно залилось в гит, но не существенно. Собсно неогда это выяснять.

Насколько я понял, вы все-таки глянули и исправили. Спасибо.

 

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

Мне было бы достаточно ответа: "это никому ненужная фигня, забей" или "да, действительно, patches welcome".

 

И если вам сама идея не нравится, то получается, что он того не стоит. Путь к toolchain намертво задан в kernel/Makefile, кстати.

# cat kernel/Makefile | grep toolc

и где простите?

~/wive-ng/wive-ng $ git show origin:kernel/Makefile | egrep '(WIVE|CROSS)' 
WIVEROOT    = /opt/Wive
CROSSPATH    = /usr/local/bin/
CROSS_COMPILE     = mips-linux-
AS        = $(CROSSPATH)$(CROSS_COMPILE)as

 

И в toolchain/nonmips-tcb/Makefile. Т.е. менять нужно как минимум в нескольких местах, если хочется, что не вполне очевидно.
Тут да, но о очевидности однако никто не говорил как и о необходимости пересборки тулчейна.

А тулчейн надо пересобирать, если есть желание разместить его по другим путям, а не в /opt/Wive/toolchain или если система 64-битная, или если GLIBC старее 2.7 и т.д. К тому же судя по конфигу пересборка тулчейна интегрирована в процесс, по крайней мере такое впечатление создается и думаешь, что это прозрачно и автоматически.

 

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

Каждый делает так как угодно ему. FOSS однако. Мне удобно так, если вам так неудобно - переделайте.

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

 

Ну вот я ведь головой думал так: у устройства и так мало памяти. Ramdisk забит менее, чем наполовину. В 0.2.x его размер был меньше. Почему бы его и не уменьшить, чтобы иметь лишних 512kiB. А то, что у gz может не получиться записать настройки из-за нехватки места, не сразу в голову приходит, когда пишешь "fs store" и он отвечает, что все ok. Да, выдает gzip ошибку, но не такую уж и очевидную. А ramdisk может по разным причинам забиться -- может пользователь syslog криво настроил или еще что-нибудь такое. И вот он видит ошибку, правит конфиг, fs store, он ему говорит, что все ок, после ребута дефолтные настройки. Круто.

Чего чего? Вы бы со штатной б разобрались бы со структурой хоть. А то понастроили умозаключений полезли что-то менять, а я вот такой вот дятел не додумался до этого =)))))

Да я вроде бы основные идеи понял и скрипты загрузочные читать умею, ага. И мне как-то так кажется, что ramdisk есть ramdisk, если он больше, значит свободной ОЗУ на все остальное меньше. И во время работы все модифицируемые части именно в ramdisk находятся, а только при сохранении создается tar.gz с содержимым и записывается на отдельный mtd раздел.

 

Если вам нужны мосты то вообще нет смысла что-то менять. Загрузились - отрубили eth1 - готов к работе/настройки. Чтобы железка не улетала в ребут с включенным eth1 не включайте её в одбщую сеть жопой. Я же не виноват что экономисты из одной весьма интересной компании пожалели привернуть 2 phy и съэкономили на памяти.

Пробовал ведь, не срабатывает, виснет. JTAG под рукой дома нет, извиняйте.

 

Кстати для любителей кастратов есть wive.

Я же хотел самую клевую прогрессивную прошивку, которая по уму сделана и т.д. Тем более она явно способна работать на этом кастрате не хуже wive.

 

а успеть отключить eth1 в тот малый период после старта eth0 по ssh мне не представляется возможным.
arg s/g
Это еще в нужный момент надо успеть команду дать, после поднятия eth0 и до подключения eth1 в bridge. Не практично, особенно без последовательной консоли.

 

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


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

И я не думаю, что кто-то использует сколько-нибудь современные wive-ng на g700ap, по крайней мере google мне про таких не рассказывал.

Гугл много о чём не рассказывает.

 

Мне было бы достаточно ответа: "это никому ненужная фигня, забей" или "да, действительно, patches welcome".

Обычно если кому-то что-то нуно и человек уже знает как поправить то берёт и правит шлёт или не шлёт патч дело 10е. А развести разговоров на 2 экрана вместо правки одной строки и дифа эт как-то странно.

 

~/wive-ng/wive-ng $ git show origin:kernel/Makefile | egrep '(WIVE|CROSS)' 
WIVEROOT    = /opt/Wive

Эти пережитки прошлого убить давно пора, просто висят и забыл уже о них. Собсно лень уже трогать.

 

А тулчейн надо пересобирать, если есть желание разместить его по другим путям, а не в /opt/Wive/toolchain или если система 64-битная, или если GLIBC старее 2.7 и т.д. К тому же судя по конфигу пересборка тулчейна интегрирована в процесс, по крайней мере такое впечатление создается и думаешь, что это прозрачно и автоматически.

Вот только никому это нафиг не надо. Положить в опт, пнуть компайл и наслождаться. Что касается 64бита - ССЗБ. Интересно что вы будете делать с железками под которые вообще тулчейн только бинарный.

 

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

make не меньший костыль. Начал осиливать cmake но переводить wive на него не имею смысла, гораздо проще сделать надстройку над make.

 

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

На заборе тоже написано.

 

свободной ОЗУ на все остальное меньше. И во время работы все модифицируемые части именно в ramdisk находятся, а только при сохранении создается tar.gz с содержимым и записывается на отдельный mtd раздел.

Смешались в кучу кони-люди. Для rwfs используется ramfs и в ней лежит ровно то что лежит в rw_fs_stub (и то не всё см /etc/rc.d/start). И это в большинстве своём текстовые файлы которые прекрасно жмуться. Более того смотрите внимательней что и где лежит не обращая особого внимания на имена переменных ибо там много ошмётков которые просто лень было править.

 

Пробовал ведь, не срабатывает, виснет. JTAG под рукой дома нет, извиняйте.

О каких-то чудесах рассказываете.

 

 

Я же хотел самую клевую прогрессивную прошивку, которая по уму сделана и т.д. Тем более она явно способна работать на этом кастрате не хуже wive.

С клёвыми прогрессивными прошивками это вам не к риалтэк. Риалтэк это самые мёртвые дрение некрофильские поделия и ни я ни кто-то другой этого не изменит. Они даже под 2.6 взяли древнючий uClinux и сбоку прикрутили 2.6.19 ядро попутно поломав всё что можно. И это под их свежие чипы. Я еле убедил Acorp больше не под каким предлогом не подписываться на риалтэки. В итоге слава богу делаем на Ralink.

 

 

Это еще в нужный момент надо успеть команду дать, после поднятия eth0 и до подключения eth1 в bridge. Не практично, особенно без последовательной консоли.

Отнесите вашу тухлятину на помойку. Ибо даже тот экземпляр Г700 который есть у меня прекрасно поднимается и с включенным eth1 и остаётся время на срабатываение костыля.

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


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

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

 

Для rwfs используется ramfs
Признаю, был не прав.

 

Отнесите вашу тухлятину на помойку. Ибо даже тот экземпляр Г700 который есть у меня прекрасно поднимается и с включенным eth1 и остаётся время на срабатываение костыля.
Спасибо за совет, но я уж как-нибудь просто пересоберу с отключенным по умолчанию eth1, потому что в остальном эта тухлятина работает не хуже, чем от нее ожидается, для нашей лаборатории вполне сойдет.

 

Спасибо за прошивку.

 

Happy hacking!

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


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

Оживили ветку :). Sfstudio выжал из этой железяки все возможное, uptime уже 43 дня, нагрузка на линк(2.5 км на даблбиквадах простых кстати) небольшая но постоянная, в том числе и торренты. Так что успокойтесь с пересборками, настройте то что есть и пользуйтесь, а если не устраивает - меняем hardware.

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


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

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

Да да да. Где-то мы уже эту песню слышали =)))

 

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

Хех. Ну удачи. С genext2fs вы меня здорово подставили =) Оказывается в некоторых дистрибах выкинули genext2fs из реп в других даже не включали. В итоге получил кучу матов на мыло и пришлось в деверо сырцов ещё и это безобразие включать.

 

Спасибо за прошивку.

Не за что. Я лишь обточил и расширил то что уже было сделано хотя подход и сменился кардинально. Это такой стартовый опыт =)

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


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

всем хай.

 

Имею в наличии древнюю железку на RTL8186, обслуживающую малую сеть.

На текущий момент железка работает под AP Router 8.2d firmware, но это глючное творение португальских коллег с дико урезанной консолью вконец меня добило...

 

Задумался перейти на wive-ng (нет пока возможности и сильного желания менять роутер), и возник только один вопрос: возможно ли переназначить порт ssh доступа извне со стандартного на нужный мне?

 

ЗЫ ногами просьба не пинать, осилил только 20+ страниц ветки в обратном направлении

ЗЗЫ поиск по теме отсутствует

ЗЗЫ ставить и самому тестить нет возможности - нужен живой ссш туннель

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


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

Скорее всего, да. Поправить скрипт запуска.

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

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


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

Скорее всего, да. Поправить скрипт запуска.

мерси, зашьюсь во время сервис брейка

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


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

Люди, подскажите пожалуйста. Где найти datasheet на rtl8186 или BCM4318E.

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

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

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


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

все даташиты включая дизан pcb есть в моём sdk. git в зубы

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


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

sadnet.ru ключевое слово git а вообще учу пользоваться поиском - ДОРОГО!

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


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

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.