[a_andry]

отлаживать не на чем, как научить freeradius выдавать подобные сообщения ?

 

У меня rlm_perl.

Давайте, я открою свой радиус наружу, дам Вам несколько логинов/паролей для проверок. Будете получать что-то в этом роде --

 

[root@pppoe1 ~/radius]# ./test_auth.sh

Sending Access-Request of id 14 to 172.16.1.22 port 1812

...

rad_recv: Access-Reject packet from host 172.16.1.22 port 1812, id=14, length=120

MS-CHAP-Error = "E=1315 R=0 V=3"

Reply-Message = "invalid login: [sfdsdf] ip=[unknown] CLIENT_ENDPOINT=[00:90:05:87:02:03]"

 

После передачи MS-CHAP-Error винде (Reply-Message просто для удобства отладки радиуса) через бсдшный mpd, высвечивает стандартную виндовую ошибку 1315 ERROR_INVALID_ACCOUNT_NAME (The name provided is not a properly formed account name)

 

Пойдет?

Только с Вас нужен ip с которого стучаться на радиус будете, или в лс или на почту (отправил Вам свою в личку) ...

[adron2]

Здравствуйте уважаемые форумчане. Вот возникла проблема при сборке версии 1.3.5(commit 8e76381804b680bdb3a2026521df9382976914d1 - текущая на данный момент из git).

Система slackware 13.1

Ядро:2.6.35.7

 

При выполнении make все компилится без ошибок а вот модуль pptp.ko не появляется.

 

При выполнении команды make -C /usr/src/linux M=/usr/src/accel/accel-ppp/driver/driver modules

make: Entering directory `/usr/src/linux-2.6.35.7'

Building modules, stage 2.

MODPOST 0 modules

make: Leaving directory `/usr/src/linux-2.6.35.7'

То есть 0 модулей обработано.

И соответственно pptp.ko нигде нет.

 

Выяснил что если добавить в ./driver/Makefile строчку

obj-m:=pptp.o

То все начинает успешно собираться и файл pptp.ko появляется там где и должен быть.

 

Вот и вопрос. Это специфика сборки accel на slackware или какой то баг?

Изменено 19 июля, 2011 пользователем adron2

[Painter]

Здравствуйте, при подключении к серверу с mppe шифрованием возникает задержка на этапе "Проверка имени пользователя и пароля", где-то секунды 3-4, после этого Access-Request пакет приходит к радиус-серверу... Можно ли убрать эту задержку, чтобы радиус запрос отправлялся сразу?

Изменено 20 июля, 2011 пользователем Painter

[adron2]

Здравствуйте, при подключении к серверу с mppe шифрованием возникает задержка на этапе "Проверка имени пользователя и пароля", где-то секунды 3-4, после этого Access-Request пакет приходит к радиус-серверу... Можно ли убрать эту задержку, чтобы радиус запрос отправлялся сразу?

 

Подтверждаю.

Наблюдаю аналогичную проблему.

[cpulink]

Сейчас обновил весь софт, и ацел тоже. Падает ядро(при чем на старом ацеле тоже падает). При чем похоже падает....

Может кто видел или было подобное:

