Bekijk de volledige versie : Где посмотреть версию бутблока на -gd?
Сабж?
Свеженький делюкс, родная прошивка -1.8.2.1 (ессно сразу залита -5а)
Не понятно надо ли ему бутблок обновлять или нет - Lan от Wan кажись не отсекается при загрузке -комп успел ухватить с внешнего Dhcp адрес.
В telnet
nvram get hardware_version
Вот я торомжу... :)
01-03-01-33 - можно спокойно шить 1.04/1.50? Сброс к дефолту я так опнимаю не нужен, 32 мб уже включены и после перепрошивки бутболка/mac-адреса девайс загрузится с теми установками и той же фирмварью что до того?
Да, но возвращаемая версия окажется прежней, т.к. этот номер тоже хранится, как переменная.
Залил, полет нормальный ;)
Только вот не пойму почему интерфейсы на LAN стартуют на 10мбит?
WAN стартует на 100 - видно на хабе-аплинке, а комп говорит что 10-ка. Принудительно ан коме 100/full ставлю - отваливается коннект. Кабел CAT5e, Intel PRO/1000.
MII-tool как я понимаю для делюкса не подходит ?
mii-tool - это как раз то, что доктор прописал. Только с -5a она работать не будет, вот в следующей версии - будет.
Когда ждать обновления и почему в текущей версии не пашет?
Проверил все пять портов, попробовал кроссом соединить - один фиг. Не помню только, коннектилось ли на 100 с родным бут-блоком хоть раз, то что 10-ки выпадали - точно.
Когда ждать обновления и почему в текущей версии не пашет?
Не работает, т.к. не поддерживаются необходимые вызовы.
Проверил все пять портов, попробовал кроссом соединить - один фиг. Не помню только, коннектилось ли на 100 с родным бут-блоком хоть раз, то что 10-ки выпадали - точно.
От лоадера это не зависит.
У меня p4p800 работает без проблем, только там не интел, а 3ком.
Да я уже на втором компе на P4P8X првоерил, там тот же 3Com - все работает. Есть подозрение что это бодаются интел с бродкомом где-то на этапе определения MDI/MDI-X. Бутблок наверняка что-т на низком уровне инициализирует, могло бы спасти. Хотя если эта приблуда не спасет, то и из бутблока не вылечить...
Да я уже на втором компе на P4P8X првоерил, там тот же 3Com - все работает. Есть подозрение что это бодаются интел с бродкомом где-то на этапе определения MDI/MDI-X. Бутблок наверняка что-т на низком уровне инициализирует, могло бы спасти. Хотя если эта приблуда не спасет, то и из бутблока не вылечить...
Ничего он не инициализует.
Тады ой - с тулзой на 100-ке принудительно не поднялось =(
Что пишет mii-tool -vvv -p номер_порта eth0 ?
eth0: negotiated 10baseT-FD flow-control, link ok
registers for MII PHY 4:
1000 782d 0040 6371 05e1 cc61 000d 2001
0000 0000 0000 0000 0000 0000 0000 0000
1000 0000 0000 0000 0200 0600 0400 0000
0039 8a17 9f00 008a 0029 0000 10a0 000b
product info: vendor 00:10:18, model 55 rev 1
basic mode: autonegotiation enabled
basic status: autonegotiation complete, link ok
capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
link partner: 10baseT-FD 10baseT-HD flow-control
Забавно. Интел (link partner) говорит, что поддерживает только 10 мегабит... :) Думаю, что надо искать другие драйвера. Можно кстати и линукс попробовать.
Дравера тут могут не спасти. При выключенном компе сетевуха обычно работает, так вот симптомы при соединении выключенного компа с роутером те же - дооолго устанавливает линк и не зажигается 100мбит индикацию. :rolleyes:
Ну интел... "твоя беда - ты слишком умный!"
Поставил свежескачанные интеловые дровишки с встенными тулзами.
Тестирую current link status.
С роутером:
The cable connected to this port is missing
pairs needed to connect at 1000 Mbps.
С нормально работающим хабом
The link partner is not capable of running
at 1000 Mbps.
Тестирую best link option:
С роутером:
Could not establish link. The cable may
be disconnected or have a bad connection.
For more information, run the Cable test
if supported by the adapter
С хабом:
Could not connect at Adapter's maximum
speed because link partner does not support
that speed.
Сабж работает ка кописано для 1.7хх или нет?
Работает ли для pptp - соединений и что происходит если значения не заданы? Словил вот такой вот баг:
Jun 12 14:36:04 pppd[128]: No response to 6 echo-requests
Jun 12 14:36:04 pppd[128]: Serial link appears to be disconnected.
Jun 12 14:36:04 pppd[128]: MPPE disabled
Jun 12 14:36:04 dnsmasq[98]: read /etc/hosts - 4 addresses
Jun 12 14:36:04 dnsmasq[98]: read /etc/ethers - 3 addresses
Jun 12 14:36:04 dnsmasq[98]: reading /tmp/resolv.conf
Jun 12 14:36:04 dnsmasq[98]: using nameserver 212.48.128.130#53
Jun 12 14:36:04 dnsmasq[98]: using nameserver 212.1.224.34#53
Jun 12 14:36:04 PPTP: Disconnected
Jun 12 14:36:07 pppd[128]: Connection terminated.
Jun 12 14:36:07 pppd[128]: Connect time 18642876.0 minutes.
Jun 12 14:36:07 pppd[128]: Sent 178571 bytes, received 445830 bytes.
Jun 12 14:36:07 pptp[134]: anon warn[decaps_hdlc:pptp_gre.c:197]: short read (-1): Input/output error
Jun 12 14:36:07 pptp[134]: anon warn[decaps_hdlc:pptp_gre.c:209]: pppd may have shutdown, see pppd log
Jun 12 14:36:07 pptp[143]: anon log[callmgr_main:pptp_callmgr.c:230]: Closing connection
Jun 12 14:36:07 pptp[143]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 12 'Call-Clear-Request'
Jun 12 14:36:09 pptp[143]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 12 'Call-Clear-Request'
Jun 12 14:36:09 pptp[143]: anon log[pptp_conn_close:pptp_ctrl.c:433]: Closing PPTP connection
Jun 12 14:36:09 pptp[143]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 3 'Stop-Control-Connection-Request'
Jun 12 14:36:13 pptp[143]: anon log[call_callback:pptp_callmgr.c:77]: Closing connection
Jun 12 14:36:28 ntp client: Synchronizing time with time.nist.gov ...
Jun 12 14:36:37 pptp[240]: anon log[main:pptp.c:267]: The synchronous pptp option is NOT activated
Jun 12 14:36:37 pppd[128]: Serial connection established.
Jun 12 14:36:37 pppd[128]: Using interface ppp0
Jun 12 14:36:37 pppd[128]: Connect: ppp0 <--> /dev/pts/0
Jun 12 14:36:40 pptp[242]: anon warn[open_inetsock:pptp_callmgr.c:317]: connect: No route to host
Jun 12 14:36:40 pptp[242]: anon fatal[callmgr_main:pptp_callmgr.c:123]: Could not open control connection to 10.10.1.1
Jun 12 14:36:40 pptp[240]: anon fatal[open_callmgr:pptp.c:426]: Call manager exited with error 256
Jun 12 14:36:40 pppd[128]: Modem hangup
Jun 12 14:36:40 pppd[128]: Connection terminated.
Jun 12 14:36:40 pppd[128]: Connect time 18642876.0 minutes.
Jun 12 14:36:40 pppd[128]: Sent 178571 bytes, received 445830 bytes.
#и так еще 10 раз
Jun 12 14:41:35 pppd[128]: Connect time 18642876.0 minutes.
Jun 12 14:41:35 pppd[128]: Sent 178571 bytes, received 445830 bytes.
#^ не забыл удалить - две строчки вконце были дважды
Jun 12 14:41:35 pppd[128]: Exit.
Jun 12 16:36:28 ntp client: Synchronizing time with time.nist.gov ...
Jun 12 18:36:28 ntp client: Synchronizing time with time.nist.gov ...
Jun 12 20:36:28 ntp client: Synchronizing time with time.nist.gov ...
Jun 12 21:32:53 login[320]: root login on `pts/0'
Не понятно что страслось, толи просто впн шлюз временно упал (такое периодически случается), толи ван отвалился. В любом случае после ребута все пошло, но почему попытки соединения не продолжались - не понятно.
AnatolyB
13-06-2005, 11:32
Jun 12 14:36:07 pppd[128]: Connect time 18642876.0 minutes.
Кстати, похоже ошибка в pppd: время коннекта должно быть 0 minutes.
Сабж работает ка кописано для 1.7хх или нет?
Работает ли для pptp - соединений и что происходит если значения не заданы? Словил вот такой вот баг:
По умолчанию - 10 попыток с паузой 30 секунд.
Переменные лучше не использовать те, проще в поле Additional pppd options вписать "maxfail 0", тогда будет бесконечное число попыток.
Спасибо, а я уж думал у меня WAN отваливается.
Чаще надо было man читать :D
Какова вероятность что сабж на 500gDeluxe когда-нибудь заработает?
Уже руки чешуться развести USB и сериальники наружу, да лишние дырки делать нехочется. Кроме того сзади вывести ВСЁ не получается, даже если использовать для сериальников RJ-45.
Там беда в том, что на ttyS0 висит консоль. А в ядре по такому случаю не допускается шаринг irq, хотя ttyS1 его всё равно на самом деле использует...
Не совсем понял.
Т.е. так как на ttyS0 висит консоль, то его IRQ не шарится? но ttyS1 вроде на другом IRQ сидит судя по тому что в бутлоге пишется. Обойти-то какнить можно, или только отключением консоли, и опять-таки всего 1 порт получается?
Физически на том же самом прерывании, ядро изменяет на 0 (нет), когда обнаруживает это.
Можно пропатчить ядро и выкинуть проверку. На что может повлиять - не знаю.
Т.е. ядро попросту маскирует прерывания от ttyS1 получается?
Имхо без аппаратного контроля потока два работающих сериальника на одном прерывании просто ядро с ума сведут %)
Хотя попробовать стоит!
В крайнем случае если ничего не получится, хорошо бы сделать чтобы консоль на ttyS0 перенаправлялась по какому-нить ключу в nvram, и можно было освободить порт без пересборки фирмвари - консоль-консолью, а серриальник лишним не бывает ;)
I am not so fluent in Russian, but the intriging title of this thread contained ttyS0 and in the posts I could see ttyS1 and IRQ and WL500deluxe. Therefore, could one of the contributers in this thread tell me whether you are discussing a problem with the second internal serial on the WL500gx (in my case /dev/tts/1 hangs the whole system when I write or read to/form it). /dev/tts/0 works fine and uses IRQ3 /dev/tts/1 uses IRQ 0 and fails. If not, sorry to interrupt.
:D sodb, the irq problem is just due to the fact, that ttyS0 physically uses the same irq (shared), but the linux kernel does not allow that, so it disables ttyS1 irq. On the other hand you could try recompiling kernel either by disabling console on ttyS0 or removing the check for shared console irq. Also, check the openwrt forum. I've read a post from a guy using GPS on the ttyS1 with wrt54g.
Yes, we're discussing any posibilities to make ttyS1 (/dev/tts/1) working. It seems that both UARTS using the same IRQ line, and kernel just masks tts/1 requests with IRQ0. It is possible to patch kernel to prevent it from masking tts/1, but the result will be unpredictable, i.e. both serial ports may be unusable because of the lack of hardware flow conrtol
Кстати насчет шаренных прерываний - вот ето-то как-то работает.
[Duke@(none) root]$ cat /proc/interrupts
CPU0
2: 7991257 MIPS eth1, usb-uhci, usb-uhci, ehci_hcd
3: 98 MIPS serial
4: 9335900 MIPS eth0
7: 19442503 MIPS timer
Кстати насчет шаренных прерываний - вот ето-то как-то работает.
Они работают, проблем в другом - консольный сериальный порт не может почему-то шарить прерывание с другим портом. Т.е. само ядро этого не допускает, причина не ясна.
То есть если убрать console=ttyS0, то в принипе на 3-м проерывании сядт оба сериальника и будут работать?
see Thread 1993 on disabling console on /dev/ttyS0. Would it cost you guys a lot of effort to discuss this topic in English, because I am certainly interested in getting both serials work simultaneously. Thanks for the translation so far!
покопался я тут..
из main.c вызывается
console_init(), ПОСЛЕ init_IRQ();
console_init() надо полагать сидит в init.c бизибокса - никаких следов работы с прерываниями в этом вызове нету.
linux/drivers/char/serial.c:
#ifdef CONFIG_SERIAL_CONSOLE
/*
* The interrupt of the serial console port
* can't be shared.
*/
if (sercons.flags & CON_CONSDEV) {
for(i = 0; i < NR_PORTS; i++)
if (i != sercons.index &&
rs_table[i].irq == rs_table[sercons.index].irq)
rs_table[i].irq = 0;
}
#endif
Чего-то в Gpl1819 ничего подобного нет!
Не, наврал - есть такое.
Посомтрел в дремучей версии 2.0.36 - не было такого, как и упоминания о консоли в serial.c, хотя думаю если в иниттабе прописывалась все равно работало. Хотя в нативных родных сорсах от 2.4.37 уже все есть. Мож действительно попробовать убрать?
Пообщался с техсуппортом асуса - говорят такого не может быть, все должно работать - проверили. Завтра повезу девайс в сервис. Почти уверен что ничего они вразумительного на выходе не формулируют. везти мать вместе с роутером будет лень.
Пообщался с техсуппортом асуса - говорят такого не может быть, все должно работать - проверили. Завтра повезу девайс в сервис. Почти уверен что ничего они вразумительного на выходе не формулируют. везти мать вместе с роутером будет лень.
Сдал в сервис. Примечательно, но полежавший ночь выключенным девайс держал линк на 100 мбит 3-5 минут, после чего все срубилось взад на 10-ку и встало на сотню только после отключениеи охлаждения девайса - это окончательно указывает что неисправность больше на совести роутера. Завтра поеду возьму девайс на замену, посомтрим, болезнь ли это конкретного экземпляра или все трансиверы кривые ставятся...
В сервисе заменили на свежий, серийник 54ххх, бут-блок сразу 1.05/1.40. Полет нормальный. Заодно девайс без резиновых ножек и гарантийной наклейки - паяй -нехочу ;)))
В сервисе заменили на свежий, серийник 54ххх, бут-блок сразу 1.05/1.40. Полет нормальный. Заодно девайс без резиновых ножек и гарантийной наклейки - паяй -нехочу ;)))
Каналы 12 и 13 есть?
Нету. А я чего-то и е обратил внимания - были ли в старом?
Вообще странно, на наклейке с серийником код продукта кончается на /eu, надодумать должен быть европейский с 13 -. каналамииа не тайванский с 11-ю. В бутблоке вырублено?
Да, должно быть 13 (Европа). Я ведь писал уже - в российском тех саппорте шьют версию для тайваня. :) Именно такой вариант прислал АСУС, в результате мне пришлось эти вещи подправить.
Да я просто весь форум перелопачивал наскоком за 2 дня, помню что было, что конкретно - уже смутно. Так тот что в архиве с прошивалкой - уже правленный до 13 каналов?
Кстати в тебя кинуть 1.04/1.50 из девайса с серийником 54хх? Сравнил с тем что есть - несколько десятков байт отличаются только.
Да я просто весь форум перелопачивал наскоком за 2 дня, помню что было, что конкретно - уже смутно. Так тот что в архиве с прошивалкой - уже правленный до 13 каналов?
Да. В принципе перешивать в твоём случае необязательно, я сейчас в ФАК добавлю пост о том, как разрешить все 14-ть каналов.
Кстати в тебя кинуть 1.04/1.50 из девайса с серийником 54хх? Сравнил с тем что есть - несколько десятков байт отличаются только.
Не надо, я знаю что они шьют - отличается именно сеттингами.
http://wl500g.info/showpost.php?p=17721&postcount=10