[sfstudio]

Так точно... Если что - экспериментируем с mtu/mru (смотрим значение Вадима)

Сейас занимаюсь этой болячкой, подробнее тут http://sfstudio.livejournal.com/10047.html?thread=1#t89663

 

В кратце, где-то в skbuff выделятся мало памяти для хранения пакета >1500байт, т.к. если внутри туннеля имеем 1500 байт пакет то с учётом оверхида и MPPE результирующий пакет будет сильно больше 1500 байт, что приведёт к его фрагментации на eth интерфейсе, как итог имеем дикую потерю производительности и переодические краши.

 

То что краши из-за механизма фрагментации удалось отбросить, т.к. по pppoe который работает на L2 ситуация аналогична. Значит болячка где-то в skbuff в чистом виде. Сделал версию с 2ным резервированием памяти, сейчас залью и ссылку дам в блоге, прошу потестить.

[sfstudio]

Собсно проблема для big-endian не нова http://lkml.indiana.edu/hypermail/linux/ke...506.0/0176.html

Попробую повторить финт ушами.

 

В общем выправил, сейчас выложу тестовую версию, линк будет тут http://sfstudio.livejournal.com/10047.html, разделим тестеров pppoe/pptp/l2tp от остальных и вынесем в ЖЖ в указанную ветку, ибо голова уже кругом идёт на тему где когда у кого и как =) Так что welcome и бум фиксить.

 

Всё, залилось, жду результатов.

Изменено 22 января, 2009 пользователем sfstudio

[sfstudio]

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

Наверное мы на разных языках говорим. Я вообще-то Русский обычно =)

 

 

Часть первая. ДНС в роутинге

Вот так есть проблема (представлены записи в таблице роутинга, они были нужны, т.к. defaultgateway ваш скрипт убивает при старте pptp):

ip route add 213.234.192.8 via 10.66.72.1 dev eth1
ip route add 85.21.192.3 via 10.66.72.1 dev eth1
ip route add 85.21.0.0/21 via 10.66.72.1 dev eth1

Первые два - ДНС (ну нужны позарез, т.к. адресс сервера указан как vpn.corbina.net)

Пилять а .... Ну слов нет... Ну добавили, рады?

 

 

А так уже проблемы нет:

ip route add 85.21.0.79 via 10.66.72.1 dev eth1

И что?

 

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

После подключения ДНС гонится, соответственно, через ppp0, до подключения - ДНС работать не будет, как и вся сеть, впрочем...

Рад за вас.

 

Из первого выводим второе.

Часть два. Нету денег и т.д...

А вдруг у нас нету денег на счету? Или vpn серверы лежат? Или ещё чо? Ну не подымиться интерфейс же, да и шлюз убит будет скриптом настройки.

Тяжёлый случай.

 

Так почему бы не сделать replace вместо delete? Сами понимаете, что это решит проблему и с автопрописыванием маршрута до pptp и ничего не станет менять, если соединения нет...

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

 

PS: всёравно mru/mtu = 580 приходится пользовать

http://sfstudio.livejournal.com/10047.html?view=90175#t90175

 

Пробуйте, нам расскажете.

[sfstudio]

Ггыггы, наткнулся а анологичную проблему в опэнврт https://dev.openwrt.org/ticket/1742 , но они её не починили. Но видимо мне таки удалось. Тестовый комплект работает корретно при mtu=1300 уже 5ть часов при полной нагрузке, с большим mtu не проверял, т.к. нет возможножности оставлять юзверей без инета увеличивая MTU на сервере.

[sherv]

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

адрес vpn сервера вписывается в pptppeers:

pty "pptp nas.foris-telecom.ru --nolaunchpppd --loglevel 0"

так?

логин и пароль вписываются в chappassword в таком виде:

chr222 * qwer *

напомню, что я для примера считаю логином chr222 и паролем qwer. по этому поводу у меня есть еще вопросик: игнорируются ли здесь пробелы?

но я так и не нашел, куда вписывать адрес шлюза, данный провайдером? напомню: провайдер не раздает адреса по dhcp, а требует вводить их вручную.

 

еще непонятно для чего pappassword? может мне нужно эти данные забить туда, а не в chappassword?

[sfstudio]

еще непонятно для чего pappassword? может мне нужно эти данные забить туда, а не в chappassword?