[ 6089.358502] BUG: unable to handle kernel NULL pointer dereference at           (null)
[ 6089.362482] IP: [<ffffffffa0264e24>] __nf_conntrack_confirm+0x2b4/0x480 [nf_conntrack]
[ 6089.362482] PGD 117822067 PUD 117823067 PMD 0
[ 6089.362482] Oops: 0002 [#1] SMP
[ 6089.362482] last sysfs file: /sys/devices/virtual/net/ppp6/uevent
[ 6089.362482] CPU 1
[ 6089.362482] Modules linked in: act_mirred act_skbedit cls_u32 sch_ingress arc4 ecb ppp_mppe l2tp_ppp l2tp_netlink l2tpd
[ 6089.362482]
[ 6089.362482] Pid: 0, comm: kworker/0:0 Not tainted 2.6.39-std-def-alt3 #1 ASUS RS100-E4/PI2/P5M2-M/RS100-E4
[ 6089.362482] RIP: 0010:[<ffffffffa0264e24>]  [<ffffffffa0264e24>] __nf_conntrack_confirm+0x2b4/0x480 [nf_conntrack]
[ 6089.362482] RSP: 0018:ffff88011fc83a80  EFLAGS: 00010202
[ 6089.362482] RAX: 00000000000047cd RBX: ffff88011fc94620 RCX: 0000000000000000
[ 6089.362482] RDX: 000000000000fa10 RSI: 00000000d00dd719 RDI: ffffffffa026f680
[ 6089.362482] RBP: ffff88011fc83ac0 R08: 00000000e753847a R09: ffff880117f00000
[ 6089.362482] R10: 0000000000004000 R11: 0000000000000001 R12: 0000000000000000
[ 6089.362482] R13: ffff880116a95080 R14: ffffffff81a4e1c0 R15: 00000000000114d8
[ 6089.362482] FS:  0000000000000000(0000) GS:ffff88011fc80000(0000) knlGS:0000000000000000
[ 6089.362482] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 6089.362482] CR2: 0000000000000000 CR3: 0000000117821000 CR4: 00000000000006e0
[ 6089.362482] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 6089.362482] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 6089.362482] Process kworker/0:0 (pid: 0, threadinfo ffff880118ef6000, task ffff880118ef42c0)
[ 6089.362482] Stack:
[ 6089.362482]  000000007d09da80 0000400016bd4400 0000000116ea2000 ffff880116a95080
[ 6089.362482]  0000000000000001 ffff88011fc94620 0000000000000002 ffff880116ea2000
[ 6089.362482]  ffff88011fc83b30 ffffffffa02b1dd8 ffff880116ea2000 0000000000000000
[ 6089.362482] Call Trace:
[ 6089.362482]  <IRQ>
[ 6089.362482]  [<ffffffffa02b1dd8>] ipv4_confirm+0x188/0x1c0 [nf_conntrack_ipv4]
[ 6089.362482]  [<ffffffff81382004>] nf_iterate+0x84/0xa0
[ 6089.362482]  [<ffffffff81389390>] ? ip_rcv_finish+0x390/0x390
[ 6089.362482]  [<ffffffff81382096>] nf_hook_slow+0x76/0x130
[ 6089.362482]  [<ffffffff81389390>] ? ip_rcv_finish+0x390/0x390
[ 6089.362482]  [<ffffffff813897d7>] ip_local_deliver+0x67/0x90
[ 6089.362482]  [<ffffffff81389135>] ip_rcv_finish+0x135/0x390
[ 6089.362482]  [<ffffffff81389a1c>] ip_rcv+0x21c/0x2e0
[ 6089.362482]  [<ffffffff81356f5a>] __netif_receive_skb+0x52a/0x690
[ 6089.362482]  [<ffffffff813572d0>] netif_receive_skb+0x60/0x90
[ 6089.362482]  [<ffffffff8124de9c>] ? is_swiotlb_buffer+0x3c/0x50
[ 6089.362482]  [<ffffffff81357440>] napi_skb_finish+0x50/0x70
[ 6089.362482]  [<ffffffff813579bd>] napi_gro_receive+0xbd/0xd0
[ 6089.362482]  [<ffffffffa012129b>] igb_poll+0x6fb/0xae0 [igb]
[ 6089.362482]  [<ffffffff8107fb61>] ? enqueue_hrtimer+0x31/0x80
[ 6090.302391]  [<ffffffff81357be5>] net_rx_action+0x135/0x270
[ 6090.302391]  [<ffffffff81062705>] __do_softirq+0xa5/0x1d0
[ 6090.302391]  [<ffffffff8141301c>] call_softirq+0x1c/0x30
[ 6090.302391]  [<ffffffff8100d355>] do_softirq+0x65/0xa0
[ 6090.302391]  [<ffffffff81062a96>] irq_exit+0x86/0xa0
[ 6090.302391]  [<ffffffff8100cf01>] do_IRQ+0x61/0xe0
[ 6090.302391]  [<ffffffff8140a593>] common_interrupt+0x13/0x13
[ 6090.302391]  <EOI>
[ 6090.302391]  [<ffffffff81012deb>] ? mwait_idle+0x9b/0x1d0
[ 6090.302391]  [<ffffffff8140de35>] ? atomic_notifier_call_chain+0x15/0x20
[ 6090.302391]  [<ffffffff8100a1e6>] cpu_idle+0x56/0xa0
[ 6090.302391]  [<ffffffff81403729>] start_secondary+0x197/0x19c
[ 6090.302391] Code: ff 74 09 40 0f b6 ff 41 0f b7 0c 38 66 41 39 cc 0f 84 f1 fe ff ff 48 8b 00 a8 01 0f 84 51 ff ff ff 4
[ 6090.302391]  89 01 75 04 48 89 48 08 48 8b 05 4c 4a 60 e1 48 01 83 98 00
[ 6090.302391] RIP  [<ffffffffa0264e24>] __nf_conntrack_confirm+0x2b4/0x480 [nf_conntrack]
[ 6090.302391]  RSP <ffff88011fc83a80>
[ 6090.302391] CR2: 0000000000000000
[ 6090.611999] ---[ end trace ded67c8afb62f164 ]---
[ 6090.625910] Kernel panic - not syncing: Fatal exception in interrupt
[ 6090.645022] Pid: 0, comm: kworker/0:0 Tainted: G      D     2.6.39-std-def-alt3 #1
[ 6090.667822] Call Trace:
[ 6090.675232]  <IRQ>  [<ffffffff81407284>] panic+0x8c/0x197
[ 6090.691563]  [<ffffffff8140b4d2>] oops_end+0xe2/0xf0
[ 6090.706514]  [<ffffffff81039ad0>] no_context+0xf0/0x260
[ 6090.722242]  [<ffffffff81382096>] ? nf_hook_slow+0x76/0x130
[ 6090.739013]  [<ffffffff8138e0f0>] ? ip_fragment+0x960/0x960
[ 6090.755784]  [<ffffffff81039d65>] __bad_area_nosemaphore+0x125/0x1e0
[ 6090.774894]  [<ffffffff81039e2e>] bad_area_nosemaphore+0xe/0x10
[ 6090.792703]  [<ffffffff8140dbf6>] do_page_fault+0x306/0x4b0
[ 6090.809473]  [<ffffffff8106b48e>] ? mod_timer+0x15e/0x2c0
[ 6090.825725]  [<ffffffff81345b47>] ? sk_reset_timer+0x17/0x30
[ 6090.842754]  [<ffffffff81393eeb>] ? inet_csk_reset_keepalive_timer+0x1b/0x20
[ 6090.863945]  [<ffffffff81393fe7>] ? inet_csk_reqsk_queue_hash_add+0xf7/0x110
[ 6090.885135]  [<ffffffff8140a855>] page_fault+0x25/0x30
[ 6090.900608]  [<ffffffffa0264e24>] ? __nf_conntrack_confirm+0x2b4/0x480 [nf_conntrack]
[ 6090.924189]  [<ffffffffa02b1dd8>] ipv4_confirm+0x188/0x1c0 [nf_conntrack_ipv4]
[ 6090.945950]  [<ffffffff81382004>] nf_iterate+0x84/0xa0
[ 6090.961420]  [<ffffffff81389390>] ? ip_rcv_finish+0x390/0x390
[ 6090.978710]  [<ffffffff81382096>] nf_hook_slow+0x76/0x130
[ 6090.994959]  [<ffffffff81389390>] ? ip_rcv_finish+0x390/0x390
[ 6091.012250]  [<ffffffff813897d7>] ip_local_deliver+0x67/0x90
[ 6091.029281]  [<ffffffff81389135>] ip_rcv_finish+0x135/0x390
[ 6091.046052]  [<ffffffff81389a1c>] ip_rcv+0x21c/0x2e0
[ 6091.061000]  [<ffffffff81356f5a>] __netif_receive_skb+0x52a/0x690
[ 6091.079332]  [<ffffffff813572d0>] netif_receive_skb+0x60/0x90
[ 6091.096622]  [<ffffffff8124de9c>] ? is_swiotlb_buffer+0x3c/0x50
[ 6091.114431]  [<ffffffff81357440>] napi_skb_finish+0x50/0x70
[ 6091.131201]  [<ffffffff813579bd>] napi_gro_receive+0xbd/0xd0
[ 6091.148234]  [<ffffffffa012129b>] igb_poll+0x6fb/0xae0 [igb]
[ 6091.165262]  [<ffffffff8107fb61>] ? enqueue_hrtimer+0x31/0x80
[ 6091.182553]  [<ffffffff81357be5>] net_rx_action+0x135/0x270
[ 6091.199323]  [<ffffffff81062705>] __do_softirq+0xa5/0x1d0
[ 6091.215573]  [<ffffffff8141301c>] call_softirq+0x1c/0x30
[ 6091.231562]  [<ffffffff8100d355>] do_softirq+0x65/0xa0
[ 6091.247035]  [<ffffffff81062a96>] irq_exit+0x86/0xa0
[ 6091.261983]  [<ffffffff8100cf01>] do_IRQ+0x61/0xe0
[ 6091.276413]  [<ffffffff8140a593>] common_interrupt+0x13/0x13
[ 6091.293442]  <EOI>  [<ffffffff81012deb>] ? mwait_idle+0x9b/0x1d0
[ 6091.311593]  [<ffffffff8140de35>] ? atomic_notifier_call_chain+0x15/0x20
[ 6091.331742]  [<ffffffff8100a1e6>] cpu_idle+0x56/0xa0
[ 6091.346692]  [<ffffffff81403729>] start_secondary+0x197/0x19c
[ 6091.363986] Rebooting in 30 seconds.

[NiTr0]

cpulink

Поставьте 2.6.35 ядро. 2.6.38, 2.6.39 - кое-кто жаловался на нестабильность. И отключите GRO и прочие излишние оффлоады, оставьте tx/rx checksums и sg.

Изменено 21 июля, 2011 пользователем NiTr0

[xeb]

Здравствуйте, при подключении к серверу с mppe шифрованием возникает задержка на этапе "Проверка имени пользователя и пароля", где-то секунды 3-4, после этого Access-Request пакет приходит к радиус-серверу... Можно ли убрать эту задержку, чтобы радиус запрос отправлялся сразу?

 

Подтверждаю.

Наблюдаю аналогичную проблему.

нужны логи уровня 4 или 5 ...

[Painter]

Здравствуйте, при подключении к серверу с mppe шифрованием возникает задержка на этапе "Проверка имени пользователя и пароля", где-то секунды 3-4, после этого Access-Request пакет приходит к радиус-серверу... Можно ли убрать эту задержку, чтобы радиус запрос отправлялся сразу?

 

Подтверждаю.

Наблюдаю аналогичную проблему.

нужны логи уровня 4 или 5 ...

 

