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

Хотел бы уточнить, почему изредка при попытке перечитать конфиг акцеля (подавая команду reload в cli или через tcp) в ответ тут же отдается "failed". Но самое печальное при этом, что процесс вываливается из памяти вместе со всеми абонентами (сначала виден как <defunc>, и потом и следа его нет). После перезапуска - все ок.

 

[root@acc45 ~]# echo "reload"|nc 127.0.0.1 2001

failed

 

root@acc45 ~]# echo "pppoe interface show"|nc 127.0.0.1 2001|awk '{ SUM += $2} END { print SUM }'

0

 

[root@acc45 ~]# ps ax|grep acc

1832 ? Zsl 3050:51 [accel-pppd] <defunct>

Edited by Dmitry76

Share this post


Link to post
Share on other sites

Ну это он банально падает при попытке перечитать конфиг.

Какая версия стоит? Вроде как эти баги были пофикшены давным-давно, еще до 1.9.0, после ни разу не вываливался.

Но мы nc не пользуемся, только 'accel-cmd reload'. Может в сетевой консоли какая беда есть.

Share this post


Link to post
Share on other sites

Ну это он банально падает при попытке перечитать конфиг.

Какая версия стоит? Вроде как эти баги были пофикшены давным-давно, еще до 1.9.0, после ни разу не вываливался.

Но мы nc не пользуемся, только 'accel-cmd reload'. Может в сетевой консоли какая беда есть.

Версия стоит 1.10.0 последний релиз. Такой же баг получался и если непосредственно делать в телнете акцеля (2000 порт). Через accel-cmd попробую.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Я также, но не смог найти причину. Причем непонятно что помогло и в чем было дело (фиг отследишь), но стало виснуть намного реже (кажись отключил мультитридовость и еще что-то, но это все шаманство получается).

Share this post


Link to post
Share on other sites

Я также, но не смог найти причину. Причем непонятно что помогло и в чем было дело (фиг отследишь), но стало виснуть намного реже (кажись отключил мультитридовость и еще что-то, но это все шаманство получается).

Кажется, в точку. А именно, выключение мультитредовости.По большому счету для accel оно не нужно, точнее нужно самому userspace процессу. Пока полет нормальный. Релоадил несколько раз - проходит нормально. Может, какие-то проблемы с межпроцессным взаимодействием, может у меня в конфиге что-то накручено - не знаю. Работет, наблюдаю.

Share this post


Link to post
Share on other sites

Беда в том, что хотелось бы автору помочь, но как это отладить?

Под valgrind все еле ползает.

Share this post


Link to post
Share on other sites

Собрать в дебаге, сделать краш путем многократного релоада, посмотреть в gdb что в корке получилось.

Для IPOE мы лечили именно так, вроде полностью вылечили 3-4 фиксами. Для PPPoE возможно древние баги все еще живут.

Share this post


Link to post
Share on other sites
если виснет, то надо подключиться к нему с помощью gdb и посмотреть что там:

gdb -p пид_процесса

info threads

thread apply all bt full

valgrind это таки оверкруто :)

Share this post


Link to post
Share on other sites

если там например повреждение стека - имхо gdb не поможет - и не факт, что оно полностью висит, но вобщем попробую

Share this post


Link to post
Share on other sites

Подскажите, а можно ли сделать такую вещь, чтобы после освобождения порта (речь идет о ppp), он не сразу занимался следующим авторизовываемым абонентом, а по возможности держался свободным какой-то время? Биллинг жалуется, что иногда старт по новой сессии они видят раньше, что стоп по этому же порту от предыдущего юзера. В логах аццеля последовательность правильная: сначала юзер отвалился (например по lcp timeout), а потом на этот порт подключает следующего. И это в одну секунду. С учетом, что авторизация происходит примерно 100-120 мс, то теоретически может быть, что очередь на самом радиусе создается иногда не в том порядке.

Share this post


Link to post
Share on other sites

Не подскажете, если на один влан/интерфейс отдавать несколько подсетей

[ipoe]

...

interface=eth3,range=172.16.104.0/24

