MagMike Опубликовано 28 февраля, 2009 · Жалоба При 10% сколько сессий и пакетов получилось? порядка 400 машина 2-х ядерная 3 ггц а у меня другая проблема. похоже, accel-pptp "живет" на одном процессоре. причем вместе с одной из сетёвок 05:45:14 PM CPU %user %nice %sys %iowait %irq %soft %steal %idle intr/s 05:45:15 PM all 1.49 0.00 2.49 0.00 0.00 46.52 0.00 49.50 4698.00 05:45:15 PM 0 3.00 0.00 7.00 0.00 0.00 86.00 0.00 4.00 3624.00 05:45:15 PM 1 0.00 0.00 2.00 0.00 0.00 1.00 0.00 97.00 0.00 05:45:15 PM 2 0.00 0.00 1.00 0.00 0.00 100.00 0.00 0.00 53.00 05:45:15 PM 3 2.00 0.00 0.00 0.00 0.00 0.00 0.00 98.00 0.00 на CPU2 softirq на 100%, а на остальных sys почти не занят. и это при >900 сессиях. т.е. получается, что скорее всего все-таки pptp висят на этом же втором CPU. как-то заставить работать его на другом можно? или выход только от обратного - переносом irq сетевой карты на CPU3? акссел работает на том-же ядре где идет софт ирк... если 1-ый проц перегрузится - начнет заниматься второй и так далее... надо распределить софт ирк от сетеых плат по процессорам... щас е вспомню но где-то уже про это на форуме писали в двух словах 1. надо посмотреть на каких ирках висят ваши сетевухи 2. прописать афинити маски для этих ирков (их надо загонять в какой-то стартап скрипт после поднятия сетевух т.к. они сбрасываются при up'е делается все через /proc 1-2 сделанов сервере 2 сетевых. на одной запущен pptp. эта карта работает на CPU0. вторая (на CPU2) смотрит в инет. запущено 2 серверных процесса - один с mppe, другой без.кстати, чтобы не делать костыли в виде двух процессов, в состав пакета включен патч для pppd-2.4.4 (pppd-allow-mppe.patch), который позволяет подключаться клиентам как с mppe так и без него Совсем недавно искал такой патчик, и не нашел зато нашел что не работает allow but not require mppe.. дайте ссылку на доку плз (( тоже не нашел патч... тоже прошу дать ссылку. можно попробовать сделать патч для распараллеливания, но нужны добровольцы с 4 более ядрами для тестирования, так что если кто будет заинтересован - обращайтесьнужно именно 4 ядра или пойдет coreduo c включенным HT? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
shicoy Опубликовано 28 февраля, 2009 · Жалоба Кстати, оффтопик и нубский вопрос: как повесить сетевую карту на определенный cpu? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xeb Опубликовано 28 февраля, 2009 (изменено) · Жалоба запущено 2 серверных процесса - один с mppe, другой без.кстати, чтобы не делать костыли в виде двух процессов, в состав пакета включен патч для pppd-2.4.4 (pppd-allow-mppe.patch), который позволяет подключаться клиентам как с mppe так и без него Совсем недавно искал такой патчик, и не нашел зато нашел что не работает allow but not require mppe.. дайте ссылку на доку плз (( тоже не нашел патч... тоже прошу дать ссылку. r61 | xebd | 2009-02-12 10:34:35 +0000 (Чтв, 12 Фев 2009) | 1 line on request of workers developed and included pppd-allow-mppe.patch в каталоге contrib можно попробовать сделать патч для распараллеливания, но нужны добровольцы с 4 более ядрами для тестирования, так что если кто будет заинтересован - обращайтесь нужно именно 4 ядра или пойдет coreduo c включенным HT? подойдёт Кстати, оффтопик и нубский вопрос: как повесить сетевую карту на определенный cpu?в /proc/irq находишь прерывание сетевой карты и в smp_affinity пишеть маску на каких процессорах можно запускать обработку этого прервания, например #ls /proc/irq/313/ eth0 smp_affinity spurious #echo 1 > /proc/irq/313/smp_affinity это привязывает прерывание на первый проц Изменено 28 февраля, 2009 пользователем xeb Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sdy_moscow Опубликовано 28 февраля, 2009 · Жалоба дополню предид. пост smp_affinity - это битовая маска для конкретного прерывания если у вас 4 ядра то можно привязать на 1 и 2 ой проц #echo 3 > /proc/irq/313/smp_affinity если на 4-ый то #echo 8 > /proc/irq/313/smp_affinity а если на все 4 то #echo 1 > /proc/irq/313/smp_affinity если у вас 2 сетевухи, то желательно чтоб они были на разных прерываниях для каждого из прерываний можно указать разные процессоры... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
stelsik Опубликовано 28 февраля, 2009 (изменено) · Жалоба У меня есть сервер HP DL360 с E5310 это 4 ядра, как раз собирать хотел под PPTP с accel-pptp, могу ssh на него, но сессий более 100 пока предложить не могу. Соединения с шифрованием и без одновременно, адреса у клиентов все статик, опция delegate В отладке понимаю мало изза этого и ssh, предполагаемая система CentOS Изменено 28 февраля, 2009 пользователем stelsik Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xeb Опубликовано 28 февраля, 2009 · Жалоба stelsik, ну если клиенты вижать не будут, то не откажусь :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xeb Опубликовано 1 марта, 2009 · Жалоба r65 | xeb | 2009-03-01 15:53:49 +0300 (Вск, 01 Мар 2009) | 4 lines * added ppp_generic_smp driver for 2.6.26-28 kernels (untested) This driver is replacement of kernel's ppp_generic driver for better smp performance. It is disabled by default, to enable you should uncomment it in kernel/driver/Makefile * added ppp_generic_smp driver for 2.6.26-28 kernels (untested) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xeb Опубликовано 1 марта, 2009 · Жалоба тестирование ppp_generic_smp показало малую эффективность текущей реализации, но есть идеи как сделать несколько иначе Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
shicoy Опубликовано 3 марта, 2009 · Жалоба Ждем ждем :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SokolovS Опубликовано 3 марта, 2009 · Жалоба Если accel так молотит на одном проце, то я уже представляю как он будет пахать на 4-х ядрах к примеру. Тоже очень жду. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 3 марта, 2009 (изменено) · Жалоба Кстати, это принципиальная позиция не работоспособности persist с accel pptp или просто руки не дошли? А то удалось наконец прикрутить данное чудо к wive-ng и засада с persist всё портит. Если не сложно добавьтие в плагин обработку сего дела, в своём коде ИМХО проще разобраться чем мне. Пока привернул вот такой костылик, но как-то оно не кузяво: --- pptp_callmgr.c.old 2009-03-04 05:50:19.511922522 +0600 +++ pptp_callmgr.c 2009-03-04 05:55:22.169920349 +0600 @@ -26,6 +26,10 @@ #include "vector.h" #include "util.h" +/* Supplied by pppd if we're a plugin */ +extern int persist; +extern int holdoff; + extern struct in_addr localbind; /* from pptp.c */ extern int call_ID; @@ -87,6 +91,12 @@ if(lci->pid[0] > 1) kill(lci->pid[0], SIGTERM); if(lci->pid[1] > 1) kill(lci->pid[1], SIGTERM); } + /* redial if peer closed connect */ + if (persist) { + log("Persist mode, start redial."); + sleep(holdoff); + execl("/bin/sh", "sh", "-c", "/etc/init.d/vpnnetwork-pptp restart", (char *)0); + } break; default: log("Unhandled call callback state [%d].", (int) state); Зато гарантированно переподнимется, но ИМХО нужно сделать более элегантно. Изменено 3 марта, 2009 пользователем sfstudio Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 9 марта, 2009 · Жалоба Есть ещё одна проблема. Если в роли сервера linux/bsd то всё работает как часы, если в роли сервера винды то в независимости от настроек имеем: Jan 1 06:00:12 kernel: PPP MPPE Compression module registered Jan 1 06:00:13 pptp[177]: Plugin /lib/pptp.so loaded. Jan 1 06:00:13 pptp[177]: PPTP plugin version 0.8.2 compiled for pppd-2.4.5 Jan 1 06:00:13 pptp[177]: pppd 2.4.5 started by root, uid 0 Jan 1 06:00:13 pptp[181]: anon log[callmgr_main:pptp_callmgr.c:142]: IP: 10.253.253.1 Jan 1 06:00:58 pptp[181]: anon log[callmgr_main:pptp_callmgr.c:146]: control connection Jan 1 06:00:58 pptp[181]: anon log[callmgr_main:pptp_callmgr.c:150]: unix_sock Jan 1 06:00:58 pptp[262]: anon log[ctrlp_disp:pptp_ctrl.c:747]: Received Start Control Connection Reply Jan 1 06:00:58 pptp[262]: anon log[ctrlp_disp:pptp_ctrl.c:781]: Client connection established. Jan 1 06:00:59 pptp[262]: anon log[ctrlp_disp:pptp_ctrl.c:866]: Received Outgoing Call Reply. Jan 1 06:00:59 pptp[262]: anon log[ctrlp_disp:pptp_ctrl.c:901]: Set link (call ID 717403780, peer's call ID 7173. Jan 1 06:00:59 pptp[177]: using channel 1 Jan 1 06:00:59 pptp[262]: anon log[ctrlp_disp:pptp_ctrl.c:906]: Outgoing call established (call ID 1, peer's cal. Jan 1 06:00:59 pptp[177]: Using interface ppp0 Jan 1 06:00:59 pptp[177]: Connect: ppp0 <--> pptp (10.253.253.1) Jan 1 06:00:59 pptp[177]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x33d20a85>] Jan 1 06:01:02 pptp[177]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x33d20a85>] Jan 1 06:01:05 pptp[177]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x33d20a85>] Jan 1 06:01:08 pptp[177]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x33d20a85>] Jan 1 06:01:11 pptp[177]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x33d20a85>] Jan 1 06:01:14 pptp[177]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x33d20a85>] Jan 1 06:01:17 pptp[177]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x33d20a85>] Jan 1 06:01:20 pptp[177]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x33d20a85>] Jan 1 06:01:23 pptp[177]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x33d20a85>] Jan 1 06:01:26 pptp[177]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x33d20a85>] Jan 1 06:01:29 pptp[177]: LCP: timeout sending Config-Requests Jan 1 06:01:29 pptp[177]: Connection terminated. Jan 1 06:01:29 pptp[177]: Modem hangup в снифере тем временем: [root@sfstudio ppp]# tcpdump -i wlan0 -p -n | grep "10.200.200.249" tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on wlan0, link-type EN10MB (Ethernet), capture size 96 bytes 03:13:03.549540 ARP, Request who-has 10.253.253.1 tell 10.200.200.249, length 28 03:13:03.552502 IP 10.200.200.249.52768 > 10.253.253.1.1723: Flags [SEW], seq 1009255031, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 0], length 0 03:13:06.562888 IP 10.200.200.249.52768 > 10.253.253.1.1723: Flags [SEW], seq 1009255031, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 0], length 0 03:13:12.586335 IP 10.200.200.249.52768 > 10.253.253.1.1723: Flags [SEW], seq 1009255031, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 0], length 0 03:13:24.636201 IP 10.200.200.249.52768 > 10.253.253.1.1723: Flags [SEW], seq 1009255031, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 0], length 0 03:13:48.734194 IP 10.200.200.249.52768 > 10.253.253.1.1723: Flags [SEW], seq 1009255031, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 0], length 0 03:13:48.734845 IP 10.253.253.1.1723 > 10.200.200.249.52768: Flags [S.], seq 104428056, ack 1009255032, win 64240, options [mss 1460,nop,wscale 0,nop,nop,sackOK], length 0 03:13:48.735588 IP 10.253.253.1.1723 > 10.200.200.249.52768: Flags [S.], seq 104428056, ack 1009255032, win 64240, options [mss 1460,nop,wscale 0,nop,nop,sackOK], length 0 03:13:48.737920 IP 10.200.200.249.52768 > 10.253.253.1.1723: Flags [.], ack 1, win 5840, length 0 03:13:48.756604 IP 10.200.200.249.52768 > 10.253.253.1.1723: Flags [P.], ack 1, win 5840, length 156: pptp CTRL_MSGTYPE=SCCRQ PROTO_VER(1.0) FRAME_CAP(AS) BEARER_CAP(DA) MAX_CHAN(65535) FIRM_REV(1) [|pptp] 03:13:48.757058 IP 10.253.253.1.1723 > 10.200.200.249.52768: Flags [P.], ack 157, win 64084, length 156: pptp CTRL_MSGTYPE=SCCRP PROTO_VER(1.0) RESULT_CODE(1) ERR_CODE(0) FRAME_CAP(S) BEARER_CAP(DA) MAX_CHAN(0) FIRM_REV(2600) [|pptp] 03:13:48.758119 IP 10.253.253.1.1723 > 10.200.200.249.52768: Flags [P.], ack 157, win 64084, length 156: pptp CTRL_MSGTYPE=SCCRP PROTO_VER(1.0) RESULT_CODE(1) ERR_CODE(0) FRAME_CAP(S) BEARER_CAP(DA) MAX_CHAN(0) FIRM_REV(2600) [|pptp] 03:13:48.761367 IP 10.200.200.249.52768 > 10.253.253.1.1723: Flags [.], ack 157, win 5840, length 0 03:13:49.829978 IP 10.200.200.249.52768 > 10.253.253.1.1723: Flags [P.], ack 157, win 5840, length 168: pptp CTRL_MSGTYPE=OCRQ CALL_ID(52768) CALL_SER_NUM(0) MIN_BPS(2400) MAX_BPS(10000000) BEARER_TYPE(Any) FRAME_TYPE(E) RECV_WIN(50) PROC_DELAY(0) [|pptp] 03:13:49.835824 IP 10.253.253.1.1723 > 10.200.200.249.52768: Flags [P.], ack 325, win 63916, length 32: pptp CTRL_MSGTYPE=OCRP CALL_ID(16415) PEER_CALL_ID(52768) RESULT_CODE(1) ERR_CODE(0) CAUSE_CODE(0) CONN_SPEED(549240320) RECV_WIN(16384) PROC_DELAY(0) PHY_CHAN_ID(0) 03:13:49.836453 IP 10.253.253.1.1723 > 10.200.200.249.52768: Flags [P.], ack 325, win 63916, length 32: pptp CTRL_MSGTYPE=OCRP CALL_ID(16415) PEER_CALL_ID(52768) RESULT_CODE(1) ERR_CODE(0) CAUSE_CODE(0) CONN_SPEED(549240320) RECV_WIN(16384) PROC_DELAY(0) PHY_CHAN_ID(0) 03:13:49.839830 IP 10.200.200.249.52768 > 10.253.253.1.1723: Flags [.], ack 189, win 5840, length 0 03:13:49.969890 IP 10.200.200.249 > 10.253.253.1: GREv1, call 16415, seq 1, length 32: LCP, Conf-Request (0x01), id 1, length 18 03:13:49.971554 IP 10.253.253.1 > 10.200.200.249: GREv1, call 52768, seq 0, ack 1, length 77: LCP, Conf-Request (0x01), id 0, length 59 03:13:49.971615 IP 10.253.253.1 > 10.200.200.249: GREv1, call 52768, seq 1, length 32: LCP, Conf-Ack (0x02), id 1, length 18 03:13:49.972782 IP 10.253.253.1 > 10.200.200.249: GREv1, call 52768, seq 0, ack 1, length 77: LCP, Conf-Request (0x01), id 0, length 59 03:13:49.973111 IP 10.253.253.1 > 10.200.200.249: GREv1, call 52768, seq 1, length 32: LCP, Conf-Ack (0x02), id 1, length 18 03:13:51.958357 IP 10.253.253.1 > 10.200.200.249: GREv1, call 52768, seq 2, length 73: LCP, Conf-Request (0x01), id 1, length 59 03:13:51.959649 IP 10.253.253.1 > 10.200.200.249: GREv1, call 52768, seq 2, length 73: LCP, Conf-Request (0x01), id 1, length 59 03:13:52.975534 IP 10.200.200.249 > 10.253.253.1: GREv1, call 16415, seq 2, length 32: LCP, Conf-Request (0x01), id 1, length 18 03:13:52.976473 IP 10.253.253.1 > 10.200.200.249: GREv1, call 52768, seq 3, ack 2, length 36: LCP, Conf-Ack (0x02), id 1, length 18 03:13:52.977325 IP 10.253.253.1 > 10.200.200.249: GREv1, call 52768, seq 3, ack 2, length 36: LCP, Conf-Ack (0x02), id 1, length 18 03:13:54.965712 IP 10.253.253.1 > 10.200.200.249: GREv1, call 52768, seq 4, length 73: LCP, Conf-Request (0x01), id 2, length 59 03:13:54.966463 IP 10.253.253.1 > 10.200.200.249: GREv1, call 52768, seq 4, length 73: LCP, Conf-Request (0x01), id 2, length 59 03:13:55.987877 IP 10.200.200.249 > 10.253.253.1: GREv1, call 16415, seq 3, length 32: LCP, Conf-Request (0x01), id 1, length 18 03:13:55.988789 IP 10.253.253.1 > 10.200.200.249: GREv1, call 52768, seq 5, ack 3, length 36: LCP, Conf-Ack (0x02), id 1, length 18 03:13:55.989527 IP 10.253.253.1 > 10.200.200.249: GREv1, call 52768, seq 5, ack 3, length 36: LCP, Conf-Ack (0x02), id 1, length 18 03:13:58.966573 IP 10.253.253.1 > 10.200.200.249: GREv1, call 52768, seq 6, length 73: LCP, Conf-Request (0x01), id 3, length 59 03:13:58.967297 IP 10.253.253.1 > 10.200.200.249: GREv1, call 52768, seq 6, length 73: LCP, Conf-Request (0x01), id 3, length 59 03:13:58.997626 IP 10.200.200.249 > 10.253.253.1: GREv1, call 16415, seq 4, length 32: LCP, Conf-Request (0x01), id 1, length 18 03:13:58.998407 IP 10.253.253.1 > 10.200.200.249: GREv1, call 52768, seq 7, ack 4, length 36: LCP, Conf-Ack (0x02), id 1, length 18 03:13:58.999141 IP 10.253.253.1 > 10.200.200.249: GREv1, call 52768, seq 7, ack 4, length 36: LCP, Conf-Ack (0x02), id 1, length 18 03:14:02.010043 IP 10.200.200.249 > 10.253.253.1: GREv1, call 16415, seq 5, length 32: LCP, Conf-Request (0x01), id 1, length 18 03:14:02.010985 IP 10.253.253.1 > 10.200.200.249: GREv1, call 52768, seq 8, ack 5, length 36: LCP, Conf-Ack (0x02), id 1, length 18 03:14:02.012050 IP 10.253.253.1 > 10.200.200.249: GREv1, call 52768, seq 8, ack 5, length 36: LCP, Conf-Ack (0x02), id 1, length 18 03:14:02.996406 IP 10.253.253.1 > 10.200.200.249: GREv1, call 52768, seq 9, length 73: LCP, Conf-Request (0x01), id 4, length 59 03:14:02.997121 IP 10.253.253.1 > 10.200.200.249: GREv1, call 52768, seq 9, length 73: LCP, Conf-Request (0x01), id 4, length 59 03:14:05.022434 IP 10.200.200.249 > 10.253.253.1: GREv1, call 16415, seq 6, length 32: LCP, Conf-Request (0x01), id 1, length 18 03:14:05.034159 IP 10.253.253.1 > 10.200.200.249: GREv1, call 52768, seq 10, ack 6, length 36: LCP, Conf-Ack (0x02), id 1, length 18 03:14:05.034826 IP 10.253.253.1 > 10.200.200.249: GREv1, call 52768, seq 10, ack 6, length 36: LCP, Conf-Ack (0x02), id 1, length 18 03:14:06.976452 IP 10.253.253.1 > 10.200.200.249: GREv1, call 52768, seq 11, length 73: LCP, Conf-Request (0x01), id 5, length 59 03:14:06.977211 IP 10.253.253.1 > 10.200.200.249: GREv1, call 52768, seq 11, length 73: LCP, Conf-Request (0x01), id 5, length 59 03:14:08.034544 IP 10.200.200.249 > 10.253.253.1: GREv1, call 16415, seq 7, length 32: LCP, Conf-Request (0x01), id 1, length 18 03:14:08.035308 IP 10.253.253.1 > 10.200.200.249: GREv1, call 52768, seq 12, ack 7, length 36: LCP, Conf-Ack (0x02), id 1, length 18 03:14:08.036155 IP 10.253.253.1 > 10.200.200.249: GREv1, call 52768, seq 12, ack 7, length 36: LCP, Conf-Ack (0x02), id 1, length 18 03:14:11.000378 IP 10.253.253.1 > 10.200.200.249: GREv1, call 52768, seq 13, length 73: LCP, Conf-Request (0x01), id 6, length 59 03:14:11.001187 IP 10.253.253.1 > 10.200.200.249: GREv1, call 52768, seq 13, length 73: LCP, Conf-Request (0x01), id 6, length 59 03:14:11.048123 IP 10.200.200.249 > 10.253.253.1: GREv1, call 16415, seq 8, length 32: LCP, Conf-Request (0x01), id 1, length 18 03:14:11.048819 IP 10.253.253.1 > 10.200.200.249: GREv1, call 52768, seq 14, ack 8, length 36: LCP, Conf-Ack (0x02), id 1, length 18 03:14:11.049956 IP 10.253.253.1 > 10.200.200.249: GREv1, call 52768, seq 14, ack 8, length 36: LCP, Conf-Ack (0x02), id 1, length 18 03:14:14.059798 IP 10.200.200.249 > 10.253.253.1: GREv1, call 16415, seq 9, length 32: LCP, Conf-Request (0x01), id 1, length 18 03:14:14.060488 IP 10.253.253.1 > 10.200.200.249: GREv1, call 52768, seq 15, ack 9, length 36: LCP, Conf-Ack (0x02), id 1, length 18 03:14:14.989388 IP 10.253.253.1 > 10.200.200.249: GREv1, call 52768, seq 16, length 73: LCP, Conf-Request (0x01), id 7, length 59 03:14:14.989975 IP 10.253.253.1 > 10.200.200.249: GREv1, call 52768, seq 16, length 73: LCP, Conf-Request (0x01), id 7, length 59 03:14:17.071913 IP 10.200.200.249 > 10.253.253.1: GREv1, call 16415, seq 10, length 32: LCP, Conf-Request (0x01), id 1, length 18 03:14:17.072657 IP 10.253.253.1 > 10.200.200.249: GREv1, call 52768, seq 17, ack 10, length 36: LCP, Conf-Ack (0x02), id 1, length 18 03:14:17.073516 IP 10.253.253.1 > 10.200.200.249: GREv1, call 52768, seq 17, ack 10, length 36: LCP, Conf-Ack (0x02), id 1, length 18 03:14:18.991348 IP 10.253.253.1 > 10.200.200.249: GREv1, call 52768, seq 18, length 73: LCP, Conf-Request (0x01), id 8, length 59 03:14:18.993265 IP 10.253.253.1 > 10.200.200.249: GREv1, call 52768, seq 18, length 73: LCP, Conf-Request (0x01), id 8, length 59 03:14:20.151214 IP 10.200.200.249.52768 > 10.253.253.1.1723: Flags [P.], ack 189, win 5840, length 16: pptp CTRL_MSGTYPE=CCRQ CALL_ID(52768) 03:14:20.151817 IP 10.253.253.1.1723 > 10.200.200.249.52768: Flags [P.], ack 341, win 63900, length 148: pptp CTRL_MSGTYPE=CDN CALL_ID(16415) RESULT_CODE(0) ERR_CODE(0) CAUSE_CODE(0) [|pptp] 03:14:20.152592 IP 10.253.253.1.1723 > 10.200.200.249.52768: Flags [P.], ack 341, win 63900, length 148: pptp CTRL_MSGTYPE=CDN CALL_ID(16415) RESULT_CODE(0) ERR_CODE(0) CAUSE_CODE(0) [|pptp] 03:14:20.155455 IP 10.200.200.249.52768 > 10.253.253.1.1723: Flags [.], ack 337, win 5840, length 0 03:14:20.157065 IP 10.200.200.249.52768 > 10.253.253.1.1723: Flags [R.], seq 341, ack 337, win 5840, length 0 С userllevel pptp всё ОК, уже голову сломал. Есть мысли? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sdy_moscow Опубликовано 9 марта, 2009 · Жалоба Ну для начала сниферните поподробнее и побольше размер пакета... что там в LCP не понравилось - из этого не понятно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 9 марта, 2009 · Жалоба Ну для начала сниферните поподробнее и побольше размер пакета... что там в LCP не понравилось - из этого не понятно. Блин, пришлось заливать чёрт знает куда http://ifolder.ru/10957167 тут подключение файла отказало %( В общем это дамп соединений из wireshark Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 9 марта, 2009 · Жалоба Ребята, отбой, это глюки conntrack $( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
witos Опубликовано 11 марта, 2009 · Жалоба Ув. xeb, нельзя ли немного отвлечь? Увидел ссылку на pppd-allow-mppe.patch для одновременной возможности работы как с mppe, так и без.. Взял исходники из ppp-2.4.4-1.el5.src.rpm (у меня centos-5.2), пропатчил сабжем, собрал пакет... Вставил в options allow-mppe-128, больше никаких параметров относительно mppe нет. Коннекчусь с winXP, с обязательным шифрованием данных, - проблем нет, коннект ок. Пробую коннектиться без шифрования (отключаться, если есть шифрование) - винда выдает ошибку 734, протокол управления связью был прерван. в логах pppd sent [CHAP Success id=0xd4 "S=5F005FEA7FEEF251B7F26BD6298B5D73C46EE5F8"] sent [iPCP ConfReq id=0x1 <addr 172.16.1.1>] rcvd [CCP ConfReq id=0x5 <mppe +H -M -S -L -D +C>] sent [CCP ConfReq id=0x1 <mppe +H -M +S -L -D -C>] sent [CCP ConfNak id=0x5 <mppe +H -M +S -L -D -C>] rcvd [iPCP ConfReq id=0x6 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-wins 0.0.0.0> <ms-dns3 0.0.0.0> <ms-wins 0.0.0.0>] sent [iPCP ConfRej id=0x6 <ms-wins 0.0.0.0> <ms-wins 0.0.0.0>] rcvd [iPCP ConfAck id=0x1 <addr 172.16.1.1>] rcvd [CCP ConfRej id=0x1 <mppe +H -M +S -L -D -C>] MPPE required but peer refused sent [LCP TermReq id=0x2 "MPPE required but peer refused"] rcvd [CCP ConfReq id=0x7] Discarded non-LCP packet when LCP not open rcvd [iPCP ConfReq id=0x8 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>] Discarded non-LCP packet when LCP not open rcvd [LCP TermAck id=0x2 "MPPE required but peer refused"] Connection terminated. В чем может быть проблема , - у меня в настройках, или в патче? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xeb Опубликовано 11 марта, 2009 · Жалоба witos, да, я в курсе этой проблемы, дело в том что венда пытается пропихнуть сжатие mppc, это то и не нравится pppd, как немного освобожусь постараюсь доработать патч Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
witos Опубликовано 12 марта, 2009 · Жалоба witos, да, я в курсе этой проблемы, дело в том что венда пытается пропихнуть сжатие mppc, это то и не нравится pppd, как немного освобожусь постараюсь доработать патч Окей, не буду мешать, т.к. я в этом вопросе помочь не могу, уровень знаний не позволяет... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 13 марта, 2009 (изменено) · Жалоба Поставил вместо CentOS (в которой устал бороться с кваггой) Gentoo и на нее accel-pptp, квагга (0.9.11) вроде не падает, 0.98.6-r4 - теряла маршруты, accel-pptp r66 - при малой нагрузке (пара тестеров) работает вроде нормально, одно замечание - smp-версия модуля ppp не захотела компилироваться, пришлось закомментировать в мейкфайле... И еще одна странность - смущает состояние UNKNOWN интерфейса по ip a (на 0.7.13 такого не видел): ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1400 qdisc htb state UNKNOWN qlen 3 P.S. еще небольшая просьба - можно ли в новых версиях включать сразу ebuild для их сборки? Для этого не обязательно для каждого билда делать отдельный тарбол - можно ведь и в форме патча для стабильной выложенной версии сделать... Изменено 14 марта, 2009 пользователем NiTr0 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xeb Опубликовано 13 марта, 2009 · Жалоба r67 | xebd | 2009-03-13 17:40:16 +0300 (Птн, 13 Мар 2009) | 2 lines updated ppp-allow-mppe.patch P.S. еще небольшая просьба - можно ли в новых версиях включать сразу ebuild для их сборки?хорошо, начиная с 0.8.3 ... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 15 марта, 2009 (изменено) · Жалоба Кстати,е сть такая бага с accel-pptp в режиме клиента. При подъёме соединения он на какой-то чёрт шлёт icmp пакет destination unreacheble серверу, тот "естественно кладёт трубку", проблема решается правилом iptables -A OUTPUT -o wlan0 -p icmp -m icmp --icmp-type 3 -j DROP нанужном ифейсе. Но как-то некузяво. Как лечить? Хочется избавиться от костыля. Такой пакет генериться в еденичном экземпляре и после того как соединение установлено правило можно смело удалять. P.S. Ядро 2.4, с 2.6 может и не проявляться, нужно потестировать. В роли сервера последний poptop обчлуживающий ещё не одну стоку клиентов. Изменено 15 марта, 2009 пользователем sfstudio Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sdy_moscow Опубликовано 15 марта, 2009 (изменено) · Жалоба icmp пакеты аксел никогда не слал и слать не будет ибо icmp к pptp НИКАКОГО ОТНОШЕНИЯ НЕ ИМЕЕТ! Ищите косяк в системе. Хотя как вариант - причиной может быть отсутвие открытого сокета на момент получения пакета. Изменено 15 марта, 2009 пользователем sdy_moscow Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 15 марта, 2009 · Жалоба icmp пакеты аксел никогда не слал и слать не будет ибо icmp к pptp НИКАКОГО ОТНОШЕНИЯ НЕ ИМЕЕТ! Ищите косяк в системе. Хотя как вариант - причиной может быть отсутвие открытого сокета на момент получения пакета. Да понятно что шлёт не он а ядро сообщает о том что сторона не готова/не доступна. Вполне вероятно что да, сокет ещё не открыт а пакет уже прилетел ессно ядро отправило назад icmp пакет. Возможно стоит пересмотреть порядок обработки соединения, я уже думал над этим, но сейчас времени практически нет даже близко разбираться с этим делом. На 2.6 не повторямо? Проблема только если accel-pptp работает клиентом. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sdy_moscow Опубликовано 15 марта, 2009 (изменено) · Жалоба я его клиентом не тестил :-( и не анализировал... зато сервером работает уже месяц с лишним - просто прекрасно :-)... По теме - там косяки в основном завязаны не на сам драйвер а на поптоп - так что начинать надо с самого начала разбираться .... Это на сутки возни минимум. В любом случае - я бы рекомендовал попробовать на 2.6 ядре с последней версией акселя. З.Ы. как говорится - курите сурсы... Изменено 15 марта, 2009 пользователем sdy_moscow Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 15 марта, 2009 · Жалоба я его клиентом не тестил :-( и не анализировал...зато сервером работает уже месяц с лишним - просто прекрасно :-)... Ну сервером оно и у меня работает кое-где с незапамятных времён. По теме - там косяки в основном завязаны не на сам драйвер а на поптоп - так что начинать надо с самого начала разбираться ....Это на сутки возни минимум. Угу, плугин вообще страшный. В любом случае - я бы рекомендовал попробовать на 2.6 ядре с последней версией акселя. Когда риалтэк откроет сырцы wifi модуля тогда может хотябы переедем на последнее 2.4 ядро, а пока у нас 2.4.18 куда модуль пришлось портировать самостоятельно, спасибо ребятам из dxilab. У них ещё веселее 2.4.17 монтависта. Но проблема есть и у них и у меня и на последнем 2.4 в режиме клиента, думаю и в 2.6 будет. З.Ы. как говорится - курите сурсы... Дык и курим, и чем больше курим тем больше желание снести нахрен этот плугин и начать кивирять с нуля свою реализацию ибо там сам чёрт ногу сломит. Отягощается тем что отлаживать вслепую на 200 мегагерцовом мипсе это ещё то занятие. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...