Jul 22 10:21:58 agat pptpd[23506]: MGR: Launching /usr/local/sbin/pptpctrl to handle client
Jul 22 10:21:58 agat pptpd[23506]: CTRL: local address = 172.27.67.224
Jul 22 10:21:58 agat pptpd[23506]: CTRL: remote address = 172.27.67.229
Jul 22 10:21:58 agat pptpd[23506]: CTRL: pppd options file = /etc/ppp/options.pptpd
Jul 22 10:21:58 agat pptpd[23506]: CTRL: Client 87.244.0.100 control connection started
Jul 22 10:21:58 agat pptpd[23506]: CTRL: Received PPTP Control Message (type: 1)
Jul 22 10:21:58 agat pptpd[23506]: CTRL: Made a START CTRL CONN RPLY packet
Jul 22 10:21:58 agat pptpd[23506]: CTRL: I wrote 156 bytes to the client.
Jul 22 10:21:58 agat pptpd[23506]: CTRL: Sent packet to client
Jul 22 10:21:58 agat pptpd[23506]: CTRL: Received PPTP Control Message (type: 7)
Jul 22 10:21:58 agat pptpd[23506]: CTRL: Set parameters to 100000000 maxbps, 64 window size
Jul 22 10:21:58 agat pptpd[23506]: CTRL: Made a OUT CALL RPLY packet
Jul 22 10:21:58 agat pptpd[23506]: CTRL: Starting call (launching pppd, opening GRE)
Jul 22 10:21:58 agat pptpd[23506]: CTRL: I wrote 32 bytes to the client.
Jul 22 10:21:58 agat pptpd[23506]: CTRL: Sent packet to client
Jul 22 10:21:58 agat pptpd[23507]: CTRL (PPPD Launcher): program binary = /usr/sbin/pppd
Jul 22 10:21:58 agat pptpd[23507]: CTRL (PPPD Launcher): local address = 172.27.67.224
Jul 22 10:21:58 agat pptpd[23507]: CTRL (PPPD Launcher): remote address = 172.27.67.229
Jul 22 10:21:58 agat pppd[23507]: Plugin radius.so loaded.
Jul 22 10:21:58 agat pppd[23507]: RADIUS plugin initialized.
Jul 22 10:21:58 agat pppd[23507]: Plugin radattr.so loaded.
Jul 22 10:21:58 agat pppd[23507]: RADATTR plugin initialized.
Jul 22 10:21:58 agat pptp[23507]: Plugin pptp.so loaded.
Jul 22 10:21:58 agat pptp[23507]: PPTP plugin version 0.8.5 compiled for pppd-2.4.5, linux-2.6.
Jul 22 10:21:58 agat pptp[23507]: pppd 2.4.5 started by root, uid 0
Jul 22 10:21:58 agat pptp[23507]: using channel 40
Jul 22 10:21:58 agat pptp[23507]: Using interface ppp0
Jul 22 10:21:58 agat pptp[23507]: Connect: ppp0 <--> pptp (87.244.0.100)
Jul 22 10:21:58 agat pptp[23507]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0xfd6e980f> <pcomp> <accomp>]
Jul 22 10:21:58 agat pptpd[23506]: CTRL: Received PPTP Control Message (type: 15)
Jul 22 10:21:58 agat pptpd[23506]: CTRL: Got a SET LINK INFO packet with standard ACCMs
Jul 22 10:22:00 agat pptp[23507]: rcvd [LCP ConfReq id=0x1 <mru 1400> <magic 0x1b47605f> <pcomp> <accomp> <callback CBCP>]
Jul 22 10:22:00 agat pptp[23507]: sent [LCP ConfRej id=0x1 <callback CBCP>]
Jul 22 10:22:00 agat pptp[23507]: rcvd [LCP ConfReq id=0x2 <mru 1400> <magic 0x1b47605f> <pcomp> <accomp>]
Jul 22 10:22:00 agat pptp[23507]: sent [LCP ConfAck id=0x2 <mru 1400> <magic 0x1b47605f> <pcomp> <accomp>]
Jul 22 10:22:01 agat pptp[23507]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0xfd6e980f> <pcomp> <accomp>]
Jul 22 10:22:01 agat pptp[23507]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0xfd6e980f> <pcomp> <accomp>]
Jul 22 10:22:01 agat pptp[23507]: sent [LCP EchoReq id=0x0 magic=0xfd6e980f]
Jul 22 10:22:01 agat pptpd[23506]: CTRL: Received PPTP Control Message (type: 15)
Jul 22 10:22:01 agat pptpd[23506]: CTRL: Ignored a SET LINK INFO packet with real ACCMs!
Jul 22 10:22:01 agat pptp[23507]: sent [CHAP Challenge id=0xbd <33a2154f49ab33bf6f0c2895d395683a>, name = "sun-pptpd"]
Jul 22 10:22:01 agat pptp[23507]: rcvd [LCP Ident id=0x3 magic=0x1b47605f "MSRASV5.10"]
Jul 22 10:22:01 agat pptp[23507]: rcvd [LCP Ident id=0x4 magic=0x1b47605f "MSRAS-0-WIN-XP-VM"]
Jul 22 10:22:01 agat pptp[23507]: rcvd [LCP EchoRep id=0x0 magic=0x1b47605f]
Jul 22 10:22:01 agat pptp[23507]: rcvd [CHAP Response id=0xbd <111b3ae4cb284f5ef857c318f1ad3fe30000000000000000d9302b0c1710e432d2eb94a23ff50677a1a5acef7aab9b1a00>, name = "bna"]
...

 

Как назло сейчас задержка стала 2 секунды)

[_random]

Добрый день. Столкнулся с проблемой, в диспетчере задач скорость ВПН соединения 12мбит, следовательно по интерфейсу выше трафик не бегает.

Убираю шейп на сервере, в пике получаю до 70мбит, но такая скорость держится около 15сек и валится до 12мбит. Как порешать эту проблему?

[xeb]

Painter, во-первых, у тебя accel-pptp-0.8.5, так что по поводу задержек и пр. обращайтесь к разработчикам poptop/pppd/radiusclient, во-вторых, тут и так видно откуда задержка:

Jul 22 10:21:58 agat pptp[23507]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0xfd6e980f> <pcomp> <accomp>]
Jul 22 10:22:00 agat pptp[23507]: rcvd [LCP ConfReq id=0x1 <mru 1400> <magic 0x1b47605f> <pcomp> <accomp> <callback CBCP>]

клиент долго отвечает

[XLighter]

cpulink

Поставьте 2.6.35 ядро. 2.6.38, 2.6.39 - кое-кто жаловался на нестабильность. И отключите GRO и прочие излишние оффлоады, оставьте tx/rx checksums и sg.

Или 2.6.36. Подтверждаю проблему на всех ядрах с 2.6.37 по 2.6.39.х. При поднятии соединения в большинстве случаев ядро падает в панику. Воспроизводимость почти стопроцентная. Так что могу подебажить, если дать инструкцию.

Речь про старый accel конечно.

[xeb]

там в ядрах 37-39 ошибка сидит, отправил патч на lkml...

[cpulink]

там в ядрах 37-39 ошибка сидит, отправил патч на lkml..

Попробую его, они там что-то на патч ругнулись...

[XLighter]

там в ядрах 37-39 ошибка сидит, отправил патч на lkml...

Можно ссылку? Не могу там найти.

[alexaaa]

мой совет используем accel-pptp 1.3.5 почти год, падений нет, шифрование вообще не используем, с ним идут падения, стоит на Slackware 13.1, и iptables netflow, настроен contrack, pppoe не тестировали

[xeb]

Можно ссылку? Не могу там найти.

http://www.spinics.net/lists/netdev/msg170687.html

[XLighter]

Можно ссылку? Не могу там найти.

http://www.spinics.net/lists/netdev/msg170687.html

С патчем проблема не проявляется. Спасибо! Буду надеяться, что он будет в следующем релизе ядра.