interface=eth3,range=172.16.105.0/24

interface=eth3,range=172.16.106.0/24

 

можно так сделать или нужно использовать секцию ip-pool?

 

Так не работает, через запятую тоже... если брать ip-pool, там тоже каждая подсеть под своим именем. Друзья есть ли вообще возможность привязать несколько /24 подсетей на определенный интерфейс?

Share this post


Link to post
Share on other sites

можно через запятую попробовать.

 

если глобально - то можно так:

interface=re:eth1.[1-9][0-9][0-9][0-9]
gw-ip-address=10.251.0.1/21
gw-ip-address=10.250.128.1/20

Share this post


Link to post
Share on other sites

NiTr0

Это ж dhcp-пулы им не отдает, только шлюз меняет принудительно.

Share this post


Link to post
Share on other sites

Debian 7.8

Linux vesta 3.2.0-4-amd64 #1 SMP Debian 3.2.68-1+deb7u3 x86_64 GNU/Linux

accel-ppp-1.9.0_wheezy_amd65.deb

 

Столкнулся с проблемой подвисания. В определенный момент перестает принимать новые подключения (PPTP/L2TP) и передавать accounting по существующим подключениям. Причем через ранее поднятые подключения трафик идет. В чем может быть проблема?

 

В логах из непонятного только такие сообщения:

[2016-03-18 19:03:10]: error: : failed to connect PPTP socket (Operation already in progress)

За сутки их бывает достаточно много.

Share this post


Link to post
Share on other sites

Mar 19 04:49:47 svn kernel: PPP generic driver version 2.4.2
Mar 19 04:49:47 svn kernel: NET: Registered protocol family 24
Mar 19 04:49:47 svn kernel: PPTP driver version 0.8.5
Mar 19 04:49:47 svn kernel: PPTP: can't add protocol
Mar 19 04:49:47 svn kernel: PPPoL2TP kernel driver, V1.0
Mar 19 04:49:47 svn accel-pppd: accel-ppp version 95bef06065ba1a95c3334fcb22cf613776d1433b

смотрю, на centos 6 так до сих пор и не пофиксили багу. Или я что то делаю не так?

 

Mar 19 12:23:55 svn accel-pppd: ippool: open (null): Bad address

еще при старте стала появляться такая строка, раньше ее не было. Или это нормально?

 

А на ядрах 3.10.x. -DKDIR вообще не надо задавать?

# cmake -DKDIR=/usr/src/kernels/3.10.101-1.el6.elrepo.x86_64 -DCMAKE_INSTALL_PREFIX=/opt/accel-ppp-1.10.0-3.10.101 ../accel-ppp-src/
-- The C compiler identification is GNU 4.4.7
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- 'x86_64'
-- Looking for timerfd_create
-- Looking for timerfd_create - found
-- Looking for linux/netfilter/ipset/ip_set.h
-- Looking for linux/netfilter/ipset/ip_set.h - found
-- Configuring done
-- Generating done
CMake Warning:
 Manually-specified variables were not used by the project:

   KDIR


-- Build files have been written to: /root/vpn/build

Share this post


Link to post
Share on other sites

В логах из непонятного только такие сообщения:

[2016-03-18 19:03:10]: error: : failed to connect PPTP socket (Operation already in progress)

 

За сутки их бывает достаточно много.

Проблема есть где то с unit-cache, для теста можно попробовать выключить данный функционал.

Share this post


Link to post
Share on other sites

В логах из непонятного только такие сообщения:

[2016-03-18 19:03:10]: error: : failed to connect PPTP socket (Operation already in progress)

 

За сутки их бывает достаточно много.

Проблема есть где то с unit-cache, для теста можно попробовать выключить данный функционал.

Проблема, похоже, все таки не с этим. Пробовал ставить unit-cache=2000, пробовал совсем отключать unit-cache=0. Ситуация повторяется. Сервер в тесте и терминирует всего 300-400 пользователей. Причем самое печальное в этом, это то, что в момент подвисания интерфейсы не прибиваются и Quagga считает, что маршрут есть и даже если пользователя перебросит на другой сервер, то появится задвоенный маршрут, т.к. у нас несколько серверов с динамической маршрутизацией.

 

