Aliech Опубликовано 9 января, 2009 · Жалоба В peers/pptp вернуть на родину pty --loglevel 0 и убрать ноу буффер, проблема у вас похоже только в MTU/MRU. В общем поэксперементируйте и отпишитесь. Я завтра буду, стучитесь в jabber (координаты на сайте), дам доступ к вики и аккуратно прямо там бум править. Нашёл значения нужные... содрал из мануаля по настройке зюхеля на rtl8186 под корбину... Вроде, пока что, стабильно Всё равно login as: root root@192.168.0.1's password: ::Wive-NG-0.2.7::RTL8186-REALTIME:: Base station firmware version Wed, 07 Jan 2009 02:57:02 +0600 BusyBox v1.12.1.-wive-ng.sf.net (2009-01-07 02:53:30 OMST) built-in shell (ash) Enter 'help' for a list of built-in commands. [Wive-NG@/]# grep pp /var/log/messages Jan 1 06:00:18 pppd[183]: pppd 2.4.5 started by root, uid 0 Jan 1 06:00:19 pppd[183]: Using interface ppp0 Jan 1 06:00:19 pppd[183]: Connect: ppp0 <--> /dev/ttyp0 Jan 1 06:00:19 pptp[186]: anon log[main:pptp.c:314]: The synchronous pptp option is NOT activated Jan 1 06:00:20 pptp[211]: anon log[ctrlp_disp:pptp_ctrl.c:752]: Received Start Control Connection Reply Jan 1 06:00:20 pptp[211]: anon log[ctrlp_disp:pptp_ctrl.c:786]: Client connection established. Jan 1 06:00:21 pptp[211]: anon log[ctrlp_disp:pptp_ctrl.c:871]: Received Outgoing Call Reply. Jan 1 06:00:21 pptp[211]: anon log[ctrlp_disp:pptp_ctrl.c:910]: Outgoing call established (call ID 0, peer's call ID 8029). Jan 1 06:00:21 pppd[183]: CHAP authentication succeeded Jan 1 06:00:21 pppd[183]: local IP address 93.80.18.42 Jan 1 06:00:21 pppd[183]: remote IP address 85.21.0.79 Jan 1 06:12:02 pptp[186]: anon log[decaps_gre:pptp_gre.c:417]: accepting packet 934 (expecting 933, lost or reordered) Jan 1 06:12:02 pptp[186]: anon log[decaps_gre:pptp_gre.c:408]: discarding duplicate or old packet 933 (expecting 935) Jan 1 06:12:12 pptp[186]: anon log[decaps_gre:pptp_gre.c:417]: accepting packet 1382 (expecting 1381, lost or reordered) Jan 1 06:12:12 pptp[186]: anon log[decaps_gre:pptp_gre.c:408]: discarding duplicate or old packet 1381 (expecting 1383) Jan 1 06:12:22 pptp[186]: anon log[decaps_gre:pptp_gre.c:417]: accepting packet 1828 (expecting 1827, lost or reordered) Jan 1 06:12:22 pptp[186]: anon log[decaps_gre:pptp_gre.c:408]: discarding duplicate or old packet 1827 (expecting 1829) Jan 1 06:17:06 pptp[186]: anon log[decaps_gre:pptp_gre.c:417]: accepting packet 6487 (expecting 6486, lost or reordered) Jan 1 06:18:09 pptp[186]: anon log[decaps_gre:pptp_gre.c:417]: accepting packet 6874 (expecting 6873, lost or reordered) [Wive-NG@/]# Вплоть до послед. ребута, как при лог 0, так и при но буфер Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vmn_fs Опубликовано 9 января, 2009 · Жалоба Все по старому. Виснет может не так быстро бывает, но виснет. Внес исправления в версию 0.2.7 mtu\mru, iptables - итог не помогло. Откатился с нуля на версию 0.2.0 с "http://sourceforge.net/" (самая ранняя) все равно виснет. для pptp выставил логлевел 2. вот, что выдает (переодичность повторяется) : Jan 1 07:06:39 pptp[192]: anon log[dequeue_gre:pptp_gre.c:452]: accepting 735 from queue Jan 1 07:06:39 pptp[192]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 737 (expecting 736, lost or reordered) Jan 1 07:06:39 pptp[192]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 738 (expecting 736, lost or reordered) Jan 1 07:06:39 pptp[192]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 739 (expecting 736, lost or reordered) Jan 1 07:06:39 pptp[192]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 740 (expecting 736, lost or reordered) Jan 1 07:06:39 pptp[192]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 741 (expecting 736, lost or reordered) Jan 1 07:06:39 pptp[192]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 742 (expecting 736, lost or reordered) Jan 1 07:06:39 pptp[192]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 743 (expecting 736, lost or reordered) Jan 1 07:06:39 pptp[192]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 744 (expecting 736, lost or reordered) Jan 1 07:06:39 pptp[192]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 745 (expecting 736, lost or reordered) Jan 1 07:06:39 pptp[192]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 746 (expecting 736, lost or reordered) Jan 1 07:06:39 pptp[192]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 747 (expecting 736, lost or reordered) Jan 1 07:06:39 pptp[192]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 748 (expecting 736, lost or reordered) Jan 1 07:06:39 pptp[192]: anon log[dequeue_gre:pptp_gre.c:449]: timeout waiting for 1 packets Jan 1 07:06:39 pptp[192]: anon log[dequeue_gre:pptp_gre.c:452]: accepting 737 from queue Jan 1 07:06:39 pptp[192]: anon log[dequeue_gre:pptp_gre.c:452]: accepting 738 from queue Jan 1 07:06:39 pptp[192]: anon log[dequeue_gre:pptp_gre.c:452]: accepting 739 from queue Jan 1 07:06:39 pptp[192]: anon log[dequeue_gre:pptp_gre.c:452]: accepting 740 from queue Jan 1 07:06:39 pptp[192]: anon log[dequeue_gre:pptp_gre.c:452]: accepting 741 from queue Jan 1 07:06:39 pptp[192]: anon log[dequeue_gre:pptp_gre.c:452]: accepting 742 from queue Jan 1 07:06:39 pptp[192]: anon log[dequeue_gre:pptp_gre.c:452]: accepting 743 from queue Jan 1 07:06:39 pptp[192]: anon log[dequeue_gre:pptp_gre.c:452]: accepting 744 from queue Jan 1 07:06:39 pptp[192]: anon log[dequeue_gre:pptp_gre.c:452]: accepting 745 from queue Jan 1 07:06:39 pptp[192]: anon log[dequeue_gre:pptp_gre.c:452]: accepting 746 from queue Jan 1 07:06:39 pptp[192]: anon log[dequeue_gre:pptp_gre.c:452]: accepting 747 from queue Jan 1 07:06:39 pptp[192]: anon log[dequeue_gre:pptp_gre.c:452]: accepting 748 from queue Jan 1 07:06:39 pptp[192]: anon log[decaps_gre:pptp_gre.c:395]: accepting packet 749 Jan 1 07:06:39 pptp[192]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 751 (expecting 750, lost or reordered) Jan 1 07:06:39 pptp[192]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 752 (expecting 750, lost or reordered) Jan 1 07:06:39 pptp[192]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 753 (expecting 750, lost or reordered) с логлевел 0 наблюдаем следующее : Jan 1 07:04:05 pptp[241]: anon log[logecho:pptp_ctrl.c:677]: Echo Request received.Jan 1 07:04:05 pptp[241]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 6 'Echo-Reply' Jan 1 07:05:05 pptp[241]: anon log[logecho:pptp_ctrl.c:677]: Echo Request received. Jan 1 07:05:05 pptp[241]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 6 'Echo-Reply' Jan 1 07:05:05 pptp[241]: anon log[callmgr_main:pptp_callmgr.c:234]: Closing connection (unhandled) Jan 1 07:05:05 pptp[241]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 12 'Call-Clear-Request' Jan 1 07:05:05 pptp[241]: anon log[call_callback:pptp_callmgr.c:79]: Closing connection (call state) Jan 1 07:05:05 kernel: Unable to handle kernel paging request at virtual address 7d207d1c, epc == 8000abf8, ra == 800ad9cc Jan 1 07:05:05 kernel: Oops in fault.c:do_page_fault, line 205: Jan 1 07:05:05 kernel: $0 : 00000000 1000f400 00000000 fffffffe 80bd2980 00000001 00000001 00000003 Jan 1 07:05:05 kernel: $8 : 00000000 a03f08a0 00000014 80c05054 0000000b 00000003 00000012 00000000 Jan 1 07:05:05 kernel: $16: 7d207d20 00000001 80bd2980 1000f401 00000001 000008ff 80bd2170 80bd2150 Jan 1 07:05:05 kernel: $24: 00000000 2ab8bee0 80b30000 80b31db0 80b31db0 800ad9cc Jan 1 07:05:05 kernel: Hi : 0000005e Jan 1 07:05:05 kernel: Lo : 003b19ee Jan 1 07:05:05 kernel: epc : 8000abf8 Not tainted Jan 1 07:05:05 kernel: Status: 1000f400 Jan 1 07:05:05 kernel: Cause : 00000008 Jan 1 07:05:05 kernel: Process pptp (pid: 192, stackpage=80b30000) Jan 1 07:05:05 kernel: Stack: fffffff9 8011e274 00000000 801e9838 80bd2000 80b46000 80bd2170 00000000 Jan 1 07:05:05 kernel: 000008ff 00000004 800ad9cc 80b31ea0 802f8e00 80b46000 802f8e00 80b46000 Jan 1 07:05:05 kernel: 802f8e00 80b46000 800c4250 800c41a0 80169928 80169854 800311ec 0000032e Jan 1 07:05:05 kernel: 000008ff 80b46000 00000000 7fff343f 80bd2000 800adbdc 80b31ee8 00000104 Jan 1 07:05:05 kernel: 00000000 00000000 7fff2b40 000008ff 80bd2000 7fff2b40 00000000 80ceb740 Jan 1 07:05:05 kernel: 80bd2980 ... Jan 1 07:05:05 kernel: Call Trace: [<8011e274>] [<800ad9cc>] [<800c4250>] [<800c41a0>] [<80169928>] [<80169854>] Jan 1 07:05:05 kernel: [<800311ec>] [<800adbdc>] [<800aab08>] [<8004ee58>] [<800aa8f4>] [<800a7fc4>] Jan 1 07:05:05 kernel: [<800a5388>] [<80038134>] [<800146a4>] [<8002274c>] [<80006e64>] [<80006e64>] Jan 1 07:05:05 kernel: Jan 1 07:05:05 kernel: Code: 00c08821 12040015 00000000 <8e04fffc> 00002821 8c820000 00541024 1040000c 00000000 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vmn_fs Опубликовано 9 января, 2009 · Жалоба В догонку сообщаю, что не открывается через роутер FTP - сервер локалной сети , пишет сервер перегружен. Хоя могет фаревол, но не думаю, ибо правила стандартные, что были описаны , ничего дополнительно не настраивал. Вставил кабель от модема в комп - открылся. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 9 января, 2009 · Жалоба Вплоть до послед. ребута, как при лог 0, так и при но буфер Консоль на порт и смотреть что происходит на коноси перед ребутом, иначе никак. Скорость какая ? Всемысле сколько отдаёт аплинк? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 9 января, 2009 · Жалоба Jan 1 07:06:39 pptp[192]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 737 (expecting 736, lost or reordered)Jan 1 07:06:39 pptp[192]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 738 (expecting 736, lost or reordered) Jan 1 07:06:39 pptp[192]: anon log[dequeue_gre:pptp_gre.c:449]: timeout waiting for 1 packets Похоже таки мощей проца нехватает. Канал какой? Jan 1 07:04:05 pptp[241]: anon log[logecho:pptp_ctrl.c:677]: Echo Request received.Jan 1 07:05:05 kernel: Unable to handle kernel paging request at virtual address 7d207d1c, epc == 8000abf8, ra == 800ad9cc Jan 1 07:05:05 kernel: Oops in fault.c:do_page_fault, line 205: Падает уже после того как соединение отвалилось. Странно. В догонку сообщаю, что не открывается через роутер FTP - сервер локалной сети , пишет сервер перегружен. Хоя могет фаревол, но не думаю, ибо правила стандартные, что были описаны , ничего дополнительно не настраивал. Вставил кабель от модема в комп - открылся. FTP/FTP рознь, tcpdump и смотреть со стороны сервера. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 9 января, 2009 · Жалоба Сейчас выложу обновлённую версию c правками в mm/pptp/ppp_mppe(kerenl module). Будем смотреть дальше. Самое обидное что мне до сих пор неудаётся повторить падения. С моими серверами всё работает без проблем. На серверах последний poptop из CVS и acell pptp кое где. Версия pppd тоже везде актуальная. Значть бы что у вас там с обратной стороны чтобы попытаться повторить. Сейчас выложу обновлённую версию c правками в mm/pptp/ppp_mppe(kerenl module). Будем смотреть дальше. Самое обидное что мне до сих пор неудаётся повторить падения. С моими серверами всё работает без проблем. На серверах последний poptop из CVS и acell pptp кое где. Версия pppd тоже везде актуальная. Значть бы что у вас там с обратной стороны чтобы попытаться повторить. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Aliech Опубликовано 9 января, 2009 · Жалоба Сейчас выложу обновлённую версию c правками в mm/pptp/ppp_mppe(kerenl module). Будем смотреть дальше. Самое обидное что мне до сих пор неудаётся повторить падения. С моими серверами всё работает без проблем. На серверах последний poptop из CVS и acell pptp кое где. Версия pppd тоже везде актуальная. Значть бы что у вас там с обратной стороны чтобы попытаться повторить. Для чайника плз.: а mppe разве не шифрование? Вроде бы, например у меня, оно отключенно... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 9 января, 2009 · Жалоба Залил http://sadnet.ru/?Dokumentaciya Шейте, пробуйте, настройки нужно сбросить fs restore && reboot или зажав reset. Для чайника плз.:а mppe разве не шифрование? Вроде бы, например у меня, оно отключенно... А вы считаете что я занимаюсь только вашими проблемами? У моих абонентов вылезла маленькая проблемка с шифрованием, которая правда не мешала жить, но была быстро локализована и исправлена. Более того, в приоритете по разработке/правки были есть и будут на первом месте собственные абоненты, затем коммерческие заказы и далее уже проблемы которые никак не проявляюься не у первых не у вторых. Самое сложной в отладке - добиться повторяемости в лабораторных условиях проблемы с крашами pptp я у себя на столе повторить не могу, есть пара мыслей на эту тему, Вадим обещал проверить у себя, но пока тишина. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Aliech Опубликовано 9 января, 2009 · Жалоба А вы считаете что я занимаюсь только вашими проблемами? Нет, не считаю... Но, пока что, как в дурном анекдоте... Теперь и аутентификация отвалилась (не пинать, всё сделал как на предыдущих): Jan 1 06:00:18 pppd[181]: pppd 2.4.5 started by root, uid 0 Jan 1 06:00:18 pppd[181]: Using interface ppp0 Jan 1 06:00:18 pppd[181]: Connect: ppp0 <--> /dev/ttyp0 Jan 1 06:00:19 pptp[184]: anon log[main:pptp.c:314]: The synchronous pptp option is NOT activated Jan 1 06:00:20 pptp[209]: anon log[ctrlp_disp:pptp_ctrl.c:752]: Received Start Control Connection Reply Jan 1 06:00:20 pptp[209]: anon log[ctrlp_disp:pptp_ctrl.c:786]: Client connection established. Jan 1 06:00:21 pptp[209]: anon log[ctrlp_disp:pptp_ctrl.c:871]: Received Outgoing Call Reply. Jan 1 06:00:21 pptp[209]: anon log[ctrlp_disp:pptp_ctrl.c:910]: Outgoing call established (call ID 0, peer's call ID 33551). Jan 1 06:00:21 dnsmasq[233]: started, version 2.43 cachesize 150 Jan 1 06:00:21 dnsmasq[233]: compile time options: no-IPv6 GNU-getopt no-RTC no-ISC-leasefile no-DBus no-I18N no-TFTP Jan 1 06:00:21 dnsmasq[233]: reading /etc/resolv.conf Jan 1 06:00:21 dnsmasq[233]: using nameserver 85.21.192.3#53 Jan 1 06:00:21 dnsmasq[233]: using nameserver 213.234.192.8#53 Jan 1 06:00:21 dnsmasq[233]: read /etc/hosts - 1 addresses Jan 1 06:00:23 pppd[181]: MS-CHAP authentication failed: E=691 Authentication failure Jan 1 06:00:23 pppd[181]: CHAP authentication failed Jan 1 06:00:23 pppd[181]: Connection terminated. Jan 1 06:00:23 pptp[184]: anon warn[decaps_hdlc:pptp_gre.c:207]: short read (-1): Input/output error Jan 1 06:00:23 pptp[184]: anon warn[decaps_hdlc:pptp_gre.c:219]: pppd may have shutdown, see pppd log Jan 1 06:00:23 pptp[209]: anon log[callmgr_main:pptp_callmgr.c:237]: Closing connection (unhandled) Jan 1 06:00:23 pptp[209]: anon log[call_callback:pptp_callmgr.c:82]: Closing connection (call state) Jan 1 06:00:28 kernel: auth uses obsolete (PF_INET,SOCK_PACKET) Jan 1 06:01:43 ssh[307]: Child connection from 192.168.0.2:1565 Jan 1 06:01:49 ssh[307]: password auth succeeded for 'root' from 192.168.0.2:1565 Jan 1 06:02:03 pppd[181]: Using interface ppp0 Jan 1 06:02:03 pppd[181]: Connect: ppp0 <--> /dev/ttyp1 Jan 1 06:02:03 pptp[335]: anon log[main:pptp.c:314]: The synchronous pptp option is NOT activated Jan 1 06:02:03 pptp[341]: anon log[ctrlp_disp:pptp_ctrl.c:752]: Received Start Control Connection Reply Jan 1 06:02:03 pptp[341]: anon log[ctrlp_disp:pptp_ctrl.c:786]: Client connection established. Jan 1 06:02:04 pptp[341]: anon log[ctrlp_disp:pptp_ctrl.c:871]: Received Outgoing Call Reply. Jan 1 06:02:04 pptp[341]: anon log[ctrlp_disp:pptp_ctrl.c:910]: Outgoing call established (call ID 0, peer's call ID 5795). Jan 1 06:02:07 pppd[181]: MS-CHAP authentication failed: E=691 Authentication failure Jan 1 06:02:07 pppd[181]: CHAP authentication failed Jan 1 06:02:07 pppd[181]: Connection terminated. Jan 1 06:02:07 pptp[335]: anon warn[decaps_hdlc:pptp_gre.c:207]: short read (-1): Input/output error Jan 1 06:02:07 pptp[335]: anon warn[decaps_hdlc:pptp_gre.c:219]: pppd may have shutdown, see pppd log Jan 1 06:02:07 pptp[341]: anon log[callmgr_main:pptp_callmgr.c:237]: Closing connection (unhandled) Jan 1 06:02:07 pptp[341]: anon log[call_callback:pptp_callmgr.c:82]: Closing connection (call state) Jan 1 06:03:47 pppd[181]: Using interface ppp0 Jan 1 06:03:47 pppd[181]: Connect: ppp0 <--> /dev/ttyp1 Jan 1 06:03:47 pptp[369]: anon log[main:pptp.c:314]: The synchronous pptp option is NOT activated Jan 1 06:03:47 pptp[375]: anon log[ctrlp_disp:pptp_ctrl.c:752]: Received Start Control Connection Reply Jan 1 06:03:47 pptp[375]: anon log[ctrlp_disp:pptp_ctrl.c:786]: Client connection established. Jan 1 06:03:48 pptp[375]: anon log[ctrlp_disp:pptp_ctrl.c:871]: Received Outgoing Call Reply. Jan 1 06:03:48 pppd[181]: Modem hangup Jan 1 06:03:48 pppd[181]: Connection terminated. Jan 1 06:03:48 pptp[375]: anon log[ctrlp_disp:pptp_ctrl.c:910]: Outgoing call established (call ID 0, peer's call ID 6101). Jan 1 06:03:48 pptp[375]: anon log[callmgr_main:pptp_callmgr.c:237]: Closing connection (unhandled) Jan 1 06:03:48 pptp[375]: anon log[call_callback:pptp_callmgr.c:82]: Closing connection (call state) Да, спасибо за комменты новые в конфигах Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 10 января, 2009 · Жалоба Нет, не считаю... Но, пока что, как в дурном анекдоте... Теперь и аутентификация отвалилась (не пинать, всё сделал как на предыдущих): Аутентификацию вообще не трогал никоим боком и у мну везде mschap v2 и у всех всё работает. Может деньги на балансе? Или таки что-то пропустили? Да, спасибо за комменты новые в конфигах Собсно не за что, это заметки на полях не более. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 10 января, 2009 · Жалоба Похоже мне удалось решить проблему с падениями на 8Мб девайсах без использования mppe. 30минут аптайм постоянно гоняются данные через туннель, шифрование включено. На 8Мб девайсах раньше при любых настройках память утекала в течении 5-15 минут при включенном pptp вне зависимости от шифрования. Проблема как выяснилось лежала в неверноем определении размера фрэйма при деокмпрессии. Если это так, то 0.2.9 должна работать без проблем и показывать значительно лучшию производительность. Тестовую версию брать тут http://sadnet.ru/downloads/wive-0.2.9-test.bin.7z Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 10 января, 2009 · Жалоба В общем результат: [Wive-NG@/]# uptime 06:59:33 up 59 min, load average: 0.30, 0.46, 0.44 [Wive-NG@/]# ifconfig ppp0 ppp0 Link encap:Point-to-Point Protocol inet addr:192.168.1.3 P-t-P:192.168.1.254 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:572 Metric:1 RX packets:171962 errors:0 dropped:0 overruns:0 frame:0 TX packets:171381 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3 RX bytes:90791940 (86.5 MiB) TX bytes:90484734 (86.2 MiB) [Wive-NG@/]# free total used free shared buffers Mem: 5720 4960 760 0 192 Swap: 0 0 0 Total: 5720 4960 760 Падать даже не думает как и жрать память. В догонку: [Wive-NG@/]# cat /var/log/messages | grep pp Jan 1 06:00:12 pppd[165]: pppd 2.4.5 started by root, uid 0 Jan 1 06:00:12 pppd[165]: Using interface ppp0 Jan 1 06:00:12 pppd[165]: Connect: ppp0 <--> /dev/ttyp0 Jan 1 06:00:13 pptp[168]: anon log[main:pptp.c:314]: The synchronous pptp option is NOT activated Jan 1 06:00:15 pptp[191]: anon log[ctrlp_disp:pptp_ctrl.c:752]: Received Start Control Connection Reply Jan 1 06:00:15 pptp[191]: anon log[ctrlp_disp:pptp_ctrl.c:786]: Client connection established. Jan 1 06:00:16 pptp[191]: anon log[ctrlp_disp:pptp_ctrl.c:871]: Received Outgoing Call Reply. Jan 1 06:00:16 pptp[191]: anon log[ctrlp_disp:pptp_ctrl.c:910]: Outgoing call established (call ID 0, peer's cal. Jan 1 06:00:16 pppd[165]: CHAP authentication succeeded Jan 1 06:00:16 pppd[165]: MPPE 128-bit stateless compression enabled Jan 1 06:00:16 pppd[165]: local IP address 192.168.1.3 Jan 1 06:00:16 pppd[165]: remote IP address 192.168.1.254 Тестируйте, вероятно это также решит и ваши проблемы с падениями. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 10 января, 2009 · Жалоба Таки после 1,5 часов работы память на 8Мб рам девайсе утекла ;( Но это закономерно. Ждём результатов тестов на 16Мб устройствах. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vmn_fs Опубликовано 10 января, 2009 · Жалоба канал 128к для глобальной сети интернет. Так что не думаю, что в нем дел ;). Единственное, трафик запускал по полной, включал закачку, открытие картинок и etc. ща попробую оттестить новую версию. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vmn_fs Опубликовано 10 января, 2009 (изменено) · Жалоба с версией 0.2.9 test таж же песня. Вылетает на ура ,быстро вот лог: Jan 1 06:02:13 pptp[184]: anon log[decaps_gre:pptp_gre.c:398]: accepting packet 23 Jan 1 06:02:13 pptp[243]: anon log[callmgr_main:pptp_callmgr.c:237]: Closing connection (unhandled) Jan 1 06:02:13 pptp[243]: anon log[call_callback:pptp_callmgr.c:82]: Closing connection (call state) Jan 1 06:02:13 kernel: Unable to handle kernel paging request at virtual address 7d207d1c, epc == 8000af80, ra == 800c0d54 Jan 1 06:02:13 kernel: Oops in fault.c:do_page_fault, line 205: Jan 1 06:02:13 kernel: $0 : 00000000 1000f400 00000000 fffffffe 80bb1980 00000001 00000001 00000003 Jan 1 06:02:13 kernel: $8 : 00000000 0000002a 00000000 80be2054 7d207d20 00000000 0000000d 00000000 Jan 1 06:02:13 kernel: $16: 7d207d20 00000001 80bb1980 1000f401 00000001 00000a61 80bb1170 80bb1150 Jan 1 06:02:13 kernel: $24: 00000000 2ab759d0 80b1c000 80b1ddb0 80b1ddb0 800c0d54 Jan 1 06:02:13 kernel: Hi : 00000099 Jan 1 06:02:13 kernel: Lo : 00024772 Jan 1 06:02:13 kernel: epc : 8000af80 Not tainted Jan 1 06:02:13 kernel: Status: 1000f400 Jan 1 06:02:13 kernel: Cause : 10000008 Jan 1 06:02:13 kernel: Process pptp (pid: 184, stackpage=80b1c000) Jan 1 06:02:13 kernel: Stack: fffffff9 80134064 00000000 8020d838 80bb1000 80b87000 80bb1170 00000000 Jan 1 06:02:13 kernel: 00000a61 00000004 800c0d54 80022ed8 802abe00 80b87000 802abe00 80b87000 Jan 1 06:02:13 kernel: 802abe00 80b87000 800d82c8 800d8208 7fff1000 80f66490 8021983c 800083dc Jan 1 06:02:13 kernel: 00000a61 80b87000 00000000 7fff1589 80bb1000 800c0f64 80f66490 00000001 Jan 1 06:02:13 kernel: 80d94f90 7fff1000 7fff0b28 00000a61 80bb1000 7fff0b28 00000000 80cb96d0 Jan 1 06:02:13 kernel: 80bb1980 ... Jan 1 06:02:13 kernel: Call Trace: [<80134064>] [<800c0d54>] [<80022ed8>] [<800d82c8>] [<800d8208>] [<800083dc>] Jan 1 06:02:13 kernel: [<800c0f64>] [<800bdcac>] [<800bda98>] [<800baf08>] [<800b80a4>] [<80039e88>] Jan 1 06:02:13 kernel: [<8000706c>] [<80007030>] Jan 1 06:02:13 kernel: Jan 1 06:02:13 kernel: Code: 00000000 12040018 00c08821 <8e04fffc> 00002821 8c820000 00000000 00541024 1040000d память не забивает, ошибок в ifconfig не выдает. непонятки.... в догонку : ppp0 Link encap:Point-to-Point Protocol inet addr:94.143.56.210 P-t-P:79.98.95.1 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:37 errors:0 dropped:0 overruns:0 frame:0 TX packets:57 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3 RX bytes:27653 (27.0 KiB) TX bytes:48590 (47.4 KiB) [Wive-NG@/]# free total used free shared buffers Mem: 13792 8176 5616 0 796 Swap: 0 0 0 Total: 13792 8176 5616 Изменено 10 января, 2009 пользователем vmn_fs Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 10 января, 2009 · Жалоба с версией 0.2.9 test таж же песня. Вылетает на ура ,быстро вот лог: Боюсь проблема не там где ищу её я, хтя попутно в любом случае удалось выправить некоторые старые болячки. MTU:1500 И на eth тоже MTU 1500 ? Т.е. вы желаете сказать что любой полный пакет в вашем случае будет фрагментирован? Даже незнаю как в таком положении раком оведёт себя 2.4.18 skbuff. На той стороне что? Не винда в роли сервера? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 10 января, 2009 · Жалоба Ещё на тест http://sadnet.ru/downloads/wive-0.2.9-test.bin.7z Логи сюда. Настройки сбросить в default. Да, и попробуйте отключить RX_DELAY и BR_SHORTCUT (echo 3 /proc/ethX/eth_flag где X - номер интерфейса), не могу нащупать почему у вас происходят такие чудеса. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kefiller Опубликовано 11 января, 2009 · Жалоба Уважаемые, прошу сильно не пинать, но где можно прочитать про настройку WDS? 138 страниц, к сожалению, не осилил )) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 11 января, 2009 · Жалоба Уважаемые, прошу сильно не пинать, но где можно прочитать про настройку WDS? 138 страниц, к сожалению, не осилил )) В коментариях menu->general , более для этого ничего не требуется, если этого будет мало, то и тему читать смысла не имеет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Aliech Опубликовано 12 января, 2009 (изменено) · Жалоба Ув. sfstudio А не может быть подобная причина, от того, что народу сидит куча на внешнем ip? + оказалось что mtu/mru ещё меньше нужны Изменено 12 января, 2009 пользователем Aliech Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
az113 Опубликовано 12 января, 2009 · Жалоба Товарищи! Попрошу сразу в гугль не слать (там уже был, и ответов не нашел) и в баню не отправлять, за такие тупые вопросы, но у меня идеи уже кончились.... 1) есть G700AP, rev.B1. Умирала долго, и странно: сначала слетела родная прошивка, через tftp влили концептроник. Проработала недели три-четыре, и слетела опять. После этого на кнопку она еще отзывалась, и по tftp прошивка вливалась, но уже не работала. Потом перестала принимать прошивку (т.е. только включается, зажигает Power и LAN, и так и стоит).. После этого начался совсем уже полтергест: точка неделю пролежала выключенная, включили - вошла в краш, съела прошивку... и не перезапустилась. А потом и в краш перестала вводиться. Сейчас не реагирует на внешние раздражители, на консольном порту тишина как в танке (смотрел осциллографом). 2) Спаял JTAG DLC5 на 4*100ом резисторах, собрал JTAG под cygwin, подпаялся - все сдетектилось, прочиталось, пишу boot.jtag -- записалось, ребут - и опять как в танке. Ситуация повторилась, только теперь с другим интерфейсом. Час-полтора полежит выключенной железка - начинает детектиться, при этом читается то, что записал перед этим, читается без ошибок. Но железяка признаков жизни не подает ;( Когда железка перестает отвечать на detect - на ноге TCK появляется сигнал нормального уровня, но сам проц молчит как рыба об лёд... 3) Что я делаю не так? куда бежать, кого трясти, об какую стену биться лбом? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SXM.U Опубликовано 12 января, 2009 (изменено) · Жалоба az113, не у вас одного такая ситуация. уже 4 железяки с таким диагнозом лежит. проблема пока необьяснима, где-то на неделе консолью подпаяюсь - посмотрю что делается. Косвенно об проблеме: - работает, еще 1 рес - тоже, полежала пол дня - не заводится, складывается впечатление будто флешку не детектит, ибо светодиод power горит, лан - моргает, перерошиваться - пожалуйста, пока питание есть - работает, на некоторое время вынул - не арбайтн. Пока без консоли не понятно...воть.... Девайсы G700 (rev B1/B2) Изменено 12 января, 2009 пользователем SXM.U Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 13 января, 2009 · Жалоба Ув. sfstudio А не может быть подобная причина, от того, что народу сидит куча на внешнем ip? + оказалось что mtu/mru ещё меньше нужны Врятли. Я выложил 0.2.9 лфициальную, там ещё стопочка правок. Т.е. ещё уменьшили mtu и глюки пропали? az113, не у вас одного такая ситуация. уже 4 железяки с таким диагнозом лежит. проблема пока необьяснима, где-то на неделе консолью подпаяюсь - посмотрю что делается. Косвенно об проблеме: - работает, еще 1 рес - тоже, полежала пол дня - не заводится, складывается впечатление будто флешку не детектит, ибо светодиод power горит, лан - моргает, перерошиваться - пожалуйста, пока питание есть - работает, на некоторое время вынул - не арбайтн. Пока без консоли не понятно...воть.... Девайсы G700 (rev B1/B2) Абсолютно такие же чудеса были на моей боевой точке на которой тестирую каждое изменение, т.е. шью по 20-30 раз в день. Заменил флэшку прошил через jtag и она опять встрою. Посмотрим сколько перезаписей выдержит эта мелкосхема. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Aliech Опубликовано 13 января, 2009 · Жалоба Врятли. Я выложил 0.2.9 лфициальную, там ещё стопочка правок. Т.е. ещё уменьшили mtu и глюки пропали? Пропали lost or reordered пакеты (mtu 1300)... Как до дома доберусь - 2.9 попробую Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 13 января, 2009 · Жалоба Пропали lost or reordered пакеты (mtu 1300)... Как до дома доберусь - 2.9 попробую Это полная ерунда. В 0.2.9 вообще отключил вывод этого мусора при логлэвел нихе 2х. Собсно эта бяка не может служить причиной глюков и маты вполне штатные даже при нормальной работе на мощном железе. Меня больше интересует как оно себя чувствует теперь при нормальной эксплуатации. 0.2.9 сутки гонял сидя сам через неё в инете да ещё и на 8Мб устройстве, проблем при моей типовой активности не было. Флуд через туннель приводит через 1,5 часа к тому что на 8Мб устройствах память закачнивается, на 16Мб таких проблем нет. Впринципе и на 8мб можно отрубить систлог и прочие плюшки типа wpa который у мне везде и всям, тогда вероятно памяти для работы pptp клиента будет достаточно но без запаса. Пробуйте. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