[NiTr0]

они там что-то на патч ругнулись...

Ругнулись т.к. патч испохабился почтовым клиентом (табы заменились на пробелы).

[cpulink]

там в ядрах 37-39 ошибка сидит, отправил патч на lkml...

Патч помог, на сервере стало возможным работать, спасибо!

[cpulink]

Сервак заработал, появилась пара вопросов.

Для начала конфиг:

[modules]
log_file
pptp
l2tp
auth_mschap_v2
radius
sigchld
pppd_compat

[core]
log-error=/var/log/accel-ppp/core.log
thread-count=4

[ppp]
verbose=4
min-mtu=1000
mtu=1460
mru=1460
single-session=replace

[lcp]
echo-interval=30
echo-failure=10

[pptp]
verbose=1

[l2tp]
verbose=1

[dns]
dns1=10.0.0.2
dns2=10.0.0.3

[radius]
nas-identifier=nas3
nas-ip-address=172.16.101.3
gw-ip-address=10.128.0.130
auth-server=172.16.100.100:1812,pass
acct-server=172.16.100.100:1813,pass
acct-timeout=0
verbose=4

[log]
log-file=/var/log/accel-ppp/accel-ppp.log
log-emerg=/var/log/accel-ppp/emerg.log
log-fail-file=/var/log/accel-ppp/auth-fail.log
copy=1
level=4


[pppd-compat]
ip-pre-up=/etc/ppp/ip-pre-up
ip-up=/etc/ppp/ip-up
ip-down=/etc/ppp/ip-down
radattr-prefix=/var/run/radattr
verbose=1

[cli]
telnet=127.0.0.1:2000
tcp=127.0.0.1:2001

[client-ip-range]
10.0.0.0/16

 

1 вопрос - при acct-timeout=0 думал не будет равать по не ответу радиус сервера,

но по логу выходит иначе, если радиус сразу не ответил - отрубит тут же. Можно как-либо изменить это поведение?

например если радиус не ответил для этого абонента - забить на радиус и не посылать аккаунтинг, или посылать но не смотреть итог?

[2011-07-25 00:16:57]:   msg: accel-ppp version 8e76381804b680bdb3a2026521df9382976914d1
[2011-07-25 00:25:57]:  info: pptp: new connection from 10.0.7.201
[2011-07-25 00:25:57]:  info: : recv [PPTP Start-Ctrl-Conn-Request <Version 1> <Framing 1> <Bearer 1> <Max-Chan 0>]
[2011-07-25 00:25:57]:  info: : send [PPTP Start-Ctrl-Conn-Reply <Version 1> <Result 1> <Error 0> <Framing 3> <Bearer 3> <Max-Chan 1>]
[2011-07-25 00:25:57]:  info: : recv [PPTP Outgoing-Call-Request <Call-ID 4000> <Call-Serial 48f9> <Min-BPS 300> <Max-BPS 100000000> <Bearer 3> <Framing 3> <Window-Size 64> <Delay 0>]
[2011-07-25 00:25:57]:  info: : send [PPTP Outgoing-Call-Reply <Call-ID 875> <Peer-Call-ID 4000> <Result 1> <Error 0> <Cause 0> <Speed 100000000> <Window-Size 64> <Delay 0> <Channel 0>]
[2011-07-25 00:25:57]:  info: ppp0: connect: ppp0 <--> pptp(10.0.7.201)
[2011-07-25 00:25:57]:  info: ppp0: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1436> <magic 333ab105>]
[2011-07-25 00:25:57]:  info: ppp0: recv [PPTP Set-Link-Info]
[2011-07-25 00:25:59]:  info: ppp0: recv [LCP ConfReq id=1 <mru 1400> <magic 24bc6955> <pcomp> <accomp> < d 3 6 >]
[2011-07-25 00:25:59]:  info: ppp0: send [LCP ConfRej id=1  <pcomp> <accomp> < d 3 6 >]
[2011-07-25 00:25:59]:  info: ppp0: recv [LCP ConfReq id=2 <mru 1400> <magic 24bc6955>]
[2011-07-25 00:25:59]:  info: ppp0: send [LCP ConfAck id=2 ]
[2011-07-25 00:25:59]:  info: ppp0: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1436> <magic 333ab105>]
[2011-07-25 00:25:59]:  info: ppp0: recv [LCP ConfAck id=1 <auth MSCHAP-v2> <mru 1436> <magic 333ab105>]
[2011-07-25 00:25:59]:  info: ppp0: send [MSCHAP-v2 Challenge id=1 <76bbb47811d6406e0dc71a340f81>]
[2011-07-25 00:25:59]:  info: ppp0: recv [PPTP Set-Link-Info]
[2011-07-25 00:25:59]:  info: ppp0: recv [LCP Ident id=3 <MSRASV5.10>]
[2011-07-25 00:25:59]:  info: ppp0: recv [LCP Ident id=4 <MSRAS-0-HOM1>]
[2011-07-25 00:25:59]:  info: ppp0: recv [MSCHAP-v2 Response id=1 <c20416d630a0da209642c149b3e9>, <e856883357e33f29193e2c5595c53dbc37b4734f1264d1f>, F=0, name="dd"]
[2011-07-25 00:25:59]:  info: ppp0: send [RADIUS Access-Request id=1 <User-Name "dd"> <NAS-Identifier "nas3"> <NAS-IP-Address 172.16.101.3> <NAS-Port 0> <NAS-Port-Type Virtual> <Service-Type Framed-User> <Framed-Protocol PPP> <Calling-Station-Id "10.0.7.201"> <Called-Station-Id "10.0.0.130"><Microsoft MS-CHAP-Challenge ><Microsoft MS-CHAP2-Response >]
[2011-07-25 00:25:59]:  info: ppp0: recv [RADIUS Access-Accept id=1 <Acct-Interim-Interval 300> <Configuration-Token "-14398"> <Framed-IP-Address 192.168.1.2> <Class "TYPE=unlim,UP=35000,DOWN=17500"> <Filter-Id "0"><Microsoft MS-CHAP2-Success ><Microsoft MS-MPPE-Recv-Key ><Microsoft MS-MPPE-Send-Key ><Microsoft MS-MPPE-Encryption-Policy 2><Microsoft MS-MPPE-Encryption-Type 4>]
[2011-07-25 00:25:59]:  info: ppp0: send [MSCHAP-v2 Success id=1 "S=7615AAFC774FD71C6C2A0E96E33E77A9FBF17100 M=Authentication successed"]
[2011-07-25 00:25:59]:  info: ppp0: send [iPCP ConfReq id=1 <addr 10.128.0.130>]
[2011-07-25 00:25:59]:  info: ppp0: send [CCP ConfReq id=1 <mppe +H -M +S -L -D -C>]
[2011-07-25 00:25:59]:  info: ppp0: dd: authentication successed
[2011-07-25 00:25:59]:  info: ppp0: recv [CCP ConfReq id=5 <mppe +H -M -S -L -D +C>]
[2011-07-25 00:25:59]:  info: ppp0: send [CCP ConfNak id=5 <mppe +H -M +S -L -D -C>]
[2011-07-25 00:25:59]:  info: ppp0: recv [iPCP ConfReq id=6 <addr 0.0.0.0> <dns1 0.0.0.0> < 82 6 0 0 0 0 > <dns2 0.0.0.0> < 84 6 0 0 0 0 >]
[2011-07-25 00:25:59]:  info: ppp0: send [iPCP ConfRej id=6 < 82 6 0 0 0 0 > < 84 6 0 0 0 0 >]
[2011-07-25 00:25:59]:  info: ppp0: recv [iPCP ConfAck id=1 <addr 10.128.0.130>]
[2011-07-25 00:25:59]:  info: ppp0: recv [CCP ConfAck id=1 <mppe +H -M +S -L -D -C>]
[2011-07-25 00:25:59]:  info: ppp0: recv [CCP ConfReq id=7 <mppe +H -M +S -L -D -C>]
[2011-07-25 00:25:59]:  info: ppp0: send [CCP ConfAck id=7]
[2011-07-25 00:25:59]:  info: ppp0: recv [iPCP ConfReq id=8 <addr 0.0.0.0> <dns1 0.0.0.0> <dns2 0.0.0.0>]
[2011-07-25 00:25:59]:  info: ppp0: send [iPCP ConfNak id=8 <addr 10.128.0.130> <dns1 10.0.0.2> <dns2 10.0.0.3>]
[2011-07-25 00:25:59]:  info: ppp0: recv [iPCP ConfReq id=9 <addr 192.168.1.2> <dns1 10.0.0.2> <dns2 10.0.0.3>]
[2011-07-25 00:25:59]:  info: ppp0: send [iPCP ConfAck id=9]
[2011-07-25 00:25:59]:  info: ppp0: send [RADIUS Accounting-Request id=1 <User-Name "dd"> <NAS-Identifier "nas3"> <NAS-IP-Address 172.16.101.3> <NAS-Port 0> <NAS-Port-Type Virtual> <Service-Type Framed-User> <Framed-Protocol PPP> <Calling-Station-Id "10.0.7.201"> <Called-Station-Id "10.0.0.130"> <Class "TYPE=unlim,UP=35000,DOWN=17500���!e"> <Acct-Status-Type Start> <Acct-Authentic RADIUS> <Acct-Session-Id "0040de0f53556379"> <Acct-Session-Time 0> <Acct-Input-Octets 0> <Acct-Output-Octets 0> <Acct-Input-Packets 0> <Acct-Output-Packets 0> <Acct-Input-Gigawords 0> <Acct-Output-Gigawords 0> <Acct-Delay-Time 0> <Framed-IP-Address 192.168.1.2>]
[2011-07-25 00:26:02]:  info: ppp0: send [RADIUS Accounting-Request id=1 <User-Name "dd"> <NAS-Identifier "nas3"> <NAS-IP-Address 172.16.101.3> <NAS-Port 0> <NAS-Port-Type Virtual> <Service-Type Framed-User> <Framed-Protocol PPP> <Calling-Station-Id "10.0.7.201"> <Called-Station-Id "10.0.0.130"> <Class "TYPE=unlim,UP=35000,DOWN=17500���!e"> <Acct-Status-Type Start> <Acct-Authentic RADIUS> <Acct-Session-Id "0040de0f53556379"> <Acct-Session-Time 0> <Acct-Input-Octets 0> <Acct-Output-Octets 0> <Acct-Input-Packets 0> <Acct-Output-Packets 0> <Acct-Input-Gigawords 0> <Acct-Output-Gigawords 0> <Acct-Delay-Time 0> <Framed-IP-Address 192.168.1.2>]
[2011-07-25 00:26:05]:  info: ppp0: send [RADIUS Accounting-Request id=1 <User-Name "dd"> <NAS-Identifier "nas3"> <NAS-IP-Address 172.16.101.3> <NAS-Port 0> <NAS-Port-Type Virtual> <Service-Type Framed-User> <Framed-Protocol PPP> <Calling-Station-Id "10.0.7.201"> <Called-Station-Id "10.0.0.130"> <Class "TYPE=unlim,UP=35000,DOWN=17500���!e"> <Acct-Status-Type Start> <Acct-Authentic RADIUS> <Acct-Session-Id "0040de0f53556379"> <Acct-Session-Time 0> <Acct-Input-Octets 0> <Acct-Output-Octets 0> <Acct-Input-Packets 0> <Acct-Output-Packets 0> <Acct-Input-Gigawords 0> <Acct-Output-Gigawords 0> <Acct-Delay-Time 0> <Framed-IP-Address 192.168.1.2>]
[2011-07-25 00:26:08]:  warn: ppp0: radius:acct_start: no response
[2011-07-25 00:26:08]:  info: ppp0: send [LCP TermReq id=3]
[2011-07-25 00:26:08]:  info: ppp0: pppd_compat: ip-up started (pid 24097)
[2011-07-25 00:26:08]:  info: ppp0: recv [PPTP Set-Link-Info]
[2011-07-25 00:26:08]:  info: ppp0: recv [LCP TermAck id=3]
[2011-07-25 00:26:08]:  warn: ppp0: pppd_compat: ip-up is not yet finished, terminating it ...
[2011-07-25 00:26:08]:  info: ppp0: pppd_compat: ip-down started (pid 24098)
[2011-07-25 00:26:08]:  info: ppp0: pppd_compat: ip-up finished (0)
[2011-07-25 00:26:08]:  info: ppp0: pppd_compat: ip-down finished (1)
[2011-07-25 00:26:08]:  info: ppp0: send [PPTP Call-Disconnect-Notify <Call-ID 40> <Result 3> <Error 0> <Cause 0>]
[2011-07-25 00:26:08]:  info: ppp0: send [PPTP Stop-Ctrl-Conn-Request <Reason 0>]
[2011-07-25 00:26:08]:  info: ppp0: recv [PPTP Stop-Ctrl-Conn-Reply <Result 1> <Error 0>]
[2011-07-25 00:26:08]:  info: ppp0: disconnected