Ещё раз повторяю. Wive-NG не что иное как дистрибутив Linux. И всё что актуально для Linux актуально и для Wive-NG за некоторыми упрощениями. opennet.ru один из лучших ресурсов на эту тему.

[sherv]

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

провайдер дал в частности такие настройки: ip адрес 192.168.10.10, маска 255.255.255.0, шлюз 192.168.10.1. я собираюсь присвоить адрес wan порту роутера. пишу в interfaces так:

ETH1_IPADDR=192.168.10.10/24

но мне непонятно, куда вписывать шлюз?

[Aliech]

Вы меня простите пожалуйста, но кажется Вы не пользовались этой прошивкой, т.к. в меню routes даже есть пример добавления default gateway'а. Поправьте, если не так...

Ну и дальше больше... Вы писали, что у Вас pptp? Ну так посмотрите страницы четыре назад то, как я с ним парился... И поймите, что шлюз вам нужен только для записи роутинга к серверам pptp и dns

[sherv]

я смотрел. но у вас провайдер раздает эти настройки по dhcp - не такой случай как у меня.

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

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

[Aliech]

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

[vmn_fs]

Поставил тестовую версию 0.2.11 на акрп wr-g для соединения по pptp

результаты следующие:

1. С дефолтным mtu опять краш

2. С мту 726(половина от максимума) связь стабильна. и даже лампочки мыргают почти синхронно. :)

3. Повысив мту до 1100 почемуто перестали проходить запосы по именам, т.е. по ой-пи пинг есть, по имени пинга нет....

4. Не могу подцепиться к фтп локальному... Может есть какие предложения ?

5. Нашел на просторах инета в форуме такую конфигурацию для иптеблес

iptables -A FORWARD -o ppp0 -j TCPMSS --clamp-mss-to-pmtu

утсаканивает мту на концах точка-клиент. Заремил в конфиге знчение мту. По дефолту стало 1500 проработало 15 мин

потом тупо заткнулось. ppp0-есть, но не работает, т.е. не пингуется......

