[xeb]

Если используется шейпер, то было бы хорошо в консоли отображать скорость которая назначена на интерфейс клиенту.

да знаю, что надо команду show sessions расширять, но пока не первоочередная задача ...

 

[xeb]

где 100 и 101 access list содержит time-range для дня и ночи на входящую и исходящую скорость

можно полную строку ?

 

[alexxx71]

access-list 100 permit ip any any time-range day

access-list 101 permit ip any any time-range night

 

time-range day

periodic daily 9:00 to 1:00

!

time-range night

periodic daily 1:01 to 8:59

!

 

вот так на nas описано

 

[xeb]

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

[alexxx71]

ну я понял )

 

просто нужно что бы вот такой пакет нормально отрабатывался.

 

[2010-12-28 13:44:06]: info: ppp63: recv [RADIUS Access-Accept id=1 <Service-Type Framed-User> <Framed-Protocol PPP> <Framed-IP-Address 10.50.11.150> <Framed-IP-Netmask 255.255.255.255> <Acct-Interim-Interval 62><Cisco Ci

sco-AVPair "lcp:interface-config#1=rate-limit output access-group 101 5120000 960000 1920000 conform-action transmit exceed-action drop"><Cisco Cisco-AVPair "lcp:interface-config#1=rate-limit output access-group 100 512000

0 960000 1920000 conform-action transmit exceed-action drop"><Cisco Cisco-AVPair "lcp:interface-config#1=rate-limit input access-group 101 5120000 960000 1920000 conform-action transmit exceed-action drop"><Cisco Cisco-AVP

air "lcp:interface-config#1=rate-limit input access-group 100 5120000 960000 1920000 conform-action transmit exceed-action drop"><Microsoft MS-MPPE-Encryption-Policy 1><Microsoft MS-MPPE-Encryption-Type 6><Microsoft MS-MPP

E-Send-Key ><Microsoft MS-MPPE-Recv-Key ><Microsoft MS-CHAP2-Success >]

 

скорость то не ограничивается..

Изменено 28 декабря, 2010 пользователем alexxx71

[NiTr0]

А биллинг что, CoA слать не умеет?

[alexxx71]