2 вопрос - по шифрованию, конфиг см.выше. При этом клиент WinXP SP3 - в настройках vpn (l2tp,pptp - пофигу) указываю "шифрование запрещено, иначе отключиться" - получаю ошибку 734 и обрыв. Если ставлю - "подключится даже без шифрования" - получается шифрование всегда включается.... Чем можно исправить такое поведение? Проблема еще в том, что у части юзверей шифрование включено по умолчанию, а у части настроено именно так "шифрование запрещено, иначе отключиться"...

вот лог:

[2011-07-25 00:29:58]:   msg: accel-ppp version 8e76381804b680bdb3a2026521df9382976914d1
[2011-07-25 00:30:36]:  info: pptp: new connection from 10.0.7.201
[2011-07-25 00:30:36]:  info: : recv [PPTP Start-Ctrl-Conn-Request <Version 1> <Framing 1> <Bearer 1> <Max-Chan 0>]
[2011-07-25 00:30:36]:  info: : send [PPTP Start-Ctrl-Conn-Reply <Version 1> <Result 1> <Error 0> <Framing 3> <Bearer 3> <Max-Chan 1>]
[2011-07-25 00:30:36]:  info: : recv [PPTP Outgoing-Call-Request <Call-ID 8000> <Call-Serial 48fa> <Min-BPS 300> <Max-BPS 100000000> <Bearer 3> <Framing 3> <Window-Size 64> <Delay 0>]
[2011-07-25 00:30:36]:  info: : send [PPTP Outgoing-Call-Reply <Call-ID 876> <Peer-Call-ID 8000> <Result 1> <Error 0> <Cause 0> <Speed 100000000> <Window-Size 64> <Delay 0> <Channel 0>]
[2011-07-25 00:30:36]:  info: ppp0: connect: ppp0 <--> pptp(10.0.7.201)
[2011-07-25 00:30:36]:  info: ppp0: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1436> <magic 436c6125>]
[2011-07-25 00:30:36]:  info: ppp0: recv [PPTP Set-Link-Info]
[2011-07-25 00:30:38]:  info: ppp0: recv [LCP ConfReq id=1 <mru 1400> <magic ae737be> <pcomp> <accomp> < d 3 6 >]
[2011-07-25 00:30:38]:  info: ppp0: send [LCP ConfRej id=1  <pcomp> <accomp> < d 3 6 >]
[2011-07-25 00:30:38]:  info: ppp0: recv [LCP ConfReq id=2 <mru 1400> <magic ae737be>]
[2011-07-25 00:30:38]:  info: ppp0: send [LCP ConfAck id=2 ]
[2011-07-25 00:30:38]:  info: ppp0: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1436> <magic 436c6125>]
[2011-07-25 00:30:38]:  info: ppp0: recv [LCP ConfAck id=1 <auth MSCHAP-v2> <mru 1436> <magic 436c6125>]
[2011-07-25 00:30:38]:  info: ppp0: send [MSCHAP-v2 Challenge id=1 <e0616d2163f123972592eda27c5dc0e>]
[2011-07-25 00:30:38]:  info: ppp0: recv [PPTP Set-Link-Info]
[2011-07-25 00:30:38]:  info: ppp0: recv [LCP Ident id=3 <MSRASV5.10>]
[2011-07-25 00:30:38]:  info: ppp0: recv [LCP Ident id=4 <MSRAS-0-HOM1>]
[2011-07-25 00:30:38]:  info: ppp0: recv [MSCHAP-v2 Response id=1 <d6815b61b22fb072ca97c6a27336f7b8>, <fd3913d354b7656443b55955c88018399f5754de107554c6>, F=0, name="dd"]
[2011-07-25 00:30:38]:  info: ppp0: send [RADIUS Access-Request id=1 <User-Name "dd"> <NAS-Identifier "nas3"> <NAS-IP-Address 172.16.101.3> <NAS-Port 0> <NAS-Port-Type Virtual> <Service-Type Framed-User> <Framed-Protocol PPP> <Calling-Station-Id "10.0.7.201"> <Called-Station-Id "10.0.0.130"><Microsoft MS-CHAP-Challenge ><Microsoft MS-CHAP2-Response >]
[2011-07-25 00:30:38]:  info: ppp0: recv [RADIUS Access-Accept id=1 <Acct-Interim-Interval 300> <Configuration-Token "-14398"> <Framed-IP-Address 192.168.1.2> <Class "TYPE=unlim,UP=35000,DOWN=17500"> <Filter-Id "0"><Microsoft MS-CHAP2-Success ><Microsoft MS-MPPE-Recv-Key ><Microsoft MS-MPPE-Send-Key ><Microsoft MS-MPPE-Encryption-Policy 2><Microsoft MS-MPPE-Encryption-Type 4>]
[2011-07-25 00:30:38]:  info: ppp0: send [MSCHAP-v2 Success id=1 "S=4C6F450C6FED075AFC415648DDC8B6390A1A3223 M=Authentication successed"]
[2011-07-25 00:30:38]:  info: ppp0: send [iPCP ConfReq id=1 <addr 10.128.0.130>]
[2011-07-25 00:30:38]:  info: ppp0: send [CCP ConfReq id=1 <mppe +H -M +S -L -D -C>]
[2011-07-25 00:30:38]:  info: ppp0: dd: authentication successed
[2011-07-25 00:30:38]:  info: ppp0: recv [CCP ConfReq id=5 <mppe +H -M -S -L -D +C>]
[2011-07-25 00:30:38]:  info: ppp0: send [CCP ConfNak id=5 <mppe +H -M +S -L -D -C>]
[2011-07-25 00:30:38]:  info: ppp0: recv [iPCP ConfReq id=6 <addr 0.0.0.0> <dns1 0.0.0.0> < 82 6 0 0 0 0 > <dns2 0.0.0.0> < 84 6 0 0 0 0 >]
[2011-07-25 00:30:38]:  info: ppp0: send [iPCP ConfRej id=6 < 82 6 0 0 0 0 > < 84 6 0 0 0 0 >]
[2011-07-25 00:30:38]:  info: ppp0: recv [iPCP ConfAck id=1 <addr 10.128.0.130>]
[2011-07-25 00:30:38]:  info: ppp0: recv [CCP ConfRej id=1]
[2011-07-25 00:30:38]:  info: ppp0: send [LCP TermReq id=3]
[2011-07-25 00:30:38]:  warn: ppp0: CCP: discarding packet
[2011-07-25 00:30:38]:  info: ppp0: send [LCP ProtoRej id=4 <80fd>]
[2011-07-25 00:30:38]:  warn: ppp0: IPCP: discarding packet
[2011-07-25 00:30:38]:  info: ppp0: recv [PPTP Set-Link-Info]
[2011-07-25 00:30:38]:  info: ppp0: recv [LCP TermAck id=3]
[2011-07-25 00:30:38]:  info: ppp0: send [PPTP Call-Disconnect-Notify <Call-ID 80> <Result 3> <Error 0> <Cause 0>]
[2011-07-25 00:30:38]:  info: ppp0: send [PPTP Stop-Ctrl-Conn-Request <Reason 0>]
[2011-07-25 00:30:38]:  info: ppp0: recv [PPTP Call-Clear-Request <Call-ID 8000>]
[2011-07-25 00:30:38]:  info: ppp0: send [PPTP Call-Disconnect-Notify <Call-ID 80> <Result 4> <Error 0> <Cause 0>]
[2011-07-25 00:30:38]:  info: ppp0: recv [PPTP Stop-Ctrl-Conn-Reply <Result 1> <Error 0>]
[2011-07-25 00:30:38]:  info: ppp0: disconnected