Еще один момент заметил в момент подвисания. Если останов делать с помощью /etc/init.d/accel-ppp stop (сигнал там судя по логу SIGTERM=15), то очень долго процедура выполняется. Если в нормальном режиме, то быстрее.

Есть еще варианты что покрутить?

 

UPDATE:

Удалось выяснить достоверно, что accel перестает принимать подключения после следующего сообщения в логе:

[2016-03-23 22:25:28]:  info: ppp180: 9352: second session denied 

При этом в конфиге стоит:

[common]
single-session=deny

 

Вроде как неправильное поведение. Была такая бага?

Edited by SokolovS

Share this post


Link to post
Share on other sites

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

cat /var/log/accel-ppp/accel-ppp.log | grep ppp180

Логи желательно уровня 5, при accel-cmd reload применяется без перезапуска демона.

 

И покажите секцию [ppp] в конфиге accel-ppp.conf

Edited by Dimka88

Share this post


Link to post
Share on other sites

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

cat /var/log/accel-ppp/accel-ppp.log | grep ppp180

Логи желательно уровня 5, при accel-cmd reload применяется без перезапуска демона.

 

И покажите секцию [ppp] в конфиге accel-ppp.conf

 

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

[2016-03-23 17:37:09]:  info: ppp180: connect: ppp180 <--> pptp(192.168.104.35)
[2016-03-23 17:37:12]:  info: ppp180: send [RADIUS(1) Access-Request id=1 <User-Name "10252"> <NAS-Identifier "VPN"> <NAS-IP-Address 192.168.50.8> <NAS-Port 180> <NAS-Port-Id "ppp180"> <NAS-Port-Type Virtual> <Service-Type Framed-User> <Framed-Protocol PPP> <Calling-Station-Id "192.168.104.35"> <Called-Station-Id "192.168.50.8"><Microsoft MS-CHAP-Challenge ><Microsoft MS-CHAP2-Response >]
[2016-03-23 17:37:13]:  info: ppp180: recv [RADIUS(1) Access-Accept id=1 <Session-Timeout 86400> <Service-Type Framed-User> <Session-Octets-Limit 0> <Idle-Timeout 7200> <Framed-Protocol PPP> <Acct-Interim-Interval 180> <Octets-Direction Output> <Framed-IP-Address 91.203.125.195> <Framed-Compression None><Microsoft MS-CHAP2-Success >]
[2016-03-23 17:37:13]:  info: ppp180: 10252: authentication succeeded
[2016-03-23 17:37:16]:  info: ppp180: send [RADIUS(2) Accounting-Request id=1 <User-Name "10252"> <NAS-Identifier "VPN"> <NAS-IP-Address 192.168.50.8> <NAS-Port 180> <NAS-Port-Id "ppp180"> <NAS-Port-Type Virtual> <Service-Type Framed-User> <Framed-Protocol PPP> <Calling-Station-Id "192.168.104.35"> <Called-Station-Id "192.168.50.8"> <Acct-Status-Type Start> <Acct-Authentic RADIUS> <Acct-Session-Id "4f546a2a8c2480d2"> <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> <Framed-IP-Address 91.203.125.195> <Framed-Interface-Id 91:203:125:195>]
[2016-03-23 17:37:16]:  info: ppp180: recv [RADIUS(2) Accounting-Response id=1]
[2016-03-23 22:17:06]:  info: ppp180: send [RADIUS(2) Accounting-Request id=5e <User-Name "10252"> <NAS-Identifier "VPN"> <NAS-IP-Address 192.168.50.8> <NAS-Port 180> <NAS-Port-Id "ppp180"> <NAS-Port-Type Virtual> <Service-Type Framed-User> <Framed-Protocol PPP> <Calling-Station-Id "192.168.104.35"> <Called-Station-Id "192.168.50.8"> <Acct-Status-Type Stop> <Acct-Authentic RADIUS> <Acct-Session-Id "4f546a2a8c2480d2"> <Acct-Session-Time 16797> <Acct-Input-Octets 13483765> <Acct-Output-Octets 167112568> <Acct-Input-Packets 158756> <Acct-Output-Packets 146794> <Acct-Input-Gigawords 0> <Acct-Output-Gigawords 0> <Framed-IP-Address 91.203.125.195> <Framed-Interface-Id 91:203:125:195> <Acct-Terminate-Cause User-Request>]
[2016-03-23 22:17:07]:  info: ppp180: disconnected
[2016-03-23 22:25:25]:  info: ppp180: connect: ppp180 <--> pptp(192.168.98.9)
[2016-03-23 22:25:28]:  info: ppp180: send [RADIUS(1) Access-Request id=1 <User-Name "9352"> <NAS-Identifier "VPN"> <NAS-IP-Address 192.168.50.8> <NAS-Port 180> <NAS-Port-Id "ppp180"> <NAS-Port-Type Virtual> <Service-Type Framed-User> <Framed-Protocol PPP> <Calling-Station-Id "192.168.98.9"> <Called-Station-Id "192.168.50.8"><Microsoft MS-CHAP-Challenge ><Microsoft MS-CHAP2-Response >]
[2016-03-23 22:25:28]:  info: ppp180: recv [RADIUS(1) Access-Accept id=1 <Session-Timeout 86400> <Service-Type Framed-User> <Session-Octets-Limit 0> <Idle-Timeout 7200> <Framed-Protocol PPP> <Acct-Interim-Interval 180> <Octets-Direction Output> <Framed-IP-Address 46.16.25.32> <Framed-Compression None><Microsoft MS-CHAP2-Success >]
[2016-03-23 22:25:28]:  info: ppp180: 9352: second session denied

 

