Jump to content
Калькуляторы

accel pptpd accel pptpd

совпадают, у меня еще версия с пптп...странно конечно но седня крутанулось, хотя ничего не менял...

Share this post


Link to post
Share on other sites

Добрый день.

Подскажите пожалуйста как общаться с cli консолью accel`ля через tcp ?

В конфиге есть cli tcp 127.0.0.1 2001

на все комманды аналогчные telnet cli получаю

show stat
command unknown

 

Share this post


Link to post
Share on other sites
Добрый день.

Подскажите пожалуйста как общаться с cli консолью accel`ля через tcp ?

В конфиге есть cli tcp 127.0.0.1 2001

на все комманды аналогчные telnet cli получаю

show stat
command unknown

echo "show stat" | nc -q1 localhost 2001
uptime: 6.06:33:29
cpu: 0%
mem(rss/virt): 1368/77792 kB
core:
 mempool_allocated: 219206
 mempool_available: 173370
 thread_count: 4
 thread_active: 1
 context_count: 7
 context_sleeping: 0
 context_pending: 0
 md_handler_count: 13
 md_handler_pending: 0
 timer_count: 6
 timer_pending: 0
ppp:
 starting: 0
 active: 2
 finishing: 0
pptp:
 starting: 0
 active: 2
radius:
 auth sent: 29
 auth lost(total/5m/1m): 0/0/0
 auth avg query time(5m/1m): 0/0 ms
 acct sent: 54
 acct lost(total/5m/1m): 0/0/0
 acct avg query time(5m/1m): 0/0 ms
 interim sent: 12824
 interim lost(total/5m/1m): 0/0/0
 interim avg query time(5m/1m): 4/4 ms

Share this post


Link to post
Share on other sites

Хм

А чем отличается от

echo "show sessions username,calling-sid,ip"|nc -tCq1  localhost 2000

 

Кстати не рушится ли в корку, особенно при частых обращениях с ошибками ?

у меня бывает, но воспроизвести не могу...

Share this post


Link to post
Share on other sites

в конфиге в секции [pppoe] есть интересная опция

mac-filter=filename,type

Specifies mac-filter filename and type, type maybe allow or deny

насколько я понимаю это для фильтрации/разрешения запросов с определённых маков? хотелось бы узнать формат этого файла и допустимы ли там какие-нить шаблоны

Share this post


Link to post
Share on other sites

формат простой - в каждой строчке по маку, шаблонов нет

Share this post


Link to post
Share on other sites

Заметил, что в cli не изменяется скорость командой:

shaper change ppp0 1152:1152

Приходиться делать

terminate if ppp0

Версии

accel-ppp version 57ec76a3e15006c94e579662ce710bfd3f032331

и

accel-ppp version 38077f9b9d9e86f4a7d2317b3697ea4370889999

 

Хотя в accel-pptp скорость менялась на лету через cli.

Edited by nickmas

Share this post


Link to post
Share on other sites
формат простой - в каждой строчке по маку, шаблонов нет
а означает ли, что если указана опция mac-filter=filename,allow то будут разрешены только маки, указанные в файле и наоборот в случае deny? и как оно себя будет вести в случае указания нескольких опций mac-filter? ;)

 

ЗЫ: да, и ещё... deny можно рассматривать по разному... сервер будет игнорировать абсолютно все фреймы с указанных маков или всё же как-то будет отвечать например на PADI-пакеты? я почему пристаю... если в канальном сегменте несколько пппое концентраторов то в принципе клиенты цепляются случайным образом на любой из них. таким образом осуществляется балансировка нагрузки между ними, резервирование, балансировка внешних каналов etc. так вот если сервер, на котором клиент будет блокирован по мак-филтер всё же ответит на его ПАДИ фрейм, то у клиента будут проблемы подключения через концентраторы, на которых клиент не блокирован

Edited by aran

Share this post


Link to post
Share on other sites
означает ли, что если указана опция mac-filter=filename,allow то будут разрешены только маки, указанные в файле
да

 

и как оно себя будет вести в случае указания нескольких опций mac-filter?
считает только один из них

 

сервер будет игнорировать абсолютно все фреймы с указанных маков
да

 

Share this post