[xeb]

1 вопрос - при acct-timeout=0 думал не будет равать по не ответу радиус сервера,

эта опция влияет только на Interim-Update, если не нужен аккаунтинг, то лучше его вообще убрать из конфига

 

2 вопрос - по шифрованию, конфиг см.выше. При этом клиент WinXP SP3 - в настройках vpn (l2tp,pptp - пофигу) указываю "шифрование запрещено, иначе отключиться" - получаю ошибку 734 и обрыв. Если ставлю - "подключится даже без шифрования" - получается шифрование всегда включается.... Чем можно исправить такое поведение? Проблема еще в том, что у части юзверей шифрование включено по умолчанию, а у части настроено именно так "шифрование запрещено, иначе отключиться"...вот лог:

в атрибутах приходит <Microsoft MS-MPPE-Encryption-Policy 2>, что значит шифрование обязательное

 

 

 

[cpulink]

в атрибутах приходит <Microsoft MS-MPPE-Encryption-Policy 2>, что значит шифрование обязательное

А что должно приходить чтобы было необязательное? Просто билинг закрытый, фиг что поправишь...

А на старом ацеле + pppd такого не наблюдается...

[xeb]

надо чтобы 1 приходило, наверняка в биллинге где-то должна быть настройка

[cpulink]

надо чтобы 1 приходило, наверняка в биллинге где-то должна быть настройка

С этим разобрались, спасибо за подсказки.

Дали нагрузку на сервак получился трап, пока не понял еще подробностей, но 2 раза повторился точно:

