Перейти к содержимому
Калькуляторы
При 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?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Кстати, оффтопик и нубский вопрос: как повесить сетевую карту на определенный cpu?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

запущено 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

это привязывает прерывание на первый проц

Изменено пользователем xeb

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

дополню предид. пост

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 сетевухи, то желательно чтоб они были на разных прерываниях

для каждого из прерываний можно указать разные процессоры...

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У меня есть сервер HP DL360 с E5310 это 4 ядра, как раз собирать хотел под PPTP с accel-pptp, могу ssh на него, но сессий более 100 пока предложить не могу.

Соединения с шифрованием и без одновременно, адреса у клиентов все статик, опция delegate

В отладке понимаю мало изза этого и ssh, предполагаемая система CentOS

Изменено пользователем stelsik

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

stelsik, ну если клиенты вижать не будут, то не откажусь :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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)

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

тестирование ppp_generic_smp показало малую эффективность текущей реализации, но есть идеи как сделать несколько иначе

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если accel так молотит на одном проце, то я уже представляю как он будет пахать на 4-х ядрах к примеру. Тоже очень жду.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Кстати, это принципиальная позиция не работоспособности 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);

 

Зато гарантированно переподнимется, но ИМХО нужно сделать более элегантно.

Изменено пользователем sfstudio

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Есть ещё одна проблема. Если в роли сервера 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 всё ОК, уже голову сломал. Есть мысли?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну для начала сниферните поподробнее и побольше размер пакета... что там в LCP не понравилось - из этого не понятно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну для начала сниферните поподробнее и побольше размер пакета... что там в LCP не понравилось - из этого не понятно.

Блин, пришлось заливать чёрт знает куда http://ifolder.ru/10957167 тут подключение файла отказало %( В общем это дамп соединений из wireshark

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ребята, отбой, это глюки conntrack $(

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ув. 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.

 

В чем может быть проблема , - у меня в настройках, или в патче?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

witos, да, я в курсе этой проблемы, дело в том что венда пытается пропихнуть сжатие mppc, это то и не нравится pppd, как немного освобожусь постараюсь доработать патч

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

witos, да, я в курсе этой проблемы, дело в том что венда пытается пропихнуть сжатие mppc, это то и не нравится pppd, как немного освобожусь постараюсь доработать патч

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Поставил вместо 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 для их сборки? Для этого не обязательно для каждого билда делать отдельный тарбол - можно ведь и в форме патча для стабильной выложенной версии сделать...

Изменено пользователем NiTr0

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

r67 | xebd | 2009-03-13 17:40:16 +0300 (Птн, 13 Мар 2009) | 2 lines

updated ppp-allow-mppe.patch

P.S. еще небольшая просьба - можно ли в новых версиях включать сразу ebuild для их сборки?
хорошо, начиная с 0.8.3 ...

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Кстати,е сть такая бага с 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 обчлуживающий ещё не одну стоку клиентов.

Изменено пользователем sfstudio

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

icmp пакеты аксел никогда не слал и слать не будет ибо icmp к pptp НИКАКОГО ОТНОШЕНИЯ НЕ ИМЕЕТ! Ищите косяк в системе. Хотя как вариант - причиной может быть отсутвие открытого сокета на момент получения пакета.

Изменено пользователем sdy_moscow

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

icmp пакеты аксел никогда не слал и слать не будет ибо icmp к pptp НИКАКОГО ОТНОШЕНИЯ НЕ ИМЕЕТ! Ищите косяк в системе. Хотя как вариант - причиной может быть отсутвие открытого сокета на момент получения пакета.

Да понятно что шлёт не он а ядро сообщает о том что сторона не готова/не доступна. Вполне вероятно что да, сокет ещё не открыт а пакет уже прилетел ессно ядро отправило назад icmp пакет. Возможно стоит пересмотреть порядок обработки соединения, я уже думал над этим, но сейчас времени практически нет даже близко разбираться с этим делом.

На 2.6 не повторямо? Проблема только если accel-pptp работает клиентом.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

я его клиентом не тестил :-( и не анализировал...

зато сервером работает уже месяц с лишним - просто прекрасно :-)...

 

По теме - там косяки в основном завязаны не на сам драйвер а на поптоп - так что начинать надо с самого начала разбираться ....

Это на сутки возни минимум.

В любом случае - я бы рекомендовал попробовать на 2.6 ядре с последней версией акселя.

 

З.Ы. как говорится - курите сурсы...

Изменено пользователем sdy_moscow

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

я его клиентом не тестил :-( и не анализировал...

зато сервером работает уже месяц с лишним - просто прекрасно :-)...

Ну сервером оно и у меня работает кое-где с незапамятных времён.

 

По теме - там косяки в основном завязаны не на сам драйвер а на поптоп - так что начинать надо с самого начала разбираться ....

Это на сутки возни минимум.

Угу, плугин вообще страшный.

 

В любом случае - я бы рекомендовал попробовать на 2.6 ядре с последней версией акселя.

Когда риалтэк откроет сырцы wifi модуля тогда может хотябы переедем на последнее 2.4 ядро, а пока у нас 2.4.18 куда модуль пришлось портировать самостоятельно, спасибо ребятам из dxilab. У них ещё веселее 2.4.17 монтависта.

Но проблема есть и у них и у меня и на последнем 2.4 в режиме клиента, думаю и в 2.6 будет.

 

З.Ы. как говорится - курите сурсы...

Дык и курим, и чем больше курим тем больше желание снести нахрен этот плугин и начать кивирять с нуля свою реализацию ибо там сам чёрт ногу сломит. Отягощается тем что отлаживать вслепую на 200 мегагерцовом мипсе это ещё то занятие.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.