не умеет :(

[Abram]

не умеет :(

По-моему, это проблема биллинга. И решать её надо в биллинге.

[Abram]

Поймал наконец-то своё падение.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb6c14b70 (LWP 28230)]
0xb7d133be in vsnprintf () from /lib/libc.so.6
(gdb)
(gdb)
(gdb) bt
#0  0xb7d133be in vsnprintf () from /lib/libc.so.6
#1  0xb7cf5cc2 in snprintf () from /lib/libc.so.6
#2  0xb741c023 in fill_env (env=0xb43f1f40, pd=0xc70b220) at /tmp/accel-pptp/accel-pptpd/extra/pppd_compat.c:481
#3  0xb741b8aa in ev_radius_coa (ev=0xb43f1fc0) at /tmp/accel-pptp/accel-pptpd/extra/pppd_compat.c:337
#4  0xb7fde7a2 in triton_event_fire (ev_id=201, arg=0xb43f1fc0) at /tmp/accel-pptp/accel-pptpd/triton/event.c:103
#5  0xb7c2c8bb in coa_request (rpd=0xb3cd0ea4) at /tmp/accel-pptp/accel-pptpd/radius/dm_coa.c:157
#6  0xb7fdc31f in ctx_thread (ctx=0xb43f3024) at /tmp/accel-pptp/accel-pptpd/triton/triton.c:170
#7  0xb7ce87bb in makecontext () from /lib/libc.so.6
#8  0xb43f3024 in ?? ()
#9  0xb7c8a107 in pptp_connect (h=0xb7fd3078) at /tmp/accel-pptp/accel-pptpd/ctrl/pptp/pptp.c:613
#10 0xb7fdc36f in ctx_thread (ctx=0xb7ff5d10) at /tmp/accel-pptp/accel-pptpd/triton/triton.c:181
#11 0xb7fe0470 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

[xeb]

fixed

[xeb]

-4. Можно ли в консоли accel отображать помимо remote ip еще и ip клиента с которого устанавливается сессия. Сильно бы упростило скриптописание.

Если используется шейпер, то было бы хорошо в консоли отображать скорость которая назначена на интерфейс клиенту

заценивайте новый show sessions и в help не забудьте заглянуть

 

[keshalg]

Доброго времени суток уважаемые коллеги!

Возникла тоже проблема с биллингом (stargazer.dp.ua).

Прошу Вашей помощи, похоже наткнулся на баг:

Использую версию accel-pptpd 0.8.5 на CentOS 5 со штатным ядром и ppp с вашим патчем allow-mppe-128

(большое спасибо за него, очень удобно стало, а то надоело следить за 2ми серверами).

ppp общается с биллингом по средствам радиуса, который выдает Framed-IP-Address на туннель из биллинга.

Исторически сложилось, что уживаются 2 вида тарифов:

- пометровые (вид доступа - собственный авторизатор, открыващий фаерволл на роутерах для LAN-ip)

и

- безлимиты (ВПН, на туннелях у юзеров отдельная вирт.сеть),

что обозначено в биллинге в поле IP (у пометровки - lan-ip , у анлимщиков - 10.9.248.0/23)

до перехода когда пометровые клиенты коннектились на впн-сервер со стандартным pptpd

выдавало ошибку 656 (точно не помню, воспроизвести не получается) и разрывало ВПН.

Сейчас accel-pptpd имею:

 

Dec 30 11:28:29 vpn1 pppd[801]: Plugin /usr/lib64/pppd/2.4.4/radius.so loaded.
Dec 30 11:28:29 vpn1 pppd[801]: RADIUS plugin initialized.
Dec 30 11:28:29 vpn1 pppd[801]: Plugin /usr/lib64/pppd/2.4.4/radattr.so loaded.
Dec 30 11:28:29 vpn1 pppd[801]: RADATTR plugin initialized.
Dec 30 11:28:29 vpn1 pppd[801]: Plugin /usr/lib/pptpd/pptpd-logwtmp.so loaded.
Dec 30 11:28:29 vpn1 pptp[801]: Plugin pptp.so loaded.
Dec 30 11:28:29 vpn1 pptp[801]: PPTP plugin version 0.8.5 compiled for pppd-2.4.4, linux-2.6.18-194.26.1.el5xen
Dec 30 11:28:29 vpn1 pptp[801]: pppd 2.4.4 started by root, uid 0
Dec 30 11:28:29 vpn1 pptp[801]: Using interface ppp107
Dec 30 11:28:29 vpn1 pptp[801]: Connect: ppp107 <--> pptp (10.9.2.33)
Dec 30 11:28:32 vpn1 pptp[801]: MPPE 128-bit stateless compression enabled
Dec 30 11:28:32 vpn1 pptp[801]: local  IP address 10.9.248.1
Dec 30 11:28:32 vpn1 pptp[801]: remote IP address 10.9.2.33
Dec 30 11:28:32 vpn1 kernel: HTB: quantum of class 10030 is small. Consider r2q change.
Dec 30 11:28:44 vpn1 kernel: BUG: soft lockup - CPU#0 stuck for 10s! [pppd:801]
Dec 30 11:28:44 vpn1 kernel: CPU 0:
Dec 30 11:28:44 vpn1 kernel: Modules linked in: ipt_set(U) ip_set_nethash(U) ip_set(U) xt_MARK iptable_mangle act_police sch_i
ngress cls_u32 sch_sfq cls_fw sch_htb testmgr_cipher testmgr aead crypto_blkcipher crypto_algapi crypto_api arc4 ppp_mppe ipt_
MASQUERADE iptable_nat ipt_TCPMSS xt_tcpudp iptable_filter ip_tables x_tables ip_nat_pptp ip_conntrack_pptp ip_nat ip_conntrac
k nfnetlink pptp(U) pppox ppp_generic slhc dm_mirror dm_multipath scsi_dh scsi_mod parport_pc lp parport xennet pcspkr dm_raid
45 dm_message dm_region_hash dm_log dm_mod dm_mem_cache xenblk ext3 jbd uhci_hcd ohci_hcd ehci_hcd
Dec 30 11:28:44 vpn1 kernel: Pid: 801, comm: pppd Tainted: G      2.6.18-194.26.1.el5xen #1
Dec 30 11:28:44 vpn1 kernel: RIP: e030:[<ffffffff80264aa9>]  [<ffffffff80264aa9>] .text.lock.spinlock+0x26/0x30
Dec 30 11:28:44 vpn1 kernel: RSP: e02b:ffff880005c17c28  EFLAGS: 00000286
Dec 30 11:28:44 vpn1 kernel: RAX: ffff880005c17fd8 RBX: ffff880014fdb810 RCX: 00000000000000fc
Dec 30 11:28:44 vpn1 kernel: RDX: ffffffffff578000 RSI: ffff880013e1c9c0 RDI: ffff880014fdb810
Dec 30 11:28:44 vpn1 kernel: RBP: ffff880014fdb810 R08: ffff88005e79347e R09: 0000000000000113
Dec 30 11:28:44 vpn1 kernel: R10: ffff880013e1c9c0 R11: 000000000000002f R12: ffff880002ee1800
Dec 30 11:28:44 vpn1 kernel: R13: 0000000000000034 R14: 0000000000000000 R15: ffff880004f05000
Dec 30 11:28:44 vpn1 kernel: FS:  00002b76e45d9af0(0000) GS:ffffffff805d2000(0000) knlGS:0000000000000000
Dec 30 11:28:44 vpn1 kernel: CS:  e033 DS: 0000 ES: 0000
Dec 30 11:28:44 vpn1 kernel:
Dec 30 11:28:44 vpn1 kernel: Call Trace:
Dec 30 11:28:45 vpn1 kernel:  [<ffffffff80264959>] _spin_lock_bh+0x9/0x14
Dec 30 11:28:45 vpn1 kernel:  [<ffffffff8819a76e>] :ppp_generic:ppp_push+0x61/0x54c
Dec 30 11:28:45 vpn1 kernel:  [<ffffffff8826735e>] :ppp_mppe:mppe_compress+0x141/0x178
Dec 30 11:28:45 vpn1 kernel:  [<ffffffff8022efd3>] __alloc_skb+0x77/0x12d
Dec 30 11:28:45 vpn1 kernel:  [<ffffffff8819b4e7>] :ppp_generic:ppp_xmit_process+0x525/0x5c1
Dec 30 11:28:45 vpn1 kernel:  [<ffffffff80264931>] _spin_lock_irqsave+0x9/0x14
Dec 30 11:28:45 vpn1 kernel:  [<ffffffff8819d549>] :ppp_generic:ppp_start_xmit+0x1d9/0x21f
Dec 30 11:28:45 vpn1 kernel:  [<ffffffff8041fc0d>] dev_hard_start_xmit+0x1b7/0x28a
Dec 30 11:28:45 vpn1 kernel:  [<ffffffff8042fff1>] __qdisc_run+0x136/0x1f9
Dec 30 11:28:45 vpn1 kernel:  [<ffffffff80230da8>] dev_queue_xmit+0x25d/0x394
Dec 30 11:28:45 vpn1 kernel:  [<ffffffff802332f6>] ip_output+0x2ae/0x2dd
Dec 30 11:28:45 vpn1 kernel:  [<ffffffff881b701a>] :pptp:pptp_xmit+0x537/0x56d
Dec 30 11:28:45 vpn1 kernel:  [<ffffffff8819c2a0>] :ppp_generic:ppp_channel_push+0x3d/0xae
Dec 30 11:28:45 vpn1 kernel:  [<ffffffff8819d691>] :ppp_generic:ppp_write+0x102/0x111
Dec 30 11:28:45 vpn1 kernel:  [<ffffffff80217377>] vfs_write+0xce/0x174
Dec 30 11:28:45 vpn1 kernel:  [<ffffffff80217bc4>] sys_write+0x45/0x6e
Dec 30 11:28:45 vpn1 kernel:  [<ffffffff80260106>] system_call+0x86/0x8b
Dec 30 11:28:45 vpn1 kernel:  [<ffffffff80260080>] system_call+0x0/0x8b
Dec 30 11:28:45 vpn1 kernel:
Dec 30 11:28:54 vpn1 kernel: BUG: soft lockup - CPU#0 stuck for 10s! [pppd:801]
и тд в цикле

 

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

А то не хочется отказываться от данного "чудо" ПО, действительно прирост производительности существенный.

Респект Xeb -у и тем кто принимает участия в разработке

Изменено 30 декабря, 2010 пользователем keshalg

[NiTr0]

Dec 30 11:28:29 vpn1 pptp[801]: Connect: ppp107 <--> pptp (10.9.2.33)

Dec 30 11:28:32 vpn1 pptp[801]: remote IP address 10.9.2.33

юзеру на туннель выдается его же адрес в локалке. ессно - краш.

 

А вообще - "исторически сложившуюся" кривую систему нужно менять. Если не получится простыми мерами - то радикально, с биллингом. Негоже держать биллинг, который не различает VPN с IPoE - обязательно кто-то из саппорта попутает, и вобьет IP юзера ему же на туннель, обеспечив краш всех серверов пула по очереди.

Изменено 30 декабря, 2010 пользователем NiTr0

[keshalg]

Hу с радикальными методами понятно,

пометровка сама отживает свое, я за компромиссное решение.

Cаппорту трудно будет всех перевести на один вид доступа, да и авторизатор там информативный очень.

....краш всех серверов пула по очереди.

Да не должно же такого быть, стандартный РоРоТОР - выдавал просто ошибку, но не валять же весь *nix.

Удалось воспроизвести на стандартном pptpd

[root@vpn2 ~]# rpm -q pptpd
pptpd-1.3.4-2.rhel5

 

на клиенте пишет после авторизации в момент "Регистрация компьютера в сети..."

 

Ошибка подключения ....
Проверка подключений сетевых протоколов....
TCP/IP протокол сообщает об ошибке 52:
ну удалось подключиться к сети из-за существования совпадающих имен.
Измените имя компьютера на панели управления и повторите попытку

 

на сервере в этот момент

 

Dec 30 17:49:38 vpn2 pppd[6314]: local  IP address 10.9.248.1
Dec 30 17:49:38 vpn2 pppd[6314]: remote IP address 10.9.0.248
Dec 30 17:49:38 vpn2 pppd[6314]: pptpd-logwtmp.so ip-up ppp0 kesha 10.9.0.248
Dec 30 17:49:38 vpn2 pppd[6314]: IPCP terminated by peer (h6hM-9^@<M-Mt^@^@^@4)
Dec 30 17:49:38 vpn2 pppd[6314]: pptpd-logwtmp.so ip-down ppp0
Dec 30 17:49:38 vpn2 pppd[6314]: Connect time 0.0 minutes.
Dec 30 17:49:38 vpn2 pppd[6314]: Sent 59620 bytes, received 16 bytes.
Dec 30 17:49:38 vpn2 pppd[6314]: LCP terminated by peer (h6hM-9^@<M-Mt^@^@^@^@)
Dec 30 17:49:38 vpn2 pppd[6314]: Modem hangup
Dec 30 17:49:38 vpn2 pppd[6314]: Connection terminated.
Dec 30 17:49:38 vpn2 pppd[6314]: Connect time 0.0 minutes.
Dec 30 17:49:38 vpn2 pppd[6314]: Sent 59624 bytes, received 16 bytes.
Dec 30 17:49:38 vpn2 pppd[6314]: Exit.
Dec 30 17:49:38 vpn2 pptpd[6313]: CTRL: Client 10.9.0.248 control connection finished

Изменено 30 декабря, 2010 пользователем keshalg

[xeb]

Удалось воспроизвести на стандартном pptpd

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

 

[keshalg]

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

т.е. мне не "светит" аксцель?

А нельзя ли подправить код, подобно стандартному pptpd, что бы аксцель обрабатывал точно так же это исключение?

И правда же механические операторов ошибки просто неизбежны

[xeb]

в 1.х есть защита

[xeb]

да, кстати, с CMAKE_BUILD_TYPE=Release не собирайте, падает почему-то, либо вообще не указывайте, либо CMAKE_BUILD_TYPE=Debug

[NiTr0]

Hу с радикальными методами понятно,

пометровка сама отживает свое, я за компромиссное решение.

Cаппорту трудно будет всех перевести на один вид доступа, да и авторизатор там информативный очень.

После предложения хомякам 10-20-50 мбит за 10$ они толпой побегут за дешевыми тарифами, забыв о пометровке и информативном авторизаторе. И если сравнивать траффик при "массвых" каналах в 2 мбита и "массовых" каналах в 20 мбит - разница будет максимум раза в 1.5-2.

 

т.е. мне не "светит" аксцель?

Вам виднее.

 

А нельзя ли подправить код

Можно, правьте :)

