Кстати, похоже ошибка в pppd: время коннекта должно быть 0 minutes.Code:Jun 12 14:36:07 pppd[128]: Connect time 18642876.0 minutes.
Сабж работает ка кописано для 1.7хх или нет?
Работает ли для pptp - соединений и что происходит если значения не заданы? Словил вот такой вот баг:
Не понятно что страслось, толи просто впн шлюз временно упал (такое периодически случается), толи ван отвалился. В любом случае после ребута все пошло, но почему попытки соединения не продолжались - не понятно.Code: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'
Last edited by Duke; 12-06-2005 at 19:04.
Кстати, похоже ошибка в pppd: время коннекта должно быть 0 minutes.Code:Jun 12 14:36:07 pppd[128]: Connect time 18642876.0 minutes.
По умолчанию - 10 попыток с паузой 30 секунд.Originally Posted by Duke
Переменные лучше не использовать те, проще в поле Additional pppd options вписать "maxfail 0", тогда будет бесконечное число попыток.
Спасибо, а я уж думал у меня WAN отваливается.
Чаще надо было man читать
Какова вероятность что сабж на 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.
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
Кстати насчет шаренных прерываний - вот ето-то как-то работает.
Code:[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
Last edited by Duke; 16-06-2005 at 21:10.
Они работают, проблем в другом - консольный сериальный порт не может почему-то шарить прерывание с другим портом. Т.е. само ядро этого не допускает, причина не ясна.Originally Posted by Duke
То есть если убрать console=ttyS0, то в принипе на 3-м проерывании сядт оба сериальника и будут работать?
Вроде бы да.