[ 6634.059149] kernel BUG at include/linux/skbuff.h:1189!
[ 6634.059149] invalid opcode: 0000 [#1] SMP
[ 6634.059149] last sysfs file: /sys/devices/virtual/net/ppp294/uevent
[ 6634.059149] CPU 3
[ 6634.059149] Modules linked in: cls_fw sch_sfq arc4 ecb ppp_mppe act_mirred act_skbedit cls_u32 sch_ingress l2tp_ppp l2d
[ 6634.203308]
[ 6634.203308] Pid: 0, comm: kworker/0:1 Not tainted 2.6.39-std-def-alt3 #1 ASUS RS100-E4/PI2/P5M2-M/RS100-E4
[ 6634.203308] RIP: 0010:[<ffffffff8134a94b>]  [<ffffffff8134a94b>] skb_pull+0x2b/0x30
[ 6634.203308] RSP: 0018:ffff88011fd83b20  EFLAGS: 00010293
[ 6634.203308] RAX: 000000000000048d RBX: ffff8801179347c0 RCX: 000000000000001a
[ 6634.203308] RDX: 000000000000001a RSI: 0000000000000002 RDI: ffff8801179347c0
[ 6634.203308] RBP: ffff88011fd83b20 R08: 0000000000000228 R09: 000000000000000c
[ 6634.203308] R10: 0000000000000240 R11: 0000000000000001 R12: ffff880114efcc00
[ 6634.203308] R13: ffff880116bd486e R14: 000000000000002f R15: ffff880116e14000
[ 6634.203308] FS:  0000000000000000(0000) GS:ffff88011fd80000(0000) knlGS:0000000000000000
[ 6634.203308] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 6634.203308] CR2: 00000000009b3748 CR3: 0000000117d88000 CR4: 00000000000006e0
[ 6634.203308] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 6634.203308] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 6634.203308] Process kworker/0:1 (pid: 0, threadinfo ffff880118f46000, task ffff880118f444c0)
[ 6634.203308] Stack:
[ 6634.203308]  ffff88011fd83b50 ffffffffa034463a ffff88011fd83b80 ffff880114efcc00
[ 6634.203308]  ffff8801179347c0 0000000000000000 ffff88011fd83b90 ffffffff81346ecc
[ 6634.203308]  ffff88011fd83bb0 ffffffff8134b4e9 0000000000000001 ffff8801179347c0
[ 6634.203308] Call Trace:
[ 6634.203308]  <IRQ>
[ 6634.203308]  [<ffffffffa034463a>] pptp_rcv_core+0x21a/0x220 [pptp]
[ 6634.203308]  [<ffffffff81346ecc>] sk_receive_skb+0x10c/0x140
[ 6634.203308]  [<ffffffff8134b4e9>] ? __pskb_pull_tail+0x59/0x3e0
[ 6634.203308]  [<ffffffffa0344783>] pptp_rcv+0x143/0x190 [pptp]
[ 6634.203308]  [<ffffffffa03230ad>] gre_rcv+0x5d/0x80 [gre]
[ 6634.203308]  [<ffffffff8138946d>] ip_local_deliver_finish+0xdd/0x2a0
[ 6634.203308]  [<ffffffff813897f0>] ip_local_deliver+0x80/0x90
[ 6634.203308]  [<ffffffff81389135>] ip_rcv_finish+0x135/0x390
[ 6634.203308]  [<ffffffff81389a1c>] ip_rcv+0x21c/0x2e0
[ 6634.203308]  [<ffffffff81356f5a>] __netif_receive_skb+0x52a/0x690
[ 6634.203308]  [<ffffffff81137985>] ? __kmalloc_node_track_caller+0x55/0x60
[ 6634.203308]  [<ffffffff813572d0>] netif_receive_skb+0x60/0x90
[ 6634.203308]  [<ffffffff8124de9c>] ? is_swiotlb_buffer+0x3c/0x50
[ 6634.203308]  [<ffffffff81357440>] napi_skb_finish+0x50/0x70
[ 6634.203308]  [<ffffffff813579bd>] napi_gro_receive+0xbd/0xd0
[ 6634.203308]  [<ffffffffa017629b>] igb_poll+0x6fb/0xae0 [igb]
[ 6634.203308]  [<ffffffff81356f5a>] ? __netif_receive_skb+0x52a/0x690
[ 6634.203308]  [<ffffffff81357be5>] net_rx_action+0x135/0x270
[ 6634.203308]  [<ffffffff81062705>] __do_softirq+0xa5/0x1d0
[ 6634.203308]  [<ffffffff8141301c>] call_softirq+0x1c/0x30
[ 6634.203308]  [<ffffffff8100d355>] do_softirq+0x65/0xa0
[ 6634.203308]  [<ffffffff81062a96>] irq_exit+0x86/0xa0
[ 6634.203308]  [<ffffffff8100cf01>] do_IRQ+0x61/0xe0
[ 6634.203308]  [<ffffffff8140a593>] common_interrupt+0x13/0x13
[ 6634.203308]  <EOI>
[ 6634.203308]  [<ffffffff81012deb>] ? mwait_idle+0x9b/0x1d0
[ 6634.203308]  [<ffffffff8140de35>] ? atomic_notifier_call_chain+0x15/0x20
[ 6634.203308]  [<ffffffff8100a1e6>] cpu_idle+0x56/0xa0
[ 6634.203308]  [<ffffffff81403729>] start_secondary+0x197/0x19c
[ 6634.203308] Code: 8b 47 68 55 48 89 e5 39 c6 77 1c 29 f0 3b 47 6c 89 47 68 72 16 89 f0 48 03 87 e0 00 00 00 48 89 87 e
[ 6634.203308] RIP  [<ffffffff8134a94b>] skb_pull+0x2b/0x30
[ 6634.203308]  RSP <ffff88011fd83b20>
[ 6635.301206] ---[ end trace a028fa52178139a9 ]---
[ 6635.315124] Kernel panic - not syncing: Fatal exception in interrupt
[ 6635.334234] Pid: 0, comm: kworker/0:1 Tainted: G      D     2.6.39-std-def-alt3 #1
[ 6635.357034] Call Trace:
[ 6635.364443]  <IRQ>  [<ffffffff81407284>] panic+0x8c/0x197
[ 6635.380775]  [<ffffffff8140b4d2>] oops_end+0xe2/0xf0
[ 6635.395723]  [<ffffffff8100e876>] die+0x56/0x90
[ 6635.409373]  [<ffffffff8140abf4>] do_trap+0xc4/0x170
[ 6635.424325]  [<ffffffff8100bf00>] do_invalid_op+0x90/0xb0
[ 6635.440576]  [<ffffffff8134a94b>] ? skb_pull+0x2b/0x30
[ 6635.456050]  [<ffffffff8136d8bd>] ? fib_rules_lookup+0xbd/0x120
[ 6635.473856]  [<ffffffff81412d9b>] invalid_op+0x1b/0x20
[ 6635.489325]  [<ffffffff8134a94b>] ? skb_pull+0x2b/0x30
[ 6635.504800]  [<ffffffffa034463a>] pptp_rcv_core+0x21a/0x220 [pptp]
[ 6635.523387]  [<ffffffff81346ecc>] sk_receive_skb+0x10c/0x140
[ 6635.540416]  [<ffffffff8134b4e9>] ? __pskb_pull_tail+0x59/0x3e0
[ 6635.558227]  [<ffffffffa0344783>] pptp_rcv+0x143/0x190 [pptp]
[ 6635.575518]  [<ffffffffa03230ad>] gre_rcv+0x5d/0x80 [gre]
[ 6635.591769]  [<ffffffff8138946d>] ip_local_deliver_finish+0xdd/0x2a0
[ 6635.610877]  [<ffffffff813897f0>] ip_local_deliver+0x80/0x90
[ 6635.627908]  [<ffffffff81389135>] ip_rcv_finish+0x135/0x390
[ 6635.644678]  [<ffffffff81389a1c>] ip_rcv+0x21c/0x2e0
[ 6635.659629]  [<ffffffff81356f5a>] __netif_receive_skb+0x52a/0x690
[ 6635.677962]  [<ffffffff81137985>] ? __kmalloc_node_track_caller+0x55/0x60
[ 6635.698369]  [<ffffffff813572d0>] netif_receive_skb+0x60/0x90
[ 6635.715661]  [<ffffffff8124de9c>] ? is_swiotlb_buffer+0x3c/0x50
[ 6635.733469]  [<ffffffff81357440>] napi_skb_finish+0x50/0x70
[ 6635.750244]  [<ffffffff813579bd>] napi_gro_receive+0xbd/0xd0
[ 6635.767282]  [<ffffffffa017629b>] igb_poll+0x6fb/0xae0 [igb]
[ 6635.784301]  [<ffffffff81356f5a>] ? __netif_receive_skb+0x52a/0x690
[ 6635.803152]  [<ffffffff81357be5>] net_rx_action+0x135/0x270
[ 6635.819925]  [<ffffffff81062705>] __do_softirq+0xa5/0x1d0
[ 6635.836172]  [<ffffffff8141301c>] call_softirq+0x1c/0x30
[ 6635.852162]  [<ffffffff8100d355>] do_softirq+0x65/0xa0
[ 6635.867633]  [<ffffffff81062a96>] irq_exit+0x86/0xa0
[ 6635.882583]  [<ffffffff8100cf01>] do_IRQ+0x61/0xe0
[ 6635.897014]  [<ffffffff8140a593>] common_interrupt+0x13/0x13
[ 6635.914043]  <EOI>  [<ffffffff81012deb>] ? mwait_idle+0x9b/0x1d0
[ 6635.932195]  [<ffffffff8140de35>] ? atomic_notifier_call_chain+0x15/0x20
[ 6635.952349]  [<ffffffff8100a1e6>] cpu_idle+0x56/0xa0
[ 6635.967319]  [<ffffffff81403729>] start_secondary+0x197/0x19c
[ 6635.984621] Rebooting in 30 seconds..