6. Выставил мту 1452 с верхней поправкой отработало мин 15 потом я нечаяно ребутнул роутер кргда писал этот пост :(

7. ФТП так и не открывается....жалко, будем копать далее....

 

...7 мин после ребута фильмец на закачке , пока работает....

[vmn_fs]

ну вот и краш, но без ребута...

т.е. 13 мин. отаботали все таки.....

Jan  1 06:13:27 kernel: Neighbour table overflow.                                                                                         
Jan  1 06:13:28 kernel: Neighbour table overflow.                                                                                         
Jan  1 06:13:29 kernel: Neighbour table overflow.                                                                                         
Jan  1 06:13:30 kernel: Neighbour table overflow.                                                                                         
Jan  1 06:13:31 kernel: Neighbour table overflow.                                                                                         
Jan  1 06:13:32 kernel: Neighbour table overflow.                                                                                         
Jan  1 06:13:38 kernel: NET: 16 messages suppressed.                                                                                      
Jan  1 06:13:38 kernel: Neighbour table overflow.                                                                                         
Jan  1 06:13:43 kernel: NET: 15 messages suppressed.                                                                                      
Jan  1 06:13:43 kernel: Neighbour table overflow.                                                                                         
Jan  1 06:13:48 kernel: NET: 17 messages suppressed.                                                                                      
Jan  1 06:13:48 kernel: Neighbour table overflow.                                                                                         
Jan  1 06:13:52 kernel: NET: 29 messages suppressed.                                                                                      
Jan  1 06:13:52 kernel: Neighbour table overflow.
Jan  1 06:14:46 kernel: NET: 2 messages suppressed.
Jan  1 06:14:46 kernel: Neighbour table overflow.
Jan  1 06:14:48 kernel: Neighbour table overflow.
Jan  1 06:14:49 kernel: Neighbour table overflow.
Jan  1 06:14:50 kernel: Neighbour table overflow.
Jan  1 06:14:50 pptp[232]: anon log[callmgr_main:pptp_callmgr.c:237]: Closing connection (unhandled)
Jan  1 06:14:50 pptp[232]: anon log[call_callback:pptp_callmgr.c:82]: Closing connection (call state)
Jan  1 06:14:50 kernel: Unable to handle kernel paging request at virtual address 7d297d1c, epc == 8000af10, ra == 8009bd24
Jan  1 06:14:50 kernel: Oops in fault.c:do_page_fault, line 206:
Jan  1 06:14:50 kernel: $0 : 00000000 1000f400 00000000 fffffffe 80be5980 00000001 00000001 00000003
Jan  1 06:14:50 kernel: $8 : 00000000 00000006 00000000 80bf7854 7d207d22 80b51ed0 00000000 00000000
Jan  1 06:14:50 kernel: $16: 7d297d20 00000001 80be5980 1000f401 00000001 0000085b 80be5170 80be5150
Jan  1 06:14:50 kernel: $24: 00000000 2ab759d0                   80b50000 80b51db0 80b51db0 8009bd24
Jan  1 06:14:50 kernel: Hi : 00000bc3
Jan  1 06:14:50 kernel: Lo : 0002449f
Jan  1 06:14:50 kernel: epc  : 8000af10    Not tainted
Jan  1 06:14:50 kernel: Status: 1000f400
Jan  1 06:14:50 kernel: Cause : 10000008
Jan  1 06:14:50 kernel: Process pptp (pid: 178, stackpage=80b50000)
Jan  1 06:14:50 kernel: Stack: fffffff9 801104d8 00000000 801e4838 80be5000 80d07000 80be5170 00000000
Jan  1 06:14:50 kernel:        0000085b 00000004 8009bd24 80b51ea0 802fae00 80d07000 802fae00 80d07000
Jan  1 06:14:50 kernel:        802fae00 80d07000 800b4618 800b4558 80163160 8016307c 80032b04 00000ac0
Jan  1 06:14:50 kernel:        0000085b 80d07000 00000000 7fff1383 80be5000 8009bf34 80b51ed0 80b51e88
Jan  1 06:14:50 kernel:        00002044 80b64b08 7fff0b28 0000085b 80be5000 7fff0b28 00000000 80dba6d0
Jan  1 06:14:50 kernel:        80be5980 ...
Jan  1 06:14:50 kernel: Call Trace: [<801104d8>] [<8009bd24>] [<800b4618>] [<800b4558>] [<80163160>] [<8016307c>]
Jan  1 06:14:50 kernel:  [<80032b04>] [<8009bf34>] [<80098c7c>] [<80105324>] [<80098a68>] [<80095ee4>]
Jan  1 06:14:50 kernel:  [<80105468>] [<80092f54>] [<80039e08>] [<80014d48>] [<801a3c04>] [<8000704c>]
Jan  1 06:14:50 kernel:  [<8000704c>]
Jan  1 06:14:50 kernel:
Jan  1 06:14:50 kernel: Code: 00000000  12040018  00c08821 <8e04fffc> 00002821  8c820000  00000000  00541024  1040000d
Jan  1 06:14:50 kernel: Neighbour table overflow.
Jan  1 06:14:51 kernel: Neighbour table overflow.

 

кстати с меньшим мту, выставил 726 станицы некоторые не хотят грузится.

[sfstudio]

Поставил тестовую версию 0.2.11 на акрп wr-g для соединения по pptp

результаты следующие:

1. С дефолтным mtu опять краш

Блин, ну ребята, ну пишите конкретно название файла который лили, я же не зря их обзываю по разному.

 

2. С мту 726(половина от максимума) связь стабильна. и даже лампочки мыргают почти синхронно. :)

Хыхх..

 

3. Повысив мту до 1100 почемуто перестали проходить запосы по именам, т.е. по ой-пи пинг есть, по имени пинга нет....

Это на обратной стороне некорретно обрабатываются размеры фреймов, шаттаная ситуация и решается фрагментацией на клиенте.

 

4. Не могу подцепиться к фтп локальному... Может есть какие предложения ?

Почитать о режимах active/passive и подумать?

 

5. Нашел на просторах инета в форуме такую конфигурацию для иптеблес

iptables -A FORWARD -o ppp0 -j TCPMSS --clamp-mss-to-pmtu

утсаканивает мту на концах точка-клиент. Заремил в конфиге знчение мту. По дефолту стало 1500 проработало 15 мин

потом тупо заткнулось. ppp0-есть, но не работает, т.е. не пингуется......

А если бы смотрели внимаетельно то в конфиге уже есть пример на эту тему.

 