Link to post
Share on other sites
Заметил, что в cli не изменяется скорость командой:

shaper change ppp0 1152:1152

fixed

 

Share this post


Link to post
Share on other sites

пппое сервер при завершении акселя не освобождает сетевой ифейс который слушает (ну который указан в опции interface в [pppoe]). Ну может в случае "чистого" изернета и освобождает - нет щас возможности проверить сплошные виланы, так вот в случае вилана точно не освобождает. Это приводит например к тому, что при перезагрузке сервера ядро навсегда зависает вот на этом:

unregister_netdevice: waiting for vlan5 to become free. Usage count = 1

помогает только ресет... ну и подругим причинам это нехорошо. Проверено на версиях 1.3.4 и 38077f9b9d9e86f4a7d2317b3697ea4370889999

Share this post


Link to post
Share on other sites

поднимаем пптп

ppp0: 1d2f01c080edd5f9: ipcp_layer_started
ppp0: 1d2f01c080edd5f9: pptp: ppp started
ppp0: 1d2f01c080edd5f9: send [PPTP Echo-Request <Identifier 3352255a>]
ppp0: 1d2f01c080edd5f9: recv [PPTP Echo-Reply <Identifier 3352255a>]
ppp0: 1d2f01c080edd5f9: send [LCP EchoReq id=2 <magic 140e0f76>]
ppp0: 1d2f01c080edd5f9: recv [LCP EchoRep id=2 <magic 3e55d907>]
ppp0: 1d2f01c080edd5f9: send [PPTP Echo-Request <Identifier 109cf92e>]
ppp0: 1d2f01c080edd5f9: recv [PPTP Echo-Reply <Identifier 109cf92e>]
ppp0: 1d2f01c080edd5f9: send [LCP EchoReq id=3 <magic 140e0f76>]
ppp0: 1d2f01c080edd5f9: recv [LCP EchoRep id=3 <magic 3e55d907>]
ppp0: 1d2f01c080edd5f9: send [PPTP Echo-Request <Identifier ded7263>]
ppp0: 1d2f01c080edd5f9: recv [PPTP Echo-Reply <Identifier ded7263>]
ppp0: 1d2f01c080edd5f9: send [LCP EchoReq id=4 <magic 140e0f76>]
ppp0: 1d2f01c080edd5f9: recv [LCP EchoRep id=4 <magic 3e55d907>]

на этом месте выдёргиваем кабель

ppp0: 1d2f01c080edd5f9: send [PPTP Echo-Request <Identifier 7fdcc233>]
ppp0: 1d2f01c080edd5f9: send [LCP EchoReq id=5 <magic 140e0f76>]
ppp0: 1d2f01c080edd5f9: send [PPTP Echo-Request <Identifier 1befd79f>]
ppp0: 1d2f01c080edd5f9: send [LCP EchoReq id=6 <magic 140e0f76>]
ppp0: 1d2f01c080edd5f9: send [PPTP Echo-Request <Identifier 41a7c4c9>]
ppp0: 1d2f01c080edd5f9: send [LCP EchoReq id=7 <magic 140e0f76>]
ppp0: 1d2f01c080edd5f9: send [PPTP Echo-Request <Identifier 6b68079a>]
ppp0: 1d2f01c080edd5f9: send [LCP EchoReq id=8 <magic 140e0f76>]
ppp0: 1d2f01c080edd5f9: send [PPTP Echo-Request <Identifier 4e6afb66>]
ppp0: 1d2f01c080edd5f9: send [LCP EchoReq id=9 <magic 140e0f76>]
ppp0: 1d2f01c080edd5f9: send [PPTP Echo-Request <Identifier 25e45d32>]
ppp0: 1d2f01c080edd5f9: send [LCP EchoReq id=a <magic 140e0f76>]
ppp0: 1d2f01c080edd5f9: send [PPTP Echo-Request <Identifier 519b500d>]
ppp0: 1d2f01c080edd5f9: lcp: no echo reply
ppp0: 1d2f01c080edd5f9: ppp_terminate
ppp0: 1d2f01c080edd5f9: lcp_layer_free
ppp0: 1d2f01c080edd5f9: auth_layer_free
ppp0: 1d2f01c080edd5f9: ccp_layer_free
ppp0: 1d2f01c080edd5f9: ipcp_layer_free
ppp0: 1d2f01c080edd5f9: ppp destablished
ppp0: 1d2f01c080edd5f9: pptp: ppp finished
ppp0: 1d2f01c080edd5f9: send [PPTP Call-Disconnect-Notify <Call-ID c0> <Result 3> <Error 0> <Cause 0>]
ppp0: 1d2f01c080edd5f9: send [PPTP Stop-Ctrl-Conn-Request <Reason 0>]
ppp0: 1d2f01c080edd5f9: pptp: disconnect
ppp0: 1d2f01c080edd5f9: disconnected