[Abram]

(gdb) bt
#0  0x0804a90d in __list_del (prev=0x0, next=0x0) at /tmp/accel-pptp/accel-pptpd/include/list.h:85
#1  0x0804a937 in list_del (entry=0xaab5cbc) at /tmp/accel-pptp/accel-pptpd/include/list.h:96
#2  0x0804b038 in destablish_ppp (ppp=0xaab5cbc) at /tmp/accel-pptp/accel-pptpd/ppp/ppp.c:195
#3  0x0804b960 in ppp_layer_finished (ppp=0xaab5cbc, d=0xaf796430) at /tmp/accel-pptp/accel-pptpd/ppp/ppp.c:432
#4  0x0804d7e7 in _lcp_layer_finished (lcp=0xaf796430) at /tmp/accel-pptp/accel-pptpd/ppp/ppp_lcp.c:125
#5  0xb7fdc31f in ctx_thread (ctx=0xb429b024) at /tmp/accel-pptp/accel-pptpd/triton/triton.c:170
#6  0xb7ce87bb in makecontext () from /lib/libc.so.6
#7  0xb429b024 in ?? ()
#8  0xb7c8a107 in pptp_connect (h=0xb7fd3078) at /tmp/accel-pptp/accel-pptpd/ctrl/pptp/pptp.c:613
#9  0xb7fdc36f in ctx_thread (ctx=0xb7ff5d10) at /tmp/accel-pptp/accel-pptpd/triton/triton.c:181
#10 0xb7fe0470 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