Изменено 28 июля, 2011 пользователем cpulink

[Max P]

Граждане, а кто нить под openwrt клиента собирал? Сейчас вот пробую замутить, собрал, закинул файло, поправил скрипты, вылезла грабля:

 

Jul 29 01:07:59 OpenWrt daemon.info pptp[2931]: Plugin pptp.so loaded.

Jul 29 01:07:59 OpenWrt daemon.info pptp[2931]: PPTP plugin version 0.8.5 compiled for pppd-2.4.4, linux-2.6.39.2

Jul 29 01:07:59 OpenWrt daemon.notice pptp[2931]: pppd 2.4.4 started by root, uid 0

Jul 29 01:07:59 OpenWrt daemon.notice pptp[2933]: anon log[callmgr_main:pptp_callmgr.c:132]: IP: 10.0.128.10

Jul 29 01:07:59 OpenWrt daemon.notice pptp[2933]: anon log[callmgr_main:pptp_callmgr.c:136]: control connection

Jul 29 01:07:59 OpenWrt daemon.notice pptp[2933]: anon log[callmgr_main:pptp_callmgr.c:140]: unix_sock

Jul 29 01:07:59 OpenWrt daemon.notice pptp[2934]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request'

Jul 29 01:07:59 OpenWrt daemon.notice pptp[2934]: anon log[ctrlp_disp:pptp_ctrl.c:737]: Received Start Control Connection Reply

Jul 29 01:07:59 OpenWrt daemon.notice pptp[2934]: anon log[ctrlp_disp:pptp_ctrl.c:771]: Client connection established.

Jul 29 01:08:00 OpenWrt daemon.notice pptp[2934]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request'

Jul 29 01:08:00 OpenWrt daemon.notice pptp[2934]: anon log[ctrlp_disp:pptp_ctrl.c:856]: Received Outgoing Call Reply.

Jul 29 01:08:00 OpenWrt daemon.notice pptp[2934]: anon log[ctrlp_disp:pptp_ctrl.c:895]: Outgoing call established (call ID 1, peer's call ID 6112).

Jul 29 01:08:00 OpenWrt daemon.debug pptp[2931]: using channel 1

Jul 29 01:08:00 OpenWrt daemon.info pptp[2931]: Using interface pptp-vpn

Jul 29 01:08:00 OpenWrt daemon.notice pptp[2931]: Connect: pptp-vpn <--> pptp (10.0.128.10)

Jul 29 01:08:00 OpenWrt daemon.debug pptp[2931]: sent [LCP ConfReq id=0x1 <mru 1452> <asyncmap 0x0> <magic 0x3429d173>]

Jul 29 01:08:03 OpenWrt daemon.debug pptp[2931]: sent [LCP ConfReq id=0x1 <mru 1452> <asyncmap 0x0> <magic 0x3429d173>]

Jul 29 01:08:06 OpenWrt daemon.debug pptp[2931]: sent [LCP ConfReq id=0x1 <mru 1452> <asyncmap 0x0> <magic 0x3429d173>]

Jul 29 01:08:09 OpenWrt daemon.debug pptp[2931]: sent [LCP ConfReq id=0x1 <mru 1452> <asyncmap 0x0> <magic 0x3429d173>]

Jul 29 01:08:12 OpenWrt daemon.debug pptp[2931]: sent [LCP ConfReq id=0x1 <mru 1452> <asyncmap 0x0> <magic 0x3429d173>]

Jul 29 01:08:15 OpenWrt daemon.debug pptp[2931]: sent [LCP ConfReq id=0x1 <mru 1452> <asyncmap 0x0> <magic 0x3429d173>]

Jul 29 01:08:18 OpenWrt daemon.debug pptp[2931]: sent [LCP ConfReq id=0x1 <mru 1452> <asyncmap 0x0> <magic 0x3429d173>]

Jul 29 01:08:21 OpenWrt daemon.debug pptp[2931]: sent [LCP ConfReq id=0x1 <mru 1452> <asyncmap 0x0> <magic 0x3429d173>]

Jul 29 01:08:24 OpenWrt daemon.debug pptp[2931]: sent [LCP ConfReq id=0x1 <mru 1452> <asyncmap 0x0> <magic 0x3429d173>]

Jul 29 01:08:27 OpenWrt daemon.debug pptp[2931]: sent [LCP ConfReq id=0x1 <mru 1452> <asyncmap 0x0> <magic 0x3429d173>]

Jul 29 01:08:27 OpenWrt daemon.notice pptp[2934]: anon log[ctrlp_disp:pptp_ctrl.c:927]: Call disconnect notification received (call id 256)

Jul 29 01:08:27 OpenWrt daemon.notice pptp[2934]: anon log[ctrlp_disp:pptp_ctrl.c:786]: Received Stop Control Connection Request.

Jul 29 01:08:27 OpenWrt daemon.notice pptp[2934]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 4 'Stop-Control-Connection-Reply'

Jul 29 01:08:27 OpenWrt daemon.notice pptp[2934]: anon log[callmgr_main:pptp_callmgr.c:269]: Closing connection (shutdown)

Jul 29 01:08:27 OpenWrt daemon.notice pptp[2934]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 12 'Call-Clear-Request'

Jul 29 01:08:27 OpenWrt daemon.notice pptp[2934]: anon log[pptp_read_some:pptp_ctrl.c:542]: read returned zero, peer has closed

Jul 29 01:08:27 OpenWrt daemon.notice pptp[2934]: anon log[call_callback:pptp_callmgr.c:79]: Closing connection (call state)

Jul 29 01:08:30 OpenWrt daemon.warn pptp[2931]: LCP: timeout sending Config-Requests

Jul 29 01:08:30 OpenWrt daemon.notice pptp[2931]: Connection terminated.

Jul 29 01:08:30 OpenWrt daemon.notice pptp[2931]: Modem hangup

 

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