на этом месте кернел паник. постоянно. всегда

 

accel-ppp version a2fe6bb78b048a0214a2c3e02e26105179ec4c3a

Linux billing 2.6.37-6-server-billing #19 SMP Sun Feb 6 00:34:08 EET 2011 i686 i686 i386 GNU/Linux

Share this post


Link to post
Share on other sites

Хотим попробовать внедрить accel ppp для pppoe, сейчас пользуемся mpd на freebsd

 

Есть вопросы

1) Есть ли возможность отдавать радиусу счётчики трафика по ip зонам, как в mpd ?

2) Хотим шейперы на ppp интерфейсе к абоненту, скорость тоже хочется резать по зонам, возможно ли? Как запускаете шейпер? В if-up ?

3) Какой дистрибутив наиболее безглючно работает с accel ppp ? Или может быть какая-то определенная версия ядра нужна?

Edited by marikoda

Share this post


Link to post
Share on other sites
1) Есть ли возможность отдавать радиусу счётчики трафика по ip зонам, как в mpd ?
нет

 

2) Хотим шейперы на ppp интерфейсе к абоненту, скорость тоже хочется резать по зонам, возможно ли? Как запускаете шейпер? В if-up ?
по зонам можно, через ip-up

 

3) Какой дистрибутив наиболее безглючно работает с accel ppp ? Или может быть какая-то определенная версия ядра нужна?
с пппое вроде особых проблем нет, так что подойдёт любой более менее свежий дистрибутив, вообще замечена наиболее стабильная связка 3.6.35 ядро и интеловские карты с интеловскими дровами, ядра 2.6.36-37 лучше не использовать

 

Share this post


Link to post
Share on other sites
пппое сервер при завершении акселя не освобождает сетевой ифейс который слушает (ну который указан в опции interface в [pppoe]). Ну может в случае "чистого" изернета и освобождает - нет щас возможности проверить сплошные виланы, так вот в случае вилана точно не освобождает. Это приводит например к тому, что при перезагрузке сервера ядро навсегда зависает вот на этом:
unregister_netdevice: waiting for vlan5 to become free. Usage count = 1
помогает только ресет... ну и подругим причинам это нехорошо. Проверено на версиях 1.3.4 и 38077f9b9d9e86f4a7d2317b3697ea4370889999