0489841b673164b666a800255d86ab94d25cd45b

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

[xeb]

да, это уже исправлено

[Abram]

Свежачок. 6409b409508f22ea7dbb3f3fa2cb9de78d5073c5

(gdb) bt
#0  0xb7fdb050 in __list_del (prev=0x0, next=0x0) at /tmp/accel-pptp/accel-pptpd/triton/list.h:85
#1  0xb7fdb07a in list_del (entry=0xb27f1878) at /tmp/accel-pptp/accel-pptpd/triton/list.h:96
#2  0xb7fdb30e in triton_thread (thread=0xb27f1878) at /tmp/accel-pptp/accel-pptpd/triton/triton.c:104
#3  0xb7fb4e60 in start_thread () from /lib/libpthread.so.0
#4  0xb7d7bf9e in clone () from /lib/libc.so.6

 

[xeb]

думаю что исправил

[keshalg]

А нельзя ли подправить код

Можно, правьте :)

Обошлось без правки кода.

По совету уважаемого martin74, моя "частная проблема" решена скриптом auth-up из /еtс/ppp (man pppd)

Спасибо за помощь и разрешение править GPL-проект.

Я думал версия 0.8.5 актуальна, хотя бы для тех, кто работает на RH5-based системах

(которым недоступны официальные новые ядра для 1.X).

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

[NiTr0]

Ну у меня 0.8.5; работает. Все что нужно - поправил в биллинге. На 1.x - пока не спешу переползать, т.к. это требует втягивания в мой дистр cmake и еще скорее всего еще библиотек + насилования всего этого для кросс-компиляции, + пока его в продакшн пускать рановато...