Секция [ppp]

[ppp]
mppe=deny
verbose=1
min-mtu=1280
mtu=1400
mru=1400
ipv4=require
ipv6=allow
ipv6-intf-id=0:0:0:1
ipv6-peer-intf-id=ipv4
ipv6-accept-peer-intf-id=0
lcp-echo-interval=20
lcp-echo-failure=2
lcp-echo-timeout=120
unit-cache=2000

 

Может стоит в этом случае поставить?:

[common]
single-session=replace

Share this post


Link to post
Share on other sites

из man

lcp-echo-interval=n

If this option is given and greater then 0 then lcp module will send echo-request every n seconds.

 

lcp-echo-failure=n

Specifies maximum number of echo-requests may be sent without valid echo-reply, if exceeds connection will be terminated.

 

lcp-echo-timeout=sec

Specifies timeout in seconds to wait for any peer activity. If this option specified it turns on adaptive lcp echo functionality and "lcp-echo-failure" is not used.

 

Используйте или lcp-echo-failure или lcp-echo-timeout. Но по сути получается, что интерфейс уже как бы ушел в down а accel все еще думает что он поднят. Написал по этому поводу xebу, сказал посмотрит.

Edited by Dimka88

Share this post


Link to post
Share on other sites

из man

lcp-echo-interval=n

If this option is given and greater then 0 then lcp module will send echo-request every n seconds.

 

lcp-echo-failure=n

Specifies maximum number of echo-requests may be sent without valid echo-reply, if exceeds connection will be terminated.

 

lcp-echo-timeout=sec

Specifies timeout in seconds to wait for any peer activity. If this option specified it turns on adaptive lcp echo functionality and "lcp-echo-failure" is not used.

 

Используйте или lcp-echo-failure или lcp-echo-timeout. Но по сути получается, что интерфейс уже как бы ушел в down а accel все еще думает что он поднят. Написал по этому поводу xebу, сказал посмотрит.

LCP не должен влиять, вы верно пишите. accel почему то пытается прибить нового клиента к тому же интерфейсу, что и был у только что отключившегося.

Share this post


Link to post
Share on other sites

Есть необходимость в готовом решении авторизации Wi-Fi сети в гостинице

chillispot/nodogsplash. но это обсуждайте в новом топике, не в этом.

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