Удалось проверить на "чистом" изернете - там этой проблемы нет. Так что дело именно в виланах. К слову, у пппое сервера из пакета rp-pppoe, собранного с поддержкой кернел моуд, и запускаемого в этом режиме на вилане тоже этой проблемы нет. Так что можно ковырнуть евойные сырцы на тему виланов. Вощем надо шось робыты... А то отказываться от акселя только из-за этого не хотелось бы :(

 

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

 

ЗЫ2: подобная тема (про unregister_netdevice: waiting for vlan...) не раз поднималась в инете... но то были косяки ведра которые уже пофикшены... здесь дело не в ведре потому как:

 

1. это начинается только после работы через аксель

2. после работы через pppoe-server от rp такого не происходит

Edited by aran

Share this post


Link to post
Share on other sites

внедряю bgbill

в качестве пппое - accel из GITa, [2011-02-12 01:37:29]: msg: accel-ppp version 53f22bd8a8cd4a407b7eb9c9b034b215e2299e30 (в файле accel-ppp.log почему то на 10 метров в начале все в точках)

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

написал разрабам bg, там молчат. пока молчат решил проверить подключением с винды через пппое с клиентского логина.

что интересно - работает без разрывов. выходит что с модема кто коннектится - связь рвёт, если пппое поднят на винде (в случае моего теста в7) то не рвет. что это может быть? как объяснить поведение accel ? и он ли виноват?

вот лог ассел:

[2011-02-12 02:41:43]: error: ppp1: lcp:echo: magic number size mismatch
[2011-02-12 02:41:43]:  info: ppp1: send [RADIUS Accounting-Request id=2 <User-Name "in-2357927"> <NAS-Identifier "accel-ppp"> <NAS-IP-Address 10.10.100.12> <NAS-Port 1> <NAS-Port-Type Virtual> <Service-Type Framed-User> <Framed-Protocol PPP> <Calling-Station-Id "00:1d:6a:37:5c:1e"> <Called-Station-Id "40:61:86:c4:85:b8"> <Acct-Status-Type Stop> <Acct-Authentic RADIUS> <Acct-Session-Id "06d1df4da157d630"> <Acct-Session-Time 31> <Acct-Input-Octets 54> <Acct-Output-Octets 58> <Acct-Input-Packets 3> <Acct-Output-Packets 4> <Acct-Input-Gigawords 0> <Acct-Output-Gigawords 0> <Acct-Delay-Time 0> <Framed-IP-Address 195.238.105.46> <Acct-Terminate-Cause User-Error>]
[2011-02-12 02:41:43]:  info: ppp1: recv [RADIUS Accounting-Response id=2]
[2011-02-12 02:41:43]:  info: ppp1: connect: ppp1 <--> pppoe(00:1d:6a:37:5c:1e)
[2011-02-12 02:41:43]:  info: ppp1: disconnected
[2011-02-12 02:41:43]:  info: ppp1: send [RADIUS Access-Request id=1 <User-Name "in-2357927"> <NAS-Identifier "accel-ppp"> <NAS-IP-Address 10.10.100.12> <NAS-Port 1> <NAS-Port-Type Virtual> <Service-Type Framed-User> <Framed-Protocol PPP> <Calling-Station-Id "00:1d:6a:37:5c:1e"> <Called-Station-Id "40:61:86:c4:85:b8"> <User-Password >]
[2011-02-12 02:41:43]:  info: ppp1: recv [RADIUS Access-Accept id=1 <Acct-Interim-Interval 60> <Service-Type Framed-User> <Framed-Protocol PPP> <Traffic-Shape-in 256>]
[2011-02-12 02:41:43]:  info: ppp1: in-2357927: authentication successed
[2011-02-12 02:41:43]:  info: ppp1: send [RADIUS Accounting-Request id=1 <User-Name "in-2357927"> <NAS-Identifier "accel-ppp"> <NAS-IP-Address 10.10.100.12> <NAS-Port 1> <NAS-Port-Type Virtual> <Service-Type Framed-User> <Framed-Protocol PPP> <Calling-Station-Id "00:1d:6a:37:5c:1e"> <Called-Station-Id "40:61:86:c4:85:b8"> <Acct-Status-Type Start> <Acct-Authentic RADIUS> <Acct-Session-Id "06d1df4da157d631"> <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 195.238.105.47>]
[2011-02-12 02:41:43]:  info: ppp1: recv [RADIUS Accounting-Response id=1]

 

и так по кругу каждые 35 сек.

если я под этим логином войду с винды - всё будет ок.

и что означает "lcp:echo: magic number size mismatch"? в каких случаях так выдает?

 

p.s. обновил версию

[2011-02-12 03:12:08]: msg: accel-pptp version 2fdf3586c13a72c36f9530084962e29d57dc0329

ничего не изменилось. пппое с модемов рвёт, с винды работает :(

 

з.ы. что интересно, у сотрудника тоже в модеме пппое поднимается. его аккаунт работает без разрывов.

[2011-02-12 03:12:24]:   msg: accel-pptp version 2fdf3586c13a72c36f9530084962e29d57dc0329
[2011-02-12 03:13:39]:  info: ppp0: connect: ppp0 <--> pppoe(00:02:cf:82:8a:38)
[2011-02-12 03:13:39]:  info: ppp0: send [RADIUS Access-Request id=1 <User-Name "alexandr"> <NAS-Identifier "accel-ppp"> <NAS-IP-Address 10.10.100.12> <NAS-Port 0> <NAS-Port-Type Virtual> <Service-Type Framed-User> <Framed-Protocol PPP> <Calling-Station-Id "00:02:cf:82:8a:38"> <Called-Station-Id "40:61:86:c4:85:b8"> <User-Password >]
[2011-02-12 03:13:39]:  info: ppp0: recv [RADIUS Access-Accept id=1 <Acct-Interim-Interval 60> <Service-Type Framed-User> <Framed-Protocol PPP> <Traffic-Shape-in 256>]
[2011-02-12 03:13:39]:  info: ppp0: alexandr: authentication successed
[2011-02-12 03:13:39]:  info: ppp0: send [RADIUS Accounting-Request id=1 <User-Name "alexandr"> <NAS-Identifier "accel-ppp"> <NAS-IP-Address 10.10.100.12> <NAS-Port 0> <NAS-Port-Type Virtual> <Service-Type Framed-User> <Framed-Protocol PPP> <Calling-Station-Id "00:02:cf:82:8a:38"> <Called-Station-Id "40:61:86:c4:85:b8"> <Acct-Status-Type Start> <Acct-Authentic RADIUS> <Acct-Session-Id "06d1df4da157d5c1"> <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 195.238.105.32>]
[2011-02-12 03:13:39]:  info: ppp0: recv [RADIUS Accounting-Response id=1]

а у остальных рвёт :(

Edited by lost

Share this post


Link to post
Share on other sites
[2011-02-12 02:41:43]: error: ppp1: lcp:echo: magic number size mismatch
и что все клиенты с таким сообщением обрываются ?

 

Share this post


Link to post
Share on other sites

C magic это бсд- у нее какойто свой путь расчета

у клиента с роутером m0n0wall вылечили

добавлением в конфиг mpd

set link disable check-magic

похожая проблема есть с клиентами MacOs

Share this post


Link to post
Share on other sites
и что все клиенты с таким сообщением обрываются ?
да, все. но насколько все - не знаю. днем тестировать нельзя, а то клиенты приедут ногами колотить за отсутствие тырнетов. пытался ночью перевести когда в онлайне остается 4-5 клиентских модемов (у нас фирмы и организации).

 

примерно за час тщетной попытки перевести:

[root@bgbill accel-ppp]# grep -a magic accel-ppp.log |wc -l
399

 

C magic это бсд- у нее какойто свой путь расчета
у меня линукс fc14

[root@bgbill accel-ppp]# uname -a
Linux bgbill.infonet.uz 2.6.35.10-74.fc14.x86_64 #1 SMP Thu Dec 23 16:04:50 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux

 

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

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

как ещё можно подебажить, какие логи показать?

Edited by lost

Share this post


Link to post
Share on other sites

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

Если это поднимается в качестве 2-го сервера - то можно, т.к. проблемы будут ловиться только у вновь коннектящихся - а их не так и много.

Share this post


Link to post
Share on other sites

это выглядит странно, но у меня в сети два пппое сервера - rp-pppoe через icradius, и accel через bgbill

так вот вновь подключаемые ниразу не попали на accel. если rp-ppoe потушить то все уже бегут на аццел.

хотя оба пппое сервера в одной сети только на разных серверах. еще есть третий на виртуалбоксе в офисе, но их разделяет linux рутер в качестве рутера, но туда пакеты не релеятся даже если pppoe-relay включаю.

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

xeb что то призадумался :)

Share this post


Link to post
Share on other sites
у меня линукс fc14

[root@bgbill accel-ppp]# uname -a
Linux bgbill.infonet.uz 2.6.35.10-74.fc14.x86_64 #1 SMP Thu Dec 23 16:04:50 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux

Я говорил про клиентов. Внутри некоторых роутеров тоже можно встретить МПД

Share this post


Link to post
Share on other sites
Я говорил про клиентов. Внутри некоторых роутеров тоже можно встретить МПД
а ясно, речь идёт о модемах-рутерах?

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

Share this post


Link to post
Share on other sites

ну как и предполагал. натравил rp-pppoe на bgbill, юзера работают без дисконнектов.

выходит аццел имеет какой то необъяснимый баг?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now