6. Выставил мту 1452 с верхней поправкой отработало мин 15 потом я нечаяно ребутнул роутер кргда писал этот пост :(

7. ФТП так и не открывается....жалко, будем копать далее....

...7 мин после ребута фильмец на закачке , пока работает....

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

[sfstudio]

ну вот и краш, но без ребута...

т.е. 13 мин. отаботали все таки.....

Jan  1 06:13:27 kernel: Neighbour table overflow.                                                                                         
Jan  1 06:13:28 kernel: Neighbour table overflow.                                                                                         
Jan  1 06:14:51 kernel: Neighbour table overflow.

Это уже видать из другой серии. Глянем.

 

кстати с меньшим мту, выставил 726 станицы некоторые не хотят грузится.

Что логично если DF бит на пакетах установлен. Методы лечения тоже существуют.

[sfstudio]

Выложил test4.

 

P.S. не даром прошу отписываться в ЖЖ, у мну доступ к форуму серез СТК на скорости 1,5кбит/с... Т.е. пока страница загрузится проще поседеть...

[sfstudio]

Я понимаю что это фантастика, однако поднял у себя в песочнице pptpd сеоврер mtu1500/mru1500 шифрования включено, всё работает корректно... Фантастика? Сейчас попробую отрубить шифрование.

[sfstudio]

Вот оно!!! ПОймал!!! Крашиться только если шифрование отключено и только если нужна фрагментация на стороне роутера!!! Сейчас бум разбираться.

[Aliech]

Хорошо, оч. похоже на коробку мою любимую (наши крендели шифрования не хотят), а пока что пример двух крешев В ОДНОМ логфайле (два раза первый без ребута):

Jan  1 06:02:00 pppd[178]: Using interface ppp0
Jan  1 06:02:00 pppd[178]: Connect: ppp0 <--> /dev/ttyp0
Jan  1 06:02:00 pptp[312]: anon log[main:pptp.c:314]: The synchronous pptp option is NOT activated
Jan  1 06:02:00 pptp[318]: anon log[ctrlp_disp:pptp_ctrl.c:752]: Received Start Control Connection Reply
Jan  1 06:02:00 pptp[318]: anon log[ctrlp_disp:pptp_ctrl.c:786]: Client connection established.
Jan  1 06:02:01 pptp[318]: anon log[ctrlp_disp:pptp_ctrl.c:871]: Received Outgoing Call Reply.
Jan  1 06:02:01 pppd[178]: Modem hangup
Jan  1 06:02:01 pppd[178]: Connection terminated.
Jan  1 06:02:01 pptp[318]: anon log[ctrlp_disp:pptp_ctrl.c:910]: Outgoing call established (call ID 0, peer's call ID 64494).
Jan  1 06:02:01 pptp[318]: anon log[callmgr_main:pptp_callmgr.c:237]: Closing connection (unhandled)
Jan  1 06:02:01 pptp[318]: anon log[call_callback:pptp_callmgr.c:82]: Closing connection (call state)
Jan  1 06:03:41 pppd[178]: Using interface ppp0
Jan  1 06:03:41 pppd[178]: Connect: ppp0 <--> /dev/ttyp0
Jan  1 06:03:41 pptp[339]: anon log[main:pptp.c:314]: The synchronous pptp option is NOT activated
Jan  1 06:03:41 pptp[345]: anon log[ctrlp_disp:pptp_ctrl.c:752]: Received Start Control Connection Reply
Jan  1 06:03:41 pptp[345]: anon log[ctrlp_disp:pptp_ctrl.c:786]: Client connection established.
Jan  1 06:03:42 pptp[345]: anon log[ctrlp_disp:pptp_ctrl.c:871]: Received Outgoing Call Reply.
Jan  1 06:03:42 pppd[178]: Modem hangup
Jan  1 06:03:42 pppd[178]: Connection terminated.
Jan  1 06:03:42 pptp[345]: anon log[ctrlp_disp:pptp_ctrl.c:910]: Outgoing call established (call ID 0, peer's call ID 64544).
Jan  1 06:03:42 pptp[345]: anon log[callmgr_main:pptp_callmgr.c:237]: Closing connection (unhandled)
Jan  1 06:03:42 pptp[345]: anon log[call_callback:pptp_callmgr.c:82]: Closing connection (call state)
Jan  1 06:05:23 pppd[178]: Using interface ppp0
Jan  1 06:05:23 pppd[178]: Connect: ppp0 <--> /dev/ttyp0
Jan  1 06:05:23 pptp[360]: anon log[main:pptp.c:314]: The synchronous pptp option is NOT activated
Jan  1 06:05:23 pptp[366]: anon log[ctrlp_disp:pptp_ctrl.c:752]: Received Start Control Connection Reply
Jan  1 06:05:23 pptp[366]: anon log[ctrlp_disp:pptp_ctrl.c:786]: Client connection established.
Jan  1 06:05:24 pptp[366]: anon log[ctrlp_disp:pptp_ctrl.c:871]: Received Outgoing Call Reply.
Jan  1 06:05:24 pppd[178]: Modem hangup
Jan  1 06:05:24 pppd[178]: Connection terminated.
Jan  1 06:05:24 pptp[366]: anon log[ctrlp_disp:pptp_ctrl.c:910]: Outgoing call established (call ID 0, peer's call ID 64553).
Jan  1 06:05:24 pptp[366]: anon log[callmgr_main:pptp_callmgr.c:237]: Closing connection (unhandled)
Jan  1 06:05:24 pptp[366]: anon log[call_callback:pptp_callmgr.c:82]: Closing connection (call state)
Jan  1 06:07:04 pppd[178]: Using interface ppp0
Jan  1 06:07:04 pppd[178]: Connect: ppp0 <--> /dev/ttyp0
Jan  1 06:07:04 pptp[389]: anon log[main:pptp.c:314]: The synchronous pptp option is NOT activated
Jan  1 06:07:04 pptp[395]: anon log[ctrlp_disp:pptp_ctrl.c:752]: Received Start Control Connection Reply
Jan  1 06:07:04 pptp[395]: anon log[ctrlp_disp:pptp_ctrl.c:786]: Client connection established.
Jan  1 06:07:05 pptp[395]: anon log[ctrlp_disp:pptp_ctrl.c:871]: Received Outgoing Call Reply.
Jan  1 06:07:05 pppd[178]: Modem hangup
Jan  1 06:07:05 pppd[178]: Connection terminated.
Jan  1 06:07:05 pptp[395]: anon log[ctrlp_disp:pptp_ctrl.c:910]: Outgoing call established (call ID 0, peer's call ID 64562).
Jan  1 06:07:05 pptp[395]: anon log[callmgr_main:pptp_callmgr.c:237]: Closing connection (unhandled)
Jan  1 06:07:05 pptp[395]: anon log[call_callback:pptp_callmgr.c:82]: Closing connection (call state)
Jan  1 06:08:45 pppd[178]: Using interface ppp0
Jan  1 06:08:45 pppd[178]: Connect: ppp0 <--> /dev/ttyp0
Jan  1 06:08:46 pptp[401]: anon log[main:pptp.c:314]: The synchronous pptp option is NOT activated
Jan  1 06:08:46 pptp[407]: anon log[ctrlp_disp:pptp_ctrl.c:752]: Received Start Control Connection Reply
Jan  1 06:08:46 pptp[407]: anon log[ctrlp_disp:pptp_ctrl.c:786]: Client connection established.
Jan  1 06:08:47 pptp[407]: anon log[ctrlp_disp:pptp_ctrl.c:871]: Received Outgoing Call Reply.
Jan  1 06:08:47 pppd[178]: Modem hangup
Jan  1 06:08:47 pppd[178]: Connection terminated.
Jan  1 06:08:47 pptp[407]: anon log[ctrlp_disp:pptp_ctrl.c:910]: Outgoing call established (call ID 0, peer's call ID 64570).
Jan  1 06:08:47 pptp[407]: anon log[callmgr_main:pptp_callmgr.c:237]: Closing connection (unhandled)
Jan  1 06:08:47 pptp[407]: anon log[call_callback:pptp_callmgr.c:82]: Closing connection (call state)
Jan  1 06:10:27 pppd[178]: Using interface ppp0
Jan  1 06:10:27 pppd[178]: Connect: ppp0 <--> /dev/ttyp0
Jan  1 06:10:27 pptp[435]: anon log[main:pptp.c:314]: The synchronous pptp option is NOT activated
Jan  1 06:10:27 pptp[441]: anon log[ctrlp_disp:pptp_ctrl.c:752]: Received Start Control Connection Reply
Jan  1 06:10:27 pptp[441]: anon log[ctrlp_disp:pptp_ctrl.c:786]: Client connection established.
Jan  1 06:10:28 pptp[441]: anon log[ctrlp_disp:pptp_ctrl.c:871]: Received Outgoing Call Reply.
Jan  1 06:10:28 pptp[441]: anon log[ctrlp_disp:pptp_ctrl.c:910]: Outgoing call established (call ID 0, peer's call ID 64580).
Jan  1 06:10:28 pppd[178]: CHAP authentication succeeded
Jan  1 06:10:28 pppd[178]: local  IP address 93.80.17.114
Jan  1 06:10:28 pppd[178]: remote IP address 85.21.0.79
Jan  1 09:36:21 syslog: wlan0: WPA2-AES PSK authentication in progress...
Jan  1 09:36:21 kernel: wlan0: A wireless client is associated - 00:15:AF:EF:86:5F
Jan  1 09:36:24 kernel: wlan0: A STA is rejected by 802.1x daemon - 00:15:AF:EF:86:5F
Jan  1 09:36:37 kernel: wlan0: A wireless client is associated - 00:15:AF:EF:86:5F
Jan  1 09:36:37 syslog: wlan0: WPA2-AES PSK authentication in progress...
Jan  1 09:36:39 syslog: wlan0: Open and authenticated
Jan  1 09:39:45 syslog: wlan0: WPA2-AES PSK authentication in progress...
Jan  1 09:39:45 kernel: wlan0: A wireless client is associated - 00:15:AF:EF:86:5F
Jan  1 09:39:47 syslog: wlan0: Open and authenticated
Jan  1 09:41:33 pptp[441]: anon log[callmgr_main:pptp_callmgr.c:237]: Closing connection (unhandled)
Jan  1 09:41:33 pptp[441]: anon log[call_callback:pptp_callmgr.c:82]: Closing connection (call state)
Jan  1 09:41:33 kernel: Unable to handle kernel paging request at virtual address 29ec7e74, epc == 8000af10, ra == 8009bd24
Jan  1 09:41:33 kernel: Oops in fault.c:do_page_fault, line 206:
Jan  1 09:41:33 kernel: $0 : 00000000 1000f400 00000000 fffffffe 80a27980 00000001 00000001 00000003
Jan  1 09:41:33 kernel: $8 : 00000000 00000000 00000002 0000006c 00000000 00000002 00000000 00000004
Jan  1 09:41:33 kernel: $16: 29ec7e78 00000001 80a27980 1000f401 00000001 00000813 80a27170 80a27150
Jan  1 09:41:33 kernel: $24: 0000000b 00000016                   8094c000 8094ddb0 8094ddb0 8009bd24
Jan  1 09:41:33 kernel: Hi : 000002cb
Jan  1 09:41:33 kernel: Lo : 000ad323
Jan  1 09:41:33 kernel: epc  : 8000af10    Not tainted
Jan  1 09:41:33 kernel: Status: 1000f400
Jan  1 09:41:33 kernel: Cause : 10000008
Jan  1 09:41:33 kernel: Process pptp (pid: 435, stackpage=8094c000)
Jan  1 09:41:33 kernel: Stack: fffffff9 801104d8 00000000 801e4838 80a27000 80c08000 80a27170 00000000
Jan  1 09:41:33 kernel:        00000813 00000004 8009bd24 a08ae084 8034f800 80c08000 8034f800 80c08000
Jan  1 09:41:33 kernel:        8034f800 80c08000 800b4618 800b4558 00000001 00000000 00000000 8011ada8
Jan  1 09:41:33 kernel:        00000813 80c08000 00000000 7fff133b 80a27000 8009bf34 8013cd14 7fff4b80
Jan  1 09:41:33 kernel:        80239790 80caa060 7fff0b28 00000813 80a27000 7fff0b28 00000000 80b20cf0
Jan  1 09:41:33 kernel:        80a27980 ...
Jan  1 09:41:33 kernel: Call Trace: [<801104d8>] [<8009bd24>] [<800b4618>] [<800b4558>] [<8011ada8>] [<8009bf34>]
Jan  1 09:41:33 kernel:  [<8013cd14>] [<80098c7c>] [<800e1cf4>] [<8013cd14>] [<80098a68>] [<80095ee4>]
Jan  1 09:41:33 kernel:  [<800156bc>] [<800156bc>] [<80092f54>] [<80039e08>] [<800913cc>] [<80014d48>]
Jan  1 09:41:33 kernel:  [<801a3c0c>] [<8000704c>] [<801af244>]
Jan  1 09:41:33 kernel: 
Jan  1 09:41:33 kernel: Code: 00000000  12040018  00c08821 <8e04fffc> 00002821  8c820000  00000000  00541024  1040000d

Версия 0.2.11-tes.bin bla-bla-bla (отнёс комп с XP в утиль, так что сказать точней не могу)

 

PS: у Вас же был доступ к сорцам Зюхеля... у этих парней и рашн пптп где-то засветился... и для p330 конфиги l2tp под страшную тучу провайдеров, с Корбиной во главе был....

Изменено 24 января, 2009 пользователем Aliech

[sfstudio]

Хорошо, оч. похоже на коробку мою любимую (наши крендели шифрования не хотят), а пока что пример двух крешев В ОДНОМ логфайле (два раза первый без ребута):

PS: у Вас же был доступ к сорцам Зюхеля... у этих парней и рашн пптп где-то засветился... и для p330 конфиги l2tp под страшную тучу провайдеров, с Корбиной во главе был....

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

 

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

 

А вот и решение. Правду говорят утро вечера мудренее, сейчас придумаю как решить проблему с DRIVER SPEEDUP при включенном ppp и залью.

 

Поторопился блин... Ищу дальше %(

[vmn_fs]

версия "::Wive-NG-0.2.11-TEST::RTL8186-REALTIME::"

мту=960

включены исправления коллизий для pptp

ррtp без шифрования.

метод авторизации chap

работает уже часов 14 , продолжается закачка фильмеца...из 1.5 гигов скачано 53% - уже успех.

 

зы железяка - акорп вр-г.

[sfstudio]

Дальнейший разбор полётов. В общем mtu на интерфейсе не играет роли для локальных пакетов, т.е. Даже если ppp0 локально с MTU=100 то ping -s1010 через туннель гарантированно убьёт его, с шифрованием всё красиво. Причём именно -s1010 т.е. результирующий icmp пакет будет иметь размер 1018 байт. Куда копать уже сесслово незнаю, требуется свежий взгляд на код ppp_generic.c

[Aliech]

Дальнейший разбор полётов. В общем mtu на интерфейсе не играет роли для локальных пакетов, т.е. Даже если ppp0 локально с MTU=100 то ping -s1010 через туннель гарантированно убьёт его, с шифрованием всё красиво. Причём именно -s1010 т.е. результирующий icmp пакет будет иметь размер 1018 байт. Куда копать уже сесслово незнаю, требуется свежий взгляд на код ppp_generic.c

А это баг skbuff? М.б., прошу за глупость, другую службу ppp грохнуть? У меня вот ща как-то с mtu 1460 на ноуте идёт ppp (Ubuntu Intrepid).

 

[sfstudio]

А это баг skbuff?

Это баг вылезший при переносе на big endian, где он вылез найти не могы нифига ;( И далеко не факт что skbuff, всё дело в том что будь баг в нём то и с mppe так же бы сыпалось. Я уже выризал весь код из модуля ppp который реализует например мультилинк и пытаюсь по шагам найти где возникает переполнение, но пока успехи нулевые. Возможно я даже не там собсно и проблему ищу.

 

М.б., прошу за глупость, другую службу ppp грохнуть? У меня вот ща как-то с mtu 1460 на ноуте идёт ppp (Ubuntu Intrepid).

Млин, ну вы читайте внимателеньее условия проявления бага? Только при отклюбченном mpee и только если пакет исходящий относительно руотера и только если этот пакет >1018 байт (ping -s1010 на роутере). Кого грохнуть-то? Всех горбин отстрелить? Я незнаю к чему экономия на спичках в виде отключенного шифрования, но увы это повсеместная практика ;(

 

Страдают ВСЕ туннели pptp/l2tp/pppoe, если на pptp это можно подпереть костылём в виде нетфильтра который умеет согласовывать размеры пакетов на L3, то для pppoe/l2tp такой финт ушами не проканывает и единственная возможность их использовать - включить шифрование с ОБОИХ СТОРОН.

 

Лучше бы вместо нелепых предположений взяли бы в зубы код и попробовали бы разобраться, может на свежий взгляд и нашли бы причину. Я вот уже 2е сутки безвылазно бьюсь над этой проблемой, хотя по сути мне она вообще фиолетова ибо шифрование я всёравно использую абсолютно везде и на всех типах туннелей.

[Aliech]

Ну так может костылём? Программист я конечно крутой - в обратную сторону аж =(

[sfstudio]

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